Release date: 26 April 2021

What’s New

End of Support for Internet Explorer

---

As announced in this forum post, Internet Explorer is no longer supported for accessing Orchestrator versions starting with v2021.4. Please use one of the other supported browsers instead.

Heads-up for v2021.10, as Microsoft Edge Legacy support is next in line at being dropped.

 

Goodbye, Platform Installer

---

This new release brings about the UiPathPlatformInstaller.exe deprecation, so you can no longer install or upgrade Orchestrator along with other core UiPath products using the same installer.

While we continue to offer support for previous versions of the UiPlatformInstaller.exe installer, performing a v2021.4 Orchestrator installation or upgrade is now possible only via the UiPathOrchestrator.msi installer.

No action is required on your part if you previously used the UiPlatformInstaller.exe installer. However, if you decide to uninstall UiPathPlatformInstaller.exe, make sure to double-check which installer you are removing.

 

Performance

---

We wouldn't be us if we didn't keep up with the times. We didn't forget about performance tuning, and there are considerable improvements on this front. Orchestrator is now more capable than ever and won't turn away from demanding tasks.

To give you some numbers, IaaS environments with up to 200k Attended Robots are now showing enhanced ramp-up performance, and the same goes for PaaS environments with up to 80k Attended Robots.

For more details on the configurations we used, check out our performance testing scenarios.

Aside from that, you will also notice the following tweaks in terms of performance:

• A new setting is now available to use in Identity Server's AppSettings.json and appsettings.Production.json files: UseRedisStoreCache. You are recommended to set its value to true to prevent any performance issues when using Interactive Sign In to connect a large number of robots in a short amount of time. For additional details, see the AppSettings section.

• You can now enable NuGet package caching via UiPathOrchestrator.dll.config file to improve performance in large-scale environments.

• A high rate of lock contentions was identified during application execution causing performance issues. We reduced lock contention to improve performance and scalability.

 

OAuth Support for Third-party Applications

---

Your non-UiPath applications (we call these external applications) can now use the OAuth 2.0 authorization framework to access your UiPath resources over API. This way, you can share access without also sharing credentials.

Available APIs: In this release, we are introducing OAuth support for the following resources:

• Orchestrator API
• Test Manager API

For the time being, you are able to also see Data Service API as a resource. This is a cloud-only service and our team is working on removing this option from on-premises Orchestrator.

To allow external applications to obtain authorization using OAuth, the system administrator must register them in External Applications and define the scopes they can access. The new setting is available at the tenant host level, under Settings > Security.

Documentation
To learn more, see Registering External Applications.

Also see:
Instructions for system administrators: Managing External Applications
Instructions for developers: Using OAuth for External Apps

 

Deprecated Authenticate Endpoint

The https://{Orchestrator_URL}/api/account/authenticate endpoint (details) has been deprecated. We recommend that you switch to using the OAuth flow instead.

 

Multiple Entry Points in RPA Processes

---

In this release, we add support for multiple entry points in RPA processes. Broadly, this feature enables you to create and configure your processes in Studio with different entry points than the usual Main.xaml. To this end, a new Entry Point field is added in Orchestrator which enables you to specify a particular entry point for your workflow as long as multiple have been defined in Studio.

Say you build a workflow that checks invoices. The invoice could be downloaded from cloud storage, or it could be located on your device.
You design two workflows inside the project:

• DownloadInvoiceFromStorage.xaml — workflow that downloads the invoice from an external storage.
• GetInvoiceFromLocal.xaml — workflow that gets the invoice from your device.

At run time in Orchestrator, you set as an entry point the workflow that corresponds to your scenario. If the invoice is already on your local device, you set GetInvoiceFromLocal.xaml as an entry point. This starts the execution beginning with that step and continues with the invoice checking workflow (the Main.xaml file).

Enable entry points in the project context menu in Studio.
Learn more about runtime arguments.

 

Sharing Resources Between Folders

---

Starting today, it becomes possible to share assets, queues, storage buckets, and action catalogs between folders directly from Orchestrator. Sharing resources between folders enables launching jobs in multiple folders when the underlying processes are targeting the same resources without having to redesign your workflows in Studio.

In previous versions, accessing resources in different folders can be performed via the FolderPath property; however, this can quickly become a nuisance upon organization tree changes; any change altering folder paths requires workflow reconstruction.

Today, we bring this to an end by decoupling workflow design from execution time. Sharing resources among multiple folders increases resource utilization in the tenant and allows you to move the resources to where they are needed without reconfiguring your workflows.

 

Linking Multiple Resources to the Current Folder

When creating resources in a folder, you are now presented with a new option to add an existing resource residing in a different folder.

 

Linking a Specific Resource to Multiple Folders

The same can be achieved by editing the resource wherever it may be present and making it available to multiple folders. A feed of the changes is displayed to help you keep track of the folders the resource has been added in or removed from.

See how to link queues.
See how to link storage buckets.
See how to link assets.
See how to link action catalogs.

 

User-Machine Mappings

---

User-machine mappings address infrastructure challenges where specific sets of users can only log in on specific machines. This is accomplished by enabling you to tie unattended usage under particular users to specific machine templates. The feature gives granular control over the execution target of your automations while also reflecting the same user profile-machine mappings you are used to when configuring Windows profiles.

 

Tenant Mappings

You can configure tenant user-machine mappings on the Machines page in Orchestrator. The operation involves linking users who usually log in on specific host machines to the associated machine templates. The resulting user-machine mappings become the only available pairs for execution.

Reverting to the default state (i.e., no mappings in place) is as easy as editing the machine template and allowing any user to use it.

 

Folder Mappings

For an added layer of granularity, user-machine mappings can be configured on a per-folder basis, meaning that, in a particular folder, on a machine template, you can limit the execution to specific users only. Folder mappings act as subsets of tenant mappings and allow you to achieve the utmost level of granularity possible. Not providing folder-level mappings leaves tenant-level mappings in place as the defaults. The resulting user-machine mappings become the only available pairs for execution in that folder.

You can configure folder user-machine mappings in multiple places in the UI.

• At the folder level, on the Settings page.

 

• At the tenant level, on the Folders page.

 

Enabling User-Machine Mappings

1. At the tenant level, navigate to Settings > General.
2. In the Modern Folders section, enable or disable the corresponding toggle.

Learn more about job execution and execution targets in Orchestrator.

 

Start Job & Triggers in Modern Folder

---

Launching jobs from Orchestrator has been overhauled to showcase the new capabilities provided by the user-machine mappings feature.

 

Jobs Page

Debugging just got better; you can now see which machines are available when choosing to run a job using a certain machine template.

See details on managing jobs in Orchestrator.

 

Triggers Page

• A new User-Machine Mappings strategy that allows you to schedule execution on multiple user-machine mappings is available for time triggers. Orchestrator launches one job for each user-machine pair you selected as the execution target. According to the availability of the resources, the jobs can either begin executing or remain pending.

• The Dynamic Allocation job allocation strategy has been enhanced for both time triggers and queue triggers and you can now choose the machine on which jobs get executed. Unlike the User-Machine Mappings option, Dynamic Allocation only allows specifying one user-machine pair.

See details on managing triggers in Orchestrator.

 

Asset Per User-Machine Pair

---

Not long ago, we delivered assets per user, the modern counterpart of classic per-robot assets. Aimed at creating a mapping between the user and the credential, assets per user had a big downside: users logging in to multiple machines had no easy way of controlling who gets assigned what job.

Fortunately, the asset story has come full circle as we've added machines to the equation. That creates a precise mapping between the user, machines, and the credential used during execution.

Learn about assets per user-machine.

🚧

Compatibility Considerations

• Assets per user-machine only work on Robots v2020.10 or newer.

• You cannot debug assets per user/machine pairs from Studio. To check if an asset is received by a specific user-machine pair, you need to launch the job from the Assistant or Orchestrator.

 

Standard Machines in Modern Folders

---

Migrating from classic folders to modern folders has never been easier. Today, we're giving the possibility to create and associate standard machines to modern folders so that upon migrating, you do not need to change the machine key.

Because a standard machine cannot work in both classic and modern folders simultaneously, the classic model takes precedence. A standard machine works in the classic folder as long as there are active robots defined. Disabling all robots that are using it in the classic context will render it usable in modern folders.

To accommodate this change, the Machine Template window has been renamed to Machines and has been repurposed to show both standard machines and machine templates.

 

CyberArk CCP Integration

---

Lots of good news ahead as we’ve expanded and improved our credential store functionality by integrating CyberArk CCP with Orchestrator.

The Central Credential Provider (CCP) is the agentless AAM method used to integrate Orchestrator with CyberArk. It allows retrieval of sensitive information such as Robot credentials and credential assets from CyberArk without deploying an agent on the server, as passwords that are stored in a vault are retrieved to the Central Credential Provider, where they can be accessed by authorized remote applications. A client certificate is necessary to ensure the secure retrieval of the credentials.

To successfully integrate with CyberArk® CCP, we suggest you take a look at how to correctly set up your environment in CyberArk® PVWA:

1. Create an application for your Orchestrator instance and add client certificates.
2. Create a Safe and add members to it to ensure proper permissions.

 

Setup

---

There are two approaches to a v2021.4 upgrade, depending on your current Orchestrator version. You can either move directly to v2021.4 from v2018.4 or newer, or you need to first upgrade to v2018.4, v2019.x, or v2020.x, and then jump to v2021.4, if you currently use a version prior to v2018.4.

When upgrading to Orchestrator v2021.4, make sure you also move to AI Center v2021.4 if you are using both products. While AI Center v2021.4 is backward compatible with Orchestrator, Orchestrator v2021.4 does not work with older AI Center versions.

The AzureRM PowerShell module is now deprecated, and the Publish-Orchestrator.ps1, Publish-IdentityServer.ps1, and Publish-Webhooks.ps1 scripts should migrate to Az. Publish-Orchestrator.ps1 will try to uninstall the AzureRM module, but it will wait for confirmation from the user even if -unattended flag is used.

You can now configure the SQLServer timeout for queries running against the Orchestrator database to populate the Insights database. Use the new Insights.Ingestion.QueryTimeout setting available in Orchestrator’s UiPath.Orchestrator.dll.config file to make these changes.

UiPath.Orchestrator.dll.config file's EncryptionKey setting would previously accept only 256-bit keys as a valid value. The restriction no longer applies, and you can now choose any key length that suits your needs.

Previously, retrieving credentials from a CyberArk vault did not work when using Path authentication, and a Script run using untrusted shell. exception was thrown. As of now, you can enable the Plugins.SecureStores.CyberArk.UsePowerShellCLI app setting to overcome this issue.

You can now control whether or not login error codes are displayed in the UI, by using the HideErrorCodesInUi parameter in the Identity Server appsettings.Production.json file.

More filtering options are now available for handling Elasticsearch logs. These enhancements are mainly focused on the Level and Timestamp default log fields.

We have improved logging for identity/.well-known/openid-configuration requests to more accurately reflect exceptions.

UiPath.IdentityServerConfigProtector.exe tool has been renamed to UiPath.ConfigProtector.exe, and its size is now smaller. All usage remains unchanged.

 

Dropping Actions Support from Orchestrator

---

Please be aware that starting v2021.10, the Actions management feature in Orchestrator will be dropped. To continue managing actions and allowing your users to complete them, install on-premises Action Center, which provides improved functionality and user interaction.

 

Improvements

Licensing

---

Orchestrator offers a fresh perspective on licensing, with new names and license information to reflect the SKUs structure from our commercial offering.

All license-related terminology across the user interface has been updated to match the current SKUs, which are now user-oriented instead of product-oriented, as follows:

• Attended Robot Named User Attended Named User
• Attended Robot Concurrent User Attended Multiuser
• StudioX Named User Citizen Developer Named User
• StudioX Concurrent User Citizen Developer Multiuser
• Studio Named User RPA Developer Named User
• Studio Concurrent User RPA Developer Multiuser
• Studio Pro Named User RPA Developer Pro Named User
• Studio Pro Concurrent User RPA Developer Pro Multiuser

Also, we’ve added license information to the Users and profile pages so that you have it handy.

This adjustment does not require any action from you, as your commercial agreement, Terms & Conditions, and licensing functionality remain unchanged.

 

Role Management

---

Role management has been improved in Orchestrator to better delimit permissions that apply on the tenant level and permissions that apply on the folder level.

Role Types

There are now three types of roles:

• Tenant roles include only tenant-level permissions, which grant rights in relation to your tenant resources.
• Folder roles include only folder permissions for working within a folder.
• Mixed roles include a combination of both tenant and folder permissions.

You can no longer create new Mixed roles, but you can still use the ones you already have.

Role types are now indicated in the relevant pages, for example:

 

Moving Away from Mixed Roles

Although you can still use your existing Mixed roles, we recommend that you replace them with separate roles for the tenant and folder permissions they include and assign the new roles appropriately.

A warning is displayed when editing a Mixed role. Expand it for guidance on transitioning to the Tenant and Folder role types:

 

Creating Roles

When creating a role, you now choose the type of role you want to create: Tenant or Folder.

Each role type allows you to add permissions for the selected context only. It is no longer possible to create roles that contain both tenant and folder permissions, namely Mixed roles. If you have users who need both, you must assign them a Tenant role and a Folder role.

 

Assigning Roles

The way in which you assign roles has also changed, depending on the type of role and on whether or not you still use classic folders.

• If Activate Classic Folders is cleared under Tenant > Settings > General:
  You assign Tenant roles and Mixed roles from the Users page or from the Roles page.
  You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.

• If Activate Classic Folders is selected under Tenant > Settings > General:
  You assign any of the three types of roles from the Users page or from the Roles page.
  You assign Folder roles and Mixed roles from the Folders page or from the folder's Settings page.

 

Processes

• To upgrade a process to the latest version easily we've added an Upgrade to latest version option in the contextual menu of a specific process.

Learn about managing package versions in Orchestrator.

 

Multiple Sessions Per Robot

---

If you made it this far down, here's a big one: to tackle the gap between classic and modern, we're allowing multiple sessions per attended robot with a single license. You are allowed 3 simultaneous sessions with one license so you can connect your robot to all machines that provide your automations with the required resources. Happy automating!

📘

Note:

This feature only works for v2020.4 Robots or newer.

 

Enhanced Robots View

---

You asked. We listened. In this release, we've turned our attention to the global Robots view exposed at the tenant level in Orchestrator. We've made a number of changes to improve the view in an effort to offer a more coherent portrayal of the robot configuration and to ensure more cross-product consistency.

The Robots page at the tenant level has been augmented to show the robot configuration done in Orchestrator as well as how this maps to your attended and unattended scenarios. To this end, we now provide four separate tabs where you can choose the context you are interested in.

 

A. Configured robots

This section shows the robot configuration made in modern folders. Specifically, it offers a breakdown of all robots created for your users, by enabling the Automatically create an attended robot for this user and/or Automatically create an unattended robot for this user options.

 

B. Unattended sessions

This section offers an overview of all unattended sessions and related information.

 

C. User sessions

This section offers an overview of all user sessions started from the Assistant and related information.

 

D. Classic robots

This section offers an overview of robots as defined in classic folders and related information. This tab is not displayed in modern-only organizations.

 

Retrieve Target Framework

---

You can retrieve the Target Framework of a package by making a GET request to the /odata/Processes endpoint.

 

Test Automation

---

If you want to run a test case again, you now have the option to re-execute individual test cases on the Test Executions page.

You can run your test sets through a specific user that is assigned to the folder. This is available for Modern Folders only.

Now you can parametrize your test cases at runtime by defining arguments at the test set level. You can use this feature to reconfigure existing test cases by overriding the default argument value, instead of creating new ones.

You can attach files (e.g., spreadsheets) to test runs to provide additional execution information.

You can configure a higher amount of up to 2GB for your data variation storage file.

Audit test automation operations to examine the testing process adherence to your defined procedures and guidelines.

 

Others

---

You can no longer remove non-working day calendars if they are attached to active queue triggers. Remove or disable the trigger to remove the attached calendar. Previously, removing a calendar employed in a queue trigger displayed a Calendar does not exist error message.

You can now upload packages targeting net5.0 TFM.

We eliminated the need for an additional hot-swap database during deployment.

Orchestrator upgrades would fail when duplicates existed within the package definitions, but the packages were named differently. Now a warning signaling a package migration failure prompts the user, but the upgrade process itself is carried out.

The confirmation dialog box on Identity Server's External Providers page now prompts users with a more intuitive message when trying to apply changes to a provider.

Updated some Storage Buckets fields for a more intuitive selection of the credential store, storage account password, and credential type for Azure, MinIO, and Amazon S3 providers.

 

Breaking Changes

Job Counting Strategies

---

In this release, we're giving you full control over the job count strategy for jobs launched through triggers. The Triggers.JobsCountStrategy parameter enables you to choose the strategy that best suits your needs as follows:

• PerProcess - A trigger launches the required number of jobs taking into account any pending jobs for the specified process. E.g., two triggers are defined for the same process launch 3 and 5 jobs, respectively. If the first trigger launches 3 jobs at a given point in time, when the second trigger is set off, 2 jobs are launched so as to reach the 5 required jobs.
• PerTrigger - A trigger launches the required number of jobs taking into account any existing jobs previously launched by that same trigger. E.g., a trigger is defined to launch 9 jobs at a given point in time. If 2 jobs have been successfully completed by the time this trigger is set off again, Orchestrator launches another 2 jobs so as to reach the 9 required jobs.
• NoLimit- The trigger launches the required number of jobs irrespective of any existing, pending jobs. E.g., a trigger is defined to launch 5 jobs at a given point in time. The second time the trigger is set off, another 5 jobs are launched.

Learn about the Triggers.JobsCountStrategy parameter.

 

Azure Key Vault

---

We upgraded the Microsoft.Azure.KeyVault library with its up-to-date successor, Azure.Security.KeyVault.Secrets. This translates into a couple of changes that impact AzureKeyVault credential stores and per-tenant encryption keys.

• It is now mandatory to set the directory ID of your organization when configuring AzureKeyVault credential stores. Find the directory ID in the Azure portal (Properties > Directory ID). Make sure to update existing credential stores with the Directory ID.
• If you store Orchestrator encryption keys in Azure Key Vault, you must define the directory ID in UiPath.Orchestrator.dll.config using the Azure.KeyVault.DirectoryId parameter. Find the directory ID in the Azure portal (Properties > Directory ID).

Azure.KeyVault.DirectoryId - Indicate the directory ID of your organization as found in the Azure portal. Mandatory if you store per-tenant encryption keys in Azure Key Vault. For example <add key="Azure.KeyVault.DirectoryId" value="c9d0e174-684e-469e-84ea-d32c863ad534" />.

 

Known Issues

---

Processes containing queue items can be run only from the folder in which the queue was initially created, and not from the folders to which the queue has been shared. Removing the queue from its original folder causes the process to fail, even if the queue exists in a shared folder. The name of the original folder is displayed on the process card.

Users upgrading from Orchestrator versions prior to v2019.10 are impacted by an issue occurring due to concurrent folder create requests. The problem causes some user roles to be displayed incorrectly while also affecting the process of deleting or reassigning users. We have provided a workaround in the form of a script. For more info, see Concurrent Folder Create Requests.

For the time being, if you add an external application to the identity server of your on-premises Orchestrator, you are able to see Data Service API available as a resource. Our team is working on removing this option from the drop-down menu, as Data Service is a cloud-only service.

You can no longer filter results on the Transactions (Home page) and Robots Usage (Licenses page) graphs using the labels displayed below the chart.

Deleted queues are no longer taken into account in monitoring widgets such as Transactions Overview or Transactions Timeline.

Attended robots running jobs appear as Available if the Assistant is refreshed.

You cannot debug assets per user/machine pairs from Studio. To check if an asset is received by a specific user-machine pair you need to launch the job from the Assistant or Orchestrator.

Your persistence jobs may remain in the robot service queue (i.e., in a Running state), even if the corresponding long-running workflows have been paused. The robot retries every 30 seconds to remove the job from the queue, as it fails to receive the Suspended command from Orchestrator. This is due to a miscommunication between the robot service and Orchestrator.
Workaround: Restarting the robot service forces it to empty the jobs queue, so the job status shifts to Suspended:

• Service Mode installations: Open services.msc and restart the UiPath Robot Service.
• User Mode installations: Open Task Manager and kill the UiPath.Service.UserHost process.

 

Bug Fixes

---

Orchestrator did not load credential store plugins referencing DLL files in the Plugins folder unless the files were present in the Orchestrator installation folder. As of now, credential store plugins referencing DLL files in the Plugins folder alone are loaded successfully.

You could not log out of Orchestrator in Internet Explorer after adding the Orchestrator website to IE’s Compatibility View list.

Users would previously need to adjust the configuration file in order to enable the SSL flag for Redis. UiPathOrchestrator.msi installer now supports SSL for Redis right out of the box.

The UiPath Orchestrator Setup wizard now allows a maximum password length of 33 characters for the host and default tenant. Previously, the lack of a maximum length limit could lead to login issues.

Occasionally, deleting test sets with a large number of test cases resulted in timeout. This issue has been fixed and the response time has been generally improved.

Triggering two jobs simultaneously in a classic folder resulted in one of them not being executed unless launching it manually a second time. Such jobs are now picked up by the Robot and properly executed.

Creating a testing process threw in an error by mistake.

Test cases with failed assertions were flagged as passed due to a missing Test Case Execution Artifact folder role.

For security reasons relating to the risk of sensitive data exposure, we now discourage the use of the FileSystem bucket provider. While FileSystem remains an option, it is disabled by default on both new installations and upgrades. However, if you decide to use the provider, you first need to enable it, and then explicitly indicate the FileSystem locations you want to make available. This is possible using a new UiPath.Orchestrator.dll.config setting: Buckets.FileSystem.Allowlist. The setting has no default value, so no FileSystem paths can initially be used. Only paths subsequently added to this allowlist by the administrator are accessible.

Please refer to Using the FileSystem Storage Allowlist Securely before configuring Buckets.FileSystem.Allowlist.

Trying to update processes in large-scale environments would occasionally lead to timeout or failure. The transaction is now carried out successfully.

In certain upgrade scenarios, a migration issue would cause license allocation not to be displayed in Orchestrator's GUI. We have solved the problem.

Fixed a SAML2 authentication issue causing Identity Server to throw an error. Whenever initiating the login to an external identity provider, users with access to multiple tenants were unable to see the tenant list.

A case-sensitivity issue occurred when creating Identity Server resources. We have addressed the problem.

Using duplicate verbs in both Server and Site Request Filtering would cause either Orchestrator or Identity Server to fail. This issue no longer occurs.

In certain scenarios, the Identity Server UI would falsely allow users to check the Force automatic login using this provider option for multiple external providers at the same time, even though, in fact, it was enabled only for the most recently selected provider. We have eliminated this inconsistency.

When creating new Amazon, Azure, or MinIO storage buckets and opting for the CyberArk credential store, an error prompted users due to the Password field being visible in the UI. We have addressed the problem.

Making a GET request to the api/PackageFeeds/GetAccessibleFeeds endpoint returned only the libraries tenant feed, even though both the tenant and host feeds are enabled in Orchestrator.

Job creation and job start operations used two different time sources, which would cause the job start to appear as taking place ahead of job creation. We're now using the web server time for both to prevent such discrepancies.

Connecting to an unattended machine in attended mode would throw a Robot does not exist error in the Assistant when using the .\username syntax for the unattended robot. See details about Domain\Username field syntax.

Several folders disappeared from the sidebar after collapsing it and only became visible after refreshing the page.

A generic error message was thrown when trying to add a new Azure/AWS/MinIO bucket with an empty or wrong password.