2021.10.1

Release date: 7 December 2021

What’s New

New Mechanism for Launching Jobs Via Queue Triggers

Important: This release marks a significant change in how Orchestrator launches jobs via queue triggers. The new behavior is enabled by default and cannot be turned off. Read the release note carefully before upgrading to 2021.10.1. If you are unsure, stay tuned for the next patches in which we will further address the behavior.

In this patch, we've changed the logic behind queue triggers by accounting for both New and In Progress queue items when computing the number of target jobs that must be reached. Previously, only new items were considered, so whenever there were fewer new items than items in progress, no jobs were launched despite robots being idle. This happened because the number of running jobs (i.e. actively processing queue items) would exceed the number of target jobs (jobs needed to process new items).

Here's an example to better understand the behavior before and after the change:

Say we have a queue trigger defined as follows:

Field	Value
Minimum number of items to trigger the first job:	1
Maximum number of pending and running jobs allowed simultaneously	100
Another job is triggered for each ___ new item(s)	1

Replication steps and behavior previous to this change:

1. Add 3 queue items to the queue. Orchestrator computes the number of target jobs based on the number of new items => 3 target jobs are needed. Orchestrator launches 3 jobs to process the 3 queue items. The 3 items move to In Progress.
2. Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new items => 2 target jobs are needed. Orchestrator does not launch any other new jobs since the number of target jobs is lower than the number of running jobs.
3. Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new items => 4 (2+2) target jobs are needed. Orchestrator launches 1 job so as to reach the target of 4.

Replication steps and behavior after this change:

1. Add 3 queue items to the queue. Orchestrator computes the number of target jobs based on the number of new and in-progress items => 3 target jobs are needed. Orchestrator launches 3 jobs to process the 3 queue items. The 3 items move to In Progress.
2. Add another 2 new items to the queue. Orchestrator computes the number of jobs based on the number of new and in-progress items => 5 (3+2) target jobs are needed. Orchestrator launches 2 new jobs to reach the target of 5.

Logging Runtime Exceptions to Elasticsearch

To provide better visibility into runtime issues such as permission problems or connection failures, Orchestrator now logs runtime exceptions to Elasticsearch.

S3 Compatible Storage

Plug and play your S3 compatible storage with Orchestrator and take advantage of all its unique benefits: scale, cost and reliability.

Learn how to enable S3 compatible providers for creating storage buckets in Orchestrator.

Learn how to create and configure storage buckets.

Azure AD at the Organization/tenant Level

Starting with this release, the integration with Azure Active Directory (Azure AD) is also available at the organization/tenant level (each organization comprises one tenant).

An integration with Azure AD was already available at the host level, which allows you to leverage it for SSO. With this change, if the Azure AD integration is configured at the organization/tenant level, you benefit from SSO, but also from directory search and automatic user provisioning.

For more information and instructions, see Setting up the Azure AD integration.

Custom AIMWebserviceName

From now on, you can give a custom name to the Central Credential Provider web service. To this end, a new field is available when configuring a CyberArk CCP credential store that allows you to set the service name, Web Service Name. Leaving this field empty means the default name is used: AIMWebService.

Improvements

Performance

• Wondering what the latest developments are in terms of Orchestrator performance? We are happy to announce that standalone Orchestrator allows you to connect up to 300,000 attended robots with interactive sign-in in a 15-node IaaS deployment. For a detailed account of the latest performance improvements, see Scaling Your Deployment.

Setup

• In both clean installations and upgrades, Update Server now defaults to the existing Orchestrator database instead of its own database.
• We introduced five new command line parameters to add flexibility in configuring and customizing the connections to your Orchestrator databases. Include them in an Orchestrator silent installation command, either clean installations or upgrades. You can also add the new parameters in the parameters.JSON file.

  Find out which are the new parameters and see some examples on how to use them in our installation guide.

• Publish-IdentityServer.ps1 now has two new mandatory parameters: -orchDetails and -identityServerDetails. These are hash tables that contain the following values for Orchestrator and Identity Server, respectively: resourceGroupName, appServiceName, and targetSlot. For more on this, see Publish-IdentityServer.ps1 Parameters.

Password Policy

We have made the following changes to host-level security settings, available in the host Management portal:

• We now allow the value of the Minimum password length field to be within the range from 1 to 256. Previously, the maximum allowed value was 14.
• We now allow the value of the Days before password expiration field to be within the range from 0 to 1000. Previously, the maximum allowed value was 120.

Known Issues

Note: The UiPathOrchestrator.msi installer only works with ASP.NET Core Hosting Bundle 3.0.x or 5.0.0-5.0.2.

• The default SignalR setting in Orchestrator (with only the Websocket transport selected) prevents the corresponding remote robot utility UiPath.RemoteDebugging.Agent.exe from executing in multi-node environments (either standalone or Automation Suite installations). To correct this behavior, select all available SignalR transports - WebSocket (default selection), Server-Sent Events (SEE), and Long polling - and enable sticky sessions on the load balancer.
• After upgrading to Orchestrator 2021.10, starting the application may return an "HTTP Error 500.30 ASP.NET Core app failed to start" error message.

  This happens because the configuration system fails to initialize and returns the following exception:

  "Exception Info: System.Configuration.ConfigurationErrorsException: Configuration system failed to initialize -System.Configuration.ConfigurationErrorsException: Unrecognized configuration section system.web. (C:\Program Files (x86)\UiPath\Orchestrator\UiPath.Orchestrator.dll.config line 228)".

To prevent this behavior, correct the UiPath.Orchestrator.dll.config file by removing the following configuration sections and their corresponding subsections:

• <system.web>
• <system.webserver>
• <system.webServer>
• <system.serviceModel>
• <nwebsec>
• <system.net>

• Updating your Orchestrator version to 2021.10 may return the following error:

Updating failed with the following error: System.Exception: Error:-1, Message:An error occurred while migrating orchestrator data during post migration. DomainUnreachable at UiPath.OrchestratorCAs.IdentityDatabaseManager.RunDbMigrationToolObfuscatedLogging(String arguments, String[] tokensToObfuscate) at UiPath.OrchestratorCAs.IdentityDatabaseManager.MigrateUsersFromOrchestratorDbOnIdentityDecoupledInstall(String webConfigPath, String identityPublicUrl, String orchestratorDBConnectionString, String identityDBConnectionstring, String secretsFilePath) at UiPath.OrchestratorCAs.IdentityDatabaseManager.ApplyDbMigrationsOnIdentityDecoupledInstalling(String webConfigPath, String identityAppSettingsJsonPath, String orchestratorUrl, String identityPublicUrl, String orchestratorDbConnectionString, String identityDbConnectionstring) at UiPath.OrchestratorCAs.CustomActions.Deferred.UpdateConfigurationAndDatabasesAction.ApplyIdentityDbConfigMigrations() at UiPath.OrchestratorCAs.CustomActions.Deferred.UpdateConfigurationAndDatabasesAction.Execute() at UiPath.OrchestratorCAs.CustomActions.Base.BaseCustomAction.InternalExecute

To prevent this behavior, make sure the installation is run by a domain user with domain access. To verify the domain user has access, run the following shell command:

$domain="WindowsAuth.Domain" $context = new-object System.DirectoryServices.ActiveDirectory.DirectoryContext("domain",$domain) [system.directoryservices.activedirectory.domain]::GetDomain($context)

Bug Fixes

• Orchestrator did not render correctly time formats on the Logs page when the Orchestrator language was set to Chinese, Japanese or Korean. 0 characters were rendered as slashed zeros and prevented the glyph following the 0 from being displayed. For example what should have been displayed as 11時20分03秒 is rendered as 11時2Ø03秒.
• Occasionally, when starting/restarting your Orchestrator machine, one of the nodes showed errors and was rendered unusable. This is no longer an issue.
• Deadlocks would occur in Orchestrator 2020.10.10 environments where queue item processing took less than a second per queue item. Processes would throw multiple "An error has occurred. Error code: 0" errors before crashing. The issue has been fixed and you are now able to process queue items without running into deadlocks.
• When configuring system email notifications, the Test Email Settings button could not be used when Use Default Credentials was selected if the SMTP Username and SMTP Password fields were blank.