Maintaining the Logging Database

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

Log entries also include copies of the licenses issued for various RMS operations, such as enrolling users and assigning use licenses. In a worst-case scenario — in which every log entry is a successful user enrollment or a successful attempt to acquire a use license — each log entry will add around 200 KB to the size of the logging database.

For example, assume that an RMS-protected e-mail message has been sent to all employees in a company that employs 50,000 users and every employee opens it. If each employee opened this e-mail message over a period of one day, the logging database would grow by 10 GB. The amount of information logged can be reduced by configuring the listener service to not log the actual XrML data.

Consider creating scripts to archive older information from the logging database into a secondary database. Examples of logging scripts are available in the RMS Toolkit, which is available as a free download from the Microsoft Web site (https://go.microsoft.com/fwlink/?LinkId=20760).

Variables Affecting Logging Database Growth

Predicting the size of a logging database depends on your environment. A number of entries within the log can be predicted, including:

• RMS server enrollment

• User enrollment (a unique request for each computer used by each user)

• Automated user requests for offline publishing certificates

The bulk of entries in the logging database after the initial entries relate to the issuance of use licenses for protected content. A number of conditions affect the growth of this database:

• Requiring a new license each time a user accesses protected content. This is not the default method for protected documents, but is an optional setting. If you choose to implement this requirement, you databases will grow at a faster rate.

• Expected number of protected e-mail messages sent to each person each day.

• Expected number of unique users who will read these protected e-mail messages.

• Expected number of documents protected by RMS-enabled applications produced by each person each day.

• Expected recipients of the protected documents.

The initial size of the logging database will be about 1.7 MB, which includes the request for a certificate by the RMS cluster. Each time a new user enrolls, the new user obtains a rights account certificate (RAC) and client licensor certificate (CLC). These two actions are logged, and between them they increase the database by 0.06 MB. Each time a user successfully acquires a license for protected content, the database will grow by 0.19 MB.

To consider how this estimation works, consider an organization with 5,000 users who deploys RMS for all to use. Each user has one computer, and the organization uses two RMS servers. After deployment, each user, on average, creates one RMS-protected e-mail message each day, which is sent to five other users. Each user also creates one RMS-protected document during a day, which is accessed by three other users. The following table estimates how much this activity increases the size of the logging database.

Thus, after enrollment, the logging database has a static size of about 300 MB. However, the daily growth in this example is 7.6 GB — close to the 8 GB limit of the default Message Queuing installation. If the logging database became unavailable for any longer than a day, messages will not be logged and data could be lost.

Controlling the Logging Database Size

Your deployment plan needs to include a method for managing the logging database. This following are the most common approaches.

• Prune and archive

  This method involves using SQL Server scripts to archive selected information from the logging database into a secondary database once the log entries reach a certain age. It also involves filtering the databases of irrelevant information so that space is not wasted on it.

• Limit the information logged

  The logging database is composed of three main tables. One of these is DRMS_Log_Filter, which identifies which field in the master table should be logged when log filtering is enabled.

  The on/off table entries dictate which fields in the master table are actually logged by the logging listener service on the RMS server. Two of these fields (related to XrML) have already been set to 0 to disable logging because these two fields account for about 99% of the size of each license-request row.

  Another table under the RMS configuration database, called DRMS_ClusterPolicies, contains a PolicyName of LoggingFiltering. LoggingFiltering is not enabled by default. If you change the value for LoggingFiltering to 1 and restart the logging listener service, the daily database growth in the example provided earlier would drop from 7.6 GB each day to about 160 MB each day.

• Move the logging database

  Another option for managing a growing logging database is to simply move it to a server with more disk space. The logging database can exist on a different database server than the configuration database. To move the database to a different server, follow these steps:

  1. Stop the logging listener service on each RMS server.

  2. Copy the database (or create a new one) on a different server.

  3. Edit the RMS DRMS_Config_ServerName_Port database by selecting the DRMS_ClusterPolicies table and editing the values for LoggingDatabaseName (Database server name) and LoggingDatabaseServer (Database name).

  4. Restart IIS by running IISRESET.exe from the command line.