Deploying RMS into a Large Enterprise

Published: February 14, 2007

By Rand Morimoto, Ph.D., MVP, MCSE

See other Security MVP Article of the Month columns.

Recently, our consulting group, led by security consultant Tyson Kopczynski, was approached by a large corporate entity (here called “”) that was seeking a method to thwart a user’s ability to forward “sensitive” e-mails outside of the organization. Windows Rights Management Services (RMS) immediately came to mind as the solution that this enterprise would need, but further review of the problem was required before making such a recommendation.

The project sponsor in this case was the enterprise’s Corporate Communications department. Over the past several months, there had been major incidents of “internal informers” forwarding highly sensitive content outside the organization. Naturally, the leak in information was not looked upon favorably by the senior staff, and an effort was made to stop it. At first, Corporate Communications worked with its Microsoft Exchange Server administrators to try to prevent the information leaks by building a convoluted message screening system. However, with an enterprise that consisted of more than 15,000 users, the task was daunting and the resulting solution didn’t work.

Corporate Communications needed a solution and needed it fast. had Microsoft Office 2003 as its office productivity suite and Windows XP Professional Service Pack (SP) 2 as the operating system for all of its corporate desktops. After reviewing the problem and the company’s IT infrastructure, it was determined that RMS was indeed the solution best suited to safeguarding the information in sensitive e-mail messages. RMS allows content creators of Microsoft Office Word documents, PowerPoint presentations, Excel worksheets, and Outlook to apply persistent protection so that the usage rights are contained within the content no matter where that content travels. With RMS, the executive team could create, protect, and send sensitive e-mails with confidence that the e-mail message itself could not be forwarded by recipients of the content.

After learning about these benefits, the Corporate Communications department was ready to push through a project that would deploy RMS to its entire enterprise. The rest of this article explains aspects of the project including how we designed and implemented RMS so that there is a link between business needs and the RMS solution.

Step One: Identify the Project Goals

The first step of this RMS project was to identify its goals and objectives. We conducted several discovery sessions with the project sponsor and determined that the project would be based around the following business goals:

  1. Provide a low-cost and easily deployable solution that can be used to protect sensitive e-mail.

  2. Provide a solution that can be used throughout the rest of the organization to both protect and consume content.

After defining the business goals, the next step of any technology-based project is to create tangible IT goals, ones that are based on the business goals. During a set of discovery sessions, we identified the following IT goals for the RMS project:

  1. Enable Corporate Communications, Legal, IT, and Executive staff to send rights-protected e-mail to worldwide employees using Microsoft Office Outlook 2003.

  2. Enable worldwide employees within the domain and on workstations to consume rights-protected e-mail using Office Outlook 2003 or Outlook Web Access.

  3. Support the following access methods:

    1. Internal

    2. Virtual private network (VPN)

    3. External (Outlook Web Access)

  4. Allow IT administrators to recover rights-protected content that has expired.

  5. Integrate authentication support for workstations that are on the internal network.

  6. Support Internet Explorer (IE) 6.0 when using the RMS IE Add-on.

Step Two: Understand the Environment

Now that we had a set of goals to work from, our next step was to gain an understanding of the environment for which we were creating the RMS design. In interviews with members of the IT team, we gathered the following useful information:

  •’s Active Directory infrastructure consisted of two forests that each held a single production domain.

  • The first production domain named was used as a corporate account domain.

  • The second production domain, named, was used as a contractor’s account domain.

  • Contractors should never have access to sensitive, protected content.

  • ran a split DNS configuration for internal and external sourced queries.

  • The company had the following infrastructure standards:

    • SQL Server 2005 was for database servers.

    • Application servers (like RMS) are installed on Virtual Server 2005.

    • Most desktops were Windows XP Professional SP2.

    • Most desktops had Office 2003 installed on them.

Step Three: Create the Design

With an understanding of the IT environment, we next wanted to design the RMS deployment to meet the project goals. To do this, we asked the IT team a set of questions that allowed our team to determine the optimal RMS design for Some of these questions were:

  • Has RMS been deployed before? The answer to this question was important because if RMS had been deployed before, a possible migration of protected content or cleanup of Active Directory would need to take place. The IT team’s answer was no.

  • Will the RMS private key protection method be default software-based or a hardware security module (HSM)? The answer here depends on the level of assurance required for content that was protected by an RMS hierarchy. For a lower level of assurance, default software-based protection would be used. For a higher level of assurance, an HSM would be used. The company decided to use an HSM.

  • Will the RMS clusters be deployed with a failover option? This is a very important question because it is best practice to deploy at least two servers into a cluster in the event an RMS server suffers some type of failure. decided to deploy at least two RMS servers in each cluster.

Resulting RMS Topology
Based on the stated project goals and information gathered during the design sessions, our consulting group recommended the following RMS topology (see Figure 1) to meet needs:

  • Single Root Cluster with two cluster members.

  • Each cluster member would be installed as a virtual machine on a Virtual Server 2005 host.

  • Separate SQL Server 2005 database server would be used for the RMS databases.

  • Load balancing for the RMS cluster would be handled by a third-party hardware load balancer (Big/IP).

  • RMS implementation would be for a single Active Directory forest.

  • RMS cluster would be protected by an Application Layer firewall.

  • The cluster name would be used for internal access.

  • External access would be through the external name

Figure 1

Figure 1. RMS Topology

Step Four: Roll Out the Plan

The final step for the RMS project was to develop a rollout plan (project plan) that would be used to deploy RMS at The plan that we developed consisted of the following high-level tasks:

  • Prototype the RMS in a lab environment to verify the design.

  • Install and configure RMS into production.

  • Verify the production RMS installation via a series of pilots.

  • Deploy the RMS client to the entire enterprise.

  • Begin training users on how to create and consume protected content.


Implementation of a technology like Windows Rights Management Services wasn’t just a technology solution that involved going in and installing software and server systems. It required consulting, planning, and confirmation from business-level decision makers in the organization to agree on how content-level management would be handled. Without their buy-in, it would be hard to have RMS adopted and accepted as a critical security solution to solve a critical business challenge. With the right set of goals and expectations in place, the design, implementation, and ultimate acceptance of RMS in the environment went smoothly.

This project was led by Convergent Computing security consultant Tyson Kopczynski, who provided details for this article.