This guide provides troubleshooting information for Active Directory® Rights Management Services (AD RMS) in Windows Server® 2008, Windows Server® 2008 R2 and Windows Server® 2012. It is designed to help you identify and resolve problems that may be related to AD RMS.

Author: Eddie Bowers, Senior Support Escalation Engineer, Microsoft
Co-author: Brad Mahugh, Senior Technical Writer, Microsoft

In this guide 

• Introduction to Troubleshooting AD RMS
• Top 7 Things to Check When Troubleshooting AD RMS
• Troubleshooting AD RMS Problems

Introduction to Troubleshooting AD RMS

 

This guide explains how to troubleshoot and resolve common problems that can occur when working with AD RMS. If you are not familiar with AD RMS, you will find it helpful to familiarize yoruself with some of the AD RMS-related product documentation that is already published and available elsewhere in TechNet Library before using this guide.

When to use this guide

Use this guide when: 

• You need to understand how to perform basic troubleshooting of common problems that might occur when you are working with AD RMS.
• You want to understand how to locate and configure tools that can help you to better understand AD RMS service activity.
• You want to have a good background in how to debug, analyze, or report on complex issues in your AD RMS deployment.

This guide assumes that you have a basic understanding of AD RMS, how it works, and why your organization uses it to support its identity and access needs. If you need more inforamtion, please see the AD RMS Documentation Roadmap to locate additional resources in TechNet Library that might be helpful to you learning more about rights management.

You should also have a thorough understanding of how identity technology is designed and deployed in your organization. This includes an understanding of the mechanisms that your organization uses to configure and manage directory services (such as Active Directory Domain Services (AD DS) or other settings that are used for managing identity and security in your business environment.

Top 7 Things to Check When Troubleshooting AD RMS

The following is a list of the top 7 most basic issues that are commonly found to occur across a wide array of AD RMS deployment scenarios. Depending on the symptoms you are seeing, these are often the best place to start your troubleshooting of an AD RMS related issue.

1) Verify that you can get to the pipeline URLs from an AD RMS client computer.

When an AD RMS cluster is deployed, there are two "pipeline" URLs that are effectively always present and used to effectively Web service AD RMS requests from clients. These are:

• The enterprise publishing URL. This URL is in the format of:
  http(or https)://<AD_RMS_cluster_name>/_wmcs/licensing/license.asmx
• The enterprise certification URL. This URL is in the format of:
  http(or https)://<AD_RMS_cluster_name>/_wmcs/Certification/certification.asmx

If you cannot access these URLs from the AD RMS client computer using Internet Explorer, then AD RMS protection will fail.  If your attempt to browse to these URLS fails, note what type of error is returned so you can best determine your next steps in the troubleshooting process.

2) Make sure that the user at the AD RMS client computer has an email address configured in Active Directory. 

When a user or group is created in Active Directory, the mail attribute is an optional attribute that can be set to include a primary email address for the user or group. For AD RMS to work properly, this attribute must be set because all users must have an email attribute to protect and consume content. This can be done by setting the email address field in the properties for the user or group using either of the following tools:

• The Active Directory Users and Computers console
• The Active Directory Administrative Center

You can also use Active Directory administration cmdlets for Windows PowerShell. For example, to specify an email address for a user include email address value using the -EmailAddress parameter when creating a new user using the New-ADUser cmdlet.

3) Make sure that the SCP for AD RMS does not have a port specified for it.

The AD RMS service connection point (SCP) is an object in Active Directory that holds the Web address of the AD RMS certification cluster. In earier releases of AD RMS, the enterprise certification URL included the TCP port number associated with the SCP. Most of the issues regarding Microsoft Office not properly parsing the enterprise certification URL when it has a port number should now be resolved with the latest hotfixes, but it’s better to avoid the issue by updating your SCP configuration to not include the port number.  For more information on SCPs, see The AD RMS Service Connection Point (SCP), also on TechNet Wiki.

Note If you are using templates that were created when using the port number for the SCP was the default behavior for AD RMS, these templates might still cause the failure and equire updating to eliminate the problem.

4) Verify that when using SSL the certificate is trusted by the AD RMS client.

If when you are browsing the AD RMS "pipeline" URLs in Internet Explorer, the URLs start with "https://..." and resolve as valid and active but there is a warning about the certificate, then AD RMS will fail to work as expected. The certificate used for SSL communication must be valid and all certificates in its hierachy must also be valid as well.  Because Internet Explorer might not warn if the certificate revocation list (CRL) is not resolvable for this certificate, you might need to check that an SSL certificate is valid or that its hierachy checks out, you can view the SSL certificate in Internet Information Services (IIS) Manager.

To view and verify the SSL Certificate and its hierachy, you can do the following in IIS 6.0 and 7.0:

From the IIS Manager console, select your Web server in the console tree, then click Server Certificates to open and select the SSL certificate for that server. Once you have located the SSL certificate in the list, double-click it to view its properties. To view the certificate hierachy, click the Certification Path tab and then click each certificate in the hierachy to ensure that the status on each is OK.

5) Check that the DRM cache is cleared of any failed installation or configuration changes.

Often after initial install and configuration changes are made at an AD RMS server, an AD RMS client might fail because the digital rights management (DRM) cache on it contains configuration data from when it previously bootstrapped against the server before the configuration changes were applied. To eliminate the possibility of this being an issue, you can clear the DRM cache folder at the ADRMS client computer where you are experiencing trouble with AD RMS service connectivity. For Windows 7 and Windows 8 clients, the DRM cache Is located at the %localAppData%\Microsoft\DRM\ folder path. For Windows XP clients, the DRM cache folder is located at %UserProfile\LocalSettings\ApplicationData\Microsoft\DRM.

6) Check that there are not multiple .GIC or .CLC files installed on the AD RMS client.

As described in the RMS FAQ: Certificates, Keys and Encryption, only one of the following should be present on the client in its local DRM cached folder:

• Machine certificate
• Rights Accounts Certificate (RAC or .gic file)
• Client Licensor Certificate (CLC)

If mulitple copies of these files are present, this usually indicates a problem with the AD RMS Client configuration and all copies should be removed and the client re-installed and re-configured.

7) Verify that the IIS application pool is started.

The IIS application pool used to service AD RMS may fail to function if the service account that it is configured to run under has been disabled or if the password for the service has expired. To verify or update the identity for the AD RMS application pool in IIS, see Specify an Identity for an Application Pool (IIS7).

Troubleshooting AD RMS Problems

The following are the most commonly identified known issues that can occur when working with AD RMS.

---

Symptom: You are seeing issues with a site certificate or an error message such as "The service is temporarily unavailable..." or "The data received from the server running AD RMS didn't match the expected format".
Cause: Most likely there is an untrusted certificate or a certificate revocation list (CRL) cannot be resolved. If there are any warnings when using Internet Explorer to browse and access the AD RMS "pipeline" URLs , then Office applications will fail to be able to contact the AD RMS server. The reasons for this include the following:

• Mismatched names such as if the certificate involved was issued for a different name than what is being requested
• The certificate involved have expired.
• The certificate involved from an untrusted authority. 

Also, Microsoft Office applications will also fail if the CRL (Certificate Revocation URL) cannot be reached.  In this specific case, Internet Explorer might not provide an error or warning message.
Resolution:  First, verify that certificate being requested matches the name of the one that is is being used to support the pipeline URLs and that it has not expired or been issued from an untrusted authority. While self-signed certificates can be used in test deployments for AD RMS, it is recommended they not be used in live production AD RMS deployments that have exposure to external networks or in Internet-facing configurations.  

Also, you can as a workaround for CRL issues, disable CRL checking in Internet Explorer. To disable CRL checking, in Internet Explorer, from the Tools menu, open Internet Options, click the Advanced tab, scroll to the Security section and uncheck the box for Warn about security address mismatch, and then click OK.

---

Symptom: The AD RMS client reports an "unexpected error" message when a user is trying to access IRM functionality.

Cause: Most likely the cause of this is because the user accessing the content does not have an e-mail address configured using the mail attribute address in Active Directory, which is required for AD RMS to work as expected.

Resolution: Verify that the user account for the user in Active Directory has the mail attribute configured with the user's email address.

---

Symptom: Microsoft Office applications are having difficulty processing a pipeline URL. The URL has been checked and it appears to have a port number specified within it.

Cause: Some patch levels of Microsoft Office have problems accessing pipeline URLs used by AD RMS clients when there is a port number in the pipeline URL.

 Resolution: Ensure that the client computer has been updated to install this fix: http://support.microsoft.com/kb/2544026. You can also update your AD RMS cluster configuration to not include the port in pipeline URLs. This is a multi-step process (below).

To remove port numbers from AD RMS pipeline URLS

1.     On the AD RMS server computer, open the AD RMS console.
2.     In the console tree, select the <AD RMS server> and right-click and select Properties.
3.     In <AD RMS server> Properties, click the Cluster URLs tab.
4.     Verify that the Licensing URL does not have the port number (":443") appended to it.
5.     Click the SCP tab and then click Remove current SCP.

If you already have an extranet URL and your licensing URLs do not end with the port number (":443"), you can now skip the next three steps and proceed directly to step 9.

6.     Click the Cluster URLs tab again and check the Extranet URLs box.
7.     Type the word 'test' in each of the available text boxes and click Apply.
8.     Uncheck the Extranet URLs box and click Apply, then OK.
9.     Close the AD RMS console and re-open it.
10.  In the console tree, select the <AD RMS server> and right-click and select Properties.
11.  Click the SCP tab and then click Change SCP to register the current SCP.
12.  Check your AD RMS cluster URL settings and confirm that there is no ":443" appended to the end of any of the URLs.

Next, you will need to update all AD RMS servers in your cluster with the new URLs

To clear and reset all AD RMS servers to use the updated cluster URLs, repeat the following steps at each AD RMS server in the cluster.

1.     Open the Windows Registry Editor (Regedit.exe) and create the following registry value:

Under HKEY_LOCAL_MACHINE\Software\Microsoft\DRMS (Note: On some versions you will have a \2.0 folder under that key, so create this value at that level if you do)

Type: REG_SZ:
Name: GICURL
Value: /_wmcs/certification/certification.asmx">https://<ad_rms_server>/_wmcs/certification/certification.asmx

2.     Open an elevated command prompt and type iisreset and ENTER to issue a reset of the Web server on each server computer.

Finally, you will need to clear cached AD RMS configuration data at the AD RMS client computer. To do so, use the following steps at each client computer.

1.     Delete the %LocalAppData%\Microsoft\DRM folder.
2.     Close all Microsoft Office applications.
3.     Retry the AD RMS client operation.

Note If you have AD RMS rights policy templates, you will also need to do the following:

1. Open the Active Directory Rights Management Services console and expand the AD RMS cluster.
2. In the console tree, click Rights Policy Templates.
3. Select the name of the rights policy template to archive, and then, in the Actions pane, click Archive this Rights Policy Template.
4. Click Yes to confirm archiving of the template.
   
   Important   Never delete a rights policy template because all content protected by the rights policy template will no longer be accessible. Always archive rights policy templates that should no longer be distributed.
    
5. Click on each template and choose Copy to create a copy.
6. Rename the new templates with a slightly different name. (You can't have two templates with the same name).
7. Right click on the new template and click Distribute to distribute the template.
8. Begin pushing the new templates out to your users.

---

Symptom:   An attempt to migrate or upgrade from RMS to AD RMS failed and failed and some of the DRMS Logging database tables are missing.

Cause: In a failed migration, your DRMS_Logging database, and your logging components do not get updated.

      Warning   Make sure you have a backup of your server licensor certificate (SLC) and your trusted publishing domain (TPD) certificate before taking any recovery steps.

Your DRMS logging database will only contain 3 tables (Log_Filter, Log_Detail, and Log_Master) instead of 13 new tables (BadQueueDataLog, Certificate, CertificateType, ErrorDescription, etc.).

There are a couple reasons that your ADRMS upgrade could end up in this state of incompleteness.

1. You've done an in-place upgrade, and did not complete the entire process.
   
   Once you do an in-place upgrade (i.e. installing AD RMS over an existing RMS installation that was originally intalled under Windows Server 2003) there are some extra steps that need to be completed that are written in 'red' after the upgrade. If you haven't completed these steps, your logging components will not be upgraded.
2. If you did a join upgrade, and used the wrong private-key password.
   
   Normally this will result in an error, but can get you into a state of inconsistency that is difficult to resolve. Make sure when you are doing a join upgrade that you know your private-key password. You should not try to guess it. (The developers on the Information Protection team at Microsoft are looking at this issue, and may change the order in which the user is alerted in the future so that nothing gets updated if the wrong password is used).

When you get ino this state your DRMS_Config database gets updated, but no other databases are updated and the next time you retry the upgradeprocess, it will fail as well. You may also see this error in the event log:

              Source:   Active Directory Rights Management
             EventID:  70
   Task Category: Logging

    "The Active Directory Rights Management Services (AD RMS) logging services could not write to the AD RMS logging database. It will try to write the last message to the AD RMS logging database. All other messages will not be read from the Message Queuing until the AD RMS logging database is available."

During the upgrade process, AD RMS looks at a value called ADRMSFileVersion in the DRMS_ClusterPolicies table of the DRMS_Config database to see if the upgrade has already been done. If the value is set to 5.2.3790.300 it determines that it needs to be upgraded. If the version number is newer (higher), AD RMS will not upgrade.

Resolution: To force AD RMS to to reset and restart upgrade of all its databases again, remove the AD RMS server role from the server computer and set the value of ADRMSFileVersion in the DRMS_ClusterPolicies table of the DRMS_Config database to 5.2.3790.300 and then add the AD RMS server role back on the server computer.

---

Symptom: Clients located over the Internet are unable to access or obtain service from AD RMS.

Cause: The pipeline URLs for AD RMS must be accessible from the Internet for external users to use AD RMS.  External or Internet-based users must also be able to do HTTP POST to these pipeline URLs.

Resolution: When clients are failing in this scenario, you should check the Web server (IIS) logs on the server computer to see if the client traffic is even reaching it. If you find that the traffic is not reaching the web server, check your web proxy logs to see if the traffic is being rejected there.

If you work your way back to the client, you can gather WinInet logging or run a Fiddler trace to troubleshoot the issue.

A typical WinInet trace command (valid on Windows Vista and later versions of Microsoft Windows) might look like this:
    
     Logman start "wininettrace" -p "microsoft-windows-wininet" -o "c:\wininettrace.etl" –ets

To create a human readable (xml) log file: 

     tracerpt "wininettrace.etl" –y –o “wininetracelog.xml" –of xml

---

Symptom: You are having difficulty getting SharePoint configured to work with AD RMS.

Cause: If you are having difficulty getting SharePoint configured properly to work with AD RMS or are confused by how to go about achieving interoperability between these technologies, it's helpful to ensure you understand how SharePoint implments IRM support.

Enabling IRM on Sharepoint forces users to use Sharepoint as a distribution method. It does this by only giving rights to the downloading user (and the SharePoint service user account), so the document cannot be forwarded.  Even if the document is forwarded to someone who has rights to it via SharePoint, they will not be able to open it because the IRM rights are only set to the downloading user.

Resolution:    Check these prerequisite steps when troubleshooting IRM issues with SharePoint:
 

1. Make sure the user account that you are using to configure SharePoint has an email attribute in Active Directory.  Also make sure the SharePoint service account has an email attribute set as well.
2. Verify that AD RMS is functional outside of SharePoint by going into Microsoft Word and from the File menu, click Info, then click Protect Document, then click Restrict Permission by People, and then click Restricted Access.  If this fails, troubleshoot AD RMS.
3. Check the Sharepoint Central Administration\Manage Profile Service: User  Profile Service  Application

   You should see Number of User Profiles at a high number to indicate it synchronized.

   If it failed to synchronize.  Go into Application Management\Manage Services on Server\User Profile Synchronization service (make sure it's started)

4. Click Application Management\User Profile Service Application to open it.

   Configure Synchronization Connections.

   If there isn't a connection already, selcet Create a New Connection.

   Go back and Start Profile Synchronization (Start Full Synchronization)

---

 

Dos and Don’ts

(originally from Jason Tylers blog):

• DO use CNAME records for your RMS cluster URL. This will allow 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 a lot of trouble.
• DO write down your private key password, and create a document with screenshots detailing the entire setup process
• 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.
• 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 http://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.
• DO use strong passwords.
• DON'T put RMS on a domain controller. You have to give the RMS_Service account admin rights on the machine to do this.
• 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.
• 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"

 

• 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).

Tools – IRMCheck and DebugDiag.

The two tools used most often for diagnosing AD RMS issues are IRMCheck and DebugDiag.
The IRM check version provided in the RMS Administrator Toolkit has not been enhanced for AD RMS, but an updated version is maintained and provided in the following link:

http://aka.ms/irmcheck

 IRMCheck - Some of the important information that IRMCheck returns is as follows:

• Office System: Microsoft Office 2003 SP1 or greater is required. Office 2003 Standard Edition can read content, but cannot publish. If you are planning to roll out an Office deployment, make sure that you provide Office 2003 Professional Edition or Office 2007 Enterprise, Professional Plus, or Ultimate for users who need to create RMS-protected content.
• Operating System: If an error displays here, it usually indicates that there is no signature for one of the system files. This usually means that you have a corrupted signature catalog (Catroot2). If you see an error here, you can run sigverif to verify that there is a problem. On a Windows 2000 machine, there is a utility called catfix that will fix this problem. On a Windows XP machine, you can rebuild your signature catalog by stopping your cryptographic service, renaming the Catroot2 folder, and restarting the service.
• RMS is essentially a security application. This means that to protect itself, it has a manifest of all of the files that it should be working and playing with, as well as one file it should specifically NOT be using. If one of the files that it is supposed to be working with is not signed, then it cannot be trusted, and RMS will refuse to work until it gets fixed.
• RM Client: This identifies the version of the client installed.
• Registry Overrides: For advanced setups, it may be necessary to override the default RMS behavior with registry overrides, which are covered in an earlier module of this course. If there is a warning here, but you know the reason why you are overriding registry settings, then this is not a problem.
• Service URLs: These tell you if your service connection point for RMS is in the Intranet Zone or Trusted Sites. Your RMS cluster Uniform Resource Locator (URL) that was created when you provisioned RMS must be listed in your intranet or trusted sites so that credentials can be passed for validation. Otherwise, RMS will think that this is an Internet site, and will either prompt for credentials or fail. If you are prompted for credentials, and enter them, you will be issued a TRAC (Temporary Rights Account Certificate) that is good for 15 minutes (or whatever you specify in the configuration database). If you are only using RMS for intranet users, then you should clear up this warning by adding the RMS cluster URL to your list of trusted sites or intranet sites.
• Machine Activation: This fails only if the system DLLs aren't signed. The machine activation happens on the machine locally, so the RMS services are not involved. Ensure that the system DLLs are signed.
• User Certificates: If these fail, then possible causes could be no access to the RMS server, a problem with the SQL connection to RMS, or an antivirus program blocking the certificates on your system. The best thing to do is make sure that you can hit the four important URLs from the client’s web browser without any errors, pop-ups, or certificate issues. In addition, the URLs should be listed at the bottom right of the browser as being either trusted or intranet zoned.
  
  The URLs are:
  http://rms.cluster.url/_wmcs/Certification/Activation.asmx
  http:// rms.cluster.url /_wmcs/Certification/Certification.asmx
  http:// rms.cluster.url /_wmcs/Licensing/License.asmx
  http:// rms.cluster.url /_wmcs/Licensing/Publish.asmx
  
  If you are having problems getting to them without prompts for credentials, then that will need to be fixed depending on the pop-up or error received.
  
• System Clock: This checks the clock to see if it has been rolled back. You need to make sure that your clock is in sync with that of the domain for many reasons, such as Kerberos and the amount of time that certificates are issued for.
• Pending Reboot: You may be requested to reboot the client if there is a warning here.
• Domain Membership: This indicates whether you are connected to a domain. If you aren't, then the automatic service discovery calls that are made to find the service connection point in the AD will fail. In this case, you will need to override RMS with some registry settings.
• Temporary Directory: Ensure that there is a valid %temp% directory defined.
• Incompatible Applications: Make sure that you are on RMS SP1 client or later. Earlier versions of RMS didn't support things like Virtual Machines and several antiviruses. If you have an incompatible AV on your system, that AV will put itself into AppInit mode. RMS may fail because it thinks that there is a malicious program trying to steal information from your lockbox. To fix the problem, you may want to take the offending program off the system if it is listed here.
• User Email in AD: This points to a very common issue – the user account does not have the mail attribute filled out in its AD object. Any user who wants to use AD RMS must have their mail attribute filled out in the AD, even if they don't have a mailbox. The attribute is used to check that the user matches the person listed in the publishing license

 The results for the Certificates section are as follows:

• GIC (group identity certificate). This is also known as a rights account certificate (RAC). This is the user certificate that is used for authentication. You can use the IRMCheck tool to view when the certificate was issued and when it expires. Also, you can usually determine if the certificate is a permanent or temporary RAC based on these dates. You should check to see if the server that issued the GIC matches the one listed in the URLs displayed by IRMCheck under “Enterprise Service Discovery Results.” If it does not, the RMS may have been reinstalled or changes could have been made to the SCP.
• CLC (client licensor certificate). This is the publishing certificate that is required to do offline publishing. Like the GIC, you should check to see if the server that issued the CLC matches the Enterprise Service Discovery Results information. If it does not, this could cause some problems with Office. In addition, below the “Issued By” URL, the CLC also lists the licensing URLs that will be published in every document the user creates. If there are two URLs, you have set the extranet URL on the RMS server. This is the URL that users with access to the Internet will connect to. If RMS is failing in an extranet scenario, you should check the CLC for the extranet URL. If the CLC does not have the extranet URL, then the content the users publish will not have the extranet URL in the publishing license (usually built into the file). In this case, the extranet user won't be able to connect to your Internet-facing RMS server.
• Machine (machine certificate). This contains the public key certificate to the private key for the machine. In RMS 1.0, the machine key was global to the entire machine. Beginning in RMS 1.0 SP1, each user has their own virtual machine key. When the RMS server issues certificates, they are tied to a particular machine key. The machine certificate information in the IRMCheck is useful only to identify when a client is configured to the pre-production (development) hierarchy.

IRM Check also displays the Office registry information for RMS. Essentially, the RMS client automatically discovers where many of the bits and pieces of the RMS organization are stored. It does this by making a call to DRMGetServiceLocation, documented at http://msdn2.microsoft.com/en-us/library/aa362560.aspx.

Many of these registry settings allow the client to override this information. Here is the translation of these settings (keys are shown here for Office 2003):

Office Activation Service
HKLM\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: ActivationServer
Value:<http://url.of.your.activation.service>
This setting is not documented. In the RMS 1.0 RTM version, all clients had to activate themselves by obtaining a lockbox from a Microsoft server on the Internet by proxying the request through the RMS server. The lockbox is basically the component that does all of the encryption, decryption, validation, signing, etc. With the introduction of RMS 1.0 SP1, this is no longer necessary because the lockbox is shipped with the components and activates itself locally. 

Office Enterprise Certification Service
HKLM\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: CorpCertificationServer
Value: <http://your.rms.server/_wmcs/Certification> 
If the SCP is registered in your AD, this setting will override it. Don't set this unless you have a specific reason to do so. If you have the SCP registered, you should let the client discover it automatically.

Office Enterprise Client Enrollment Service
HKLM\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: CorpLicenseServer
Value: <http://your.rms.server/_wmcs/Licensing>

 This setting overrides the location from which you obtain the CLC.

 Office Cloud Certification Service
HKLM\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: CloudCertificationServer
Value: http://location.of.passport.service/_wmcs/Certification

 This setting is not documented. It overrides the location of the Passport service. If you have RMS 1.0 SP1 or later, don't change this setting. If you have RMS 1.0 RTM, enter the following: https://licensing.drm.microsoft.com/_wmcs/Certification. If you have RMS 1.0 and don't enter this URL, your RMS client goes out to the Universal Description, Discovery and Integration service (http://uddi.microsoft.com) and obtains the URL specified above. Specifying the URL saves bandwidth and eliminates a service that your clients need.

Office Cloud Client Enrollment Service
HKLM\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: CloudLicenseServer
Value: :<http://location.of.passport.service/_wmcs/Licensing>

This setting is not documented. It overrides the Passport licensing URL. Leave it at its default registry setting if you are running RMS 1.0 SP1 or later. If you are running RMS 1.0 RTM, enter the following: https://licensing.drm.microsoft.com/_wmcs/Licensing.

Office RM Client Setup URL
HKLM\Software\Microsoft\Office\11.0\Common\DRM\DRM Setup\
Reg_SZ: DRMPostSetupURL
Value: <http://url.to.your.client.setup/mclientsetup.exe>

This setting is not documented. If a client gets an RMS-protected document and Office notices that RMS isn't installed, it will try to download the client from the Internet and install it. If you want Office to search internally, then you can set this key so that Office will go to your internal site to get the pre-downloaded bits. Changing this setting is good for air gap networks or locked-down situations.

Office IRM Disable
HKCU\Software\Microsoft\Office\11.0\Common\DRM\
Reg_DWORD: Disable
Value: 1 (disables) 0 (enables) 

This setting will completely disable the RMS support within Office.

Office IRM DisablePassportCertification -
HKCU\Software\Microsoft\Office\11.0\Common\DRM\
Reg_DWORD: DisablePassportCertification
Value: 1 (disables) 0 (enables)

This setting disables the Passport functionality in Office 2003 IRM. This enables organizations to block people from sending RMS-protected mail outside the company using the Passport service.

Office IRM DisableCertificateValidation -
HKCU\Software\Microsoft\Office\11.0\Common\DRM\
Reg_DWORD:DisableCertificateValidation
Value: 1 (disables) 0 (enables)

This setting is not documented.

Office IRM Permission Policy Path -
HKCU\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ: AdminTemplatePath
Value: (UNC path or local path of your RMS templates)

This setting establishes the location where Office 2003 looks for the RMS templates. You can set this to a local folder or a UNC share. Unfortunately, Office does not support a web folder for the template location.

Office Cached Enterprise Client Enrollment Service -
HKCU\Software\Microsoft\Office\11.0\Common\DRM\
Reg_SZ:CachedCorpLicenseServer
Value:<http://url.to.your.rms.cached.licensing.server/_wmcs/Licensing>

 This setting is not documented.