About 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
• RDP 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 RDP 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:

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

The process is the same for both console and RDP 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. 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:

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.

RDP Session

In a RDP session, the Robot creates a virtual Remote Desktop session on the machine it runs. You can have the Robot connect to a RDP 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 RDP session.

The Robot uses FreeRDP to create the virtual Remote Desktop session.

On a Windows Workstation there can only be one active RDP 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 RDP 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 RDP 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 UiPath.settings file.
• From the Settings Tab when you create or update a Robot in Orchestrator.

Architecture Overview

When a job is started from Orchestrator, the Robot connects to the WinSta0 Windows station based on your session connection configuration. A WinSta0 station (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:

• Processes can receive user input via Hardware events
• Processes can receive user input via Software events
• The machine display is rendered and continuously updated

A disconnected user session cannot have an active desktop. If a desktop is not active in an interactive session, the following occurs:

• Processes cannot receive user input via Hardware events
• Processes can receive user input via Software events
• The machine display is not rendered