- 基本情報
- UiPath Robot について
- UiPath Assistant
- インストール要件
- Installing robots for unattended automations
- Configuring robots for unattended automations
- Connecting robots for unattended automations to Orchestrator
- 高密度ロボット用の Windows Server を設定する
- Robot をプロキシ サーバー経由でリダイレクトする
- Implementing authentication
- Adjusting registry settings for execution in minimized RDP windows
- Using network locations
- Linux 環境のロボットを設定する
- パッケージの署名検証を設定する
- パッケージ フォルダーとネットワーク パスを設定する
- アクティビティ フィードを設定する
- Deploying unattended automations
- Installing robots for attended automations
- Configuring robots for attended automations
- Integrations
- トラブルシューティング
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&%3Bq=100)
ジョブの実行
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=True
UIPATH_DNS_MACHINENAME=True -
Running automations in environments that enforce TCP do not influence your RDP sessions.
%ProgramData%\UiPath\SessionScreenshots
directory for future troubleshooting.
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.
-
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.
-
The login of a user on that machine creates a new session called User Session. This session is used for running user-specific services.
-
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.
-
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.
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).
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.
You can transition a background automation to a foreground one, by using the Use Foreground activity.
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.
mcr.microsoft.com/dotnet/runtime
. All files required by the application are found in the /application/
directory.
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 |
---|---|---|
サービス モード |
ローカル パス |
No restrictions |
ネットワーク パス |
| |
ユーザー モード |
ローカル パス |
|
ネットワーク パス |
The path must include the machine name and username.
|
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 tofalse
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.
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:
- Windows セッション
- 動作のしくみ
- Console session
- RDP session
- The LoginToConsole option in Orchestrator
- Process execution over RDP
- Troubleshooting windows sessions
- Background automations
- 動作のしくみ
- Running attended automations in the background
- Running unattended automations in the background
- Transitioning background to foreground
- Using Orchestrator credentials
- Linux 環境のロボット
- 高密度ロボット
- HD robots particularities
- Citrix App を使用した仮想化