Translate this site using Windows Live Translator:
Tip o' the day: 12/05/2006 - Moving your RMS SQL Dbase to another server. - RMS: Protecting Your Assets. - Site Home - TechNet Blogs

RMS: Protecting Your Assets.

The Protecting 'My' Asset Disclaimer: This is my 'un-official', 'in my spare time', 'use at your own risk', all things RMS (Rights Management Services), IRM (Information Rights Management), IPP (Information Protection Pla

Tip o' the day: 12/05/2006 - Moving your RMS SQL Dbase to another server.

Tip o' the day: 12/05/2006 - Moving your RMS SQL Dbase to another server.

  • Comments 8
  • Likes

Problem: Your new boss decides that he wants the key machines within your forest to now be professionally named with a purpose, instead of using the funny office names you currently have like 'DuckButt', and 'PickleMonkey'. Maybe you got a new server, and need to move everything onto it, or maybe your old RMS server is becoming a fire hazard. 'Oh, no!' you think, the RMS database needs to be moved. What do I do?
 


Solution: Ideally, when you move/restore the RMS databases onto a SQL server, it is recommended to keep the same SQL server name and instance. Since DuckButt will not longer fly with the office brass, you need to change it to something more drab. If you must change the SQL server name and/or instance, you need to make some manual changes to the RMS configuration database, registry keys, and configuration files:
 
TIP: Always use a CNAME record for your RMS cluster URL, not the netbios name of the machine. If you need to switch servers later, or want to set up an NLB, all you will have to do is point the CNAME record at another location. Remember ALL of your content will have this URL embedded into it, so having the ability to change the server, without changing the name is key. The same goes for your SQL instance. Create and use a cname record for the SQL server, and if something happens to the SQL server, you can easily point the cname record to the backup server, with minimal downtime.
 
1) It is recommended that you back up the 3 DRMS SQL databases, but at a minimum, go to "Trust policies" and export your Enterprise Trusted Publishing Domain.  This can be used as a minimal disaster recovery backup.  If needed, you can import this file into any RMS installation to recover documents if necessary.  Please note that the export is done with the RMS Service Account so make sure the account has write
access to the destination. You should also export the 'sysmessages' table from the old master database, and import it into the new one.
 
NOTE**If you blow away your database before you exported and imported the sysmessages table, all is not lost. Just follow the steps listed here to restore it: http://support.microsoft.com/kb/913372
 
OK, so now you have everything imported into the new SQL server.
 
2) Run RMSConfigEditor.exe from the RMS toolkit.
 
3) Type the name of the SQL server in the Server text box and click "Go".
 
4) Pick the DRMS_Config database from the Database drop down list and click "Go".
 
5) Open the DRMS_ClusterPolicies and find the following PolicyName entries.  In the corresponding PolicyData entry, you will find the name of the SQL server being referred to.  Adjust the PolicyData entry to the new SQL server name and click the "Persist" button on each.
 
LoggingDatabaseServer
CertificationUserKeyStorageConnectionString
DirectoryServicesCacheDatabase
 
6) Open the DRMS_PluginProperties table and find the following PropertyID/PolicyName entry.  In the corresponding PropertyValue entry, you will find the name of the SQL server being referred to.  Adjust the PropertyValue entry to the new SQL server name and click the "Persist" button.
 
PropertyID: 101 PropertyName: PERSISTENT_STORAGE
 
7) Exit the RMS Config Editor.  The changes should have been made.
 
8) Go into the 3 web.config files located in the directories under c:\inetpub\wwwroot\_wmcs (Admin, Certification, Licensing, GroupExpansion, Decomission) and search for the old SQL name. Replace it with the new SQL name.
 
9) Go to Start>Run Regedit and modify the following keys:
 
HKLM/Software/Microsoft/DRMS/1.0/KeyProtection
There will be a key in here that starts PasswordDerivedKey_<SQL Server>...
You will need to change this to reflect the new SQL dbase name.
 
HKLM/System/ControlSet001/Services/DRMS_Logging_<rms instance>_80/Params
ConnectionString needs to be changed to reflect the new SQL name.
HKLM/System/ControlSet002/Services/DRMS_Logging_<rms instance>_80/Params
ConnectionString needs to be changed to reflect the new SQL name.
 
HKLM/System/CurrentControlSet/Services/DRMS_Logging_<rms instance>_80/Params
ConnectionString needs to be changed to reflect the new SQL name.
 
10) Go to a command prompt and run IISRESET.
 
Now you can relax, and use DuckButt as the office Quake server or something. :)

Comments
  • I've read lots about using a CName for the SQL server for DR purposes, how on a new install of Windows 2008 AD RMS do you specify the CName of the SQL server. As part of the install the only option you get is to pick the sql computer from an existing computer object in AD.

    This isnt the case for the RMS Cluster which can easily be referenced by a CName during install.

    Can you offer any advice?

  • On WS2008 you need to set the following in the registry (on the SQL server and the RMS server (to be safe)) before provisioning:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

    Create a DWORD value under this key named:

    DisableStrictNameChecking

    And set it to ‘1’

    Then try provisioning.

    -Jason

  • I have RMS running on a machine we will call acme.  It is also a file server, and there are so many things hard coded to acme, that can't be changed.  We go a new windows storage server that will have to be named acme.  I see two options, try to install RMS on a storage server, not sure if that is supported, or move RMS to some new box.  The bad news is my DRMS_ClusterServer is set to the name acme.  Suggestions?  Thanks!

  • It appears you've got yourself into a bit of a pickle that stems from not using a cname record when provisioning the RMS server. If you need to change the cluster URL the terrible truth is you need to do this:

    - First you need to make sure that you export the SLC and TPD certs out of the current installation.

    - Then you need to remove the SCP, and deprovision RMS.

    - Then you need to stand up an entirely new RMS infrastructure, keeping in mind to use cname records for the SQL server and Cluster URL *and* make sure that if the plan is to use HTTPS that you have a certificate all ready to go, and the secure channel open prior to provisioning.

    - Once you stand up the new infrastructure you need to import the TPD certificate into the new installation.

    - Now you have to write a logon script that will remove the DRM folder from every users machine in the environment, so that they will obtain a new RAC and CLC from the new installation.

    - Then you need to set the licenseserverredirection key in the registry to tell every client that if they want to open something that was issued by the old licensing server, to redirect to the new licensing server.

    Just look for the word LicenseServerRedirection on this blog and you should hit my blog post "All you can eat Office registry keys and a bag of chips". The key is defined in that post.

  • Lot's of people have used my previous posting detailing the steps necessary to move your database server

  • Hi Jason,

     Just so you know, anytime I read your blogs I LOL all the time.

    Anyway, I have the same issue as the guy with the "acme" server, though my server is not clustered and has SQL Desktop Engine running the database, not a SQL server. I don't understand what you meant by "SLC, TPD, SCP, RAC, CLC" and how to export the SLC and TPD certs.

    Also, what is a good way to backup the RMS server?

    Thanks

    -Renato  

  • SLC (Server Licensor Certificate)

    This is what signs all the shiznit for your environment. You can back this up from the 'Trust Policies' menu in the RMS administration console. You also give this to companies that you want to swap RMS protected info with. You import theirs, and they import yours.

    TPD (Trusted Publishing Domain)

    This certificate is the keys to your kingdom. Whoever owns this, owns you so be careful with it and keep it protected. This too can be backed up in the 'Trust Policies' menu item in the RMS admin console. If you ever need to do a disaster recovery, you can rebuild your environment, import this key, and you will be able to decrypt all old content. You can also piut this certificate on remote RMS servers, that you want to be able to decrypt content from another server, without the users actually going to the originating server. This would require the LicenseServerRedirection key to be set in the users registry.

    SCP (Service Connection Point)

    This is an entry in your AD that tells all your users where to go to activate their machine. Essentially the url of the RMS server.

    RAC (Rights Account Certificate) a.k.a. GIC

    This certificate allows a user to participate in the RMS environment. Whenever they try to open content, they pass this cert to the RMS server to politely prove that they are who they say they are. Without it, you can't open content.

    CLC (Client Licensor Certificate)

    This certificate allows you to publish content offline. Without this you can't create any RMS protected shiznit.

  • Can I apply this article: "How to change the TCP port that SharePoint Portal Server or SharePoint Server uses to connect to SQL Server" support.microsoft.com/.../889647 to change the  TCP port that RMS Server uses to connect to SQL Server?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment