- Getting started
- Understanding UiPath Robot
- UiPath Assistant
- Installation requirements
- Installing robots for unattended automations
- Configuring robots for unattended automations
- Deploying unattended automations
- Connecting robots for unattended automations to Orchestrator
- Setting up Windows Server for high-density robots
- Redirecting robots through a proxy server
- Implementing authentication
- Adjusting registry settings for execution in minimized RDP windows
- Using network locations
- Setting up Linux robots
- Configuring package signature verification
- Setting up package folders and network paths
- Configuring activity feeds
- Installing robots for attended automations
- Configuring robots for attended automations
- Integrations
- Troubleshooting
Windows sessions
The Robot executes automations in a Windows session, starting a console or an RDP session based on the LoginToConsole setting in Orchestrator. While all robots can connect to both session types, High-Density Robots use only RDP sessions.
A Windows session is always created on the physical or virtual machine where the Robot is installed. Orchestrator does not directly create Windows sessions. Instead, when a job starts in Orchestrator, the following sequence takes place:
-
Orchestrator sends a message with the details of the process to the Robot Service on the machine.
-
The Robot Service creates an interactive Windows session on the machine: WinSta0 .
-
The Robot Service starts the Robot Executor in the previously-created session.
-
The Robot Executor then starts the execution of the automation in that session.
The Robot Service connects the command to execute an automation to the actual execution.
Without any pending jobs, the Robot Service enters an idle state and does not require an active Windows session. The idle state allows for constant communication with Orchestrator, thus ensuring immediate execution when a command is received. The communication is done through WebSockets (SignalR).
This is the default execution environment.
In a console session, the Robot executes jobs while a user is logged in on the hosting machine. This type of session is generally recommended for:
-
attended automations, because it allows interacting with any open application, mimicking the actions of a human user.
-
automations without a custom screen resolution, since console sessions use the graphic settings of the hosting machine or those specified by the VDI hypervisor.
-
running one automation at a time, as a new execution starts once the previous one finishes and the executing robot disconnects from the active session.
In a Remote Desktop Protocol (RDP) session, the Robot executes jobs when a user remotely logs into a machine. This type of session is generally recommended for:
-
unattended automations, because it allows executing tasks that do not require user interaction, or when the machine is locked or the user is logged off.
-
automations that require a custom screen resolution, by setting the resolution width, height and depth in the Robot Settings tab in Orchestrator.
-
Windows machines, to run one automation at a time, as a new execution starts once the previous one finishes and the executing robot disconnects from the active session.
-
Windows Server machines, to run multiple automations concurrently:
-
for the same user across their different RDP session
-
for multiple users, each in their RDP session
-
When you define or edit a robot account in Orchestrator, you can select the type of session used by your robots to run automations. To do that, use the Login To Console option.
On the Tenant > Manage Access > Robot accounts > Robot Settings page in Orchestrator, the Login to Console option is disabled by default. However, the robot executes tasks in a console session by default.
To activate the console session, turn on the Login To Console option and select Yes. If a job starts from Orchestrator during an active RDP session, the RDP session is automatically terminated.
To activate the RDP session, turn on the Login To Console option and select No. If a job starts from Orchestrator and a RDP session is already active, the robot executes the job within the active RDP session.
The following image summarizes the process execution over RDP:
-
The Robot Service receives the command to start an execution from Orchestrator, via the HTTPS protocol, called WebSockets (SignalR).
-
The Robot Service then creates a Windows session on the machine using RDP. This RDP session is created for the user assigned to the robot.
-
Once the RDP session is created, the Robot Service spawns a Robot Executor within that session. The Robot Service and the Robot Executor communicate to each other through Named Pipes. This method allows the Executor to know exactly which tasks need to be run.
-
The tasks are executed within the generated Windows session.
-
The Robot Service uses RDP exclusively to start a Windows Session on the machine where the Robot is installed. It does not use RDP to connect Orchestrator to the machine on which the process is executed, nor for communicating with other components outside the machine.
-
To run unattended automations in environments where RDP sessions require Kerberos authentication, you need to use the DNS host name for the localhost value. To do that, add the following environment variable on your machine:
UIPATH_DNS_MACHINENAME=TrueUIPATH_DNS_MACHINENAME=True -
Running automations in environments that enforce TCP do not influence your RDP sessions.
%ProgramData%\UiPath\SessionScreenshots directory for future troubleshooting.
