Obviating Outlook Client Restarts after Mailbox Moves

Published 01-24-2011 10:57 AM 17.4K Views

The History

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:
  1. MappingSignature - This is a combination of the named property mapping for the mailbox and the REPLID/REPLID-GUID for the mailbox.
  2. ServerName - in Exchange 2010, this corresponds to the value of the RPCClientAccessServer property on the database containing the mailbox.
  3. 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 as long as the following conditions are observed:
  1. The source and target Mailbox servers are running SP1 RU2 or later.
  2. The RPCClientAccessServer property does not change between the source and target database.
    1. 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.
    2. 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.
    3. 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.
  3. The user does not have open additional mailboxes where the additional mailboxes do not meet the above conditions when being moved.
  4. The public folder hierarchy server does not change.
  5. The mailbox signature version on the target database is not a different version from the source mailbox database.
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. Ross Smith IV Updates
  • 1/25/18 - Added an additional condition which can trigger the mailbox signature to not be preserved.
Not applicable
Thanks Ross, very cool!  This will be great for those mid-day mailbox moves.

Can you guys provide an update on the address list segregation status?  Dave Goldman said an announcement was coming "in a few weeks" and that was nearly 6 months ago - thanks!
Not applicable
Can you guys provide an update on the address list segregation status?  Dave Goldman said an announcement was coming "in a few weeks" and that was nearly 6 months ago - thanks! +1
Not applicable
Very cool. No more out of hours work for mailbox moves completions.
Not applicable
Brilliant, love the explanation. The bit about having additional mailboxes open - does that apply anywhere in Outlook there might be a tenuous link to a legacy mailbox, for example where a Calendar is listed in "My Calendars", even if it's not open at the time?
Not applicable
Is a restart required if the mailbox is moved to a mail database that is associated with a different public folder database than the orginal?
Not applicable
Very nice question Pugsley.
@ Ross, What was the behavior before RU2. I thought this was the standard behavior since E2K10 RTM, wasn't it?
Not applicable
We are currently deploying Exchange 2010 SP1 + RU2 org wide, but all our clients are Outlook 2007 currently.  From reading this document, it seems like this would work with Outlook 2007 clients as well?
Not applicable
With 'New-MoveRequest' there is a requirement that the Source database is running on Exchange 2007 or higher; is there any requirement on Outlook versions for this new 'Obviating Outlook Restart' functionality?  OL2003 always seems to be the version on the outside looking in so to speak...  ;-)

As long as it can connect to the PF associated with the database it shouldn't require a restart.  It would be the equivalent of clicking <Reconnect> in the Exchange Connection Status window.
Not applicable
@Richard - Connected calendars, alternate mailboxes, archives being moved could all cause the client to require a restart if the above conditions are not met.

@Animesh - the behavior before SP1 RU2 was described in the history section.

@Jason - Outlook version does not matter.

Not applicable
What gives?  Even though this doesn't mention anything related to Address list segregation....

What's the word on it?  Sept was the last post from Mr. Goldman and we haven't heard anything yet.
Not applicable
Hi Ross,

I've installed E2K10 SP1 UR2 and tested online mailbox move. I've tested with OL 2007/2010 in Online Mode with the following results:

- Outlook restart message window has gone.
- When Move Request status nears Completing:
* Outlook status changes from 'Online with Microsoft Exchange' to Disconnected
* Selecting another mail item results in message: This item cannot be displayed in the reading Pane

Outlook automatically reconnects to Exchange Server after move request status turns to completed.

Is this expected behavior with Outlook in Online Mode? If so, an online mailbox move with OL in online mode is actually not 100% online because users will experience a small interruption.

The Outlook status turns also to Disconnected for a while with OL Cached Mode but reading mail items is no issue because of Cached Mode.

Not applicable
@Getting Fed Up - you will get an announcement on this very blog very soon I can assure you.
Not applicable
In our environnement, we face the problem, that not all OL clients reconnect automatically. The only database where the RPCClientAccessServer property is NOT set to the CAS-Array is the Public Folder DB.

My question  :
Do I have to set the RPCClientAccessServer property for the publicfolderdatabase to the CASArray too ?
At the moment, its set to the server hosting the PF-Database.
Not applicable
Unrelated, but can you add the StartDate and EndDate parapaters to the Exchange 2010 Mailbox Move using PowerShell? -please.
Version history
Last update:
‎Jul 01 2019 03:57 PM
Updated by: