First post in the 'Ask John' series
 
Question
 
We have deployed RMS on single server and wants to migrate ( move ) RMS to another server. Of course we do not want to lose previous permissions. What is the best way for it ?
 
John says:
 
It can be very simple, as long as the following two conditions are met:
 
1)     The Intranet Cluster URL is a FQDN (or a non-machine name); and
2)     The database is on a separate server.
 
If these conditions are met simply build a new server to replace the existing RMS Server, install the RMS Server software on it, and elect to join an existing cluster. You will be prompted for information such as the database server FQDN and the name of the Configuration database. The name of the Configuration database will be DRMS_Config_IntranetClusterFQDN_replacing_dot_with_underscores_PortNum where PortNum is 80 or 443 depending on whether or not you use SSL. Once the cluster has been established, update DNS to point to the new system and turn off the old system (do not put it into Decommission mode, which is something entirely different). I would not destroy the old system until you have tested the new system by obtaining RACs, CLCs, and EULs.
 
If the two conditions above are not met, especially #1, your best bet is to create a brand new RMS installation using a FQDN for the Intranet Cluster URL and a separate database server (also use a FQDN when specifying the name of the database server), export the SLC, private key, and templates from the existing server and import them to the new server as though creating a Publish Trust. You will then have to add Publish Trust overrides to the Registry of each RMS Client. Turn off the old system and test the new system and the established Publish Trust before destroying the old system. Note that if you have published the serviceConnectionPoint in AD you will need to override the provisioning page URL when you choose to install RMS on this server, replacing ProvisionLicensing.aspx with ProvisionCertification.aspx. You will have to deregister and reregister the serviceConnectionPoint from the new system. A simpler approach is to deregister the serviceConnectionPoint from the old system prior to provisioning the new system and register it from the new.