AD RMS Prerequisites
Applies To: Windows Server 2008, Windows Server 2008 R2
Before you install AD RMS
Before you install Active Directory Rights Management Services (AD RMS) on Windows Server® 2008 R2 for the first time, there are several requirements that must be met.
Install the AD RMS server as a member server in the same Active Directory Domain Services (AD DS) forest as the user accounts that will be using rights-protected content.
Create a domain user account that will be used as the AD RMS service account. Use the following considerations with regard to this account:
This account requires the logon locally right on the AD RMS server.
This account does not require an e-mail account.
If AD RMS is installed on a Domain Controller the service account should have Domain Administrator permissions or higher.
Select the user account for installing AD RMS with the following restrictions:
The user account installing AD RMS must differ from the AD RMS service account.
If you are registering the AD RMS service connection point (SCP) during installation, the user account installing AD RMS must be a member of the AD DS Enterprise Administrators group..
If you are using an external database server for the AD RMS databases, the user account installing AD RMS must have the right to create new databases. If Microsoft SQL Server 2005 or Microsoft SQL Server 2008 is used, the user account must be a member of the System Administrators database role, or equivalent.
Note
The Windows Internal Database in is only supported in test or lab environments. This database should not be used for your production deployment.
- If you are using a remote SQL Server, the user account installing AD RMS must be a member of the local administrators group on the SQL server. This allows the AD RMS installation to query the registry on the SQL server remotely.
- The user account installing AD RMS and the service account must have access to query the AD DS domain.
- Reserve a URL for the AD RMS cluster that will be available throughout the lifetime of the AD RMS installation. Ensure that the reserved URL differs from the computer name.
Note
It is important to point out that this parameter cannot be changed so some planning should go into the name of the URL that is reserved.
In addition to pre-installation requirements for AD RMS, we strongly recommend the following:
Install the database server that is used to host the AD RMS databases on a separate computer.
Install the AD RMS cluster by using a secure sockets layer (SSL) certificate. This certificate should be issued from a trusted root certification authority.
Important
It must be pointed out that all clients and servers in your AD RMS deployment must trust the Certificatation Authority that is issuing the SSL certificate.
Create a DNS alias (CNAME record) or DNS host record (A record) for the AD RMS cluster URL. In the event that the AD RMS servers are discontinued, lost due to a hardware failure, or the computer's name is changed, a CNAME record or A record can be updated without having to publish all rights-protected files again. If your SQL Server is running on Windows Server 2003, to use CNAME records, you will need to modify the DisableStrictNameChecking registry entry. You must set the following in the registry (on the SQL server and the AD RMS server (if they are different)) before provisioning:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters
DWORD: DisableStrictNameChecking
Value: 1
For additional information about this see the Knowledge Base Article 281308 (https://go.microsoft.com/fwlink/?LinkId=154738). This only applies if your SQL Server is running on Windows Server 2003. This does not apply if your SQL Server is running on Windows Server 2008 or later.
Create a separate CNAME record or A record for the computer that is hosting the AD RMS configuration database. This provides for serviceability or failover.
If you are using a named instance for the AD RMS configuration database, the SQL Server Browser service must be started on the database server before you install AD RMS. Otherwise, the AD RMS installation will not be able to locate the configuration database and the installation will be unsuccessful.
Important considerations for installing AD RMS
The following are a list of things that should be considered before you install AD RMS:
Self-signed certificates should be used only in a test environment. For pilot and production environments, we recommend that you use an SSL certificate issued by a trusted certification authority.
If you want to install AD RMS into a web site other than the default, you will have to install IIS 6 Compatibility Mode on IIS 7.0.
The Windows Internal Database with AD RMS is intended for use only in test environments. Because the Windows Internal Database does not support remote connections, you cannot add another server to the AD RMS cluster in this scenario.
If an SCP already exists in the Active Directory forest for which you are installing AD RMS, ensure that the cluster URL in the SCP is the same as the cluster URL for the new installation. If they are not the same, you should either delete the old SCP prior to installation or edit the old SCP after installation so that it is pointing to the cluster URL of the new installation.
When installing AD RMS, localhost is not a supported cluster URL. The extranet cluster URLs are used by AD RMS clients that are outside of your internal network to connect to the AD RMS cluster for licensing and certification. Be sure to register the URLs in your Domain Name System (DNS), and verify that it is available from the Internet.If you are adding extranet cluster URLs to an existing AD RMS cluster, new client licensor certificates (CLC) must be obtained by the current AD RMS clients. The extranet cluster URLs are added to the Extranet-License-Acquisition-URL field in the issuance license and used in AD RMS client service discovery. Also, remember that these URLs are case-sensitive.
When specifying the AD RMS service account during installation, make sure that a smart card has not been inserted into the computer. If a smart card is attached to the computer, you will get an error message that the user account installing AD RMS does not have access to query AD DS.
When joining a new server to an existing AD RMS cluster, the SSL certificate must exist on the new server before the AD RMS server starts functioning.
AD RMS Prerequisites
The following table describes the minimum hardware prerequisites and recommendations for running servers with the AD RMS server role.
AD RMS Hardware Requirements
| Requirement | Recommendation |
|---|---|
One Pentium 4 3 GHz processor or higher |
Two Pentium 4 3 GHz processors or higher |
512 MB of RAM |
1024 MB of RAM |
40 GB of free hard disk space |
80 GB of free hard disk space |
The following table describes the software prerequisites for running Windows Server 2008 servers with the AD RMS server role. For requirements that can be met by enabling features on the operating system, installing the AD RMS server role will configure those features as appropriate, if they are not already configured.
AD RMS Software Requirements
| Software | Requirement | ||
|---|---|---|---|
Operating system* |
Windows Server® 2008 R2 Enterprise Windows Server® 2008 R2 Datacenter Windows Server® 2008 R2 Standard Windows Server® 2008 R2 Foundation Windows Server® 2008 Standard, 32-bit and 64-bit editions Windows Server® 2008 Enterprise, 32-bit and 64-bit editions Windows Server® 2008 Datacenter, 32-bit and 64-bit editions Windows Small Business Server® 2008 Premium, 32-bit and 64-bit editions Windows Small Business Server® 2008 Standard, 32-bit and 64-bit editions Windows Essential Business Server® 2008 Premium, 32-bit and 64-bit editions Windows Essential Business Server® 2008 Standard, 32-bit and 64-bit editions |
||
File system |
NTFS file system is recommended |
||
Messaging |
Message Queuing |
||
Internet Information Services (IIS) |
For Windows Server® 2008 editions, the following list represents the IIS 7.0 features installed as part of the installation process for the AD RMS server role:
For Windows Server® 2008 R2 editions, the following list represents the IIS 7.0 features installed as part of the installation process for the AD RMS server role:
|
||
Active Directory |
AD RMS must be installed in an Active Directory domain in which the domain controllers are running one of the following:
All users and groups who use AD RMS to acquire licenses and publish content must have an e-mail address configured in Active Directory. |
||
Active Directory Forest Functional Level |
Any. *** |
||
Active Directory Domain Functional Level |
Any. **** |
||
Microsoft SQL Server |
Microsoft SQL Server 2000 Enterprise Edition with Service Pack 4, 32-bit and 64-bit editions * Microsoft SQL Server 2000 Standard Edition with Service Pack 4, 32-bit and 64-bit editions * Microsoft SQL Server 2005 Enterprise Edition with Service Pack 3, 32-bit and 64-bit editions Microsoft SQL Server 2005 Standard Edition with Service Pack 3, 32-bit and 64-bit editions Microsoft SQL Server 2008 Enterprise Edition with Service Pack 2, 32-bit and 64-bit editions Microsoft SQL Server 2008 Standard Edition with Service Pack 2, 32-bit and 64-bit editions Microsoft SQL Server 2008 R2 Datacenter Edition, 32-bit and 64-bit editions Microsoft SQL Server 2008 R2 Enterprise Edition, 32-bit and 64-bit editions Microsoft SQL Server 2008 R2 Standard Edition, 32-bit and 64-bit editions |
.gif)
NoteImportant
- Windows Server® 2008 Server Core, Windows® Web Server 2008, Windows Server® 2008 for Itanium-Based Systems, Windows® Web Server 2008 R2, and Windows Server® 2008 R2 for Itanium-Based Systems are NOT supported.
** Support for AD RMS is contingent upon support offering for dependency product.
*** AD RMS does not require a Windows Server 2008 R2 Active Directory Forest Functional Level.
**** AD RMS does not require a Windows Server 2008 R2 Active Directory Domain Functional Level.
AD RMS Optional Requirements
| Requirement | Benefit |
|---|---|
Active Directory Schema Extension |
The Active Directory Schema Extension is not required to install or use AD RMS. It is required if you will be using the proxyAddress attribute. In order for users to decrypt content addressed to them, they must be able to prove possession of the e-mail address specified on that content. In some cases, users must prove possession of multiple e-mail addresses. In order to facilitate this, AD RMS uses the following two Active Directory user attributes: mail and proxyAddress. The mail attribute holds a users primary e-mail address. The proxyAddress attribute holds all of the users e-mail addresses. The proxyAddress attribute is not part of Active Directory by default. When you install Microsoft Exchange, the Active Directory schema is extended and the proxyAddress attribute is added. If you do not have Microsoft Exchange installed in your Active Directory forest and require the proxyAddress attribute, you can use the Active Directory Schema Extension to achieve this. For information on this see To Enable Proxy-Addresses Active Directory Schema Attribute (https://go.microsoft.com/fwlink/?LinkId=154662). |
Microsoft Exchange |
Microsoft Exchange is not required to install or use AD RMS. Using AD RMS with Microsoft Exchange 2007 SP1 or later can provide the following benefits:
For additional information, see How to Configure Your System for the AD RMS Prelicensing Agent(https://go.microsoft.com/fwlink/?LinkId=154663). |
Microsoft Sharepoint |
Microsoft Sharepoint is not required to install or use AD RMS. Using AD RMS with Microsoft Sharepoint can provide the following benefits:
For additional information, see Microsoft Office SharePoint Server (MOSS)(https://go.microsoft.com/fwlink/?LinkId=154664). |
Microsoft Active Directory Federated Services |
Microsoft Active Directory Federated Services is not required to install or use AD RMS. Using AD RMS with AD FS can provide the following benefits:
For additional information, see Checklist Deploying AD RMS with AD FS(https://go.microsoft.com/fwlink/?LinkId=154665). |
Before you upgrade from RMS to AD RMS
If you are upgrading from any version of Rights Management Services (RMS) to AD RMS, do the following:
Back up the RMS databases and store in a secure location.
If you are using centrally managed keys, you should have the password prior to beginning the upgrade.
AD RMS requires that the service account be a domain user account. If RMS has been using the local SYSTEM account for the service account, you will need to specify a domain user account during the upgrade to AD RMS.
If you used the offline enrollment option to provision RMS, ensure that the enrollment is complete before upgrading to AD RMS.
If you have been using MSDE to host your RMS databases, you must migrate the databases to Microsoft SQL Server before you upgrade the RMS cluster to AD RMS. An upgrade from versions of RMS by using the MSDE database is not supported.
Flush the RMS Message Queuing queue to ensure that all messages are written to the RMS logging database.
If RMS was provisioned using a hardware security module (HSM), you must reinstall the HSM drivers after the upgrade to Windows Server 2008 is complete, but before you start the upgrade to AD RMS.
If you are using a port other than 80 to host your RMS cluster, the AD RMS Upgrade Wizard will bind two ports to this Web site during the upgrade. You must remove the incorrect binding and restart Internet Information Services before the AD RMS cluster can service requests.
Custom access control lists (ACLs) that are applied to the Administrator and GroupExpansion virtual directories are not migrated during the upgrade. If you have a custom ACL on either of these directories, you must set it up manually after the upgrade.
After completing the upgrade to AD RMS, you may receive the following error message when opening the AD RMS console:
A connection with the specified AD RMS cluster could not be established. Cannot read configuration file due to insufficient permissions.
You must restart Internet Information Services (IIS) to correct this error.
If you are upgrading an RMS cluster that is installed on a domain controller, you must add the AD RMS Service Group to the IIS_WPG group on the domain controller. Membership in the IIS_WPG group is required for running the AD RMS application pool (_DRMSAppPool1).
If you deployed RMS on a domain controller and protected the RMS key by using a software-based or hardware-based cryptographic storage provider instead of having RMS centrally manage the private key, you cannot upgrade the cluster to AD RMS on that domain controller. You must first join a Windows Server 2008-based member server to the RMS cluster to upgrade this cluster to an AD RMS cluster. We recommend that you remove RMS from the domain controller after the RMS cluster has been upgraded to AD RMS.
An upgrade of an RMS cluster that is installed on a domain controller using a hardware-based CSP will not succeed because the AD RMS Service Group is created as a domain group on the domain controller and not as a local group. You must first join a Windows Server® 2008 R2-based member server to the RMS cluster in order to upgrade this cluster to an AD RMS cluster. We recommend that you remove RMS from the domain controller after the RMS cluster has been upgraded to AD RMS.
If RMS is installed but not provisioned and you upgrade to Windows Server® 2008 R2 the upgrade link still appears in Server Manager. If you click this link and RMS was not provisioned, the upgrade fails.
For additional information on upgrading from RMS to AD RMS see RMS to AD RMS Migration and Upgrade Guide (https://go.microsoft.com/fwlink/?LinkId=154666).
Important considerations for installing AD RMS with identity federation support
The following are a list of things that should be considered before installing AD RMS with identity federation support:
A federated trusted relationship must be configured before you install identity federation support. During the installation of the Identity Federation Support role service, you are asked to specify the URL of the federation service.
Active Directory Federation Services (AD FS) requires secure communication between AD RMS and the AD FS resource server. In order to use federation support with AD RMS, you must assign a secure sockets layer (SSL) certificate to the Web site that will be hosting the AD RMS cluster.
The internal and external URLs must use HTTPS, otherwise the wizard won’t install Federation integration.
The AD RMS service account must have the Generate Security Audits privilege. This privilege is granted by using the Local Security Policy console. This privilege allows the AD RMS service account to generate events and write them to the Security log. If this is a multiple node cluster, this must be configured on each node.
The AD RMS extranet cluster URLs must be accessible to the federated account partner. The extranet cluster URLs are used by AD RMS clients that are outside of your internal network to connect to the AD RMS cluster for licensing and certification. Be sure to register the URLs in your Domain Name System (DNS), and verify that it is available from the Internet. If you are adding extranet cluster URLs to an existing AD RMS cluster, new client licensor certificates (CLC) must be obtained by the current AD RMS clients. The extranet cluster URLs are added to the Extranet-License-Acquisition-URL field in the issuance license and used in AD RMS client service discovery. Also, remember that these URLs are case-sensitive.
Important considerations for installing AD RMS in a multi-forest environment
The following are a list of things that should be considered before installing AD RMS in a multi-forest environment:
Only one AD RMS root cluster is allowed for each forest.
There can be multiple Licensing-only clusters in each forest.
The number of AD RMS trusts required to interact between all AD RMS forests can be defined by using the following formula: N*(N-1).
For example, if you have 4 AD RMS forests and all of them should be allowed to exchange information between each other, then – 12 (4X(4-1)) AD RMS trusts will need to be configured to achieve this.
AD RMS trusts are not the same as Windows Trusts. For additional information see Understanding AD RMS Trust Policies (https://go.microsoft.com/fwlink/?LinkId=154667).
AD RMS uses AD DS to identify users and distribution groups. When an organization’s AD DS deployment includes multiple forests, AD RMS uses AD DS contact objects to obtain the identities of users and groups that are part of a different forest than the AD RMS cluster. The problem is that user or group objects from other forests do not typically have representative objects that are in the forest where AD RMS resides. If you intend to use AD RMS to restrict permissions to users or groups who are from other forests, you need to configure your Active Directory forest appropriately to allow group expansion to occur across forests.
You can implement group expansion support across forests for AD RMS in two ways:
Deploy an AD RMS cluster into the forest where the groups are defined, and where it will be used to expand the membership of these groups. AD DS Universal groups should be used so that the group membership is replicated to every global catalog server in the forest. Schema extensions must exist in forests that contain contact objects that allow the schema extensions to point back to the forests that contain the actual objects. If schema extensions are not used, client registry overrides are required.
Synchronize group definitions among forests to allow the local AD RMS installation to determine the complete group membership for any user. If the user who is requesting a use license has a Windows account in a separate forest, there also must be a contact object in the local forest to represent that user’s group membership.