Exchange Server Caches and Their Lifetimes

In this post, I discussed the various ways that Exchange Server accesses Active Directory.

In large environments, Exchange Server has the capability of stressing the domain controllers (especially global catalog servers) that it uses, based on the number of queries that Exchange Server (and Outlook) make to the global catalog. In this case, "large" is defined as any environment that makes extensive use of features that may require access to the Active Directory. A typical recommendation is that (when using x86 domain controllers) you dedicate one global catalog server for every four Exchange Servers. If you are using 64-bit domain controllers, that ratio can be changed to 1-in-8.

In order to optimize access to Active Directory, Exchange Server maintains a set of caches. These caches are used to store the results of queries from Active Directory, for a period of time. However, these caches can get in the way of an administrator getting their job done. It is rare the administrator that has made a security change to a user object and wonders why it doesn't seem to work...or has increased the quota for a mailbox and wonders why it doesn't take effect.

The reason? Cache lifetimes.

DSAccess (discussed in the post linked above) maintains a cache of user objects. The Exchange Information Store maintains a cache of mailbox information. The DSAccess cache, by default, times out in five minutes. The information store mailbox cache, by default, times out in two hours. The concept behind this tiering is that mailbox information, being a small subset of the information that a user object contains, is not likely to change very often in comparison to the entire user object.

In a dynamic Exchange environment, that assumption is probably wrong for some small set of user and mailbox objects. If you make a change to Exchange attributes on a user or group or contact, you certainly do not expect to wait up to two hours for that change to take effect.

The Exchange Information Store also maintains yet another cache of mailbox quotas and limits. This cache is fed from the mailbox information cache. By default, this cache is also updated only each two hours. This means that, if you change a logon quota, it will normally take about two hours for that change to be reflected for the user. In the very worst case, it could take up to four hours and five minutes.

Your alternative is to restart the information store (the MSExchangeIS service). If you aren't aware of this limit, you will likely eventually get to that step (or the step of rebooting the server) as you sit around wondering what you have forgotten to change after updating the user quotas and seeing that they are not taking effect.

Neither of these alternatives is really acceptable. Therefore, in Exchange 2000 Server Service Pack 3 and Exchange Server 2003 RTM and in Exchange Server 2007 RTM, Microsoft provided registry keys that can affect the lifetime of each individual cache, as well as some basic guidelines about acceptable values for the cache lifetimes. The recommended values show tiering as well. They are:

  • DSAccess user object cache - 5 minutes
  • Mailbox information cache - no recommendation
  • Mailbox quota and limit cache - 20 minutes

Microsoft documentation warns that if you set the lifetimes to "very low values" that this can have performance implications for your Exchange server(s).

To test the above statement, I set the DSAccess user object cache lifetime to 5 seconds on a test dual-processor Exchange server with 4 GB of RAM and about 1,000 user objects. The information store pegged one processor at 100% utilization. So... they are right. Don't do that.

To find ideal values for your environment may require experimentation. However, I have had good success with these values:

You can use registry editor to set these values. See Microsoft KB 327378 (Exchange 2000 and Exchange 2003 mailbox size limits are not enforced in a reasonable period of time; fix requires Exchange 2000 SP3) for information about how to do that. For Exchange Server 2007, refer to this technet article. However, you may find it easier and less error prone to use the registry files I provide here. For DSAccess, place the following lines into a file named DSAccess-cache.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess\Instance0]
"CacheTTLUser"=dword:000000b4


Please note that the blank lines (lines 2 and 5) are significant and should not be deleted. The CacheTTLUser value is set to 180 seconds (which is three minutes or 0x0b4 in hexadecimal) in this example. To set the value to 300 seconds (which is five minutes) change the final 0b4 to 12c.

Finally, assuming that you place the file into a folder named c:\temp, execute the following command:

regedit /s c:\temp\DSAccess-cache.reg

and this will load the value into the registry of your Exchange Server.

The other two caches both exist within the Exchange Information Store and therefore the values to edit exist within a single registry key. Place the following lines into a file named ExchangeIS-cache.reg:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem]
"Reread Logon Quotas Interval"=dword:00000384
"Mailbox Cache Age Limit"=dword:0000000a


Lines 2 and 6 are significant and should be left blank and not deleted. The Reread Logon Quotas Interval value is set to 0x384 seconds (which is 900 seconds in decimal, which is equal to 15 minutes). The Mailbox Cache Age Limit value is set to 0xa minutes (which is 10 minutes in decimal).

Finally, assuming that you place the file into a folder named c:\temp, execute the following command:

regedit /s c:\temp\ExchangeIS-cache.reg

and this will load the values into the registry of your Exchange server.

Once you have made these changes, you will need to restart the Exchange Information Store service (MSExchangeIS) and the Exchange system attendant service (MSExchangeSA). Unless your server is used for other things than Exchange, you may as well reboot.

Making these recommended changes will greatly improve your administrative experience, if they are suitable in your environment.

Published Friday, January 18, 2008 1:54 PM by michael

Comments

Tuesday, July 21, 2009 9:22 AM by E2K7: Exchange Cache Limits : Servus

# E2K7: Exchange Cache Limits : Servus

Pingback from  E2K7: Exchange Cache Limits : Servus