Disaster recovery for Microsoft Rights Management (RMS) service

  • Article

Many customers have been asking me if they should have a disaster recovery plan for Microsoft Rights Management Service (RMS). As with any IT service, you should be prepared to restore RMS functionality after failure or physical destruction. Since RMS is implemented as a web service, with all configuration data stored in a SQL database, RMS disaster recovery is mostly focused on recovery of the SQL database. RMS disaster recovery minimally requires the Config database (you should also make sure to include the sysmessages table from the master database in your back up. If this table does not include the RMS-specific messages, the root certification server will not be able to function and will return an error), though it is recommended that you also backup the Logging database for reporting and audit purposes. The Directory Services database is used for group expansion caching and does not need to be backed up. The RMS server itself does not have to be backed up; you could simply rebuild new Windows Server 2008 systems as needed if that approach is judged to be more cost effective.

To restore a single RMS server from a cluster, rebuild the server, reinstall RMS and then join the server to the cluster by using the existing database. This activity does not affect the users of the RMS system because the clustered servers operate as one.

The recommended steps for you to follow when restoring a failed or destroyed RMS Service are as follows:

  • Restore the Config/Logging databases (and sysmessages table) on the SQL Server if necessary
  • Install RMS on the system that will be functioning as the new RMS server (which may be the original hardware)
  • Provision RMS
  • Remove existing SCP from AD
  • Use same service account and password
  • Use same private key password (or HSM module)
  • Use same URLs (to preserve access to existing content)
  • Register the SCP