For server side troubleshooting I’m going to focus on two different scenarios. In the first scenario we will assume we have a user or group of users who are unable to activate or unable to consume a protected document, but we have other users who are not having issues. In the second scenario we will assume that all users are unable to activate or consume protected content.

Scenario 1

In this scenario we have a user or group of users who are unable to activate and consume protected content. We have done our client side troubleshooting, but we haven’t been able to determine the problem. Let’s begin.

1. Our first step should be to run a troubleshooting report within the AD RMS Management Console.** When you open the Troubleshooting report you are presented with menu below.

   

   Select the appropriate date and time for the query (these would be the dates the user attempted to active or consume protected content.) Select the appropriate user and hit Finish. Once the report has finished, it will be presented to you similar to the image below.

   

   The reporting features of AD RMS in Server 2008 R2 leave a lot to be desired, but for basic troubleshooting the report can be helpful. I’m not going to go into any detail with how to read the report, as it is straightforward.

   **The reporting features of AD RMS in Server 2008 R2 require the Microsoft Report Viewer Distributable 2005 update be installed.

2. Is the troubleshooting report not helpful enough to diagnose the issue? Maybe it’s an issue with the user object, distribution group objects, or contact object.
   • For user objects, verify the user object has an email address. Typically if a user attempts to open a protected document and does not have an email address, it will be logged to the AD RMS server Application Event log.
   • For distribution group objects, verify an email address is assigned. Also verify the user is actually a member of the distribution group.
   • For contact objects representing groups in another forest, verify the object has an email address and has msExchOriginatingForest is populated.
3. Is the issue stemming from users in a trusted Active Directory forest which has its own implementation of AD RMS and you have a Trusted User Domain with? Well there are a few things we can check.
   • Verify the service account in the trusted forest has been granted the appropriate permissions. Namely Read on the group expansion pipeline. This is required when group expansion needs to occur.
   • Verify you have not set HKLMSoftwareMicrosoftDRMSGICURL. I’ve explained this in a previous host, but let me go into a bit more detail. When this registry entry is set, both intraforest and interforest users will be referred to whatever pipeline is referenced in the GICURL entry. This means if you’ve set it to something like https://adrms.contoso.local/_wmcs/certification, users in the fabrikam forest will receive that URL back when requesting an activation URL for their domain. The AD RMS client on the fabrikam user’s computer will then attempt to activate in the wrong forest and will fail.I can’t stress this one enough folks, play carefully with the GICURL registry entry. It’s a painful Easter egg for future administrators.

Scenario 2

Complete failure of the service could mean a lot of things, but let’s quickly run through a list of must checks.

1. Check the GICURL registry entry as discussed above.
2. Check to make sure the service can connect with the backend WID or SQL database.
3. Check the IIS logs to verify the users aren’t being denied access to the pipelines. If you’re seeing a ton of 401s and users are failing to authenticate, check the ACLs on the AD RMS pipelines.
4. If the user is being prompted for a username and password and you have verified the AD RMS website has been added to the Intranet zone, ensure that the appropriate SPNs have been assigned to the AD RMS service account.
5. If you’re experiencing really odd behavior at the client, verify the certificates being used by your AD RMS server are valid and have reachable CDPs if you’re doing CRL checking.

Remember you can always fall back on Server Side Debug Logging. It is extremely useful when you’re stumped.