Tricks and Tweaks for Maintaining Exchange Databases

Exchange Server databases require regularly scheduled maintenance to keep them functioning at peak performance. This maintenance includes tasks such as getting rid of deleted mailboxes, cleaning up public folders, and defragmenting the database. Exchange Server 2003 performs these and other maintenance tasks automatically. Even so, it's important to have a good understanding of how this automated maintenance process works so that you can have more control over when and how the server carries out these tasks to optimize the process for your environment.

Exchange Server Maintenance Tasks
Exchange 2003 performs 11 tasks as part of its automated database maintenance schedule. Those tasks are:

As you can imagine, performing all 11 tasks against an Exchange store can take quite a while, depending on the size of the database and the condition that the database is in at the beginning of the maintenance cycle. The problem is that Exchange must perform the maintenance tasks while causing the least possible impact on users. In most cases, this means performing the maintenance tasks at night, and doing so in a way that doesn't interfere with the nightly backup. This usually doesn't leave a lot of free time for IS maintenance.

Because time limitations might prevent all the maintenance tasks from running on a nightly basis, Exchange performs the tasks in a prioritized manner according to which tasks have run most recently and which tasks are most important. Fortunately, the priorities are simple. The first 10 tasks on the list have equal priorities. However, the 11th task (performing an online defragmentation of the IS) is considered more important than the other 10 tasks.

The first time that the Exchange maintenance cycle runs, it begins with the first task on the list and works through as many of the other tasks, in the order listed, as time allows. If the maintenance period reaches the point where only 15 minutes remain and not all the tasks have been completed, then Exchange must make a decision. If Exchange has spent the entire maintenance period on one task, and that task hasn't finished running, then Exchange will continue to spend the remainder of the maintenance period on that task. However, if at least one task has finished, Exchange makes note of that last completed task, aborts the current maintenance task, and begins an online defragmentation. Because Exchange considers an online defragmentation to be more important than the other maintenance tasks, it allows the defragmentation to run for as long as an hour after the maintenance period has expired.

The next time that Exchange encounters a scheduled maintenance period, it checks to see which task was the last one to successfully finish (not counting the online defragmentation). Exchange then launches the next task on the list. By not restarting at the beginning of the task list each night, Exchange is able to guarantee that each maintenance task runs occasionally.

Adjusting the Maintenance Period
Before I show you how to modify the maintenance schedule for your stores, you need to know two things. First, maintenance is performed at the IS level. This means that if your Exchange implementation contains multiple stores, you'll need to schedule maintenance independently for each store. Second, IS maintenance is very resource intensive. It consumes a lot of disk space and CPU time. You need to take this into account when scheduling maintenance. If the maintenance cycle were to run during the nightly backup, the maintenance cycle and the backup would both be competing for disk resources, greatly slowing both processes.

You probably have a good idea of when the periods of peak activity are for your server and when the backup starts and finishes each night. Ideally, you'll want to schedule maintenance around these times. For example, if you know that your users start logging on around 7:30 A.M. and that almost everybody has gone home by 6:00 P.M., and your backup is set to run at 11:00 P.M., then you could schedule maintenance to run from 6:30 to 10:30 each night.

As you plan your maintenance schedule, keep in mind what I said about maintenance being resource intensive and that it's performed at the IS level. If your Exchange Server has multiple stores, you should configure the maintenance to occur at different times for each store, although this isn't always practical if your server has a large number of stores.

The default Exchange maintenance schedule allows it to perform maintenance on all stores from midnight to 4:00 A.M. nightly. If you want to change the maintenance schedule, you can do so by opening Exchange System Manager (ESM) and navigating through the console tree to Administrative Groups, your administrative group, Servers, your server, your storage group, your store. Right-click the store for which you want to make the adjustment, and select Properties from the context menu. Select the Database tab, as Figure 1 shows. The Database tab contains a Maintenance interval drop-down list from which you can select a four-hour block of time to use as the IS's daily (or nightly) maintenance period.

Although you can use the Maintenance interval drop-down list to specify a store's maintenance period, you aren't limited to the choices presented on the menu. You can click the Customize button to create a custom maintenance schedule for the store. When you do, you'll see a scheduling box, such as the one Figure 2 shows. I strongly recommend that you set the maintenance schedule to allow for at least four hours of maintenance a day, but you do have the option of skipping days or of performing maintenance for shorter or longer periods of time. If you're considering skimping on maintenance, just keep in mind that the maintenance tasks are designed to keep the IS running at peak efficiency and to prevent corruption. Skimping on maintenance increases your chances of experiencing performance problems or corruption within the IS.

Customizing Online Defragmentation
As you can see, it's quite easy to control when Exchange performs maintenance on a store. With a few registry tweaks, you can also control how and when online defragmentation occurs.

As I said earlier, as long as at least one task has completed, online defragmentation will begin 15 minutes before the maintenance period is set to expire and will continue to run for up to one hour after the maintenance period expires. However, you can modify the registry to allow online defragmentation to run for a longer period of time or to adjust the schedule so that it doesn't interfere with a backup.

The location that contains the registry keys that control automated online defragmentation varies slightly, depending on whether you're referencing a private store (i.e., a mailbox store) or a public store (i.e., a public folder store). If you want to modify the way that online defragmentation runs against a private store, you use the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservernamePrivate -GUID subkey, where servername is the name of your server, and GUID is the store's globally unique identifier (GUID). If you want to modify the online defragmentation settings for a public store, you'll use the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSEx changeISservername Public -GUID subkey. Figure 3 shows the registry locations that control the behavior of online defragmentation.

The first trick that I want to show you is how to adjust the amount of time to be used for online defragmentation at the end of a maintenance period. To do so, create a REG_DWORD value named OLD Minimum RunTime for either of the subkeys listed above, depending on which store you want to change. Assign the subkey a value that reflects the number of minutes that you want to dedicate to online defragmentation at the end of the maintenance cycle.

The second registry tweak that you can use to control the online defragmentation task involves creating a REG_DWORD value named OLD Completion Time. This value controls how long the online defragmentation process will run after the maintenance period has expired (the default is one hour). The value that you assign to this subkey should reflect the number of additional seconds that the online defragmentation process should run (3600 seconds equals one hour). Note that if you change these values, Exchange Server Best Practices Analyzer (ExBPA) will flag your configuration and display a nondefault configuration message. (For more information, see the Microsoft article "OLD Minimum RunTime for a public folder store is non-default" at http://www.microsoft.com/technet/prodtechnol/exchange/analyzer/5ba05346-788c-4d16-8f0f-d6631e418a83.mspx?mfr=true.)

Cleaning Up Deleted Mailboxes
Now that you know how to customize the maintenance schedule and online defragmentation process, I'll show you some adjustments that you can make to some of the other maintenance tasks (not all maintenance tasks are configurable).

The first task is cleaning up deleted mailboxes. When an administrator deletes a mailbox, the mailbox is retained within the Exchange database for a default period of 30 days. When the retention period expires, the Clean Up Deleted Mailboxes maintenance task purges the deleted mailbox from the IS. This process differs from regular deleted item retention in that we're talking about entire deleted mailboxes rather than just deleted messages. A separate maintenance task deletes expired messages.

You set the retention period for deleted mailboxes within Active Directory (AD). To do so, open the ADSI Edit utility, which is included in the Windows Server 2003 Support Tools. Navigate through the console tree to Configuration, Configuration for the domain containing the Exchange Server, Services, Microsoft Exchange, Exchange organization, Administrative Groups, your administrative group, Servers, your Exchange Server, Information Store, and select the storage group (SG) containing the store that you want to work with.

When you select the appropriate SG, you'll see the stores within that SG in the column to the right. Right-click the store whose properties you want to modify, and select Properties to view the store object's attributes. Locate the msExchMailboxRetentionPeriod attribute, as Figure 4 shows, and use the Edit button to assign a new retention period (in seconds) for the store. The default value is 2,592,000, or 30 days.

Removing Expired Messages from the Dumpster
When a user deletes a message, Exchange doesn't actually delete the message. Instead, the client sets the ptaMsgDeleted flag to indicate that the client should treat the message as being deleted and not display the message.

What happens next depends on whether the client has the Deleted Items Retention (aka dumpster) functionality enabled. If the dumpster isn't enabled, the deleted messages will be permanently deleted the next time that the remove expired messages from the dumpster maintenance task runs. If the dumpster is enabled, a retention period is assigned to each deleted message, and the remove expired message from the dumpster maintenance task will permanently delete the message only after the retention period has expired.

To set the retention period for deleted messages, open a registry editor and navigate to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservername Private-GUID subkey or the HKEY_LOCAL|MACHINESYSTEMCurrentControlSetServicesMSExchangeISservername Public-GUID subkey and create a REG _DWORD value named Deletion Thread Period. Assign it a value that reflects the desired retention period (in seconds).

Purging Indexes
Whenever the information within an Exchange Server database is sorted, the Extensible Storage Engine (ESE) dynamically creates an index for the sorted view. If these indexes didn't eventually expire, you could potentially end up with thousands of indexes for each store. To prevent this situation, Exchange assigns each index an expiration period. In Exchange 2003, indexes expire 40 days after they're created (eight days in Exchange Server 5.5).

When an index is created, Exchange adds a reference to the index and its expiration time to an internal table called the index aging table. When Exchange performs the purge indexes maintenance task, it uses this table to determine which, if any, indexes have expired and removes them.

AD controls the amount of time that indexes are retained. You can modify this setting by using ADSI Edit to navigate to Configuration, Configuration for the domain containing the Exchange server, Services, Microsoft Exchange, Exchange organization, Administrative Groups, your administrative group, Servers, your Exchange Server, Information Store. Select the SG containing the store that you want to work with. Typically, you'll change this setting only if server resources are a concern.

The attribute that controls the index-retention time is msExchAgingKeepTime. By default, this value isn't set, but you can set it to the number of seconds that you want to retain indexes. The reason that the attribute isn't assigned a default value is because index-retention time was originally controlled through the registry. You can still control the retention time through the registry, but the AD attribute supersedes settings made through the registry.

If you want to change the index-retention time by modifying the registry, you can create the necessary subkey at HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISParametersSystem. There are two different registry subkeys that you can create that will control index retention. The first is Aging Keep Time (of REG_DWORD type). This subkey does the same thing that the AD object does. It lets you set the number of seconds that indexes are retained. By default, indexes in Exchange 2003 are retained for 40 days.

The second subkey that you can create is Aging Clean Interval (of REG_DWORD type). This subkey controls how often (in seconds) Exchange attempts to purge expired indexes. By default, Exchange 2003 attempts to purge expired indexes once every 24 hours.

Typically, you should leave both of these registry keys alone. There are times when it may be prudent to decrease the Aging Keep Time value from the default period of 40 days, though. If a folder contains too many cached searches, back links, restrictions, and the like, client response times become very slow.

If client response times become extremely slow and you start receiving Messaging API (MAPI) errors that contain the phrase Client Operation Failed, decreasing the Aging Keep Time period might fix the problem. Another symptom that might indicate that you should decrease the Aging Keep Time period is if response time is slow when accessing some of the folders within a store but normal for other folders in the same store.

You can decrease the Aging Clean Interval so that Exchange will purge expired indexes more frequently, but I don't recommend doing so unless advised by Microsoft Product Support Services (PSS) because purging expired indexes can be resource intensive.

Resolving Message Conflicts Within Public Folders
One of the more obscure Exchange maintenance tasks is resolving message conflicts in public folders. The idea is that public folders can be replicated across multiple servers. If two or more replicas of a message within a public folder are simultaneously modified, the message is said to be in conflict.

Exchange gives the public folder owner a specific amount of time to resolve the conflict manually. This period of time is called the conflict age limit. If the public folder owner doesn't resolve the conflict within that period of time, the resolve message conflicts maintenance task will resolve the conflict automatically according to an internal set of rules.

You can set or modify the conflict age limit by making a change to the registry. To do so, go to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservernamePublic-GUID registry subkey and create a REG_DWORD value named Replication Folder Conflict Age Limit. Assign it a value that reflects the number of days that messages are allowed to remain in conflict.

Removing Expired Messages from Public Folders
The final maintenance task that I want to talk about is that of removing expired messages from public folders. The message-expiration period is set on a per-folder basis, so there's no registry subkey that lets you globally adjust the expiration period. However, you can create a registry value that controls how often Exchange flushes expired messages from public folders. Again, be careful using this setting because it can disrupt other maintenance tasks.

To set the message-removal frequency, go to HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesMSExchangeISservernamePublic-GUID and create a REG_DWORD value named Replication Expiry. Assign it a value that reflects the number of milliseconds between message-removal periods.

Automated Doesn't Mean Hands Off
As you can see, scheduled maintenance is vital to the integrity and performance of Exchange's IS. By understanding how the automated maintenance process works and using the techniques in this article, you can have more control over how the server performs these tasks to optimize the process for your environment.