Large organizations with many client systems might want to consider clustering and subenrolling Microsoft Windows Rights Management Services (RMS) servers to build a scalable, fault-tolerant RMS infrastructure. You can build clusters of RMS servers for load-balancing and availability purposes. And you can subenroll RMS servers under your initial RMS certification server to create a hierarchy that lets business partners and extranet users access RMS over the Internet to obtain use licenses but protects your certification servers.
Clusters. An RMS server cluster consists of multiple RMS servers that share one database server and attach to the databases that RMS creates during provisioning of the first node in the cluster. Clustered servers also share a common IP address. To configure load balancing across members of an RMS cluster, you need to use Windows Network Load Balancing (NLB) or a traffic-management device (e.g., F5 Networks' BIG-IP). You also need to ensure that the Fully Qualified Domain Name (FQDN) that you specify as the intranet or extranet cluster URL resolves to the common IP address.
Creating or extending a cluster after you've created the first node is simple. During installation of subsequent RMS servers, select the Add this server to a cluster option instead of the Provision RMS on this Web site option. You'll need to supply the credentials of the RMS service account, the name of the database server and configuration database, and the password used to protect the private key associated with the RMS licensor certificate, as I explain in the main article "Windows Rights Management Services." The database name takes the format DRMS_Config_IntranetURL_PortNumber, where IntranetURL is the FQDN you entered as the cluster URL when you provisioned the first RMS server in the cluster and PortNumber is 80 (if you're using HTTP) or 443 (if you're using HTTP Secure—HTTPS).
Hierarchies. Organizing RMS servers (or server clusters) into a hierarchy involves subenrolling the servers from the RMS root certification server. Subenrollment lets you install dedicated RMS licensing servers, which serve only to issue publishing licenses to content creators and use licenses to content consumers. Subenrolled licensing servers can help take the load from certification servers by performing these tasks. Licensing servers require a database server that they can use for configuration and logging.
To subenroll a licensing server, select the Provision RMS on this Web site option during RMS installation. Note that you must have published a serviceConnectionPoint object in AD so that the installation program can detect the certification server and can take you to the subenrollment Web page, which prompts you for the database location, the credentials of the service account to use, the intranet cluster URL, and a password to protect the private key of the subenrolled server's RMS licensor certificate. (If you haven't published a serviceConnectionPoint object for your RMS certification server, you can use a registry override to specify the server, as the RMS Server Deployment Guide explains.) For security reasons, use a different RMS service account, database, and password for each subenrolled server. You must use a different intranet cluster URL for each server. You also can create clusters of licensing servers in the same manner that you create clusters of certification servers. Be aware that if you do so, your RMS client systems must use registry overrides specific to the RMS-aware applications that will use the subenrolled licensing servers or clusters (as I explain in the main article) so that publishing licenses identify the correct server.
RMS lets you create one-way trust relationships between hierarchies so that users in the hierarchies can exchange rights-protected content. Establishing a trust relationship doesn't require establishing a trust between forests and relies solely on RMS. The two types of trust relationships that RMS supports are user trusts and publishing trusts.
When two hierarchies establish a user trust, users in the trusting hierarchy can send rights-protected content to recipients in the trusted hierarchy. To establish a user trust, select Trust policies from the list of links on the RMS Administration Web page. Doing so directs you to the Trust policies page. Click Export to save a copy of the RMS licensor certificate, which you can then exchange with the administrator of the RMS hierarchy that wants to trust the users in your hierarchy. Exchanged rights-protected content will contain publishing licenses that specify the external URL of the RMS certification server or subenrolled licensing server that will issue use licenses for the content. If you choose to trust the users of another RMS hierarchy, you need to import that hierarchy's RMS licensor certificate and configure an external URL for each server or cluster that will issue use licenses to users of the trusted hierarchy. To do so, click the Extranet cluster URL settings link on the Administration page to open the Extranet cluster URL settings page. Enter the externally resolvable FQDN of the RMS server, then click Submit.
Publishing trusts are more complex than user trusts. A publishing trust permits RMS servers to issue use licenses for content on behalf of another RMS server whose RMS licensor certificate and associated private key you must import. Publishing trusts are intended for use when one RMS hierarchy takes over another—for example, when two companies merge. The RMS Server Deployment Guide contains more information about publishing trusts and their use.