Export (0) Print
Expand All

Database Configuration and Maintenance

Applies To: Windows Server 2008, Windows Server 2008 R2

Initially, the AD RMS configuration database consumes three megabytes (MB) of disk space, and it adds an additional 1 MB for every 500 users certified. Typically, the user information makes up over 90% of this database space. Each additional user’s certification information takes up approximately 2 KB. The number of user certifications is bigger than the number of the certified users, since a certification is performed at each computer where a user creates or consumes protected information. This can make a significant difference in environments where users roam from one computer to another, as the certification process adds 2 KB for each computer where a user is certified. As an example, in Microsoft’s internal deployment experience, the certification of 250,000 AD RMS individual users (a number that includes old user accounts no longer active), over a period of five years at its main certification and licensing cluster, consumed about 2 GB of database space (including multiple certifications for each user on different systems). In addition to this 2 GB, an additional 2 GB had to be added for the transaction log and autogrow needs, so the total configuration database space for 250,000 is about 4 GB, in Microsoft’s case.

We recommend that the certification database be set to full recovery model and we highly recommended that it is backed up, at least daily. Transaction logs for the database should be backed up much more frequently (possibly to local disk) in order to truncate the logs and to provide thorough recovery capabilities.

This database is composed mainly of cached user and group information from Active Directory. The user and group information includes e-mail, SID, and other alternative names and identifiers. When user and group accounts are the members of other groups, the parent group information is also included in this cache.

In Microsoft’s case, with 250,000 user accounts (each a member of 50 groups, on average) and 250,000 group accounts (each a member of five other groups, on average), the directory services database takes up 4 GB of database space. The directory services database stores only the information used for AD RMS transactions and ignores other information in AD. 2 GB of disk space are added for transaction logs, so the total used database space for the directory services database at Microsoft’s main cluster is about 6 GB.

The information in this database is less critical for AD RMS than that in the Configuration database, since it is retrievable from the directory service when needed, even if the database is lost. However, such a loss will impact AD RMS server performance and directory service load, as well as network traffic to the directory servers. It is highly recommended that this database is kept available as much as possible. The database can be set to full recovery model, and it is generally recommended to back it up daily and to back up the transaction logs frequently (in order to reduce transaction log size and to enable fast recovery).

In AD RMS, logging is enabled by default (this can be changed in the AD RMS administration console), but logging of the XrML text in the certificate table is optional. The XrML is logged only when the LoggingLevel (DWORD) registry value under HLMK/System/CurrentControlSet/Services/AdRmsLoggingService/Params/ is set to 1 (this is not the default setting).. This reduces significantly the amount of information logged for AD RMS. Typically the default logging database size is reduced by approximately six or seven times when XRMS text inclusion in the Certificate table is not enabled.

In Windows RMS (RMS v.1), the logging database grew by approximately 1 MB for each user during the initial user certification phase when a large amount of logging occurred. Under routine operations, the logging database grew at the rate of 250 kilobytes (KB) for each user per transaction, due to the fact that identical values were written in the log for each request, including the XrML text of the certificate. If 20,000 RMS users are active in an infrastructure and each user has an average of ten RMS transactions per day, it would require 50 GB per day to log all this activity with XRML text logging in Windows RMS. Conversely, if a licensing cluster was hit with a peak of 20.000 licensing operations in a single hour (something that can occur when a protected message is sent companywide or to a large distribution list), the logging database could grow by up to 5 GB during that period.

In AD RMS, all fields that exist in RMS v1 are still logged (except for the XRMS text, by default). However, there is a difference in the way the information is structured: the data is now located in several different tables. The change to the table structure is made to reduce the amount of space required in the database to avoid identical information being logged in several different places. In RMS v1, each request contains repetitive information being written into the log such as request type, the identity of the user, their machine, the name of the server providing the licenses and certification. In AD RMS, much of this repetitive information is normalized, so it is put into separate tables where it is written only once, and subsequent requests simply point to the table containing this information. The result is that while the logs grow very quickly during the initial period, that growth slows down as the tables become populated. Eventually, most of the growth becomes restricted to the tables named Service Request and Certificate for licensing and certification operations.

Normally a certification requests consists of three service requests and populates three certificate fields, while licensing requests consist of two service requests and populate two certificate fields. Each service request field requires roughly 0.5 KB, and each certificate field requires 2 KB, or approximately 20 KB when XrML text is logged. This figure is obtained from a production AD RMS database server, with a 50 GB logging database, by dividing the database space reserved for the corresponding fields by the number of records (in different environments, the results can vary slightly, depending on the characteristics of the logged certificates).

The following information can be useful to model the logging activity based on AD RMS activity.

 

AD RMS User Actions the number of service request records populated the number of certificate records populated

AD RMS user certification

3

3

AD RMS document protection

1

0

AD RMS policy change

1

0

open protected content for the first time

2

2

open protected content subsequent times

1

0

open protected content with changed policy

2

2

attempt to open content with no rights assigned

2

1 (this will also populate error and description tables)

As can be observed in the table, more AD RMS transactions generate more records in the service request table in the database.

Based on the AD RMS deployment experience at Microsoft, 20,000 RMS users with ten RMS transactions per day each, including initial certification and ten licensing requests, will generate roughly 2 GB of logging activity per day. Even when XrML text logging is enabled, the logging volume grows only to approximately 12 GB per day. The volume of logging activity is reduced by between three and 25 times when compared to RMS v1, depending on whether XrML text logging is enabled.

While the AD RMS logs are not critical information for the operation of the AD RMS service, logging information is important for analysis, diagnostics and troubleshooting among other things, so it should be backed up frequently. Setting full recovery model for the database is an option, and it is highly recommended to back up the database daily and to backup each transaction log more frequently locally. It must be noted that in addition to valid transactions, it is likely that licensing errors and bad request data gets logged as well, typically taking about 10% of the database space used. The rule of thumb is to add a 100% safety margin on the database requirement to accommodate for unknown or sudden incidents such as huge volume of the licensing requests with consecutive company-wide e-mail messages. In addition, the logging information activities should be monitored and the logging database size must be controlled by purging it at a regular basis.

In some high-volume scenarios, the logging database can grow significantly in a short time period. While disk space is inexpensive today and the volumes implied should not represent a problem for modern hardware, managing, safeguarding, monitoring and, more generally, administering the storage might not be as inexpensive, so keeping the volume of logged data at bay is a good strategy in most environments. This type of data hygiene is usually implemented by applying the following strategies:

  • Log backup

  • Log shipping

  • Log trimming

  • Log Consolidation

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft