Historically, when an administrator moved an Exchange 2010 mailbox from one database to another, the user's Outlook client would present them with a message stating:
The Exchange administrator has made a change that requires you quit and restart Outlook.
Only after restarting Outlook would the user have access to their mailbox.
To understand this behavior, it's helpful to understand what generates the dialog in Outlook and why Exchange 2010 triggers the message. Outlook caches three items about each Exchange mailbox it opens and it requests a restart if any of them change:
- MappingSignature - This is a combination of the named property mapping for the mailbox and the REPLID/REPLID-GUID for the mailbox.
- ServerName - in Exchange 2010, this corresponds to the value of the RPCClientAccessServer property on the database containing the mailbox.
- RootFID - the root folder ID of the mailbox.
One of the many fundamental changes we made in Exchange 2010 was new named property management. In Exchange 2010, named properties are now stored per mailbox, instead of per database as was done in previous versions. This means that, in the event that a mailbox consumes its named property quota, only that mailbox is affected; all other mailboxes on the database are no longer affected. Thus, you only need to move the affected mailbox to a new database to return it to service.
A side effect of this architectural change is that the mapping signature changes whenever a mailbox is moved between Exchange 2010 databases. This results in users always receiving the Outlook restart message.
Exchange 2010 SP1 RU2 and Beyond
Like many of you, we didn't like this behavior. So we set out to change this behavior and reduce the number of times that an Outlook client needs to be restarted after a mailbox move. As a result, after you upgrade to Exchange 2010 SP1 RU2 or later, when you perform mailbox moves, the mailbox mapping signature is now preserved.
By preserving the mapping signature, we can minimize Outlook requiring a restart, as long as the following conditions are observed:
- The source and target Mailbox servers are running SP1 RU2 or later.
- The RPCClientAccessServer property does not change between the source and target database.
- If within an AD site you have created a CAS array, then when you move the mailbox within that site, you will not have to restart Outlook as long as both databases are configured with the CAS array name for the RPCClientAccessServer property.
- However, if you move the mailbox between AD sites, then the CAS array value will not change automatically. If you do a profile repair, then Outlook will have to be restarted.
- Likewise, if you do not use a CAS array and the source and target databases have different RPC endpoints (even within the same AD site) then Outlook will need to be restarted.
- The user does not have open additional mailboxes where the additional mailboxes do not meet the above conditions when being moved.
- The public folder hierarchy server does not change.
In the situation where you have named property exhaustion for the mailbox, the mailbox move will fail. In order to reset the named properties, you must use the DoNotPreserveMailboxSignature parameter with the New-MoveRequest cmdlet.
Hopefully, you are as pleased as I am about this new functionality that we have delivered in Exchange 2010 SP1 RU2. If you have any questions, please let us know.