System Recovery Preparation

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Failure of any component of the RMS system, including the Internet and intranet connections used by the RMS root cluster, any of the subenrolled RMS licensing-only servers, or the database servers hosting the RMS configuration databases, can cause an unexpected loss of service. When you set up an RMS system, it is important to consider the potential impact on your IT systems and sensitive data should a loss of RMS service occur and prepare to recover the component as efficiently as possible.

The failure of the database servers that host the RMS configuration databases would be the one component that could prevent continued access to RMS-protected information. This section describes the important considerations and factors in preparing for system recovery for an RMS system, including the following:

  • Internet Connectivity

  • Intranet Connectivity

  • Certification and Licensing Services

  • Database Servers

  • Active Directory

Internet Connectivity

If you are using online server enrollment, the RMS server needs Internet connectivity during provisioning to obtain a server licensor certificate (SLC) and to renew once each year. When the one-year anniversary approaches, the root cluster notifies you to renew the certificate by logging events to the System event Log. Events are logged one month before the SLC expiration date (Event ID 16), one week before the SLC expiration date (Event ID 17) and when the SLC expires (Event ID 18). The RMS Global Administration Web page of the RMS Administration Web site will also alert you that the SLC expiration date is approaching. If you are using the RMS Management Pack for Microsoft Operations Manager (MOM), the expiration events will trigger an alert. If the Internet connection is not available on the RMS root cluster, the server licensor certificate cannot be renewed by using the Renew button in the RMS Administration Web site and the offline enrollment process must be used to request an updated certificate.

As a best practice, renew the SLC well ahead of its expiration date to avoid complications if the Internet connection were to be unavailable when the certificate expires. The RMS root cluster cannot provide RMS services without a valid SLC, meaning users will not be able to publish RMS-protected information or obtain the use licenses and rights account certificates (RACs) required to read RMS-protected information. Users who previously acquired use licenses and RACs for portions of RMS-protected content can continue to access the information until their use licenses or RACs expire.

Intranet Connectivity

RMS is a client-server technology that relies on a connected infrastructure. Without a functioning intranet network, RMS clusters cannot connect to required services within the enterprise or to the users to supply services. Without intranet connectivity, users cannot obtain rights account certificates (RACs), client licensor certificates (CLCs), and use licenses from the RMS servers.

As a best practice, organizations should consider redundant routing architectures and failover links from remote sites to the RMS cluster sites.

Once a user has obtained a CLC for that user's computer, the user can publish RMS-protected information offline when there is no access to an RMS cluster. Some RMS-enabled e-mail applications have been configured to download use licenses for the associated RMS-protected e-mail messages automatically when synchronizing a mailbox, so that the user can read RMS-protected e-mail messages even if the intranet connection is no longer present.

Certification and Licensing Services

The RMS system relies heavily on two virtual directories within Internet Information Services (IIS) 6.0, the certification and licensing services. These services allow users and their computers to enroll into the RMS environment and RMS-enabled applications to publish and access RMS-protected information. If these services become unavailable, users could be denied service until they are restored.

To prepare for potential loss of service, consider creating the root and subenrolled licensing-only clusters so that the breakdown of any node in a cluster does not affect availability of the service.

As a best practice, build surplus capacity into clusters so that faults on any node do not affect overall performance. When you install the root cluster and each subenrolled licensing-only cluster, carefully record the configuration options and data entered during provisioning.

Database Servers

The most important components in the RMS system are the database servers that hold the configuration databases. Each RMS cluster uses a database to store configuration and logging information. The configuration information is essential to the operation of RMS. These databases hold the server licensor certificate, the RMS policy templates that have been produced, and a list of users enrolled within the RMS system. If a hardware security module is not used with an RMS cluster they also contain the private and public keys of the RMS cluster. With backups of the RMS databases, you can restore a previous RMS installation onto a new server and recreate an RMS system. The impact of a loss of database differs depending on the database. The following list describes the impact of a given database failure:

  • Configuration database. If this database becomes unavailable during operation of the RMS cluster, the RMS services can continue to operate because RMS locally caches the required information. However, if an event occurs that requires RMS to interact with the configuration database, such as a new user enrollment, it will encounter an error and the new user will not be able to work with RMS-protected content. If an operation occurs that causes the RMS cluster to discard the cached information, such as restarting the IIS service or a scheduled refresh of the local cache, RMS will stop working. The RMS cluster will not be able to return to normal service until the configuration database is available.

    If the configuration database becomes corrupted or permanently unavailable, the RMS clusters will stop working.

  • Directory services database. Holds cached information about group names and their membership details obtained from a global catalog server. There is no noticeable reduction in RMS services when this table is not available for short periods of time. Its main purpose is to provide redundancy and reduced service loads for the global catalog server.

  • Logging database. If logging has been enabled on the RMS cluster, then the logging database is used to store this information. If the database is unavailable, then the log entries will build up on the Message Queuing service on the RMS server, and will use all available disk space unless configured not to do so.

As a best practice, cluster the database servers to provide active-standby, failover protection. Also, regularly back up databases for RMS root clusters, as well as licensing-only clusters.

As another best practice, use transaction log shipping as a means to maintain a ready, backup database. Although this practice might require additional hardware, it enables organizations to recover the databases more quickly. Microsoft IT implemented this method for RMS configuration database recovery. To accomplish this, select the virtual SQL name during RMS provisioning. The virtual SQL name enables you to map to the real SQL name by using the Domain Name System (DNS). Should the original SQL Server stop working, you can switch easily to the backup SQL Server by changing the DNS name mapping from the original server to the backup server.

Active Directory

RMS relies on Active Directory for two important services: user authentication and the global catalog service. If Active Directory is not available, user authentication is not possible, and users and their computers will not be able to publish or consume rights-protected content. The certification pipeline is required to obtain a RAC; this pipeline requires authentication. Once a user has a RAC, that individual can obtain use licenses without further authentication as the licensing pipeline is anonymous by default.

Because enterprise entities can use group memberships in Active Directory to control who has access to RMS-protected information, the loss of Active Directory would prohibit users from acquiring use licenses. By default group membership information is cached on the RMS server for 15 minutes, so a temporary loss of the global catalog service can be tolerated. If you want to increase or decrease the amount of time between updates of the group membership information cache, you can modify the registry key that controls the validity time. For more information, see "Modifying Active Directory Cache Settings" in “RMS: Operations” in this documentation collection.