We are seeking guidance on expanding our RPA infrastructure safely and following UiPath’s recommended practices. Currently, we have:
10+ automation projects
3 VMs running 3 Unattended Robots
Recently purchased a fourth robot
Due to the increasing number of automations that may run in parallel, we need an additional execution environment.
Our Cybersecurity team prefers not to increase the number of VMs for operational and security reasons. They suggested using a single Windows Server with multiple isolated RDP sessions, each running one Unattended Robot under a separate Windows user account. We understand UiPath supports multiple robots on a Windows Server if each runs under its own profile.
Before proceeding, we’d like to confirm:
Is running multiple Unattended Robots in parallel on a single Windows Server via separate user accounts and RDP sessions a recommended and supported approach?
Are there any limitations, known issues, or risks when running UI automation (including browser and UI element interactions) concurrently in multiple RDP sessions on the same server?
What are the best practices or configuration guidelines for:
User session isolation
Server resource allocation
Browser automation performance
Security hardening
Avoiding session interference
Would you recommend testing this setup on a dedicated test server before production deployment?
We aim to follow UiPath’s officially supported architecture to ensure performance and security. Any guidance or references to official documentation would be greatly appreciated.
Yes, this is a good approach requires less VM management. We also have recently moved to this setup. Earlier we had more than 16 VMs but now we only have 5 multi-login windows servers and we are able to run our automations in parallel.
It’s been close to 6 months since we moved to this setup and it’s working pretty good for us.
The only challenge we faced frequently was wherein we needed to change our multiple automations for kill activity. Now that there are multiple accounts logged in on a single sever, kill activity specifically needs to be applied to a current session otherwise error is thrown for processes.
Apart from that, you just need to ensure higher configuration for this single windows server to be able to run processes in parallel without cpu utilization going full very quickly.
This has been a good change for us and we have more than 150 processes running in production.
And wrt testing, yes that would be advised. We also did regression of our processes before actually running moving everything in there. You will also have to go through multiple requests to get the urls whitelisted if there are any you are using that requires whitelisting. In our case there were number of such sites.
Get High Density setup enabled on your server and you should be good to go.
Yes, this is pretty much standard approach used.
There could be interference when using activities like Kill Process. Make sure your activities being used in the automation are configured to Applied To = Current User
If it’s set to All it will kill the application for all the users on the server. So wherever available to configure such settings, use current user or current session only
Everything gets handled by windows session manager, nothing to be done manually.
Thank you for all the information and experience you shared. Is the use of Density Robots required, or is it compatible with our existing robots under the enterprise license? Any additional details about this would be appreciated.
Thank you for all the information you shared. Is the use of Density Robots required, or is it compatible with our existing robots under the enterprise license? Any additional details about this would be appreciated.
