Upgrading Secret Server with Web Clustering

This topic only applies to Secret Server On-Premises.

Introduction

Secret Server has a built-in Web installer. The Web installer is a series of pages inside Secret Server that allow you to download and run updates. Secret Server is accessible to users for most of the upgrade process. You can bring down outside access to the site if you want to prevent users from making changes during the upgrade. Preventing user access makes restoring the database and site backups simpler if you decide to roll back the upgrade immediately afterward.

You do not need to download the installer or setup.exe.
Please see the Secret Server On-Premises Upgrade Checklist prior to upgrading. Back up your Secret Server folder and database before performing the upgrade.
Never overwrite or delete your encryption.config file.
Distributed engines automatically upgrade.

Before Beginning

  • Ensure that you have account credentials information and access for the server hosting Secret Serverand the SQL Server instance hosting your Secret Server database.

  • Have a recent backup of the application files and database available.

  • If you use clustering, stop the application pools on all of the servers.

Upgrading a Clustered Environment

  1. Follow the instructions in Upgrading Secret Server or Upgrading Secret Server Without Outbound Access as applicable to upgrade one server.

  2. Once upgraded and working, copy the Web application folder (without the database.config or the encryption.config files) to all secondary servers, and replace the content of the existing Web application folder with the new version.

  3. If the Delinea Management Server is installed and clustered, you need to copy the Delinea Management Server directory to the secondary servers as well. This directory is included by default for new installs of Secret Server 10.2 and above. The Delinea Management Server is used by advanced session recording and Privilege Manager. If the Delinea Management Server folder and site do not exist in IIS, then no additional actions are needed beyond copying the Secret Server directory.

  4. Start secondary servers and confirm they still work.

When copying the application files of the upgraded node, the log folder is optional.

EFS and DPAPI Encryption

When upgrading, after the initial cluster configuration, you do not need to copy the database.config or encryption.config files to the other servers. If you need to copy those files because the database configuration changed and uses DPAPI, disable DPAPI encryption in Secret Server by going to Admin > Configuration and clicking Decrypt Key to not use DPAPI, located on the Security tab, before copying those files to secondary servers.

EFS encryption is tied to the user account running the Secret Server application pool, so it is not machine specific. Copying EFS encrypted files between Secret Server instances will not result in errors, but is not needed.

Upgrading Database Mirroring

  1. If there is more than one Web server running Secret Server, ensure all instances are pointing to the same database.

  2. Stop all but one of the web servers.

  3. Perform the upgrade on that single instance.

  4. Once upgraded and working, copy the Web application folder to all secondary servers.

  5. Start the secondary servers, and confirm they work.

  6. Ensure all instances are properly activated.

  7. Ensure that the database changes have been replicated to the mirror database.

  8. If the secondary Web server was pointing originally to the secondary database, adjust it to point back to the secondary database.

Upgrading Remote DR Instances

  1. Perform the upgrade on one instance.

  2. Backup that instance.

  3. Copy the database backup to the remote DR instance.

  4. Restore the database.

  5. Once the instance is upgraded and working, copy the Web application folder (but not the database.config or the encryption.config files) to the remote DR instance (overwriting the existing files).

  6. Restart IIS or recycle the application pool running Secret Server on the remote DR instance.

  7. Confirm that the remote DR instance is working correctly.

Error Conditions

Error(s) that may arise if the following condition(s) exist:

The version does not match: If a node is not properly updated from the source node after an upgrade, that node will not run because the application version does not match the database. The solution is to copy the application folder (minus the database.config or encryption.config files) and to replace the files on the secondary server.