orchestrator

latest

false

Getting started
- Introduction
- Robots
  - Robot Statuses
  - Robot Settings
- Auto Updating Client Components
- Time-to-live Periods
- Orchestrator Outbound IP Addresses
- Notifications
Best practices
- Organization Modeling in Orchestrator
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Unattended automation
  - Accessing the unattended robot setup
  - Useful concepts in unattended automation
  - How is unattended automation performed
- Organizing Resources With Tags
- Orchestrator Read-only Replica
- Exporting grids in the background
Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Robots
- Folders
- Monitoring
- Access control
- Configuring automation capabilities
  - Enabling personal automations
    - Enabling individual users to run personal automations
- Machines
- Packages
- Audit
- Credential Stores
  - Integrating credential stores
  - Managing credential stores
- Webhooks
  - Types of Events
  - Managing Webhooks
- Licensing
  - Managing Your Licenses
- Settings
  - Robot Security Tab
  - Scalability Tab
    - SignalR (Robots)
Cloud robots
- Automation Cloud™ Robots - VM
- Configuring VPN for cloud robots
- My notifications
Folders Context
- About the Folders Context
- Home
Automations
- About Automations
Processes
- About Processes
- Managing Processes
- Managing Package Requirements
- Recording
Jobs
- About Jobs
- Managing Jobs
- Job States
- Working with long-running workflows
- Running Personal Remote Automations
- Process Data Retention Policy
Apps
- About Apps
- Publishing an App to a Tenant
- Managing Apps
- Running a Deployed App from a Folder
Triggers
- About triggers
- Managing triggers
- Managing Non-Working Days
- Using Cron Expressions
  - Triggering jobs on the last day of the month
Logs
- About Logs
- Managing Logs in Orchestrator
- Logging Levels
Monitoring
- About Monitoring
- Machines
- Processes
- Queues
- Queues SLA
Queues
- About Queues and Transactions
- Bulk uploading Queue Items using a CSV file
- Managing Queues in Orchestrator
- Managing Queues in Studio
- Managing Transactions
  - Editing Transactions
  - Field Descriptions for the Transactions .csv File
- Review Requests
Assets
- About Assets
- Managing Assets in Orchestrator
- Managing Assets in Studio
- Storing Assets in Azure Key Vault (read only)
- Storing Assets in HashiCorp Vault (read only)
- Storing Assets in AWS Secrets Manager (read only)
Storage Buckets
- About Storage Buckets
  - CORS/CSP Configuration
- Managing Storage Buckets
Test Suite - Orchestrator
- Test Automation
- Test Cases
  - Field Descriptions for the Test Cases Page
- Test Sets
  - Field Descriptions for the Test Sets Page
- Test Executions
  - Field Descriptions for the Test Executions Page
- Test Schedules
  - Field Descriptions for the Test Schedules Page
- Test Data Queues
- Testing Data Retention Policy
Resource Catalog Service
- About Resource Catalog Service
Authentication
- About Authentication
Integrations
- About Input and Output Arguments
  - Example of Using Input and Output Arguments
Classic Robots
- Robots
- Environments
  - Managing Environments
- Jobs
- Triggers
- Monitoring
  - Robots
- Resources
Troubleshooting
- About Troubleshooting
- Frequently Encountered Orchestrator Errors

Orchestrator User Guide

DELIVERY:

Automation Cloud Automation Cloud Public Sector Automation Suite Standalone

Last updated Nov 20, 2024

How is unattended automation performed

The steps below describe the necessary actions for running successful unattended automations. We are aware that such large-scale processes are managed differently by each company, which means that the order in which the steps are performed will vary. Thus, the order described below is merely a recommendation of how a successful setup could occur.

1. Setting up the infrastructure

The following steps help you set up your host machine for running unattended automations.

1.1. Setting up the host machines that will run the unattended robot

The host machines that will run unattended automations are connected to an Orchestrator machine template, via a machine key or a set of client credentials. This allows automations to be managed from Orchestrator.

Several host machines can be connected to the same machine template. It is, however, a good practice to maintain separate templates for each set of host machines that share the same physical setup, namely:

They have the same configuration.
They contain the same applications, in the same versions, installed under the same paths on each machine.
The users that need to log in to these applications have the same access rights.

To ensure that your host machines run automations as smoothly as possible, there are some important things to keep in mind:

All necessary resources, such as applications and services, should be installed on the relevant host machines and grouped in a logical manner, according to the processes that you want to run.
All robot accounts assigned to a folder must be able to log in to every host machine associated to the machine template that is assigned to that same folder.

All robot accounts assigned to a folder must be able to log in to every host machine associated to the machine template that is assigned to that same folder.

The host machine must match the Hardware and Software Technical Requirements, and its screen saver functionality must be disabled.

1.2. Installing a service mode robot on host machines

A Service Mode Robot is the recommended option for unattended automation scenarios and large-scale platform deployments. When a process is executed, the Robot is launched by the Windows Service Control Manager under the Local System, which means that it has all the rights of a machine administrator and it can run with the same rights as the user under which it is registered.

There are two ways of installing the Robot:

Via the command line, using the ADDLOCAL parameter - to install the Robot in service mode, you need to also add the RegisterService option. This is the recommended choice for unattended Robots, especially where large-scale deployments are concerned.
Along with UiPath® Studio, via UiPathStudio.msi - the Robot is deployed by default in service mode.

We recommend using non-persistent VDIs, which help ensure that all your host machines follow a consistent configuration, with minimum effort.

1.3. (Optional) Installing UiPath Studio on the unattended machine

Important:

This step is only necessary for developers that run unattended automations and that might want to troubleshoot any issues.

You can also debug your processes directly from the UiPath Assistant, by enabling a troubleshooting session.

In order to debug unattended automations on an unattended machine, you need to install UiPathStudio.msi on that machine. If you opt for the Quick Setup during installation, the Robot is deployed in User Mode, meaning that it runs under the user that started it, and has the exact rights as that particular user.

The UiPathStudio.msi installer can be downloaded from the Resource Center or directly from the Automation Cloud^TM Public Sector home page.

In order to start a job from Orchestrator on a local user (user mode robot), the Windows user must be logged on the machine. The User Mode Robot cannot run concurrent jobs on different users, regardless of whether the Robot is installed on a Windows Server or not.

2. Setting up Orchestrator

The following steps help you configure the Orchestrator objects that are necessary for running successful unattended automations.

2.1. Creating a machine template

A machine template is the recommended type of Orchestrator machine for unattended automations. Machine templates provide the computational power for executing the job. They help you deploy several machines by defining the configuration once and then using a single set of client credentials to allow multiple robots to connect to Orchestrator.

At the tenant level, click Machines > Add machine > Machine template. The Machine template window is displayed.
Configure the machine template and assign it minimum one unattended runtime. Runtimes are a type of service license dedicated to unattended automations, and are taken from the tenant pool and assigned at the machine template level. With one runtime, you can run one automation on a host machine. With two runtimes, you can run two automations on the same host machine or one automation on two host machines.
Click Provision.
Copy the machine key and/or the client ID and client secret for later use.

This is an example of a machine template which serves as the basis for an efficient optimization strategy:

Your infrastructure consists of:

one Windows desktop
one high-density Windows Server
three Linux machines

No. of processes	Compatibility (set in Studio)	Machine Template Settings (set in Orchestrator)	Why
4 background processes	Windows - Legacy (.NET Framework 4.6.1)	We connect one Windows desktop using template A which we define as follows: Process type = Background onlyProcess compatibility = Windows onlyUnattended Runtimes = 4	.NET Framework 4.6.1 processes can only run on Windows machines. Background processes can run concurrently under the same account. Template A has 4 runtimes assigned, allowing execution of 4 jobs concurrently.
6 background processes	Cross-platform (.NET 5.0 or higher)	We connect 3 Linux machines using template B which we define as follows: Process type = Background onlyProcess compatibility = Cross-platform onlyUnattended Runtimes = 2	.NET Framework 5.0 processes can run on any type of machine. Template B only allows execution of background processes on the connected Linux machines. Background processes can run concurrently under the same account. Template B has 2 runtimes assigned, allowing execution of 2 jobs concurrently on each connected Linux machine: 2 jobs x 3 machines results in an execution capacity of 6 concurrent jobs.
10 foreground processes	Windows (.NET 5.0 or higher)	We connect the Windows server using template C which we define as follows: Process type = Foreground onlyProcess compatibility = Windows onlyUnattended Runtimes = 10	.NET Framework 5.0 processes can run on any type of machine, Linux machines included, but because these are foreground processes developed for Windows, you need to run them on Windows machines. One account can run one foreground process at a time. An HD Windows Server allows opening multiple account sessions. Template C has 10 runtimes assigned, meaning 10 sessions are opened simultaneously, allowing execution of 10 foreground jobs concurrently.

2.2. Creating a robot account

The account is the identity that provides permissions and credentials required for the robot to consume Orchestrator resources and log into host machines respectively. It is recommended to use a robot account, which is ideal when you need to run back-office unattended processes that should not be the responsibility of any particular user.

To create a robot account, follow the steps corresponding to your environment:

2.3. Creating the folder structure

It is highly recommended to build a folder structure that’s centered around the processes that you want to run. That is to say each process should have it own specialized folder(s) containing all the assets that are needed for it to run correctly and without interruptions.

2.4. Assigning objects to folders

The machine template, the robot account, the automation process, and any other elements needed for an iteration of unattended automation should be placed in the same folder. This is very important if you want to ensure uninterrupted processing.

Assigning a robot account to a folder

At the Orchestrator tenant level, click Folders, select the desired folder for your automation (which must be the same as the one where you added the machine template), then click Assign Account/Group.
In the Account or Group name field, start typing the name of the account you have just created and select it from the list.
From the Roles list, select Automation User.
Click Assign.

Assigning a machine template to a folder

Select the folder that will contain all elements pertaining to this automation, then click Settings > Machines > Manage Machines in Folder.
Click Add machine > Machine template. The Manage machines in folder window is displayed.
Select the checkbox to the left of the desired machine template, then click Update. The machine is added to the folder.

3. Connecting the unattended robot to Orchestrator

In unattended automation, the host machine is connected and licensed in unattended mode, thus executing processes through Orchestrator. This connection is established through either a machine key or a set of client credentials, via the command line. The machine key or the credentials are generated in Orchestrator when you create the machine template. This is dependent upon the robot security settings.

To find out how to achieve this connection, visit this section.

4. Executing the unattended automation

The following sections walk you through the necessary steps to actually run the automation that you have been preparing so far.

4.1. Creating an automation project in UiPath Studio and publishing it to Orchestrator

Let’s say that we need to make a backup of log files on a server every day at 9 AM. To do that, we need to copy the log file from that day to another folder. In this example, we copy a file called "logs.txt" from the "Logs" folder to the "Old Logs" folder, overwriting the backup each time.

In Studio, create a new process, add the Copy File activity, add the necessary file and folder paths, and select the Overwrite option, so that the newly copied file can replace the previous file every day.
From Studio, publish the package to Orchestrator:
1. In the ribbon, click Publish to display the Publish Process window.
2. In the Publish properties tab, enter a name for the package.
3. In the Publish options tab, for the Publish to option, select one of these options:
  - Orchestrator Tenant Processes Feed - publish at the tenant level. From here, you will need to manually create a process in a folder of your choosing. Any organisation user will have access to the package when published in this location.
  - Orchestrator Personal Workspace Feed - publish at the personal workspace level. A process is created automatically, and placed in the personal workspace folder. Only the personal workspace’s user has access to the packages stored in this location.
  - Custom - publish to a specific folder that is different to the personal workspace.
4. Click Publish.

4.2. Creating a process in Orchestrator

Orchestrator processes are created based on packages published from UiPath Studio.

Important: The machine template, the robot account, the automation process, and any other elements needed for an iteration of unattended automation should be placed in the same folder.

Select the folder that will contain all elements pertaining to this automation, click Home > Processes or Automations > Processes, then click Add Process.
From the Package Source Name list, select the package you have just uploaded, then click Next and configure any settings in the following screens, such as any requirements or a display name, then click Create.

4.3. Running the automation

You can either run your automation directly or schedule it to run by setting up a trigger.

Direct run

You can run a job from two places within the target folder of your automation:

1.a. Click Automations > Jobs > Start. In the job settings page that opens, from the Process Name list, select the process you created at step 2.

1.b. Click Automations > Processes, then click the Run a Job symbol next to the desired process. This opens the job settings page with the desired process already displayed in the Process Name field.

2. Configure any other settings in this page, then click Start.

Scheduled run

Triggers allow you to execute jobs in a preplanned manner, either at regular intervals (time triggers) or whenever new items are added to your queues (queue triggers).

Triggers constitute a folder-scoped asset, which means that you can create them by accessing Automations > Triggers from the folder level. Just like all other assets pertaining to an automation, triggers must also be part of the same folder as the corresponding process used for running the unattended automation, as well as the robot account and machine template created for that purpose.

Triggers are created based on an existing process, and they benefit from the same execution priorities as those available at the process and job levels.

If you would like to schedule a recurrent time to start a job, you can create a time trigger.

If you would like to start a process upon trigger creation or whenever you add a new item to a queue, you can create a queue trigger.

How are Robot sessions managed

Robot session activity is available in the Unattended sessions page, accessed via Monitoring, at the tenant level.

When the Robot is disconnected, its status in this page changes, and its license is released, thus becoming available for another Robot/process.

Robots are disconnected when the host machine is turned off. They are, however, also deemed unresponsive and disconnected when they do not send a successful heartbeat for two minutes.

How are jobs allocated

Job allocation is performed based on the capabilities of the parts involved in the automation, namely the robot account, the process, the job, and the host machine.

Orchestrator picks up the following information in order to decide how to allocate jobs:

I. It checks the folders for any pending jobs, which it orders based first on priority, then on creation time. Jobs with higher priority and jobs with an older creation time re picked up first.

II. It checks the process type (which is set in Orchestrator):

Background process - it can run under any identity
Foreground process - the Robot checks for any available credentials, meaning available users within that folder
All - both background and foreground processes.

III. It checks the process compatibility (which is set in Orchestrator):

Windows only - Windows-compatible processes only
Cross-platform only - cross-platform processes only
All - both Windows-compatible and cross-platform processes

IV. It checks the job compatibility (which is set in Studio, at creation time):

Windows-legacy (.NET Framework 4.6.1) - can only run on Windows machines
Cross-platform (.NET 5.0 or higher) - can run on any type of machine
Windows (.NET 5.0 or higher) - can run on any type of machine, Linux machines included; however, since these are foreground processes developed for Windows, they need to be run on Windows machines.

V. It checks the infrastructure of the host machine for the compatible Robot version.

On this page