- Release Notes
- Getting Started
- UiPath Assistant
- Installation and Upgrade
- Robot Types
- Robot Components
- Licensing
- Connecting Robots to Orchestrator
- Processes and Activities
- Logging
- Robot JavaScript SDK
- Specific Scenarios
- Windows Sessions
- Login Using Thales Luna Credential System
- Login Using NShield Key Storage Provider
- Redirecting Robots Through a Proxy Server
- Executing Tasks in a Minimized RDP Window
- Using Mapped Network Drives
- Stopping a Process
- Disable Stop Button
- Custom Package Folders and Network Paths
- CrowdStrike Integration
- Troubleshooting
- Unresponsive Robot Over RDP
- Duplicate Execution Logs
- Frequently Encountered Robot Errors
- Increased Process Execution Duration
- Enforced Package Signature Verification
- Message Too Large to Process
- Errors When Running as Administrator
- NuGet Packages Not Accessible After Migration
- User Access Control Prompt and UI Automation Activities
- .NET6 Projects Fail to Run
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.
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.
UiPath.settings file.
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.settingsfile, set theLoginToConsoleparameter totrue. - When creating or updating a Robot in
Orchestrator, set the LoginToConsole value to
Yesfrom the Settings tab. This means that the configuration from theUiPath.settingsfile 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.
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.settingsfile, set theLoginToConsoleparameter tofalse. -
When creating or updating a Robot in Orchestrator, set the LoginToConsole value to
Nofrom the Settings tab. By default, the LoginToConsole option is disabled. This means that the configuration from theUiPath.settingsfile 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.
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.
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).
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.
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:
- 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
