Moving Mailboxes During a Microsoft Exchange Migration

Brian St. Marie - Sr. Systems Engineer

In Microsoft exchange migration 2007 and 2010, moving mailboxes between storage groups and
servers is a very simple and easy process.  When performed correctly, there is no interruption of service for the end user during the move and once it's complete, they receive an informative message from Outlook letting them know their move has been completed and requires a restart of Outlook.  Mailbox moves can be performed in groups, either via the shell or console, with full log reporting of the success or failure of each mailbox.

Unfortunately, there is one detail often left out of the migration steps that can cause confusion and maybe even a bit of panic amongst those performing the migration.  By default, Microsoft Exchange caches both user and mailbox information from Active Directory in order to increase lookup efficiency and decrease load on the directory servers.  However, while the user cache expires after only 5 minutes, the mailbox cache is valid for two hours.  This means any significant changes, like having a mailbox moved, will not completely function until after the mailbox cache has expired.  This is counterintuitive as you are performing the move from within Exchange and the mailbox move will correctly reflect in the console or shell by showing the new home server and database for the mailbox.  The end user even gets a message stating that their mailbox has been changed and Outlook needs to be restarted.  But when Outlook has been restarted, it will be unable to establish a connection to the mailbox; the cached directory information in Exchange incorrectly continues to direct Outlook to the mailbox's old location until after the directory update has taken place.  This often leads engineers or administrators to falsely assume something has gone wrong with the migration when in fact, everything is working normally.  This can result in unnecessary panic, user downtime, and potentially drastic measures as engineers may back off from a migration entirely to find out what went wrong. 

Many IT professionals are aware that Active Directory itself takes some time to synchronize across servers or even fully update on a single domain controller.  By default, this synchronization time is 15 minutes.  Likewise, it only takes 5 minutes or less for a name change to reflect correctly in Exchange.  It is often assumed that Exchange also must synchronize every 15 minutes and cache information for only 5 minutes, so more savvy engineers will wait to see if this resolves the problem.  However, the Exchange cache time is substantially longer at 120 minutes, making it impractical to move a mailbox and expect it to be ready for use in any reasonable amount of time after completion.  This often prevents the option of mailbox moves during business hours, as the two hour window severely cuts into user productivity, despite the fact that the migration itself causes no interruption at all.

The obvious solution is to force a directory synchronization after each mailbox move.  Unfortunately, the only way to force a synchronization is by restarting the Information Store, which will result in all the mailboxes on that server becoming unavailable for the duration of the restart.  Hardly a viable option, especially for large organizations. 

Microsoft's workaround for this is to create certain registry settings to decrease cache lifetime on Exchange.  The two keys are as follows:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Mailbox Cache Age Limit

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem\Mailbox Cache Idle Limit

Each are DWORD decimal values, reflecting a number of minutes.  The default value for Age Limit is 120 and for Idle Limit 15.  Setting the Age Limit and Idle Limit to a lower value will allow mailbox information to update more quickly after a move at the expense of directory performance.  The Information Store will have to be restarted for these settings to take effect, so they are best changed prior to starting the migration.  An after-hours restart of the service can be planned to implement the new cache times and then the mailbox migrations can be performed during business hours without causing excessive downtime for users.  Once the migration has been completed, the cache times can be set back to normal.