The DOs and DON'Ts of RMS
DO use CNAME records for your RMS cluster URL. This will alow you to load balance, and or do disaster recovery by simply changing the A record that the CNAME record points to.
DON'T use the netbios name of the machine as the cluster URL.
DO make a back-ups of your SLC and Publishing Certificate located in the 'Trust Policies' section of your RMS Admin UI, *immediately* after provisioning. There is an Export button for the SLC, and an Export link for the publishing cert. Put these in a safe place. If your RMS installation blows up, and you don't have these, you will be in alot of trouble.
DON'T forget to do the above. :)
DO be a good RMS admin and write down your private key password, and create a document with screenshots detailing the entire setup process, for the next admin that may come in and have to take your spot later down the road. If I had a nickel for every admin who 'acquired' someone elses RMS environment, and had no idea what the private key password was, I'd have alot of nickels.
DON'T forget to print a hard copy of this information and lock it up in a safe place. It is the 'one piece of data' you probably don't want to RMS protect. If the system blows up, and the keys are locked up by the system that blew up, well...you can see the irony in that.
DO use a CNAME for your SQL server. In a disaster recovery situation, it is easier to change the single A record of the CNAME to point to a backup server, than to change the 6 or 7 places within RMS that need to be changed.
DON'T install RMS without a detailed plan, including whether or not you want to use HTTPS, or HSMs. Changing these things after the fact is a big pain in the back-side.
DO make sure that your superusers group is a Universal Distribution group. The RMS server needs to be able to expand the group with a GC query, and this is the only group type whos full membership is replicated to the GC. This really goes for any group, with members in different domains, that you need to use RMS.
DON'T enable the superusers group unless you have to, and only put 2 or 3 people in this group for redundency.
DO make a backup of your DRMS_Config_Cluster_80 database regularly. It can be used for disaster recovery.
DON'T forget or lose your RMS software private key you used to provision the server. This should be in the paper that your *good* admin who followed the DO's and DON'Ts of RMS made for you before he was given the cardboard box, and walked to his car by security.
DO download the RMS Administration Toolkit form https://www.microsoft.com/rms, and keep it handy. IRMCheck is a great tool for troubleshooting client issues.
DON'T put RMS on a server that is hosting multiple services. The more things you put on a server, the larger the attack surface of that machine becomes. Since this machine will be responsible for the security of your companies intellectual property, keep it clean and free of excess services.
DO remember that by default ServerCertification.asmx, and MobileDeviceCertification.asmx have no-one assigned to their access control lists. In order to use things like MOSS, or Mobile Devices, you need to go into the Properties of these files, and the Security tab, click the 'Advanced' button, and check the box to allow permission from parent to propogate. For MOSS integration you also need to add the MOSS$ machinename account, and the identity that the MOSS service is running as (if it is anything other than Network Service), with Read/Read & Execute rights to the ServerCertification.asmx file in c:\InetPub\wwwroot\_wmcs\Certification directory.
DON'T forget to breathe.
DO use strong passwords.
DON'T put RMS on a domain controller. This is such a bad idea, that every time I see it, I want to go tell the person to go pick a switch and meet me behind the toolshed. You have to give the RMS_Service account admin rights on the machine to do this, and you agghhh.. Just don't!!
DO remember it's just 1's and 0's. It's not magic. :)
DON'T forget to set an extranet URL if you plan on people using RMS outside of your environment. If you don't set this, all of the CLC (offline publishing certificates) issued will not have this link, and all of the users with those CLCs will be creating content with no extranet URL embedded into them. Once that happens, you can't open that content from outside the domain (i.e. from the internet). This would be bad if you have people that need to work from home.
DO set the IIS permissions on the License.asmx, and the ServiceLocator.asmx in the licensing pipeline to 'anonymous access' only, on your Internet facing RMS machine, if you have a TUD (Trusted User Domain) with another company, or are trusting Passport RACs.
DON'T buy a car from a guy wearing a plaid suit, and white penny loafers that answers to the name 'Fast Eddie'.
DO remember that you can read RMS protected content with any version of Office 2003 or higher (there are exceptions to this if you use the HTTP option), but you can only create content with Office 2003 Professional, and Office 2007 Professional *Plus* and above.
DON'T forget that in order for your users on the internet (or intranet users if you aren't registering an SCP in the AD) to use RMS you need to have them put these registry settings on their machine (changed of course to reflect your environment). Just copy and paste this into a text file, and change the extension to .reg, give it to them and tell them to double-click on it.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation]
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\Activation]
@="https://rms.yourdomain.com/_wmcs/certification"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing]
@="https://rms.yourdomain.com/_wmcs/licensing"
-Jason
Updates:
DO check the time on the RMS server and the clients to ensure that everything is right. Otherwise you will get time expiration related errors (Well, you'll get a generic error, but if you use DebugView, the actual error code will be a time synch error). Thanks Eusebiu. :)
...and along those lines
DON'T forget that is you are using the VMWare time synchronization service that you have the latest updates for VMWAre installed. There is a bug that will cause time sync errors if you don't have this installed. (Technically we don't support VMWare but I've run into this before with a customer).
Comments
Anonymous
January 01, 2003
First of all this is a great post! In my opinion there is a DO that is not in here : check for both the clock on the client machine and the clock on the server machine. If they are not syncronized, when trying to authenticate, you'll get an "Unexpected error. Please try again later or contact you system administrator".Anonymous
January 01, 2003
There you go EUSEBIU. I've included it in the updates section of the post. Not synchronizing your time will cause all kinds of issues unrelated to RMS as well. Like instant kerberos ticket expiration. :)