2020.10.4

Release date: 15 December 2020

What’s New

CyberArk CCP Integration

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

Overview

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.

Upon upgrading to v2020.10.4, CyberArk CCP is enabled automatically if you had CyberArk enabled in your instance prior to upgrading. If that is not your case, add UiPath.Orchestrator.SecureStore.CyberArkCCP.dll to the Plugins.SecureStores parameter in UiPath.Orchestrator.dll.config to enable it.

Improvements

Job Count 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 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.

Persistence Activities Support

In this release, we've added support for persistence activities in queue item-based workflows. Previously, Orchestrator would abandon queue items that have been in progress for more than 24 hours, thus interfering with long-running workflows that exceeded the 24-hour barrier. This limitation has been removed, making it possible for you to get human input in regards to your transactions without being pressed for time.

Important: This feature was not delivered in 2020.10.4, as stated in the release notes, due to a mishap on our part. It is our priority to add it to the following Orchestrator patch. The 24-hour limit for ongoing queue items continues to exist until our team includes it in the next release.

Setup

• We now recommend using the passive mode for secondary node installations. You can specify the /passive parameter to enable a limited user interface with a progress bar and error popups. While only silent mode was previously available, you should now use /Q strictly for unattended installations.

Others

• 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.
• Orchestrator functionality can be impaired if the <system.webServer> element in web.config contains any locked sections. For this reason, we added an extra check in the Platform Configuration Tool which checks the entire <system.webServer> element for any locked sections. If such sections exist, you need to manually unlock them in IIS.
• To avoid confusion about what the Always Running Processes toggle button does, we renamed it to Process can’t be stopped from UiPath Assistant. It means that if you enable this functionality from the Processes settings page, you won’t be able to stop the corresponding process from the UiPath Assistant.

Bug Fixes

• All logs generated prior to 2019.10 were displayed on the Logs page without being filtered by the containing folder (formerly organization unit). We added and enabled by default a new UiPath.Orchestrator.dll.config setting (Logs.Elasticsearch.EnableFolderIdFilter) which prevents logs that cannot be filtered from being displayed on the Logs page. You can still see such logs by navigating to Logs from the Robots (classic folders) and Jobs pages (More Actions > View Logs).
• Whenever an upgrade failed and rollback was performed, the Administrator role lost Edit permissions on Actions and Create permissions on Action Assignment. The role now keeps both even in case of a failed upgrade.
• Due to appSettings having been moved from Web.Config to UiPath.Orchestrator.dll.config, the Configure-PlatformNode.ps1 script would cause single- to multi-node migrations to fail. The script no longer throws an error.
• Package migration did not clean up the imported but unused Storage folder following a failed upgrade. Leftover content is now removed.
• The UiPathOrchestrator.msi installer would not check for available disk space before the upgrade started, which could cause the package migration to fail. Now a warning is issued before the migration begins.
• UiPathPlatformInstaller.exe did not validate SSL certificates with specific subject formats, which resulted either in an installation failure or upgrade warning.
• Using Windows Authentication during an upgrade prevented the UiPathOrchestrator.msi installer from validating the credentials. This caused the upgrade process to be unsuccessful.
• The argument type was not validated in Orchestrator, allowing users to set unfit parameter values for their processes. Validation is now properly performed and an error is thrown if the input does not match the argument type set at design time.
• Deleting a classic folder did not remove the associated users. Users are now deleted upon deleting a classic folder.
• Upgrading from v2020.4 to v2020.10 Orchestrator unassigned Active Directory users from modern folders based on the Inherit from Tenant permission model. This occurred despite having the parent Active Directory group assigned to the folder.
• Deleting asset credentials residing in read/write credential stores only deleted them from Orchestrator. From now on, deleting an asset credential in Orchestrator also removes the associated credential object referenced in the credential store. Please ensure asset credentials to be deleted are not used in other places such as automation projects.
• User sessions did not time out after the inactivity timeout period has ended, preventing users from being logged out of their session as expected.