Release date: 28 October 2020
The TargetFramework must be upgraded from the previous .NET Framework 4.7.2 to a supported Target Framework to maintain Credential Store Plugins and NLog extensions functionality. Check the Target Framework docs for details.
The new Orchestrator UX heralds a brave new world for your deployment management - out with Classic (folders) and into a Modern only world. We have disabled classic folders for all new tenants, making the modern paradigm the default option for new users and deployments.
This shift comes with a host of improvements for those already familiar with modern folders: you can now easily move folders in or between hierarchies, delete folders and all their associated entities, and modify the associated permissions for the default folder roles.
To get you even closer to a ready-to-automate place, new tenants have personal workspaces enabled by default and the five out-of-the-box roles created automatically. Hand-in-hand with the switch to a modern-only approach, the associated permissions of the default modern folder roles have been updated.
The Administrator user comes with the following roles at the tenant level: Tenant Administrator, Allow to be Folder Administrator, Allow to be Automation User, and Administrator.
To offer a clearer separation between a folder admin's attributions and those of a tenant admin, we removed robot management privileges from folder-focused roles (Allow to be Folder Administrator and Allow to be Automation User). As a best practice, we recommend creating a separate role consisting of Robots permissions and assign it to users who need it in a controlled manner.
To further simplify access control, we deprecated the Inherit From Tenant assignment model. Existing modern folders that previously used an Inherit From Tenant model are converted, with each user receiving their tenant roles at the folder level as well.
Let’s illustrate the conversion with an example. Let say Petrina Smith works in the Finance and HR folders which previpusly used the Inherit From Tenant permission model. The role inherited from the tenant will be assigned to the user at the folder level, on a per-folder basis. As a result, Petrina is assigned the role in both the Finance and HR folders, as well as keeping it at the tenant level.
For those still clinging to the classical, don't worry. Existing deployments do not lose classic folder support on upgrade, and to further entice you into the future we've also added a migration tool to enable you to quickly and easily move to the new, modern-only world.
To streamline robot migration from classic folders to modern folders, we've made it possible to enable/disable robots residing in classic folders easily. This way, you are presented with a rollback option if a step errors out during migration. You can only disable robots in the following connection states: active, disconnected, unresponsive.
Learn about enabling/disabling robots in classic folders.
To help with delegating responsibilities in your company while keeping packages separate, first-level folders can now be created with a dedicated packages feed. See how here.
Access to the feed is controlled by a new folder-scoped Folder Packages permission set. All subfolders inherit the package feed setting from the root parent.
Personal workspaces come with their own packages feed by default and mark a historical minimum in package deployment efforts. Any package that is added to the workspace gets automatically deployed as a process in the workspace.
Starting now, Orchestrator takes over machine template management from the user. This removes unnecessary overhead from the developer who can begin working in the context of that workspace right away publishing automation projects and launching jobs from Orchestrator for debugging purposes.
Users that work in other folders besides their personal workspace can benefit from the Orchestrator debugging capabilities of their machine template by assigning it to the folders they are working in (i.e., the folders they have been assigned to).
To help new users in their automation journey, we've added a simplified UI profile in Orchestrator for those using personal workspaces. The user experience is stripped down to the functionality available in their workspace. Learn about UI Profiles.
This release graduates key capabilities in personal workspace management, bringing about multiple improvements for all personal workspace administrators and business owners out there.
Keep an eye on all workspaces from a centralized location and give a helping hand to developers in their daily activities by exploring the contents of their workspaces at a glance.
Keeping Orchestrator clean of unused data is now a breeze. You can quickly identify all workspaces with little or no activity, or those which have been orphaned upon employees leaving the organization. The clean-up strategy is at your discretion and is pretty much hassle-free, as you can either delete or convert the workspace into a folder from the convenience of the dedicated Personal Workspaces page.
Enabling personal workspaces for numerous users is now a seamless process with a new feature allowing you to enable workspaces for multiple users at once. The Personal Workspaces section on the Settings page is the dedicated place for that. Here, an administrator can enable personal workspaces for all users in a tenant that use a particular attended licensing profile and don't yet have a workspace to call home.
Read about Personal Workspaces.
If you were looking for better-debugging capabilities, rest assured, as of now, you can select the host machine on which a certain job is launched. Click here for details about jobs.
To ease unattended automation ordeals concerning local Windows users residing on multiple host machines, we ensured that unattended robots impersonating local accounts require the corresponding Windows username and password only. The host machine is no longer a mandatory identifier.
Say you are using LocalUser1 on five host machines. Instead of setting up five user entities in Orchestrator for each combination, you define the unattended robot on one user entity only, using the
.\LocalUser1 syntax in the Domain\Username field. This way, you can use that specific Windows account on each host machine through one Orchestrator user entity only.
Nothing changed for domain-joined accounts, where the robot requires the
domain\username syntax just as before.
To better align with your business needs, we've introduced assets per user, the modern counterpart of classic per-robot assets. Per-user assets improve the logic behind assets in modern folders by creating a precise mapping between the user and the credential used during execution.
For scenarios where a user cannot log in more than once at a time, we've introduced the possibility to restrict concurrent unattended execution. This helps modulate the job allocation algorithm by restricting a user from simultaneously executing multiple jobs.
For better control in terms of HSM providers, you can now choose from the convenience of your Orchestrator tenant which hardware security model to use for retrieving unattended Robot credentials.
This eliminates the need to configure the HSMs at the Robot level and streamlines the authentication experience in unattended scenarios.
Orchestrator has been migrated to .NET Core 3.1 as UiPath strives to reach a new level of scalability, performance, and security. .NET Core 3.1 enables us to keep up with technological innovations and take full advantage of the new framework's capabilities.
Beginning with v2020.10, the
TargetFramework must be upgraded from the previous .NET Framework 4.7.2 to a supported Target Frameworks to maintain Credential Store Plugins and NLog extensions functionality. The target framework of both credential stores and NLog extensions is checked by the
UiPathOrchestrator.msi installer and Platform Configuration Tool. Check the Target Framework section in the docs for details.
In older versions of Orchestrator, the CyberArk credential store plugin used a library that is not compatible with .NET Core. Orchestrator now uses the CLIPasswordSDK.exe tool that comes with CyberArk AIM. See details here.
Proxy configuration is no longer configured in
web.config but in .NET Core. See the documentation about proxy configuration in 2020.10.
Most of Orchestrator's configuration settings have been moved from
UiPath.Orchestrator.dll.config. The new file keeps the same structure as the old
web.config file and is located in the same directory. After making changes to
UiPath.Orchestrator.dll.config, manually restart the website for the new configuration to be applied.
web.config has been repurposed only to contain configuration used by IIS. Upon upgrading, the installer will automatically move the configuration settings to the new configuration file.
Connection strings and application settings are no longer be visible in IIS Manager. Using IIS Manager to edit Orchestrator connection strings or application settings is not supported. You need to edit the configuration file directly.
If you are using custom NLog targets of type
Database, the property
connectionStringName is automatically changed to
connectionString during the upgrade. If you are manually inserting the target in the configuration file after installation/upgrade, use the new property with the correct value. Details here.
We have updated the SignalR library to a newer version which is not compatible with older Robot clients. We recommend upgrading your Robots to 2020.10 in order to use WebSockets, which makes it especially cost-effective for large Robot deployments.
SignalR Redis scaleout requires sticky sessions for all transports other than WebSockets. By default, only WebSockets transport is enabled, as Orchestrator assumes sticky sessions are not enabled on the customer's load balancer.
The scale-out mechanism is switched from SQL Server to Redis during installation. Disabling SignalR authentication for Robots/activities is no longer supported. To this end, the
Scalability.SignalR.AuthenticationEnabled parameter has no effect.
You can encounter delays of up to 30 seconds if you use a Wait Queue Item activity older than 2020.10. Upgrade to the latest activity version to avoid such issues.
While we did our absolute best to make the upgrade process seamless, migrating to .NET Core brought many changes to the plate, including a better, faster, stronger NuGet protocol. We strongly suggest restarting your Robots after upgrading Orchestrator to v2020.10 for a fully polished functioning of your automations.
We updated the internal NuGet feeds' protocol from v2 to v3.
Legacy is no longer supported as a
NuGet.Repository.Type. Upon upgrading, all repositories of type
Legacy are migrated to
Legacy-related application settings are deprecated and no longer have an effect.
We have made significant changes to how we generate the
swagger.json file, which describes the Orchestrator API. If you rely on a client library generator that uses the API description in the Swagger file (e.g., AutoRest, Swagger Codegen), the generated code will be significantly different.
POST requests with parameters in form-data objects no longer works. The only supported mechanism to make
POST requests to Orchestrator is to include the request parameters in a JSON in the request's body.
Orchestrator v2020.10 ships with a better, more robust version of the Platform Configuration Tool, which has been repurposed to assist you with the Orchestrator deployment on multiple fronts. This improved version helps you check your environment's sanity and readiness before an upgrade as well as perform several operations post-installation.
Not only it performs several requirement checks, but it also streamlines the process of changing Orchestrator/Identity Server certificates and URLs post-installation. Learn more about the Platform Configuration Tool.
We’ve added a new tool in Orchestrator’s installation directory to help you encrypt sections in Orchestrator's new configuration file (
UiPath.Orchestrator.Setup.ProtectedConfiguration.Console.exe is a CLI tool wrapped over
aspnet_regiis.exe. The tool accepts all arguments passed to
aspnet_regiis.exe and adds missing .NET Core functionality. Learn about encrypting
A new tool is available to help you encrypt/decrypt the Identity Server and Webhooks
AppSettings.Production.json files. The
UiPath.IdentityServerConfigProtector.exe tool is located in Orchestrator's installation directory, in the Identity folder: C:\Program Files (x86)\UiPath\Orchestrator\Identity\Tools. See here how to use it.
To increase the control you have over your processes, we've added the Always Running Process option on the Process Setting page to restrict process termination from the UiPath Assistant. Learn how to manage processes.
Classification Station is a new feature that enhances human-robot collaboration by allowing humans to review and correct document classification and splitting results. It can be used both as an attended activity (through Present Classification Station) as well as integrated into Orchestrator’s Action Center by leveraging Long-Running Workflows (through Create Document Classification Action and Wait for Document Classification Action and Resume).
You can now configure automatic trigger disabling with two new
Triggers.DisableWhenFailingSinceDays. The trigger gets disabled automatically after a certain number of failed launches (
Triggers.DisableWhenFailedCount) if it hadn’t been successfully launched in a specific number of days (
See details about these
Decrease your time spent on testing by managing your test data through test data queues and synthetic test data creation. The Test Data Queue is your central storage where you can prepare, store, and consume test data. You can expand your testing efforts through test cases that store and consume queues items in and out of the test data queues, on a FIFO (first-in-first-out) order.
A notable addition in this release includes Action Center support for modern folders. If up until now you were restricted to only using it in classic folders, from now on, you can take advantage of all Action Center goodies regardless of the folder type.
We also added a new page exclusively for the Action Admins in your company, such that they are easily able to allocate and assign actions to any Action User from a centralized location.
Among all the usability improvements we are excited about, this release we are incredibly excited about solving some common frustrations regarding processes. Learn more about updating processes at the package level.
To help you identify and differentiate processes from one another, they now inherit the associated package description set at design time in Studio. This happens regardless of whether they are deployed manually or automatically in a personal workspace. You can also add a description to your processes or edit the existing one as you wish, no restrictions imposed. Learn here how to add a process to Orchestrator.
Updating processes across multiple folders to the latest available package version just became easy-breezy with a new bulk update feature, which enables you to upgrade all processes associated with a package. Simply select the target packages, and Orchestrator does the job for you by searching for and displaying all associated processes that do not use the latest available package version. Choose the processes to be updated to the latest available package version, and you’re done.
You can now preview any changes made to the header color and logo such that you can adjust them accordingly before saving your changes.
You can now assign users, user groups, and machine templates directly at the folder level by navigating to the Settings page in a folder context.
Assigning machine templates to folders has been made easier than ever with the addition of new capabilities previously only available on the Machines page. As a result, you can now copy a machine’s key and edit its runtimes directly from the Folders page. Bear in mind, machine templates need runtimes in order to be fit for execution, so make sure you assign some when assigning the machine to a folder.
To have a better, ready-to-hand overview of your Orchestrator statistics, you can now navigate from the job counters on the Home page to the corresponding Jobs page, which is filtered accordingly. For example, if you click the section corresponding to running jobs, the displayed page has the Running state filter applied.
The Processes page now displays the package name associated with each process.
You can now easily update the default roles with any additionally required permissions.
We've taken your feedback into account and renamed some of the predefined roles available on the Settings page. Click here to see the new names and the corresponding permissions for each role..
Enable Folder Administration
Allow to be Folder Administrator
Enable Running Automation
Allow to be Automation User
As of now, the
UiPathOrchestrator.msi installer validates the website hostname against the Subject Alternative Name of the SSL certificate and only resorts to checking the Subject Name if the alternative name is missing.
Secondary node installations can now be performed in silent mode only. Make sure to specify the
PARAMETERS_FILE parameter when doing so.
We improved the migration experience for upgrading to Identity Server-enabled Orchestrator in Azure deployments and added a rollback in case of failed migrations.
Publishing test automations with test cases automatically creates a process if it is not already in place.
Test Schedule creates a new test execution only if the previous run has finished.
Execution Media is now supported for your test executions so that you can view any screenshots taken from failed executions.
Create test sets directly on the Test Cases page.
Test sets created through external tools are now visible only through API and will not be shown on the Test Sets page.
We now perform a couple of additional validations upon uploading test automation packages. In order to successfully upload such a package or package version, make sure the following:
- The package contains at least one entry point.
- The project type is the same in between different versions of the same package.
We improved performance for release version filtering and test set creation.
You can now choose from all available versions when selecting packages for test set creation.
Previously, API requests made using Windows authentication were limited to the first tenant the AD user has been provisioned in. You can now specify the tenant when making API calls using the
X-UIPATH-TenantName header. See an example here.
Retrieve machine session IDs by making a
GET request to the
If you made it this far down, you deserve to know a lot of performance tuning has taken place, and this version brings craaazy improvements in response times.
We know the pain of having your jobs stuck in a Terminating state, so we came up with a couple of solutions to help clean up the clutter. You can now transition jobs to a Terminating state by using the Kill command. Moreover, the new
Jobs.TerminatingJobsCleanupCron parameters allow you to tailor a job cleanup strategy by transitioning jobs in a Terminating state to Failed according to your settings. By default, the cleanup background job runs once every three hours and only transitions to Failed the jobs that have been in a Terminating state for at least one day. See here how to configure the parameters.
We've added a new webhook (
task.saved) for saving actions to notify you whenever an action has been saved prior to completion.
You can now filter logs by the name of the host machine they have been generated on by using the Machine filter on the Logs page. The new filter works retroactively for logs stored in ElasticSearch, while for logs stored in the database, it only works for new log entries.
To keep you notified about everything going on in Orchestrator, we've implemented alerts for Folders and Personal Workspaces. Learn about alerts.
Restarting your v2020.10+ Robots is no longer necessary each time any of the following configurations is changed in Orchestrator:
HearbeatPeriodSeconds, NuGet feed, and SignalR settings.
To improve your troubleshooting experience you can now allow for Orchestrator PII display by adding the following key in
<add key="ExternalAuth.ShowPII" value="true" />. The key is not displayed by default in
UiPath.Orchestrator.dll.config, and the default behavior does not allow for PII display.
The scale-out mechanism is switched from SQL Server to Redis during installation. Disabling SignalR authentication for Robots/activities is no longer supported. To this end, the
Scalability.SignalR.AuthenticationEnabled parameter has no effect.
As of now, the
OData.BackwardsCompatible.Enabled parameter is set to
true by default, meaning Orchestrator parses and preserves special characters by default and no longer uses encoding and escaping mechanisms to transform input data for dynamic properties in OData models (e.g., QueueItem.SpecificContent).
OData.BackwardsCompatible.Enabled defaulted to
false, meaning special characters were encoded/escaped unless you specified the data type when performing an API request, by using the following syntax:
"[email protected]": "#String".
If your automation projects are designed to overcome character encoding/escaping any other way than using the method presented above (such as Regex unescaping expressions), make sure to adjust them accordingly as they might not work from now on. Either that or set
false to preserve past behavior.
An issue has been identified with uploading new files to MinIO buckets. Uploaded files get corrupted and do not work. Files uploaded prior to 20.10.1 are not impacted. This issue has been fixed in v2020.10.3 Orchestrator .
Do not use MinIO storage buckets in 2020.10.1 or 2020.10.2 Orchestrator.
Starting with 20.10, the Resource panel in Studio doesn't list your processes unless you grant the Robot role View permissions on Processes. We added the missing permission in 20.10 Orchestrator; however, if you upgrade from a past version, make sure to grant it explicitly.
Whenever an upgrade fails and rollback is performed, the Administrator role loses Edit permissions on Actions and Create permissions on Action Assignment.
The user is not redirected to the Login page after aborting a Windows login operation.
Custom NLog targets are not automatically migrated during an upgrade. You need to migrate them to Identity Server and Webhooks services manually. See NLog documentation in Identity Server.
Using v3 feed URLs results in a couple of display issues with packages and libraries:
- The publish date of a package (View Versions > Package Versions) is not correct when using v3 external feeds
- For MyGet feeds, the total number of packages is much greater than the actual number of packages uploaded to the feed.
Trying to connect a v2019.4.4 or older Robot to Orchestrator throws a wrong error message when the floating robot is not defined in Orchestrator. This only occurs in classic folders when using a machine template-generated key for the connection. "There are no available licenses on the server" is displayed instead of "Robot does not exist".
"An error has occurred"is displayed on the User Profile page when the Identity Application Pool is either stopped, or recycling is performed.
Package versions that contain the
+symbol are unusable in Orchestrator as they cannot be used to create processes.
Certain antivirus programs can interfere with the IdentityServer migration tool by blocking executables from running in the default windows Temp directory. Specify the 'tmpDirectory' parameter as a workaround.
The localization of Orchestrator feeds in Studio disregards the Robot language settings and causes the feeds to be displayed in English regardless of the Robot language.
Orchestrator does not filter out users that have been disabled in AD. As a result, disabled AD users are available for adding in Orchestrator.
In 2020.4 Orchestrator, you could not edit the email addresses of local users. In this release, we’re adding the option back.
Previously, launching jobs through Start Job activities in non-production environments implied exclusively using Unattended runtimes to execute them. If none were available, the jobs remained in a Pending state. As of now, if there are no Unattended runtimes available, NonProduction runtimes are consumed.
An error message (
An unexpected error occurred (500). The chunked cookie is incomplete.) was thrown when you tried to authenticate using Windows Authentication in Chrome. This occurred for users belonging to multiple AD groups, as the browser cookie size limit was exceeded.
The error message resulted from incorrectly creating or updating a credential store that was not displayed on the Alerts page, and no detail about the misconfiguration was available.
Killing a test execution job resulted in an incorrect job state in Orchestrator.
Reordered the Test Schedules Remove, Enable, and Disable buttons to improve UX consistency.
Users with Folder Administrator roles did not have access to testing features after meeting the prerequisites unless granted manually.
Disabling test automation did not disable any running test schedule.
For Azure deployments, users were occasionally redirected to a blank Identity Management Hub page. This has been corrected with the addition of the
-orchestratorUrlparameter for Azure deployment scripts.
When attempting to logout, the user would instead be redirected back to Orchestrator home page.
During an upgrade, when moving to
compositeNuGet Package storage the packages were not migrated to the correct location.
The Orchestrator installer did not properly validate the certificate alternate subject name.
On rare occasions, the same job was being triggered on multiple machines simultaneously. This occurred on machines that were connected to Orchestrator using the same machine template.
Previously, you could not edit user groups with names longer than 32 characters. We have increased the character limit for group names (Group or Username field) to 256.
Updated 26 days ago