This article identifies the main areas impacted by a new Orchestrator deployment that you should be aware of. Some of the items addressed in this article must be taken care of prior to an upgrade/installation. Several of them are validated by the installer or by the Platform Configuration Tool if you choose to use it. We highly recommend that you download and use the Platform Configuration Tool to validate your environment prior to an upgrade.
To maintain Credential Store Plugins and NLog extensions functionality, the
TargetFramework must be upgraded from the previous .NET Framework 4.7.2 to a supported target framework. The target framework of both credential stores and NLog extensions is checked by the
Supported Target Frameworks
You may need to recompile any Credential Store plugins and NLog extensions you developed in-house.
You may need to identify and copy to the Orchestrator directory other
.dllfiles targeting specified target frameworks. Most NLog targets support the specified target frameworks; however, you must ensure you copy the right
.dll. For example, if you use
NLog.Targets.Splunk, you need to download the
.nupkgfile, open it as a
.zip, navigate to the folder
lib\netstandard2.0and use the
.dllfile from there.
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.
The plugin searches for
CLIPasswordSDK.exein the default CyberArk AIM installation path, namely
C:\Program Files (x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK.exe. If CyberArk AIM was not installed at the default path, a configuration entry must be added in
UiPath.Orchestrator.dll.config, pointing to the actual path. The path can be specified in the
web.configprior to the installation or in the
UiPath.Orchestrator.dll.configafter the installation.
<add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK.exe" />
Proxy configuration is no longer configured in
web.config using the
<defaultProxy> tag. Example of configuration that is no longer supported:
<system.net> <defaultProxy> <proxy usesystemdefault="True" proxyaddress="http://<ip>:<port>" bypassonlocal="True" /> </defaultProxy> </system.net>
In .NET Core there are two mechanisms for specifying the proxy:
Environment variables can be set in
web.config using the following syntax:
<environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, for example
<environmentVariable name="HTTPS_PROXY" value="https://127.0.0.1:8080" />.
The proxy server used on HTTP requests.
The proxy server used on HTTPS requests.
The proxy server used on HTTP and/or HTTPS requests in case
A comma-separated list of host-names that should be excluded from proxying.
- Without authentication:
- With authentication:
Using the default proxy system (IE settings or Windows Proxy settings), if the environment variables are not set.
See official Microsoft documentation here.
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. Please remember that changing the
UiPath.Orchestrator.dll.config file does not restart IIS. The following sections were moved:
- connection strings
- NLog configuration
- Quartz configuration
- the encryption key
web.config has been repurposed to only contain configuration used by IIS. Upon upgrading, the installer will automatically move the sections mentioned above to the new configuration file. It will transform the configuration left in
web.config to match what is needed for Orchestrator's latest version. Customer customization, including disabled verbs, enabled/disabled modules, custom rewrite rules, are preserved.
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.
For NLog targets of type “Database”, the
connectionStringName property has been replaced by
connectionString. Its value must use the following syntax:
Default is the name of the connection string you want to use from the
See docs on Targets of the Orchestrator Execution Logs.
If you are using custom NLog targets of type
Database, the property
connectionStringNameis automatically changed to
connectionStringduring the upgrade. If you are manually inserting the target in the configuration file after installation/upgrade, use the new property with the correct value.
We have updated the SignalR library to a newer version which is not compatible with older Robot clients. To keep notifying unattended Robots when jobs are available, a compatibility mechanism was implemented, simulating the old SignalR protocol over Long Polling. Robots older than 2020.10 connect to Orchestrator via Long Polling only.
We recommend upgrading your Robots to 2020.10 in order to use WebSockets, which makes it especially cost-effective for large Robot deployments.
SignalR scaleouts require sticky sessions for all protocols other than WebSocket (i.e., SSE and Long Polling).
By default, only the WebSocket transport is enabled by default, as Orchestrator assumes sticky sessions are not enabled on the customer's load balancer.
<add key="Scalability.SignalR.RequireStickySessions" value="true" />key in
UiPath.Orchestrator.dll.configto enable sticky sessions. If set to
true, all transports are enabled, and Orchestrator assumes sticky sessions are enabled on the load balancer. Enabling sticky sessions in
UiPath.Orchestrator.dll.configwithout enabling them on the load balancer will result in failed SignalR connections.
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 been deprecated.
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.
We updated the internal NuGet feeds' protocol from v2 to v3.
Legacy is no longer a supported NuGet repository type. Upon upgrading, all repositories of type
Legacy are migrated to
The new package location depends on how you configured the
NuGet.Activities.Path parameters in
web.config for the previous Orchestrator version.
- If you stored the packages in the default locations (
~/NuGetPackages/Activities), the new package location becomes
- If you stored the packages in a custom location, during the installation you are asked for a new storage location. For silent installs, the
STORAGE_LOCATIONparameters become mandatory, unless you specify them in
web.configprior to the upgrade.
In v2020.10+, package location is configured using the
Storage.Location parameters in
UiPath.Orchestrator.dll.config. After the upgrade, all
Legacy-related app settings become deprecated and no longer have an effect.
The use of copy-paste commands in the packages-dedicated folder is not supported for
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.
You may need to update any other custom tools that use the autogenerated client.
POST requests with parameters in form-data objects no longer works.
The only supported mechanism to make
POSTrequests to Orchestrator is to include the request parameters in a JSON in the request's body.
Updated 6 days ago