Orchestrator - 2021.10

Automation Suite

We're excited to announce a new deployment option for Orchestrator. Meet UiPath Automation Suite, a bundle designed to offer a consistent, painless, and elegant experience when installing, upgrading, and managing UiPath web products, with Orchestrator being among them. For more on this, see the Automation Suite guide.

Release date: 25 October 2021

The word "automaton" is derived from the Greek word "αὐτόματον," which means "self-acting." In the world of tech nowadays, the term "automation" gets thrown about sometimes with little consensus on a singular meaning. And so, we end up with unattended automation, attended automation, background automation, foreground automation, remote automation, service automation, until the word itself seems incredibly versatile.

In part that’s because the term "automation" has evolved alongside the computing world, reaching new heights every day, making us participants in an age of exponential change: U and I witnessing automation on its PATH to zenith.

UiPath strives to break all the barriers between attended and unattended automation, making all of us potential beneficiaries of remote automation.

New Design System for Orchestrator

With this release, Orchestrator adopts the new Apollo design system. What this means for you is consistency in the user interface across Orchestrator and other UiPath products, easier navigation, and some user interface improvements.

While Orchestrator itself remains functionally the same, there are a few things you should know right off the bat:

A header (a) has been added which remains visible on all pages so that you retain access to the following controls: the user menu (b) and quick options (c).
Some controls have moved out of Orchestrator menus to the new header. The user menu (previously in the top right in Orchestrator) is now positioned in the top left. This menu includes the options for user language selection, theme selection, and the sign out option:

New Portals for System Administrators

Also an effort to improve the user experience has been to better organize host-level options. As a result, system administrators now have a cleaner Identity Management portal which displays the integrated apps, a host-level Management portal for configuring global settings for your installation, and the Orchestrator host portal, which now only includes those host-level settings that are specific to Orchestrator itself.

Don’t worry, we didn’t make any dramatic changes functionally, but we hope that the changes we did make can help you to find things more easily going forward.

For more information about the host portals and the options that are now available in each, see Host administration portals.

Unattended Automation

An increasing range of technologies are becoming suitable candidates for automation each day. This comes with its fair share of challenges, which, more often than not, require careful planning and very good control over the infrastructure that makes it all possible.

Let's dig into the challenges administrators face when dealing with unattended automation across its whole spectrum and how UiPath addresses these challenges with a series of new features.

Robot Accounts for Unattended Use

A new type of account is available in Orchestrator starting with this release: the robot account.

This is a non-user identity that you can set up in the same way as regular user accounts, but the account is clearly identified as a robot throughout the platform. This account type is similar to what Windows uses for running its services. Its purpose is to eliminate the need to create dummy user accounts for running your unattended automations, and use this type of account instead.

Transitioning to robot accounts

If you have user accounts which you use for unattended processes, you can now hand over the unattended process execution to a robot account.

To do so:

Create a robot account.
Set up the robot account for unattended use, same as you would set up a user account.

Make sure you assign the same roles and configure the same robot setup that the user account has to ensure that the process can continue to run without issues. The robot account does not require any user licenses.
Assign the robot account to the same folders where the user account was assigned.

For details, see Assigning accounts or groups to folders.
Optionally, check for and remove any roles that the user account no longer needs

For details, see Checking roles.

Streamlining the Unattended Setup

When creating a new automation project in Studio, developers are greeted by the first attribute that has a saying in the future whereabouts of the execution: the underlying target framework of the automation project and the compatible operating system.

Learn more about target frameworks in Studio.

The following table shows the UiPath Robot version required to execute processes according to their target frameworks and OS compatibility considerations.

Target framework	Operating system	Robot version
.NET Framework 4.6.1	Windows - Legacy	Any
.NET 5.0+	Windows	2021.10+
.NET 5.0+	Cross-platform	2021.10+

Another decisive attribute of your automation projects, the UI requirement defines whether your projects need user interaction to unfold (foreground) or they can simply rely on background processes to get executed (background). Unattended robots handle background processes in Session 0, under NT AUTHORITY\LOCAL SERVICE, which has no UI and cannot interact with a user session.

Learn more about background process automation.

Now, here's the trick: you need credentials for executing foreground processes, you don't need them for executing background processes. That's why we've come up with a new capability aimed at trimming down the configuration effort for unattended automation. How? By making credentials optional.

Simply put, from now on, you can configure unattended robots executing background processes without worrying about all that credential fuss.

The following table shows the UiPath Robot version required to run foreground/background processes according to the robot credential considerations.

Process type	Credential considerations	Robot version
Background	Robot with credentials	Any
Foreground	Robot with credentials	Any
Background	Robot without credentials	2021.10+
Foreground	Robot without credentials	Invalid configuration. You need credentials to run foreground jobs.

You can opt-in or out of defining credentials for:

Robot accounts - your go-to accounts for service unattended automation;
User accounts - accounts dedicated to personal remote automation that must be run under the user's identity.

Switching between having credentials and not having credentials is effortless using the new Robot credentials toggle which you can see depicted below.

Unattended Infrastructure Optimization

Your unattended workload has unique infrastructure needs that can change over time. Matching the workload with the right resources is key to maximizing efficiency and minimizing waste.

We come to your aid in this respect with two new Orchestrator controls that enable you to distribute even the most diverse collection of jobs to specific machines. How to do it?

Well, it's rather simple, by specializing your machine templates, i.e. making the machine template and the associated machine infrastructure confined to executing a particular type of process. Use the following options when creating or editing your machine template:

Field	Description
Process type	On the machine infrastructure employing that machine template you can execute: only foreground processes, (1) only background processes, (2) both background and foreground processes. (3)
Process compatibility	On the machine infrastructure employing that machine template you can execute: Windows-compatible processes only, (4) cross-platform processes only, (5) both Windows-compatible and cross-platform processes. (6)

See the documentation for details.

Personal Workspaces With a Chance of Unattended

In this release, we’re breaking down the barriers between attended & unattended automation by bringing unattended execution within the reach of all RPA developers out there. We’re paving the way for personal remote automation, meaning remotely executed RPA processes from within the comfort of your personal workspace.

Remote execution on company-managed VMs has never been easier with new users having their own personal workspace by default and unattended automation gaining permanent residency in personal workspaces!!!

Personal workspaces for all new users

This feature provides new attended users with their own personal workspace by default and is intended to push attended automation within the grasp of all automation users out there.

Administrators beware, user groups referenced in Orchestrator and users automatically provisioned after this change come with no attended functionality, an administrator needs to explicitly enable attended robots for the groups and/or users that need it.

This change makes some existing Orchestrator functionality redundant; some bits and pieces related to configuring personal workspaces have been removed.

Do not worry about your existing users and users groups as they keep their original configuration. We also do not enforce personal workspaces in any way, even though they are enabled by default for new users and user groups, you can always disable the functionality as you see fit on a per-user/group basis.

Unattended in personal workspaces

An administrator unlocking the unattended experience for all their RPA developers must know there's one requirement: a machine object - machine template or standard machine - associated with the workspaces. This makes the unattended infrastructure (machines connected to Orchestrator using their key) available for execution in all personal workspaces.

You can do that from the tenant context > Folders > Personal Workspaces.

You cannot restrict a machine object scope to specific workspaces, nor can you exclude it from certain workspaces; a machine object can be associated with either all workspaces or none.

Make sure the machine object has the necessary runtimes to support the execution for all your workspaces.

RPA developers' experience with unattended

RPA devs can benefit from all unattended-specific functionalities aforementioned, provided an administrator made the necessary configuration beforehand.

This allows them to perform the following operations:

A. Launch automations in a preplanned manner or through a queue item condition using Triggers.

B. Check the health and status of the machines and machine runtimes assigned by the administrator to your workspace using the Monitoring feature. We have added a Machines card to the workspace Home page for quick access.

C. Monitor all resources in your workspace by checking out the new Monitoring menu that allows you to learn about the health of your machines, processes, queues, and SLA predictions.

Modern folder vs. personal workspace

In a personal workspace context, jobs are launched under the identity of the workspace owner. This brings a couple of changes to the functionality as you may know if from modern folders:

Machine objects and users are not something configurable from the context of a personal workspace.
The user is not a configurable execution target for triggers since it's inherent to personal workspaces that the execution is performed under the RPA developer's identity.
Testing functionality and actions are not available. As a result, Suspended and Resumed job statuses become irrelevant in a workspace context.

To make the transition as smooth as possible, we've adjusted the predefined Personal Workspace Administrator role with new permissions. See the documentation for details.

Pushing Machine Objects to All Subfolders at Once

To further reduce the effort of unblocking the unattended experience in your company, administrators can also push the machine template or standard machine to all subfolders that need the same executing infrastructure. Instead of assigning the same machine to each and every single subfolder manually, you can push it from a parent folder to all its child folders with a couple of easy clicks.

Learn about assigning machines to folders.

Debugging for Unattended Processes

Say goodbye to the hassle of debugging when the Enforce user authentication, disable robot key authentication option is enabled (also known as interactive sign-in, set from tenant settings in Orchestrator).

While this feature brings multiple advantages (security enhancements, easier flow for attended users when connecting to Orchestrator, streamlined licensing for users by enabling the User License Management functionality), it also had as a side effect a more cumbersome debugging experience for the unattended processes:

When logging in to a machine connected to Orchestrator via machine key for debugging purposes while interactive authentication is enforced, there are no processes available in your Assistant to debug them, unless you first sign in.

Now you can achieve this, by enabling a troubleshooting session on the machine, which is available from the Unattended sessions tab of the Robots page:

Enabling a troubleshooting session allows you to see and run unattended processes from UiPath Assistant for debugging purposes. No user license is required for the developer to perform this operation.

The troubleshooting session is temporary and the above only applies while troubleshooting is active.

For instructions, see Debugging Unattended Processes.

Attended Automation

Terminating Attended Jobs Using Orchestrator

Empower administrators to keep a closer eye on attended automation in your company with a feature allowing termination of attended jobs from Orchestrator. Untangle stuck automations with a few clicks by navigating to Automations > Jobs and selecting More Actions > Stop or Kill to terminate the attended job.

Note: You can only terminate attended jobs in Orchestrator running on v2021.10+ Robots. Terminating attended jobs from Orchestrator requires that SignalR is enabled and that the Robot can connect to Orchestrator's SignalR channels using WebSocket. Make sure that SignalR is enabled and WebSocket is selected on Settings > Scalability.

Stop/Kill Pending Jobs Automatically

In this release, Orchestrator brings an improved mechanism for terminating hanging jobs in that you can now use a Kill job strategy on top of the Stop strategy, not only as an alternative to it. If you are not already familiar with the existing feature, let’s refresh your memory: you can optimize your flows and elegantly dismiss all clingy job executions in a preplanned manner by configuring your triggers to stop or kill jobs after a certain time interval has elapsed.

In the following example, Orchestrator will attempt to stop jobs that have been stuck in Pending for at least 10 minutes. If the termination does not happen, Orchestrator will attempt killing those jobs that have been Stopping for at least 20 minutes.

Learn how to configure time triggers.

Queues improvements

You asked, we listened. We bring you the power to update an existing queue by:

Renaming it while keeping the existing queue information. Ditch the previous hassle of deleting and recreating the queue (including queue items) in basic cases of spelling errors or changing your mind about the initial name.
Changing the Auto Retry option from No to Yes or vice versa. You are now able to reconsider if your failed transaction may be retried automatically or not.
Setting a new value as the Max # of retries. Give transactions several second chances to reach Successful status when you have the Auto Retry option enabled.

Although you may alter these settings after the queue creation, keep in mind that only future transactions are influenced by the changes you make.

Read more details in our Editing Queues article.

Assistant Widgets

Starting with the 2021.4.3 release, we made it possible for you to add widgets in the UiPath Assistant by making use of Automation Ops and Orchestrator libraries.

In Orchestrator, these widgets were marked just like any other library package, which was of no use, really. As of today, we introduce a new type of library dedicated to widgets: Assistant Widgets. All widgets uploaded to Orchestrator from now on will be labeled as such for you to spot them a mile off.

Note: Widgets uploaded to Orchestrator prior to this change stay labeled as Process Library.

Learn about widgets.

Long-running Workflows

The Rise of Attended Robots in Long-running Workflows

Until today, only unattended robots could execute long-running workflows. The wait is over, as you can launch an orchestration process from the UiPath Assistant, wait for the generated action to be completed in Action Center, and hand the rest of the execution over to an unattended robot.

There is a correlation between the licenses used to start the job and the licenses consumed by the unattended robot to resume the job:

If you start the job using the attended robot included in a(n)…	… then job resumption consumes a(n) …
Attended user license	Unattended robot license
Developer user licenses Citizen Developer RPA Developer RPA Developer Pro	NonProduction robot license

The job can be resumed by an unattended robot from a different server to the one the job was originally started on.

Retaining Account-machine Configuration on Job Resumption

Generally, to make the best of your resources we recommend you to stay with the default behavior for resuming suspended jobs, that is to resume them on any available robot on any available machine. However, there are cases when:

The resumed job execution depends on a specific application (for example, SAP) that is installed on a specific machine.
Starting and resuming a job requires the same user context.

To acknowledge your resources and license requirements on a job resumption, we deliver the option to use the same account-machine configuration set at the job start. Find out more details in the Managing Jobs article.

Accounts & Access

Interface Changes

In an effort to clarify the distinction between adding accounts, which is done from the Accounts & Groups page in the Management portal, and granting access to accounts, which is done from Orchestrator, we have improved the Orchestrator user interface and tweaked the terminology to make things less confusing.

So here's what changed:

We have joined the tenant-level tabs Users and Roles under a new tab called Manage access.
The functions previously accessed from the Users page are now accessed from the Assign roles tab on the Manage access page.

You could never create accounts from there, you were simply adding existing accounts to Orchestrator so that you could assign roles to them.
Similarly, the functions previously accessed from the Roles page are now accessed from the Manage access page, on the... drumroll... Roles tab. (Why fix it if it's not broken, right?)

We have separated the experience of assigning roles to accounts or groups. While previously the same steps applied for both, now the two have distinct wizards, one for users or robot accounts, and a different one for groups, better tailored for each task.
A Manage Accounts & Groups button has been added to the Assign roles tab (Tenant context > Manage Access > Assign roles) which opens the Accounts & Groups page of the Management portal where you can add new accounts or groups.
Lastly, on the Manage access > Assign roles page, the Check Permissions button has been renamed to Check roles. This is because you actually assign roles to users or groups; permissions, on the other hand, are the building blocks of roles and you do not assign them separately.

Documentation

Directory Accounts for System Administrators

If linked to a directory, you can now also add system administrators by their directory account, not only by creating local accounts. For instructions, see Adding a system administrator.

Elasticsearch OAuth2 Authentication

We now support OAuth2 authentication for reading robot logs in Elasticsearch. You can now use a token instead of a username and password as an authentication method.

To enable the new mechanism and control the token validity for reading logs, we have introduced two new parameters in Orchestrator's UiPath.Orchestrator.dll.config file: Logs.Elasticsearch.OAuthEnabled and Logs.Elasticsearch.OAuthExpireInSeconds.

We also offer OAuth2 for NLog. You can enable the functionality by setting the following attribute in the target's configuration: OAuthEnabled = “true”.

For more on the available authentication methods, see X-PACK Authentication.

Packages & Automations

Exposing Package Requirements

Until now, uncovering the resources required to launch a process meant you had to explore the automation project, either in Studio or using Orchestrator's package explorer. In an effort to ease you into your first-run experience, we've come up with a new feature that reveals the resources required to launch a process.

Get your processes up & running in a jiffy by seeing the queues, assets, action catalogs, and storage buckets they rely on from the get-go. No more getting stuck!

Note: You need Studio 2021.10+ and activity packs 2021.10+ for this feature to work correctly.

All of the process dependencies are centralized in one Orchestrator view when adding or editing processes, with useful information about each required object.

What's even better about this is the fact that you can quickly create or link the needed resources without leaving the process context. Missing asset? Just create it on the spot. Much needed queue in a different folder? Just link it with the click of a button. It's that easy. Don't take our word for it. Try it yourselves.

Restrict Robot Access to Host Libraries Feed

To address security challenges brought by robots having access to the default host feed (currently on MyGet) to retrieve library packages, we have added a new option that only allows connections to the tenant's feed.

Whereas before we provided an Only host feed and a Both host and tenant feeds options for the retrieval of your library packages, we now offer a third option: Only tenant feed.

Learn how to configure library feeds.

Process Debugging

Debug processes more easily as we changed the alert about reaching the maximum number of jobs for a process from Error to Info severity. The pop-up message you may encounter in this case is: “Folder [folder_name]: #trigger [trigger_name] for #process [process_name] could not create jobs. The maximum number of jobs for this Process has already been reached. Please check your trigger settings, robot availability, and running jobs. (#1693).”

To find these types of alerts on the Alerts page, make sure to change the State filter to All.

Recording for All Orchestrator Deployments

As of today, we enable the media recording feature by default for all Orchestrator deployments and remove the corresponding toggle from the user interface. No worries, you can still disable the feature using the corresponding MediaRecording.Enabled app setting.

As a reminder, this option needs to be switched on at the process level for it to work. Learn how to enable recording on a per-process basis.

Dynamic Typing

Dynamic typing is a new option that allows you to control how Orchestrator interprets String values inside of CSV files used to upload queue items. This can prove particularly helpful for queues with schema definitions where you need Orchestrator to interpret numeric values as Integer or Boolean in order to match the schema definition.

Previously, uploading a CSV file with numerical values could not be validated against a JSON schema requiring Integer/Boolean as Orchestrator read them as String, hence it threw a Queue item violates the specific data JSON schema error.

Learn more about uploading queue items to Orchestrator.

Performance Best Practices

To prevent performance issues when storing more than 1 million Robot logs in the Logs table, we recommend creating an index. For more details, see Orchestrator Logs.

Installation & Upgrade Experience

Auto-update Client Components

Ever thought how great it would be to always have your robots up to date? We have some great news then! You are now able to update Robot, Studio, and UiPath Assistant clients to newer versions from Orchestrator. This provides an easy way to deliver a version update to a large base of machines from a centralized location, helping remove user friction and streamlining the update process.

The UiPathOrchestrator.msi installer now has additional configuration options dedicated to the new Update Server functionality. An additional Update Server Database Settings screen is available in the UI, and the CLI comes with new Update Server-specific parameters. For more info, see The Windows Installer and Orchestrator Command Line Parameters.

Upgrade

We have removed the following parameters from the Publish-Orchestrator.ps1 script: -hostAdminPassword, -isHostPassOneTime, -defaultTenantAdminPassword, and -isDefaultTenantPassOneTime. These keys are now specific to the MigrateTo-IdentityServer.ps1 script. For more details on this, see MigrateTo-IdentityServer.ps1 Parameters.
Before upgrading to Orchestrator v2021.10, we recommend cleaning up queueItemEvents and jobEvents to prevent any performance issues.
Upgrading to Az v6.0.0 when any previous version of the module is in use causes the following message to pop up: WARNING: The version 'x.x.x' of module 'Az.<Name>' is currently in use. Retry the operation after closing the applications. In order to solve this problem, make sure to execute Publish-Orchestrator.ps1 in a new PowerShell session.
If you use Microsoft Azure Key Vault for tenant encryption, you now need to configure an additional parameter in the UiPath.Orchestrator.dll.config file of your Orchestrator instance: Azure.KeyVault.DirectoryId. For extensive instructions, see Setting Up Encryption Key per Tenant.
The conversion of Active Directory accounts - controlled by the WindowsAuth.ConvertUsersAtLogin setting from the UiPath.Orchestrator.dll.config file - is now done automatically during installation or upgrade. So we have removed this setting from the file. This conversion does not impact your existing robots.

Note: If you were ever on version 2018.4 and have never converted local AD users into directory users (or did not convert all imported users), those directory accounts that were not converted must interactively log in to Orchestrator at least once to finalize the conversion. Signing in to the Identity Management portal, or signing in from UiPath Studio or UiPath Assistant does not complete the conversion of the account.

Configuration

It is now possible to disable proxy integration by means of a new UiPath.Orchestrator.dll.config parameter: ProxyIntegration.Enabled. By default, the parameter is not visible, and its value is set to true, which means that proxy integration will be enabled unless otherwise specified.
The Publish-IdentityServer.ps1 script now requires the configuration of a new parameter to indicate the Identity Server public address: -identityServerUrl. For more details, see Publish-IdentityServer.ps1 Parameters.

API

When a tenant is in maintenance mode, API calls for that tenant now return the status code 423 instead of 503.
We improved the GetFolderNavigationContextForCurrentUser endpoint of the FolderNavigation API by adding the IsPersonal boolean property. This property is displayed in the endpoint response body and checks if the returned folder is a personal workspace. Find more details in our reference guide.
Retrieving audit logs via API now returns entries in batches of maximum 3,000 entries, to increase performance. To get the remaining entries, use the query parameters skip and top . For example, to get the second batch of 3,000 audit log entries, the API call would be: GET https://{base_url}/{organization}/{tenant}/api/auditLog?top=3000&skip=3000.
For auditing purposes, we added the necessary properties to several resources DTOs, hence to the response bodies of the following endpoints:
- /odata/Users
  
  "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0
- odata/Robots
  
  "LastModificationTime": "2021-10-12T07:32:24.940Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:32:24.940Z", "CreatorUserId": 0
- odata/Releases
  
  "LastModificationTime": "2021-10-12T07:29:25.914Z", "LastModifierUserId": 0, "CreatorUserId": 0
- odata/Assets
  
  "LastModificationTime": "2021-10-12T07:57:15.145Z", "LastModifierUserId": 0, "CreationTime": "2021-10-12T07:57:15.145Z", "CreatorUserId": 0
- odata/Libraries
  
  "Created": "2021-10-12T07:59:04.182Z", "LastUpdated": "2021-10-12T07:59:04.182Z", "Owners": "string", "IconUrl": "string", "Summary": "string", "PackageSize": 0, "IsPrerelease": true, "LicenseUrl": "string", "ProjectUrl": "string"

Important:

Erratum 9 December 2021

The DTO properties listed above were not delivered in 2021.10, as stated in the release notes, due to a mishap on our part.

Update 9 May 2022

The DTO properties were added to the following resources in Orchestrator 2022.4:

/odata/Users
/odata/Robots
/odata/Releases
/odata/Assets
/odata/Libraries

Testing

Starting now, the Tenant Administrator role comes with View permissions on Background Tasks. This change does not alter existing Tenant Administrator roles. See details about default roles and their permissions.

Goodbyes

See You on the Other Side, Actions

The moment to drop the Actions tab and management from Orchestrator has arrived, as predicted in 2021.4. It's time for your actions to say farewell to Orchestrator and fully embrace Action Center, the dedicated place where you can see and manage all of them, just make sure you are in the correct folder context. Assign, forward, complete actions, and even manage action catalogs within the Action Center experience. Don't worry about existing Orchestrator actions, as the installer redirects all Orchestrator action links to the new Action Center interface. You just need to install or upgrade the on-premises Action Center, but bear in mind that you need to connect to one Orchestrator instance. The installation may be on the same server as Orchestrator or on a different one.

Discover the Action Center experience.

Insights Leaves Orchestrator

We have decoupled Insights from Orchestrator. Rest assured, we have not dropped any functionality, and all tasks that you previously performed via Orchestrator can now be tackled in Insights. For more details, see the Insights guide.

Usability Improvements

For quick navigation between the Orchestrator host portal and the Identity Server hub, use the new Go to Identity Hub shortcut.
We’ve renamed the Disable concurrent execution field to Run only one job at a time to prevent any confusion as to what the option does.
You can now delete individual package versions from the Package Versions window, the More Actions menu.
We changed the default value of the Login To Console robot setting to Yes.
Hey there Automation User, we just unlocked the Create on Logs permission for you by default. From now on you are able to create logs every time you run jobs in Orchestrator.
To benefit from this configuration in your existing tenants, navigate to Tenant > Settings > Standard roles, and update the Automation User role to include the missing default permission.

Deprecation Timeline

Note:

The following Orchestrator capabilities have been removed starting with 2021.10:

Automatic robot enrollment with standard machines. We recommend using machine templates and connecting your machines using the command line.
NTLM authentication. We recommend using the OAuth flow instead.

Several Orchestrator capabilities are facing deprecation in 2022. We strongly encourage you to switch to superior alternatives.

Standard machines deprecation is planned for April 2022. We recommend using machine templates.
Classic folders deprecation is planned for October 2022. We recommend migrating to modern folders.

See Orchestrator’s deprecation timeline.

Breaking Changes

Execution Media Permissions

Deleting execution media by making POST requests to the /odata/ExecutionMedia/UiPath.Server.Configuration.OData.DeleteMediaByJobId endpoint now requires Delete permissions on Execution Media, whereas previously you needed View permissions.

Authentication and Emails Settings API

Updating Authentication and Email settings via the Orchestrator API is no longer possible. The corresponding endpoint is available strictly from the Identity Server API.

To continue to update these settings using REST methods use the corresponding Identity Server endpoint, as no backward compatibility is provided.

The Orchestrator endpoint used to update Email and Authentication settings: POST /odata/Settings/Uipath.Server.Configuration.Odata.UpdateBulk

The above endpoint works as expected for the rest of the Orchestrator-specific settings.

The Identity Server endpoint replacing the Orchestrator one (use it to update Email and Authentication settings): PUT /identity/api/Setting

Nonetheless, you may update Authentication and Email settings from the UI, at Host level:

Email settings: Host > Identity Hub > Management > Global Settings > Email
Authentication settings: Host > Identity Hub > Management > Users > Authentication Settings

Known Issues

You cannot assign robot accounts to a folder if prior to navigating to the tenant level the last folder selected was a classic folder. The main symptom is that when looking for a robot account to assign, the robot account is not displayed even if it exists. As a workaround, select a modern folder from the folders sidebar before navigating to Tenant > Folders to perform the assignment.
Authenticating users through Azure Active Directory may receive a 500 error response. This behavior is due to an unhandled exception thrown by the get_DNSDomainName() method, unable to resolve the Domain of Authenticating User.

To prevent the exception, fix your DNS records in your Azure Active Directory.
Time format collapses on several pages when you set Chinese, Japanese or Korean as the Orchestrator language.
Users with the Administrator role can be deleted from the Orchestrator API. This operation cannot be performed using the UI.
You cannot use the transactions .CSV file to upload items to a queue. Use the CSV template provided in the documentation instead.
Occasionally, when starting/restarting your Orchestrator machine, one of the nodes shows errors and is rendered usable. Restart Orchestrator from IIS as a workaround.
Orchestrator does not render correctly time formats on the Logs page when the Orchestrator language is set to Chinese, Japanese or Korean. 0 characters get rendered as slashed zeros and prevent the glyph following the 0 from being displayed. For example, what should be displayed as 11時20分03秒 is rendered as 11時2Ø03秒.
Filtering by host identity on the Jobs and Logs pages does not work correctly for jobs executed via accounts without credentials. When running jobs on Windows machines, the Host Identity column is populated with the actual identity of the robots (domain\username), however, filtering by this value returns no jobs. When running jobs on Linux machines, jobs are executed under Root, however, this value is not available for filtering.

Bug Fixes

Automations

Persistence jobs no longer remain in the robot service queue (i.e., in a Running state) if the corresponding long-running workflows have been paused.
The heartbeat now properly uses the IX_Executing index from the Jobs table when getting the current jobs.
Stopping or killing a job would cause the machine value for that job to disappear. Refreshing the Jobs page fixed the issue.
Robots installed in user mode did not receive stop/kill commands from Orchestrator - killing or stopping a job left the robot in a Terminating state.
Fixed a bug affecting queueItem.transactionStarted Webhooks events due to missing queue definition property.
Attended robots running jobs appeared as Available if the Assistant was refreshed.
Orchestrator did not preserve execution settings for a user's robot (it reverted them to the default values) in a scenario involving two Active Directory users using a Multiuser license and the same VDI. Explicitly, execution settings that were specified for user A robot while user B was connected to Orchestrator were cleared up upon connecting to Orchestrator with user A. This behavior no longer occurs.
An issue was seldom encountered with triggers misfiring in Orchestrator after enabling Insights. The issue would disappear upon disabling it. The problem can no longer be seen.
A Release does not exist error was thrown upon refreshing the monitoring details window for a process in a child subfolder (Monitoring > Processes > Include Subfolders > Processes Overview).
The column visibility state for the Jobs page was not persisted upon navigating away from the page.
The robot list was not populated when trying to create a trigger from the Processes page in classic folders.
You could not debug assets per user/machine pairs from Studio. To check if a specific user-machine pair received an asset, you had to launch the job from the Assistant or Orchestrator. This is no longer the case.

Setup

This new Orchestrator version brings the deprecation of the -useQuartzClustered parameter in the Publish-Orchestrator.ps1 script.
You can no longer update the bearer token expiration time via UiPath.Orchestrator.dll.config. As a result, the Auth.Bearer.Basic.Expire setting is no longer available in Orchestrator's configuration file. Changes are now possible only by adjusting the AccessTokenLifetime property of the Orchestrator.Ropc client in the Identity Server’s Clients database. See our troubleshooting section for a configuration example.
Trying to upgrade Orchestrator from v2018.4 to v2021.4 without defining the <httpErrors> element in the Web.Config file would cause issues. This would result in a failed upgrade and the duplication of each <httpErrors> entry. We have fixed the issue in the meantime, and now upgrades run smoothly without any workaround.
Upon installation, Orchestrator was not added to the Event Viewer sources. As a result, the application logs using the standard NLog eventLog target were not being recorded in the Event Viewer. The issue has been fixed.
You can now use Dynatrace OneAgent for Application Performance Monitoring (APM) without the risk of Identity Server startup issues.
The User Email field was mandatory when creating users even though the UseEmailAsIdentityName setting was set to false in Identity Server's appSettings.onprem.json file. We have fixed the issue, and you can now create users without an email address.
We have fixed an upgrade issue preventing the generated .json file containing the installation parameters from properly capturing the Insights database details.

API

The Set Asset and Set Credential activities timed out for assets targeting a large number of robots. We added a new improved mechanism for setting robot values that involves a new API endpoint: /odata /Assets /UiPath.Server.Configuration.OData.SetRobotAssetByRobotKey.
The metadata for the /odata/ProcessSchedules/UiPath.Server.Configuration.OData.SetEnabled endpoint was incorrect, leading to a generated OData client failing to call the endpoint.
Calling the /odata/Alerts/UiPath.Server.Configuration.OData.MarkAsRead endpoint did not mark the specified alert id as read. This behavior is fixed by providing the UserNotificationId instead of the alert Id. Find out more in our reference documentation.

Credential Stores

For credential store plugins with references, Orchestrator did not load the reference files unless you used a class from the referenced assembly to implement ISecureStore. Orchestrator can now load assemblies from the Plugins folder at any time.
Using CyberArk AAM credential stores with Path authentication (Plugins.SecureStores.CyberArk.UsePowershellCLI set to true) failed with the following error message: Failed to retrieve robot password from UiPath.Orchestrator.SecureStore.CyberArk.CyberArkAimSecureStore storeUiPath.Orchestrator.Extensibility.SecureStores.SecureStoreException: Could not find password! Reason: '.\GetCredential.bat : The term '.\GetCredential.bat' is not recognized as the name of a cmdlet, function, script file, or operable program.

This happened due to the GetCredentials.bat file being published to Orchestrator installation folder instead of the Plugins folder. The file is now published to the Plugins folder.

Others

Volgograd’s timezone in Orchestrator’s application settings has been renamed from (UTC+04:00) Volgograd to (UTC+03:00) Volgograd. This was a display issue, the timezone itself was correct (i.e. UTC+03:00).
When testing the email setup, a success message was displayed when no SMTP port was specified. This behavior no longer occurs, and the email validation fails in this scenario.
Performance would degrade in environments with large numbers of jobs (in the order of millions) causing timeouts when trying to retrieve job statuses. This is no longer an issue.
An error message was seldom displayed after adding a non-working day calendar, #199 - Cannot read property 'unshift' of undefined. Adding calendars no longer throws this error.
Performance would degrade with high SQL CPU consumption in environments with around 80,000 users, each with their own personal workspace.
Trying to create a calendar without Edit permissions on Settings threw a "Calendar with the same name exists" error instead of "You are not authorized!". The behavior has been corrected and the right error message is displayed.
Uploading a zero-byte file to a MinIO storage bucket using the Upload Storage File activity threw a “Response status code does not indicate success: 500” error. Uploading zero-byte files to MinIO buckets no longer throws an error.
Licensing overuse when you had no licenses of a kind left was not properly illustrated in Orchestrator on the License page due to no licensing cards being displayed. This behavior has been fixed and cards are displayed in overuse scenarios with 0 licenses.
The error message generated by Orchestrator when publishing from Studio fails because a project exceeds the maximum allowed package size did not correctly state the cause of the error. The message now indicates that the file is too large.

2021.10