Windows Sessions

The UiPath Robot executes processes in an interactive Windows session. There are two types of Windows sessions the Robot can start:

Console Session
FreeRDP Session

The type of session the Robot starts is determined by the LoginToConsole option. By default, this option is enabled.

All Robot types, regardless of license or deployment, can connect to both types of sessions. Please note that High-Density Robots only connect to a FreeRDP session.

Note: Robot settings configured in Orchestrator override those configured in the UiPath.settings file.

A Windows session is always created on the Robot machine, regardless of the type of session. In other words, a session is created from the Robot machine to the same machine, and not from Orchestrator to the Robot machine.

When a process is started from Orchestrator, a Windows session is created as follows:

Orchestrator sends a message with the process details to the Robot Service.
The Robot Service creates an interactive Windows session on the machine.
The Robot Service starts the Robot Executor in that session.
The Robot Executor starts the process execution.

The process is the same for both console and FreeRDP sessions.

If you are not connected to Orchestrator, the LoginToConsole option can only be configured from the UiPath.settings file.

Console Session

By default, the Robot connects to a Console session. Only one Console session can be active at a time on a machine. If previously set otherwise, you can have the Robot connect to a Console session by enabling the LoginToConsole option, through one of the methods below:

In the UiPath.settings file, set the LoginToConsole parameter to true.
When creating or updating a Robot in Orchestrator, set the LoginToConsole value to Yes from the Settings tab. This means that the configuration from the UiPath.settings file is used. To set the desired value from Orchestrator, you must first enable the LoginToConsole option.

Note: It is recommended to use this connection type for processes which do not require a custom resolution.

There can only be one active console session at a time on a machine. This means that only one Robot can execute processes on that machine at a time. When execution is finished, the session is disconnected and another Robot can start a session and execute processes on that machine.

If there is an active RDP session when a job is started from Orchestrator, the active RDP session is terminated.

A Console session uses the resolution specified by the default settings of the graphics card on the machine. With VDI's (such as Citrix, Hyper-V, VMware), the resolution is usually specified by the hypervisor which manages the VDI. Please note that you cannot set a custom resolution.

FreeRDP Session

In a FreeRDP session, the Robot creates a virtual Remote Desktop session on the machine it runs. You can have the Robot connect to a FreeRDP session by disabling the LoginToConsole option, through one of the methods below:

In the UiPath.settings file, set the LoginToConsole parameter to false.
When creating or updating a Robot in Orchestrator, set the LoginToConsole value to No from the Settings tab. By default, the LoginToConsole option is disabled. This means that the configuration from the UiPath.settings file is used. To set the desired value from Orchestrator, you must first enable the LoginToConsole option.

Note: High-Density Robots require connection via a FreeRDP session.

On a Windows Workstation there can only be one active FreeRDP session. This means that only one Robot can execute processes on that machine at a time. When execution is finished, the session is disconnected and another Robot can start a session and execute processes on that machine.

On a Windows Server, however, there can be an active FreeRDP session for each user of the machine, or even multiple sessions for the same user. This means that multiple Robots can simultaneously execute processes on that machine, each for its designated user. In this scenario, Robots can also execute processes for a user on multiple sessions, but they must not rely on Hardware events (such as UIAutomation activities).

If a job is started from Orchestrator and a FreeRDP session is already active, the process is executed in that session.

It is recommended to use this connection type if your automation process requires a custom resolution. You can set a custom resolution by modifying the ResolutionWidth, ResolutionHeight, and ResolutionDepth parameters in one of the following locations:

From the file.
From the Settings Tab when you create or update a Robot in Orchestrator.

Process Execution Over RDP

The main communication means between an execution command and the actual process execution is the Robot Service. If no process needs to be executed, the Robot Service idly stands by on the Windows machine and does not require an active Windows Session. This is done to ensure constant open communication with Orchestrator and to be able to immediately start a process if a command is received. The communication is done through HTTPS, more specifically through WebSockets (SignalR).

Please note that the Windows Session is spawned through RDP only if value of the LoginToConsole property is false.

When a start process command is sent to the Robot Service, it creates a Windows Session on that machine through RDP for the Robot's user. After that, the Robot Service spawns a Robot Executor inside the newly-created session. The Executor and Service then communicate through Named Pipes, and the Executor knows exactly what to execute. The process is then executed inside the Windows Session.

Note: The Robot only uses RDP to start a Windows Session. It is not used to connect from Orchestrator to the machine on which the process is executed, nor for communication with other components outside the machine.

Architecture Overview

When a job is started from Orchestrator, the Robot connects to the WinSta0 Windows session based on your session connection configuration. A WinSta0 session (interactive session) can only have one active desktop at a time.

A process is associated with the interactive desktop it's started in and cannot access other desktops during execution. An active desktop ensures the following: