Rights Management Server and Exchange 2010 (Part 8)

If you would like to read the first part in this article series please go to:


This is the final part of this article looking at the integration features of Rights Management Server (RMS) and Exchange 2010. It has been quite a long article but then again there have been many features to look at, along with the installation of the actual RMS server itself. If you’re new to RMS and have not really considered its use before, I’m sure that having read all the previous parts of this article you are now aware of the fantastic array of important and useful features that are available to you.

Since this is a resource site dedicated to Exchange rather than RMS, I’m sure that you understand that there is much more to planning, installing and configuring the RMS environment than I can present here. If you are looking to deploy RMS in a small lab environment then the information that I have presented within this article will no doubt allow you to accelerate your own testing but in order to do a full RMS deployment justice, there are many other aspects to the product that you need to understand. I therefore encourage you to check out the RMS product documentation that you can find here.

Let’s complete our look at RMS integration with Exchange 2010 by looking at a few of the logging options.

Default Logging Settings

By default, IRM logging is enabled and can be accessed on all four Exchange 2010 internal roles, namely the Mailbox, Hub Transport, Client Access Server and Unified Messaging server roles; it is not available on the Edge Transport role. For example, to examine the logging settings on the mailbox server role, we can use the Get-MailboxServer cmdlet and pipe the results to the format-list cmdlet to see all available parameters. If you do this and scroll through the list of parameters, you will come across five parameters that begin with Irm, which you’ll remember is short for Information Rights Management. An example of this is shown in Figure 65.

Figure 65: IRM Default Log Settings

Let’s have a look at these parameters in the order that they are presented in Figure 65 and check out the default settings. The first thing that you may notice is that the first parameter, IrmLogEnabled, informs us that IRM logging is already enabled on this server since the value is set to true. In fact, IRM logging is enabled by default on all of the aforementioned server roles. The IrmLogMaxAge parameter controls how long the logs are maintained on the server and this has a default value of 30 days which will probably suffice for most troubleshooting operations.

The maximum size of the directory that contains the log files is set to 250MB via the IrmLogMaxDirectorySize parameter. The system will remove the oldest log files in order to ensure that this 250MB limit is not exceeded. The IrmLogMaxFileSize parameter controls the size of any individual log file and has a default value of 10MB. During normal operations, if any single log file reaches 10MB in size, a new log file is created.

Finally, the IrmLogPath parameter controls the actual location of the log files. Exchange 2010 stores its IRM log files in the \Program Files\Microsoft\Exchange Server\V14\Logging\IRMLogs folder by default and under the Logging folder you will see other folders that contain the logs for services such as the Address Book service and RPC Client Access. Note that other types of logs are stored elsewhere. For example, on Hub Transport servers, message tracking and protocol logs are stored in separate folders found under the \Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs folder. Personally, I prefer to maintain the various logs in their default folder location unless there is a specific need to move them. All of the above settings can be changed if you require but it is probably worth going ahead with the default settings and seeing which, if any, modifications you need to make.

If you have reviewed and modified the settings for controlling the message tracking logs in Exchange 2010, you may have noticed that the parameters to control the IRM logs are very similar in nature.

Exchange IRM Logs

As you just saw, the IRM logs are held in the \Program Files\Microsoft\Exchange Server\V14\Logging\IRMLogs folder by default so let’s have a look at the contents of this folder in my lab environment. In Figure 66 you can see that in my lab environment there are four different file types. Specifically, there are file names that begin with the strings EdgeTransport, MSExchangeMailboxAssistants, msftefd and w3wp. To complete the full file name, these strings are then followed by the process ID, the string IRMLOG and then the date and time.

Let’s cover off what these files contain:

  • EdgeTransport. Even though these file names begin with the string EdgeTransport, they are actually the IRM logs found on the Hub Transport role. This is because the edgetransport.exe process runs on all transport servers regardless of whether they are Hub Transport or Edge Transport servers.
  • MSExchangeMailboxAssistants. These are the IRM logs that relate to the MSExchangeMailboxAssistants service, which itself performs background maintenance on mailboxes.
  • Msftefd. Since the msftefd.exe process is used for content indexing, it follows that these logs cover search and indexing events as they relate to RMS.
  • w3wp. You will actually see two different types of log files relating to the w3wp process, namely files relating to OWA and PowerShell. Since OWA is part of the Client Access Server role, you should expect to see the OWA-related w3wp log files on the Client Access Server itself, whereas PowerShell-related w3wp log files will be found on all server roles except the Edge Transport server role of course.

Since my lab environment consists of a single Exchange 2010 server running the mailbox, Client Access Server and Hub Transport server roles, I see all of the file types in the IRMLogs folder. You can use these log files when troubleshooting RMS-related issues.

Figure 66: Contents of the IRMLogs Folder

RMS Troubleshooting

It is also possible to use the Active Directory Rights Management Services snap-in for troubleshooting purposes where data can be retrieved from the RMS database. Let’s have a quick look at this process. If you run this snap-in and click the Reports node, you’ll be presented with the screen shown in Figure 67.

Figure 67: Rights Management Services Reports

You will notice from the text towards the bottom of the middle pane that to see the troubleshooting reports, you must install the Microsoft Report Viewer and a link is provided to do just this. The link takes you to the main Microsoft downloads site where you can download and install this tool; the installation is very straightforward and consists largely of a number of screens where you simply need to click the ‘next’ button. Once installed, restart the Active Directory Rights Management Services snap-in to see both the System Health and Troubleshooting nodes as you can see from Figure 68.

Figure 68: System Health and Troubleshooting Report Nodes

To see the troubleshooting reports, select the Troubleshooting node and then in the action pane select the View Report option. This brings up the Create Report screen that you can see in Figure 69. Here, you simply choose the start and end date and time for your query, and also select the user that you want to report on.

Figure 69: Creating a Report

Once you’re happy with your selection, click Finish and you will be presented with a screen similar to the one shown in Figure 70, where you can see what is referred to as the ‘first report’. This is in effect a report detailing other, more detailed, reports that are available.

Figure 70: Master List of Reports

From here you can drill down into the reports. For example, in Figure 70 you can see that there is a single report for the Get Client Licensor Certificate and drilling down into this report will reveal a report similar to the one shown in Figure 71.

Figure 71: Detailed Report

Should you need to perform any troubleshooting of your RMS environment, hopefully the logs on the Exchange 2010 server and the information contained within the RMS database will aid you in this process.


With that, we have completed our look at RMS integration in Exchange 2010. I hope you have found the information useful and who knows, maybe you will be implementing RMS within your Active Directory and Exchange 2010 environment soon.

If you would like to read the first part in this article series please go to:

1 thought on “Rights Management Server and Exchange 2010 (Part 8)”

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top