Rights Management Server and Exchange 2010 (Part 1)

By /

If you would like to read the other parts in this article series please go to:

Introduction

A collection of features that aren’t always used in an Exchange messaging environment are provided by the Active Directory Rights Management Server (RMS) role. Although integration with RMS was possible in Exchange 2007, the feature list is much better with Exchange 2010 and in this article I’ll be taking a look at those features, how they are installed, configured and used. Application of RMS technologies gives an organization the ability to support Information Rights Management (IRM) features. Information Rights Management is another term you will be reading and getting familiar with when looking at RMS.

So what does this actually mean for an organization and what features are available? The principle behind Information Rights Management is all about protecting specific information within your environment and preventing, where possible, that information from being intentionally or unintentionally exposed externally. As we shall see later in this article, the most obvious example of protecting information is removing the ability for a user to forward an email after they have received it.

In this example, a user is deemed authorized to receive and read the message but is not authorized to forward this message on, perhaps because it contains security-sensitive information. Of course, if a user really wants to give this information to someone else he or she can always use other methods to do just that, such as taking a photograph of the screen and passing the information on. In this case, RMS obviously cannot protect the information but at the same time the organization can say that it has taken all reasonable steps to prevent the information from being passed on via methods available within the Exchange infrastructure.

Disabling the ability to forward an email obviously means that this element is controlled using an email client and as you will see within this article. This feature can be controlled using the full Microsoft Outlook client as well as other clients such as Outlook Web App. In fact, users of Exchange ActiveSync devices can also take advantage of this feature although I won’t be demonstrating this particular element within this article.

You will see later in this article that the user can, within Outlook or Outlook Web App, choose to mark a message with RMS permissions but naturally this relies on the user choosing or remembering to do so. To avoid such situations, the administrator can configure Outlook Protection Rules to deploy the desired RMS configuration automatically and we will be looking at this feature later in this article. We’ll also be covering the feature known as Transport Protection Rules which allows messages to be protected as they are in transit through the Exchange system.

Lab Environment

To examine these features we will need a suitable lab environment containing all the necessary servers. The lab environment for this article will consist of the following four machines:

  • R-DC. An Active Directory domain controller that is also running Domain Naming Services (DNS) and additionally functions as a Windows Certificate Authority (CA). In my lab environment I already had a domain controller running the Windows 2003 operating system with Service Pack 2 deployed, so I decided to use this as it is perfectly valid for the lab requirements. If you are planning on testing your own RMS and Exchange 2010 integration, the domain controller could equally be running the Windows 2008 or Windows 2008 R2 operating system.
  • R-RMS. A Windows 2008 R2 domain member server that is to function as the RMS server. Although we will be installing the RMS role within this article, we won’t be covering all the background information required to plan and deploy RMS for a production environment. Such a configuration requires detailed planning that is beyond the scope of this article.
  • R-EXCH. This is another Windows 2008 R2 domain member server running Exchange 2010 Service Pack 1. Exchange 2010 has already been installed on this server. There are plenty of articles here on MSExchange.org that cover installation of Exchange 2010 and therefore we do not need to cover this process again in this article.
  • R-XP. A Windows XP SP3 workstation that is running Outlook 2010 to test the end-user functionality of RMS and can also be used to test Outlook Web App (OWA). As with the Exchange 2010 software, we will not be covering the installation of Outlook 2010 on this workstation.

Figure 1 shows the lab setup.


Figure 1: Lab Environment

As you can see from Figure 1 there is just a single Active Directory domain controller and therefore the Active Directory environment consists of a single forest and single domain. The Fully Qualified Domain Name (FQDN) is neilhobson.com. This domain is operating with a forest functional level set to Windows 2003.

Let’s now continue this article by looking at the pre-requisites required before the installation of the RMS role. Unfortunately, due to article space constraints, we won’t be able to get onto the actual installation steps here in part one but I’m sure you’ll agree that the background information and pre-requisites are important to understand first.

Rights Management Server Installation Pre-Requisites

To install the RMS role onto a server, that server must be a member of the domain that will utilize the services it provides. As I stated earlier, the server R-RMS has already been configured as a domain member server. Additionally, a database server is typically required to host the RMS database although in this lab environment we will be using the Windows Internal Database option which uses a database on the same server and restricts us to a single-server cluster; we will be able to select this option during the installation wizard. It goes without saying that this is acceptable for a lab environment but this is not recommended for a production deployment. In a production environment, a SQL database may be used for example.

There are other requirements that must be met:

  • Create a RMS service account. This is simply a normal user account and in my lab environment this account has been named RMSSvc.
  • When creating the RMS server, we will be prompted for the name of a URL that will be used by the RMS clients to communicate with the RMS server itself. Microsoft states that this must be different to the name of the server and therefore in this case the URL cannot be r-rms.neilhobson.com. I’ve chosen rms.neilhobson.com for the lab environment. Obviously there will need to be a corresponding DNS A record created for the host name ‘rms’. In fact, Microsoft actually recommends that you create a DNS CNAME record for the URL used by RMS for ease of transition should you experience any issues with the RMS server itself. In this lab environment, a simple DNS A record will suffice.
  • The operating system must have Internet Information Services (IIS), ASP.NET and Message Queuing installed to support RMS. If these components are not present when you attempt to add the RMS role, you will be prompted to add them as you will see later. Therefore, there is no need to go ahead and add these beforehand unless you’re the sort of administrator who likes to install components separately and test that they are functioning before moving onto the installation of additional components.

Summary

That completes part one of this article on the RMS features and how they integrate with Exchange 2010. In this part of the article we have covered the all-important background of why an organization might be looking to implement RMS and the pre-requisites we need to meet before deploying the server role. In part two we’ll install the RMS role.

 

If you would like to read the other parts in this article series please go to:

 

About The Author

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

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

Scroll to Top