Job executions

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.

How it works

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:

1. Orchestrator sends a message with the details of the process to the Robot Service on the machine.

2. The Robot Service creates an interactive Windows session on the machine: WinSta0 .

3. The Robot Service starts the Robot Executor in the previously-created session.

4. 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).

Console session

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.

RDP 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

The LoginToConsole option in Orchestrator

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.

Process execution over RDP

The following image summarizes the process execution over RDP:

1. The Robot Service receives the command to start an execution from Orchestrator, via the HTTPS protocol, called WebSockets (SignalR).

2. 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.

3. 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.

4. The tasks are executed within the generated Windows session.

Note:

• 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=True

• Running automations in environments that enforce TCP do not influence your RDP sessions.

Troubleshooting windows sessions

The Robot Service captures a series of session screenshots while setting up your windows session and deletes them once the session is successfully created. If the session setup fails, it saves the screenshots in the %ProgramData%\UiPath\SessionScreenshots directory for future troubleshooting.

Background automations

A background automation can run without interacting with UI elements, and it relies on the background actions to share information. Automations that use UI Automation activities cannot run under a locked screen, therefore they are not suited to run in the background.

Multiple background automations can run concurrently in the same Windows session. Each running automation uses its own set of dependencies. So, if two automations need the same resource but in different versions, each automation uses the specific version it requires.

How it works

1. When a Windows system starts up, it creates a Windows session called Session 0. This session runs various system processes that help the machine to operate and it is not associated to any user. It does not have a user interface and cannot interact with sessions initiated by user logins.

2. The login of a user on that machine creates a new session called User Session. This session is used for running user-specific services.

3. Attended automations, when they run in the background, operate within the user session of the user who initiated them. This way, the Robot can retrieve information and access files that are user-specific.

4. Unattended automations are initiated by the Robot Service and run within Session 0. While running in this session, unattended automations are associated with a specific user, and inherit the permissions of that user. Make sure that those permissions include access to the resources the automation requires, since Session 0 cannot access user sessions.

Running attended automations in the background

Attended automations are designed to run under human supervision. They are triggered by user events, such as mouse clicks or keyboard inputs, and run on the same machine where the user logs in.

A background execution allows the Robot to run automations in the background, without an active user interface, but for a specific user.

If you have an Attended license, you can concurrently execute only one foreground automation (with UI interaction), and multiple background automations (without UI interaction).

Running unattended automations in the background

Unattended automations are designed to run natively in the background, without a UI interaction or human supervision. This type of automations usually execute within a Windows session, under the Local Service.

Microsoft applications, such as Excel, Word, or PowerPoint, operate in user sessions. For this reason, unattended automations running in the background might have issues with these apps.

Running several unattended automations at once consumes a separate Unattended license for each one.

Transitioning background to foreground

You can transition a background automation to a foreground one, by using the Use Foreground activity.

Using Orchestrator credentials

To use login credentials that are defined in Orchestrator, you need to configure the UIPATH_HEADLESS_WITH_USER system environment variable on the robot machine and set the value to True.

Linux robots

Before the introduction of Linux Robots, UiPath Robots were confined to Windows operating systems, as they were built to interact with Windows-specific technologies.

To expand your automation scope beyond Windows-exclusive operability, we introduced Linux Robots.

A Linux Robot is a version of the Robot built to function in Linux environments, therefore making cross-platform automation possible.

The Robot, together with the Linux operating system and other software dependencies, are bundled into a Docker image. When you use this image to start a Docker container, the resulting container would be a standalone, functional Linux environment where the Robot can operate.

Note: The Docker image is based on the Ubuntu Linux version of the mcr.microsoft.com/dotnet/runtime. All files required by the application are found in the /application/ directory.

High-density robots

In a UiPath High-Density (HD) environment, commonly known as HD robots, multiple robots run concurrently under different user accounts on Windows Server machines.

Because each user has its own unique environment and access permissions,you must provide each robot with user-specific paths to navigate the system or to access certain files or folders. Different paths considerations must be made depending on the Robot operational mode:

Robot mode	Path type	Considerations for multiple robots using the same path
Service mode	Local path	No restrictions
	Network path	Not supported when Secure XAML is used. Service mode robot installed on separate machines must have its own folder on the network. Mapped network paths, such as Z:\Packages, are not supported. Use non-mapped path, such as \\server\Packages.
User Mode	Local path	You must add the NUGET_SCRATCH environment variable on the robot machine, and provide it with a value other than the NuGet installation one. This sets a different path for storing temporary NuGet files, to prevent potential conflicts when multiple robots attempt to use NuGet simultaneously. The new temporary folder should be exclusive for the NUGET_SCRATCH variable. The user accounts under which robots run must have read and write access to both NuGet folders on the machine.
	Network path	The path must include the machine name and username. <packageSettings> <add key="packagesInstallationFolder" value="\\NetworkServer\SharedFolder\UiPath\Packages\" /> </packageSettings>

HD robots particularities

A High-Density environment has the following particularities:

• Requires Windows Server or Azure Windows 10 Enterprise Multi-session OSs.

• Requires the LoginToConsole parameters to be set to false for all robots.

• You can execute the same automation with all Robots at the same time.

• You can execute different automations with all Robots at the same time.

• In Service Mode installations, all robots operating on the machine connect to the same Orchestrator instance.

• If the Robot Service is already active, you can add a new robot on the machine without restarting the service.

Citrix Apps virtualization

Using Citrix Apps means that UiPath software, such as Robot or Assistant, is set up on a central server and then delivered to your device through the Citrix virtualization technology. This allows you to use Robot and Assistant on virtual machines and run attended automations in Citrix environments, without installing the UiPath software on your local machine.

When started through Citrix, both Assistant and Robot operate on the same virtual machine, and inherit the permissions of the logged-in Citrix user. You can manage Assistant and Robot from your local machine.

Any application the Robot uses must run on the same virtual machine, and you can see the corresponding interface on your computer.

The following image describes how a Citrix environment works: