Overview

---

You can directly update Orchestrator to 2022.4 if you currently use any of the following versions:

• 2021.x
• 2020.x
• 2019.x

🚧

Important!

If you use version 2018.4 you need to upgrade to 2019.x or 2020.x or 2021.x and then jump to 2022.4.
If you use a version lower than 2018.4, you need to upgrade to v2018.4 or v2019.x or 2020.x, and then jump to 2022.4.

We recommend using 2019.10 as an intermediate version.

To see the latest available versions, please check the Release Notes page.

Preinstallation Checklist

---

Before proceeding with an Orchestrator upgrade/installation, carefully review the following task list:

Directly Updating Orchestrator

---

Installation artifacts are provided when you first purchase Orchestrator or they can be provided by your customer success manager or our support team. There are a few ways to directly update:

Using the Windows Installer

UiPathOrchestrator.msi performs an in-place update that copies all your settings and creates a backup folder for the old version. It is suitable for both one node and multi-node architecture. Some web.config settings are not copied if the version you are upgrading from was installed using the deprecated scripts. The repair functionality of the Windows Installer is not supported.

If the Orchestrator you want to update was installed using the now deprecated UiPathPlatformInstaller.exe, use the Windows installer to update to this version.

Learn how to update using the Windows installer.

Using the Azure Script

A complex update of Orchestrator and its components on one or multiple nodes, in the Azure Portal.
Learn how to update using the Azure script.

Update Considerations

---

Encryption

During an Orchestrator update, the installer cannot read an encrypted SecureAppSettings section within web.config . In order to read the EncryptionKey from Orchestrator's web.config and then migrate it into Identity Server's appsettings.Production.json, the key must be plain text. You need to manually decrypt the section before updating Orchestrator. After the Orchestrator update process was finalized, remember to re-encrypt the SecureAppSettings section in web.config.

Certificates

Note the new certificate requirements. If your existing certificate doesn't meet them, here is how to get a valid certificate and how to replace it in the existing Orchestrator instance, before upgrading.

For security reasons, for the certificate used to sign the access tokens generated by the Identity Server, make sure to use a public key on 2048 bits. The certificate's location has to be set within appsettings.Production.json's Signing Credential section.

Database

Regardless of how you choose to update, if the database you point to does not exist, it is automatically created while running the update. If you point to an existing database, it is updated during the same process. The Orchestrator SQL database is automatically set to be case-insensitive (“OrchDB” = “orchdb”) at installation.

External Providers

While performing the update, if you have any external providers enabled in web.config, you are prompted about the manual changes you need to perform on your preexistent external providers. Read here about the manual changes you need to perform.

Users

When upgrading to the latest Orchestrator version, all your local accounts are automatically migrated from Orchestrator to Identity Server and converted to the required format.

This change does not impact your robots.

If you were ever on version 2018.4 and have never completed this conversion for users imported from Active Directory (or did not convert all imported users), those directory accounts that were not converted must interactively log in to Orchestrator at least once to finalize the conversion. Signing in to the Identity Management portal, or signing in from UiPath Studio or UiPath Assistant does not complete the conversion of the account.

Once the conversion is complete, you can no longer use basic authentication to log in with the respective users.

Application Pool identities

While upgrading to the latest Orchestrator version, we strongly recommend to use the same Application Pool identity type for Identity Server and Webhooks as the one used for Orchestrator during the original installation.
For example, if you set the Application Pool identity type as a custom account during the Orchestrator v2020.10 installation, while upgrading to v2021.10, select the same Application Pool identity type (i.e., custom account) for both Identity Server and Webhooks applications. Otherwise, the access to the SQL server may be blocked.

Known Issues

Some antivirus software can prevent Data Migration scripts from functioning correctly during an upgrade.

After updating your Orchestrator from 2019.10 or older, the Profile page won't display login attempts previous to that update.

Updating Your License After Installation

---

After you upgrade or migrate Orchestrator, we recommend that you update your license information from the Licenses page using either online or offline activation. For instructions, see Activating Your License.

If you are upgrading or migrating from a version that is older than 2019.10, you must update your license information, otherwise you do not benefit from the grace period at license expiration, which can cause service disruption.

Package Migration

---

In v2020.10+, Legacy is no longer a supported NuGet repository type. Packages previously residing in a Legacy repository are migrated to a Composite repository. For composite repositories, package location is configured using the Storage.Type and Storage.Location parameters in UiPath.Orchestrator.dll.config. After the upgrade, all Legacy-related app settings become deprecated and no longer have an effect:

• NuGet.Packages.Path
• NuGet.Activities.Path
• Nuget.EnableRedisNodeCoordination
• Nuget.EnableNugetServerLogging
• NuGet.EnableFileSystemMonitoring
• NuGet.Repository.Type

The new package location depends on how you configured the NuGet.Packages.Path and NuGet.Activities.Path parameters in web.config for the previous Orchestrator version.

Default Location

If you stored the packages in the default locations (~/NuGetPackages and ~/NuGetPackages/Activities), the new package location becomes RootPath=.\Storage.

Custom Location

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_TYPE and STORAGE_LOCATION parameters become mandatory, unless you specifically add them in web.config (Storage.Type and Storage.Location) prior to the upgrade.

Packages Migration Matrix

The matrix below describes when the STORAGE_TYPE and STORAGE_LOCATION parameters are requested or ignored during an upgrade. The matrix takes into consideration the version you are upgrading from, as well as the package location customization in both the previous version and in 2020.10 and later.
For example, based on this feature combination, the matrix shows that the two parameters are requested (flagged with a check mark) in Silent Mode for an upgrade from version 2019.4+ if the package was stored in a custom location, but its new storage location is a default one.

Migration Errors

If, for any reason, package migration fails, you are presented with the following options:

• Retry - Package migration is restarted. Packages that have already been migrated are skipped.
• Abort - The installation is restarted. During the migration step, packages that have already been migrated are not skipped and are migrated again. For this reason, you may find duplicate files in different containers. This only happens when migrating from versions older than 2019.4.
• Continue - The migration is being carried on with.