Exchange Server 2003 and Exchange 2000 Server information store maintenance and online defragmentation

This article discusses some of the internal workings of the Microsoft Exchange Server information store maintenance interval and the online defragmentation period.

When a public or private Messaging Database (MDB) is started, a maintenance task is scheduled to run for that MDB.

When the maintenance task (also known as a thread) runs for the MDB, it exhibits the behavior that is described in the following sections.

Read maintenance schedule

Exchange Server reads the maintenance schedule from the internal (in-store memory) MDB object if it is available, or from Active Directory if the MDB object is not available. The schedule uses one of the following styles:

• Never
• Selected
• Always

Initially, the MDB object is marked so that it requires that the Active Directory object be queried for the schedule style (and to be queried for the schedule details if the schedule style is "Selected"). When the information store detects that the MDB object in Active Directory has been changed, the MDB object is marked so that it requires a refresh operation from Active Directory.

If the schedule style is "Never," the maintenance task is skipped.

If the schedule style is "Selected," the program determines whether the maintenance task runs in the current 15-minute period. If not, the maintenance task is skipped.

If the maintenance schedule cannot be obtained, the default schedule of 12:00 midnight to 5:00 A.M. is used.

Determine maintenance task to perform

The maintenance task (thread) next reads a table in the Extensible Storage Engine (ESE) database to determine the last maintenance subtask that was performed.

This value is used to determine which subtask is initiated first, and it makes sure that all of the maintenance subtasks are eventually run in a round-robin fashion. The following list describes the maintenance subtasks in the order in which they run:

1. Purge Indices Indexes that are created in database tables by the client to be used for views and that have not been used for a specified time are cleaned up when this subtask occurs.
   
   For more information about index aging, click the following article number to view the article in the Microsoft Knowledge Base:
   159197 Controlling folder index aging
   By default, this task runs only one time in a 24-hour period. To override this frequency, use the Aging Clean Interval registry value.
   
   
2. Tombstone Maintenance This subtask compacts the deleted message information that is used for local and public folder replication.
   
   By default, this task runs only one time in a 24-hour period.
   
   
3. Dumpster Cleanup This subtask cleans up any messages that have passed their deleted item retention date.
   
   By default, this task runs only one time in a 24-hour period. To override this frequency, use the Deletion Thread Period registry value.
   
   
4. Public Folder Expiry This subtask expires messages that are in public folders and that are older than a specified time value. The setup for message expiration is on the Limits tab in the public information store container in Microsoft System Manager. For more information about storage limits on public folders, click the following article number to view the article in the Microsoft Knowledge Base:
   319439 How to configure storage limits on Public Folders in Exchange 2000
   By default, this task runs only one time in a 24-hour period and only on the public folder MDB.
   
   
5. Age Folder Tombstone This subtask removes folder tombstone entries that are older than a specified time (the default is 180 days). Folder tombstone information is used by public folder replication. The aging prevents the folder tombstone list from growing without limits.
   
   By default, this task runs only one time in a 24-hour period and only on the public folder MDB.
   
   
6. Folder Conflict Cleanup By default, this task runs only one time in a 24-hour period and only on the public folder MDB.
   
   
7. Update Server Versions By default, this task runs only one time in a 24-hour period and only on the public folder MDB.
   
   
8. Secure Folders Cleanup By default, this task runs only one time in a 24-hour period and only on the public folder MDB. To override this frequency, use the Secure Folder Aging Task Frequency registry value.
   
   
9. Site Folder Check By default, this task runs only one time in a 24-hour period and only on the public folder MDB.
   
   
10. Deleted Mailbox Cleanup This subtask checks Active Directory to determine whether there are any deleted mailboxes. The information store performs an Active Directory lookup for each user in the MDB. The number of users who are in each MDB determines the number of Active Directory Lightweight Directory Access Protocol (LDAP) searches. These searches are used to keep the information store synchronized with any Active Directory changes (specifically, to look for deleted mailboxes). The performance cost of this task is negligible on the Exchange server, but the performance cost can be significant on the Active Directory server, depending on the number of users, number of MDBs, and the online maintenance times of each MDB.
    
    By default, in a corporate scenario, the online maintenance occurs during the night when very few users are logged on, so that the load on the Active Directory servers is very low. The extra domain controller load that is created by online maintenance is typically not a problem in this scenario.
    
    If Exchange Server is installed in a global data center that serves customers who are in multiple time zones, the default online maintenance time may become an issue. The effect that online maintenance has on Active Directory is proportional to the number of users in each of the MDBs on the servers. The maintenance task looks for a deleted mailbox for each user in an MDB. Therefore, if you have 10,000 users in an MDB, the task performs 10,000 LDAP searches of Active Directory when the online maintenance for that MDB begins. If the Active Directory servers are continually under moderate load, you may have to stagger the online maintenance, for example, by setting each MDB to start online maintenance at a different time. This is particularly critical if you have hundreds of thousands of users spread across dozens of servers and hundreds of MDBs.
    
    By default, this task runs only one time in a 24-hour period.

More information about how the maintenance task to perform is determined

The Extensible Storage Engine (ESE) database holds the information about when the last maintenance subtask was performed, and each IS maintenance subtask is performed only one time in a 24-hour period, with the default setting.

The time that is saved as the "last performed time" for each subtask is not always the same as the time of when the subtask is actually performed because the "last performed time" is calculated by adding the interval (default is 24 hours) to the current "last performed time."

For example, assume that the current "last performed time" for a subtask is 4/1/2010 2:00, and the next subtask is performed at 2:30 on 4/2/2010. When the subtask ends, the "last performed time" will be updated to "4/2/2010 2:00" (which results from adding 24 hours to 4/1/2010 2:00), not "4/2/2010 2:30."

Because of this behavior of updating the "last performed time," the subtask can be performed two times in a 24-hour period, depending on the IS maintenance schedule.

Example IS Maintenance Schedule

Monday through Thursday: 19:00 - 24:00
Friday: none
Saturday: 7:00 - 24:00
Sunday: 7:00 - 24:00

Details

1. After each subtask is performed on Thursday, "19:00 Thursday" is saved as the last performed time for each subtask.
2. Because IS maintenance is not scheduled on Friday, the last performed time for each subtask stays the same ("19:00 Thursday").
3. At 7:00 on Saturday, each subtask is performed because 24 hours have passed since the last performed time ("19:00 Thursday").
4. After each subtask is performed, the last performed time is updated to "19:00 Friday" by adding 24 hours to "19:00 Thursday." Notice that the actual performed time of "7:00 Saturday" will not be saved.
5. At 19:00 on Saturday, each subtask is performed again, because 24 hours have passed since the last performed time ("19:00 Thursday"). After each subtask ends, "19:00 Friday" is saved as the new last performed time.
6. At 7:00 on Sunday, each subtask is not performed, because 24 hours have not passed since the last performed time ("19:00 Thursday").
7. At 19:00 on Sunday, each subtask is performed, and the last performed time is updated to "19:00 Sunday."

The start of the maintenance task is indicated when the information store service logs the following event ID message:

Perform maintenance subtasks

A selected maintenance subtask is evaluated to determine whether it is appropriate to run at the current time. A subtask can start at any time during a specified maintenance window, but the subtask is not guaranteed to finish before the end of the maintenance window.

After a subtask is initiated, that subtask runs until it is complete. After a subtask is complete, the completed subtask is evaluated to determine whether it did the work that it was designed to do. For example, evaluation of the Purge Indices subtask will return a value of False if there were no indexes to clean up.

After a subtask is complete, the following event ID message is logged by the information store service: The information store continues to operate on the next subtask unless that subtask is not scheduled to run in the current time interval or unless the service has completed all of the tasks one time during the current maintenance window.

When the last subtask is run for the current maintenance window, the maintenance subtask that is performed is saved to a table in the ESE database so that it can be read when maintenance is started again. Most tasks run only one time in a 24-hour period no matter how many information store maintenance intervals are scheduled.

Maintenance tasks end

When the program determines that no more subtasks are scheduled for the current maintenance window, the following event ID message is logged by the information store service:

Online defragmentation

If at least one subtask completed successfully and performed work that resulted in a database change, online defragmentation runs after information store maintenance is complete.

By default, online defragmentation runs for a minimum of 15 minutes and a maximum of 1 hour after the information store maintenance period.

To override the minimum time for Online Defragmentation, use the OLD Minimum RunTime registry value.

To override the length of time that online defragmentation can run beyond maintenance, use the OLD Completion Time registry value.

If the maintenance schedule style is not "Always," then a check is performed to see how long online defragmentation can run. The amount of time left in the maintenance window is determined and added to the OLD Completion Time value (by default, 1 hour). This accounts for situations where the last subtask runs a little longer than the configured maintenance schedule. If the calculated value is less than the OLD Minimum RunTime value, the calculated value is set to OLD Minimum RunTime.
After online defragmentation is complete, a store routine calculates the number of free megabytes left in the database and logs the following event ID message: After the online defragmentation process is complete, the next time period for maintenance to run is calculated and scheduled.

How to enable logging for a particular Exchange Server service

To enable logging for a particular Exchange Server service, follow these steps:

1. Right-click the server in Exchange System Manager, and then click Properties.
2. On the Diagnostics Logging tab, set the Logging Level to Minimum for the following:
   • MSExchangeIS\Mailbox\General (Information Store Mailbox)
   • MSExchangeIS\Public Folder\General (Information Store Public Folders)
   
   
   Note MSExchangeIS\Mailbox and MSExchangeIS\Public Folder have many categories. You can set the Logging Level to Minimum for the categories as required.

After you set the Logging Level to Minimum, events 1208, 1209, 1210 are logged when you perform the related operations.