- Getting Started
- Requirements
- Best Practices
- Installation
- Updating
- Identity Server
- Troubleshooting startup errors
Installation Considerations
This article identifies the main affected areas you should be aware of in a new Orchestrator deployment. 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.
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 UiPathOrchestrator.msi installer.
This restriction also applies to any references that a plugin or NLog extension might have.
|
Supported target frameworks | Supported versions |
|---|---|
|
.NET Standard |
1.0 - 1.6 |
|
.NET Standard |
2.0 (recommended) |
|
.NET |
8.0 |
You may need to recompile any Credential Store plugins and NLog extensions you developed in-house.
.dll files 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 .nupkg file, open it as a .zip, navigate to the folder lib\) etstandard2.0 and use the .dll file from there.
CLIPasswordSDK64.exe tool that comes with CyberArk AIM.
CLIPasswordSDK64.exe in the default CyberArk AIM installation path,
namely C:\Program
Files(x86)\CyberArk\ApplicationPasswordSdk\CLIPasswordSDK64.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 appSettings
section in web.config prior to the installation or in the
UiPath.Orchestrator.dll.config after the installation.
Example:
<add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK64.exe" /><add key="Plugins.SecureStores.CyberArk.CLIPasswordSDKExePath" value="D:\CustomFolder\CLIPasswordSDK64.exe" />In .NET Core there are two mechanisms for specifying the proxy:
Using environment variables
web.config using the following syntax: <environmentVariable name="[insert_variable_here]" value="[insert_address_here]" />, for example <environmentVariable name="HTTP_PROXY" value="http://127.0.0.1:8080" />.
| Variable | Description |
|---|---|
HTTP_PROXY | The proxy server used on HTTP requests. |
HTTPS_PROXY | The proxy server used on HTTPS requests. |
ALL_PROXY | The proxy server used on HTTP and/or HTTPS requests in case HTTP_PROXY or HTTPS_PROXY are not defined.
|
NO_PROXY | A comma-separated list of host-names that should be excluded from proxying. |
Examples:
- Without authentication:
ALL_PROXY=http://localhost:8888 - With authentication:
ALL_PROXY=http://user:password@localhost:8888
Using the default proxy system (IE settings or Windows Proxy settings), if the environment variables are not set
See official Microsoft documentation here.
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><system.net>
<defaultProxy>
<proxy usesystemdefault="True" proxyaddress="http://<ip>:<port>" bypassonlocal="True" />
</defaultProxy>
</system.net>web.config to 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
- appSettings
- 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.
Check web.config docs.
Check UiPath.Orchestrator.dll.config docs.
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.
connectionStringName property has been replaced by connectionString. Its value must use the following syntax: connectionString="${ui-connection-strings:item=Default}", where Default is the name of the connection string you want to use from the <connectionStrings> section.
See docs on Targets of the Orchestrator Execution Logs.
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.
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.
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.config to 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.config without enabling them on the load balancer will result in failed SignalR connections.
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.
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 Composite.
NuGet.Packages.Path and NuGet.Activities.Path parameters in web.config for the previous Orchestrator version.
- If you stored the packages in the default locations (
~/NuGetPackagesand~/NuGetPackages/Activities), the new package location becomesRootPath=.\Storage. - 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_TYPEandSTORAGE_LOCATIONparameters become mandatory, unless you specify them inweb.configprior to the upgrade.
UiPath.Orchestrator.dll.config. After the upgrade, all Legacy-related app settings become deprecated and no longer have an effect.
NuGet.Packages.PathNuGet.Activities.PathNuget.EnableRedisNodeCoordinationNuget.EnableNugetServerLoggingNuGet.EnableFileSystemMonitoringNuGet.Repository.Type
Composite repositories.
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.
- .NET Core 3.1
- Target Framework
- Credential Store Plugins - CyberArk
- Proxy Configuration
- Configuration Files
- Web.config
- IIS Manager
- NLog Targets
- SignalR Protocol
- SignalR With WebSockets
- SignalR Scaleouts Sticky Sessions
- SignalR SQL Server Scaleout
- Wait Queue Item Activity
- NuGet Infrastructure
- Legacy Repositories
- Swagger Library
- API Changes
- APIs With Form POST Parameters
