Share via


AD RMS Parallel Upgrade

Issue

There may be times where it is necessary to upgrade the current AD RMS version (e.g. from 2012 R2 to 2022). This article is applicable to all supported versions of AD RMS.

Consideration

The upgrade process described in this document provides a production AD RMS cluster upgrade that does NOT affect the current production environment. Therefore the upgrade may take place during business hours, be tested and verified without any interruption to the existing cluster. If the upgrade fails or does not meet the desired outcome it may be removed while the existing infrastructure keeps processing against the production environment.

The process

  1. If the cluster key password is not known, follow this link to set it.
  2. Back up the existing AD RMS database.
  3. Restore the AD RMS databases to a new location (new instance, new SQL server, etc.).
  4. The following SQL changes must be made on the restored databases.
    1. Database: DRMS_Config
    2. Table: DRMS_ClusterPolicies
    3. PolicyName entries in which the PolicyData value needs to reflect the new SQL connection string information. This link discusses one option to update the records.
      • LoggingDatabaseServer
      • CertificationUserKeyStorageConnectionString
      • DirectoryServicesCacheDatabase
  5. Stand up a new Windows Server of the desired version for the AD RMS cluster upgrade.
  6. Add the AD RMS role.
  7. When it gets to the role configuration choose the “join an existing cluster” option.
  8. At the SQL database dialog enter the NEWLY RESTORED SQL database location, not the actual production database currently in use.
  9. Complete the role configuration using all the same settings, service accounts, etc.
  10. Edit the NTFS permissions on new AD RMS server's "C:\inetpub\wwwroot\wmcs\certification\ServerCertification.asmx" file. Configure the same permissions as on the existing AD RMS server.

How this works

At the end of the last step we have an AD RMS server, of the desired version, running against (a restored copy of) the production DB. However it is separate from the existing production cluster, using its own set of databases. Now the upgraded version of the production cluster may be tested until it is deemed production ready.

Testing against the upgraded production server

The easiest way to test the new server is via a HOSTS file on select clients. On a client machine add a HOSTS file entry pointing the AD RMS cluster URL FQDN to the new server’s IP address. Do an “ipconfig /flushdns” on the client and test away. Since both the existing AD RMS production cluster and the new upgraded server use the same RMS keys the test clients may send and receive protected content to/from any other users.

Moving to production (or not)

If, for whatever reason, the upgraded AD RMS server does not work, simply tear it down. Get rid of the restored copies of the production RMS SQL DBs and start over with a new test server if desired. The production environment was never altered by this parallel upgrade so there is nothing to do to it.

If the upgraded server meets the requirements it may become the production server. Just change DNS so that the AD RMS cluster FQDN resolves the new server’s IP address. Eventually all clients will resolve the new server as the AD RMS cluster and use it.

What’s Next?

Part of the upgrade process alters the SQL databases AD RMS uses. Thus a 2008 R2 SP1 AD RMS server cannot function against a 2012 R2 AD RMS server database. Once one server has been upgraded in a cluster the down level servers no longer issue licenses. At this point just add additional new servers of the same OS version to the new production cluster. These servers use the new AD RMS server database and not the new ones (which is specified during the “join an existing cluster” process.

Once satisfied the new cluster is functioning as expected the old cluster may be turned off. The following link may be utilized to remove the old servers out of the database. This is not necessary and just a cosmetic task.

Back to Top