As our long journey through AD RMS comes to a close, I wanted to touch on troubleshooting the service. While putting together the lab for the deep dive I ended up doing a ton of troubleshooting. The goal of this post is to pass that knowledge on in hopes it will save someone some time in the future.

When troubleshooting an AD RMS activation, consumption, or creation of protected documents, it’s best to start at the client.

Troubleshooting the AD RMS Client

1. This may seem like an obvious troubleshooting step, but it is often overlooked.  Verify that the user has an email address assigned to the identity they are using to access the document.
2. When troubleshooting the AD RMS client, your first step should be to clear the AD RMS cache and reset the AD RMS client. These two Microsoft articles do a wonderful job of outlining the steps:
   1. Reset the AD RMS Client (Office 2010)
   2. Reset the MSIPC AD RMS Client (Office 2013)

   Resetting the client according to the articles above will clear out those cached registry entries that were created during previous activations and consumption operations. It’s possible for these entries to become corrupt or outdated for some reason and they will be properly recreated during the next client activation. The other step the articles have you taking is clearing out cached keys (CLC, RAC, etc). By clearing out all the keys the client will process through the whole activation cycle.

   If activation is still failing, test on another client after resetting that client as well. If activation works on the second client, then you know there’s an issue with the first client. Move to the next step.

3. Next let’s verify the AD RMS server information wasn’t hardcoded within the client’s registry. Maybe it was done for some troubleshooting purpose in the past or perhaps an SCP wasn’t used previously. The registry entries below are worth checking.  Keep in mind if you’re using a 64-bit Office client, you’ll want to check the SoftwareWow6432Node node.
   1. HKLMSoftwareMicrosoftMSDRMServiceLocationActivation – This is a hardcoded location for client activation.
   2. HKLMSoftwareMicrosoftMSDRMServiceLocationEnterprise – This is the hardcoded location to obtain a CLC.
   3. HKCUSoftwareMicrosoftOffice14.0CommonDRMServiceLocation – This is where previously discovered service locations are stored for Office 2010.
   4. HKCUSoftwareMicrosoftOffice15.0CommonDRMServiceLocation – This is where previously discovered service locations are stored for Office 2013.

   If you found any of these registry, talk to your administrator to see why things are being hardcoded. If you determine it’s remnants of previous troubleshooting, clear out the entries, reset the client, and try again.

4. Still not working? Remember when I mentioned earlier about the importance AD RMS places on CRL checking? The AD RMS client will inherit the CRL checking configuration that is set in Internet Explorer. If you determine you can’t reach or validate the certificate distribution point in the AD RMS root cluster’s cert or SSL cert, disable CRL checking in Internet Explorer. Check out this article for details. Make sure that you uncheck both “check for server certificate revocation” and “check for publisher’s certificate revocation” options.Once that is complete, reset the client and try again.
5. Still having issues? Well my friend, you have exhausted the easier troubleshooting steps and now you need to do some client side debug tracing. You can utilize the sample debug traces I provided in my deep dive to see what a normally functionomg client debug trace looks like. If you’ve taken the time to read through the previous posts, the issue should immediately pop out to you in the debug trace.

My next blog post will explore how to troubleshoot at the server end.