AD RMS and Database Design

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

Servers in the AD RMS cluster are tightly integrated with the database server during provisioning and normal operations. The AD RMS database server stores critical configuration, logging, and directory services information for use by AD RMS. It is imperative to understand the information stored in the database and appropriate system and hardware design for the component.

You can use the Windows Internal Database in Windows Server® 2008 to support a new installation of AD RMS using a single-server. However we recommend that you use a separate database server such as Microsoft SQL Server 2005. AD RMS uses the following databases:

  • Configuration Database

    The configuration database is a critical component of an AD RMS installation because it stores, shares, and retrieves all configuration data and other data that you need to manage account certification, licensing, and publishing services for a cluster. The way that you manage your configuration database directly affects the security and availability of rights-protected content. Each AD RMS cluster has one configuration database. The configuration database for the certification cluster contains a list of Windows user identities and their rights account certificate (RAC). If the cluster key is centrally managed by AD RMS, the certificate key pair is encrypted to the AD RMS cluster key before it is stored in the database. The configuration databases for licensing-only clusters do not contain this information.

  • Directory Services Database

    This database contains information about users, identifiers (such as e-mail addresses), security ID (SID), group membership, and alternate identifiers. This information is obtained from Lightweight Directory Access Protocol (LDAP) queries made to the Active Directory Domain Services (Active Directory DS) global catalog by the AD RMS licensing service.

  • Logging Database

    For each certification or licensing-only cluster, by default AD RMS installs a logging database in the same database server instance that hosts the configuration database. AD RMS also creates a private message queue on each server in the AD RMS cluster for logging in Message Queuing. The AD RMS logging service transmits data from this message queue to the logging database.

High Availability

SQL Server provides two different high availability technologies that can be used in conjunction with AD RMS:

  • Failover Clustering

  • Log Shipping

Failover Clustering

Failover clustering is the perhaps the most widely deployed technology for SQL high availability. It uses the Microsoft Cluster Service (MSCS) feature of Windows 2003 to provide availability in the event of an application failure, hardware failure, or operating-system error.

With failover clustering the entire SQL Server instance runs from a shared disk resource and is accessible from a virtual IP. During failover another cluster node takes control of the shared disk resource and the virtual IP and restarts the SQL Server instance.

Failover clustering is supported by both SQL 2000 and SQL 2005, requiring the Enterprise Edition in SQL 2000. Support for failover clustering in Standard Edition is new in SQL Server 2005, and only two-node failover cluster instances are allowed using that version of SQL Server, even though the cluster itself might have more nodes

Failover clustering requires special hardware such as a shared disk array and cluster-aware disk controllers. It is imperative that the hardware and software configuration is on the Hardware Compatibility List (HCL) and purchased as a cluster solution in order to be supported by Microsoft. See, The Microsoft SQL Server support policy for Microsoft Clustering (https://go.microsoft.com/fwlink/?LinkId=154594).

Unlike other technologies like log shipping, clustering requires no client-side support for the failover, which happens transparently to client applications. For all purposes AD RMS treats and works with a clustered database server exactly the same way it would do with a standard non-clustered server.

Log Shipping

Log Shipping is a technology available in both SQL Server 2000 and SQL Server 2005 that allows the creation of a warm standby server. Log Shipping automatically copies and restores the database's transaction logs the standby server, making it an exact duplicate of the original database—out of date only by the delay in the copy-and-load process. You then have the ability to make the standby server a new primary server if the original primary server becomes unavailable. When the original primary server becomes available again, you can make it a new standby server—effectively reversing the servers' roles

The primary server is the production server on which the real work takes place; this server holds the source database. The secondary server holds the destination database to which you copy and restore the source database's transaction logs. A monitor server monitors both the primary and secondary servers. Microsoft strongly recommends that you put the log shipping monitor on its own server.

When the primary database server goes down—as the result of planned maintenance or an unexpected event— an intact copy is available on the secondary server, which can be brought into production. This is called a log shipping role change. .

During role change, the connection strings will have to be manually changed on the CLM Web servers and on the Certification Authorities to point to the new production server. Other than this situation, CLM works transparently with Log Shipping.

For additional information see, (How to configure security for SQL Server log shipping (https://go.microsoft.com/fwlink/?LinkId=154596).

Sizing Considerations

The scaling requirements depend on the number of AD RMS users and client PCs, and the number of the RMS-protected documents that are issued and consumed. Each AD RMS server is capable of handling a set number of client requests in a set amount of time (approximately 30 to 50 licenses per second). Because of this, adding servers linearly scales out the total license-issuing capacity of a cluster, and also provides increased reliability. As a result, scaling should be appropriate not only to each individual server, but also to the number of servers that you deploy. An in depth look at sizing is beyond the scope of this document. For detailed technical information on database sizing see the additional information referenced below.

For additional information on the AD RMS database see the related resources section.

See Also

Other Resources

Understanding the AD RMS Databases
AD RMS Performance and Logging Best Practices
AD RMS SQL Server Requirements