AD RMS Best Practices Guide
Applies To: Windows Server 2008, Windows Server 2008 R2, Windows Server 2012
A well-considered plan for designing your Active Directory Rights Management Services (AD RMS) installations makes enterprise-scale rights management deployment straightforward and easy to manage and troubleshoot.
This guide combines business and technical guidance to minimize the time and effort required to implement the AD RMS. It provides a set of checklist for specific prescriptive guidance based on best practices learned from customers that have already deployed AD RMS in their organizations and as verified by those who have in-depth experience supporting such installations.
It also provides a summary of all the main design choice tasks and decisions you need to develop a solid plan for AD RMS in your environment. The intended audience for this guide is the IT professional responsible for testing, piloting, and rolling out an AD RMS design.
AD RMS Installation Best Practices
The following are best practices to consider when preparing to install AD RMS within your organization.
| Best practice rule | Notes |
|---|---|
| Use dedicated AD RMS servers. | Installing AD RMS on the same server as a domain controller, Microsoft Exchange Server, Certification Authority, or Microsoft Office SharePoint Server is a poor security practice. |
| Do not install AD RMS on a domain controller. | If you do install AD RMS on a domain controller, you must add the AD RMS service account, which is normally configured with no additional permissions, to the Domain Admins group. |
| Do not try to install the Identity Federation Support feature until you have an Active Directory Federation Services (AD FS) server in place and be aware of case sensitivity in AD FS. | You cannot install the Identity Federation Support feature until you have an AD FS server in place. If AD FS is not yet configured in your environment at the time of AD RMS installation, you can wait until it is before attempting to add the Identity Federation Support feature. If installing Identity Federation Support, use lower case letters for the fully qualified domain name, as AD FS is case sensitive. |
| You should only use Windows Internal Database in a test environment. | Windows Internal Database does not support remote connections; therefore, you would be unable to add additional AD RMS servers to your cluster. In a production environment, to allow for future growth and AD RMS cluster expansion you should therefore always use Microsoft SQL Server to host AD RMS database services. |
| Use DNS aliases, such as CNAME records, or DNS host records, such as A Records for the fully qualified domain name of the AD RMS cluster. | This allows you to easily add additional servers to the AD RMS cluster and allows you to load balance and perform disaster recovery very easily. |
| Use DNS aliases, such as CNAME records, or DNS host records, such as A Records for your AD RMS database server. | This makes future migration of your AD RMS databases much easier. |
| Be sure that any protocol bindings and other settings that are needed by AD RMS for your Web server or its websites are configured before you install and configure AD RMS. | If you plan to deploy AD RMS on a website that is already set up, be sure that website has an HTTP binding, even if you are configuring AD RMS to use HTTPS. If you plan to deploy AD RMS on a non-default website, install the IIS 6 Management Capability role service before you start provisioning. Using SSL protocol increases the security of the connections to the AD RMS cluster. Also, SSL is required to integrate AD RMS with AD FS. Remember that this cannot be changed once it has been specified. |
| Configure an extranet URL even if you do not plan to deploy one initially. | You should configure your extranet URL at the time of installation, even if it will not be initially deployed. If external access is enabled after documents are AD RMS protected you must remove the protection, remove the DRM folder on the client computers, configure extranet access, and then protect the documents again. |
| Use an SSL certificate issued from a trusted certification authority (CA) for the Internet. | You should use self-signed certificates only in a test environment. In a production environment you should always use an SSL certificate issued from a certification authority. |
| Perform additional tasks to complete configuration and ready your AD RMS installation for use. | After an installation or upgrade is complete you must log off and log back in again before you can administer AD RMS using the AD RMS console. Once installation is complete you should also back up your Server Licensor Certificate and your private key by exporting the Trusted Publishing Domain (TPD) for your cluster and storing it in a safe place. Also, be sure to keep the password that was used during the TPD export documented in and stored separately in a safe location. |
| Be aware of the conditions and differences when moving an existing RMS installation to AD RMS. | There are two paths to upgrading an earlier version of RMS to AD RMS: migration and in-place upgrade. Migration is the recommended process. If you choose to do an in-place upgrade, be sure to run the upgrade wizard after the operating system upgrade completes. This wizard is launched from a link in Server Manager. For more information on migrating or upgrading an AD RMS cluster see RMS to AD RMS Migration and Upgrade Guide. |
| Always deploy AD RMS using clusters. | If necessary, you can use a single node cluster, but deploying AD RMS in cluster mode provides allows for later scalability and expansion should you ever need it. For best practices on working with AD RMS clusters, see the following section. |
| Use FQDNs for all URLs associated with your AD RMS deployment. | Using a single label domain can cause problems with some applications, increase the probability of spoofing attacks and cause interoperability problems with other organizations. |
| Use a common FQDN for both intranet and extranet access to your AD RMS installation. | Unless you have specific reasons for differentiating between the two URLs you should make the two URLs identical. |
AD RMS Clustering Best Practices
The following are best practices to consider when working with AD RMS clusters within your organization.
| Best practice rule | Notes |
|---|---|
| Always deploy AD RMS using clusters | If necessary, use a single node cluster and if possible, use more than one AD RMS server to support a deployment and provide additional redundancy and service availability. |
| Be aware of special considerations when selecting a load balancing solutions to support AD RMS, especially when working in virtualized environments. | In general, network load balancers (NLBs) or external load balancers are good alternatives with the following exception: If you are deploying AD RMS in a virtualized environment (a common or likely occurrence), an external load balancer will work better than an NLB solution. This happens because typically there will be specific operations or exceptions such as ARP registrations, port spanning that can require virtualization administrators to configure manually exceptions that override the default policy in those environments. This type of customization can be highly undesirable to manage in large-scale virtualization deployments. |
| Always use virtual names for AD RMS clusters | Select a generalized name that does not refer to any specific or physical server computer. For example, something like "rms.contoso.com" is a good format to use here. Then create entries in your DNS zone that helps to direct traffic to that name such as by adding a CNAME resource record that points this name to your NLB host name and an A resource record for the NLB that directly points to its IP address. Also, be sure to use fully qualified domain names (FQDNs) and not NetBIOS names to point to your AD RMS cluster. |
| If possible use a single IP address for your AD RMS cluster for both intranet and extranet clients. | In general, there are no good reasons to use multiple IP addresses or to have your AD RMS servers on multiple networks. We recommend using a single network interface with a single IP address and publish it through a proxy server. |
| Always use HTTPS/SSL when configuring your AD RMS cluster URL. | Use properly issued certificates that you obtain from a recognized Internet certification authority (CA) that are matched to your cluster URL address. You can then use Internet Information Services (IIS) Manager to create certificate requests and to export your issued certificate to other nodes in your AD RMS cluster. |
| Only use self-signed certificates in a test environment to evaluate AD RMS. | Do not use self-signed certificates in production deployment as they can cause many additional deployment problems such as the need to manually copy and reconfigure trust for the certificate on each server node in your cluster. |
| If necessary, also deploy the PKI Root certificate to the trusted root containers on all AD RMS clients and servers. | If you configured SSL with a certificate issued by a private CA, store the PKI root certificate in all nodes named "Trusted Root Certification Authorities" container. |
| Deploy one AD RMS cluster per Active Directory forest. | Each forest where users of the solution will be hosted needs to have its own AD RMS certification cluster. Do not deploy more than one AD RMS certification cluster per forest and do not deploy Licensing Only cluster unless there is a specific need for them. |
| Try to concentrate AD RMS licensing as much as possible. | If possible, point all licensing URLs in all your clusters to match the URL of one of the clusters in a forest that trusts all the other forests. That way, all licensing operations will be performed by only one cluster which simplifies logging, reporting, template configuration and troubleshooting. |
AD RMS Database Server Best Practices
The following are best practices to consider when working with AD RMS database services within your organization.
| Best practice rule | Notes |
|---|---|
| Consider thoughtfully whether failover clustering or log shipping will be sufficient for your AD RMS database design. | When you are designing your AD RMS database deployment, you need to consider the option to use a high availability design for your database server. If you are deploying AD RMS on Windows Server 2008 or Windows Server 2008 R2 and you are not using Exchange Prelicensing, a highly available database is not essential and a robust backup plan might be sufficient. But if deploying on Windows Server 2012 or if using Exchange Prelicensing or any other Exchange IRM integration capability, a highly available database is essential. Log shipping and failover clustering both can work well, with log shipping providing recoverability against a wider range of possible failure scenarios, and a cluster providing faster recovery times in most scenarios. Both can be combined in a single installation if you consider that your service’s availability needs justify it. |
| Always use virtual names for AD RMS databases. | The reason for this is similar to the reason to use virtual names with the AD RMS cluster. It is much more problematic or difficult to change the name of an AD RMS database once you have deployed it widely within an organizational infrastructure. Use CNAME records to support DNS name resolution for your AD RMS databases. Either CNAME or A resource records are good in case you need to move or relocate your AD RMS database servers. Also, as with AD RMS cluster virtual naming, use fully qualified domain names (FQDNs) and point the virtual names for your AD RMS database cluster to the cluster IP address. You can also use different CNAME resource records for different AD RMS databases, even if they are residing on the same server computer. This tends to make things easier if in the future you need to move or relocate databases to another server or move a server to another location on your network. You can also if you prefer use a different CNAME or A resource record for each AD RMS database. |
AD RMS Client Deployment Best Practices
The following are best practices to consider when deploying AD RMS clients within your organization.
| Best practice rule | Notes |
|---|---|
| With legacy AD RMS clients, always deploy the AD RMS client binaries without including additional settings in the installation package. | Do not put registry settings or other local client configuration changes in the installation package as these configuration updates can cause supportability issues. For example, you might want to change registry key settings when you re-deploy the client and in that case you would have to successfully install or re-install the client package to troubleshoot an issue. In many cases, registry settings are not updated well using this type of bundled configuration and it is more reliable to use separate GPO updates or Windows scripting to revise such settings. |
| Create a group in Active Directory and use that for targeting AD RMS client deployment | It is recommended that you use GPO to deploy AD RMS client settings and that you only deploy settings as needed. Target settings using the same groups used for client deployment. |
| Always deploy the required settings for the AD RMS clients. | The following settings should always be configured when deploying AD RMS clients: - Root CA certificate (if needed) - AD RMS cluster URLs in the Trust Sites for Internet Explorer (note that you can use GPO to do configure this setting). - Enabling or disabling IRM functionality (you can set this either on or off depending on user group) - AD RMS template path and deployment script or settings - Text to show to non-AD RMS ready clients |
AD RMS Rights Policy Templates Best Practices
Once you have deployed your AD RMS infrastructure, you will want to ensure that you follow best practices for using rights policy templates within your organization. Rights policy templates enable content authors to quickly apply a standard level of protection for content across your organization. Furthermore, templates offer additional security options that are not available in normal protection.
For more information on how to best deploy AD RMS rights policy templates to support your deployment, see AD RMS Rights Policy Templates Best Practices.
AD RMS Performance and Logging Best Practices
Once you have deployed your AD RMS infrastructure, you will also want to ensure that it meets the necessary performance requirements for your organization and can handle expected loads as well as monitor for errors, bottlenecks and other potential problems. To do this, adequate logging of your operations is essential to provide the necessary information to monitor performance and aid in troubleshooting issues as they arise.