Exchange Move Mailbox Experiences Part 1

Exchange Logo

I am currently working on a migration project from Exchange 2003 to Exchange 2010.

Most Exchange migration projects use Mailbox Moves to move the mailbox data to the new Exchange environment.

imageBut there are some things I observed during Mailbox Moves (from Exchange 2003 to 2010) that are worth mentioning.

Users can access their mailbox during moves

The users can continue to access their mailbox during a Mailbox Move but when the move has finished Outlook will request the user to restart Outlook:

The Microsoft Exchange administrator has made a change that requires you to quit and restart Outlook

Very Large Mailboxes

First of all, be prepared that move large mailboxes can take quite a large amount of time. For example a 20GB mailbox took almost 4 hours on my system:

image

But more importantly: Mailboxes with a total size of 16 Gigabytes and higher cannot be accesses during the move. If you try to open them during a move you will probably get this Error Message:

Cannot open your default e-mail folders. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance

Note that the exact message differs per Outlook version and language, for example on Dutch Outlook 2003:

Kan Microsoft Office Outlook niet starten. Kan het Outlook-venster niet openen. Kan de set mappen niet openen

On the source Exchange server an MSExchangeIS event with Event ID 9660 will be logged in the Application log:

User <userName> (<legacyExchangeDn>) failed to log on because their mailbox is in the process of being moved.

 

Device Synchronization

Users that synchronize their devices (smartphones, tablets etc) with Exchange using ActiveSync/Push Mail may receive an alert.

If such an alert is shown and the exact message depends on the device. This screenshot comes from an HTC Windows Mobile phone:

Alert | There has been a change made on your server that requires you to re-synchronise all items on your device. All changes made since your last successfull sync will be lost. Do you wish to continue?

It seems that Windows Mobile first deletes the current ActiveSync profile (and thus all mail, contacts, tasks and appointment), then creates a new ActiveSync profile and finally resynchronizes this with the Exchange Server.

The sentence “All changes made since your last successful sync will be lost” is a little alerting. So you may wish to properly inform your users before you move their mailbox if they are not synchronizing continuously.

 

Mailbox Corruptions

Mailbox corruptions can cause a Mailbox Move to fail. I’ve seen mostly messages in a corrupted state. If acceptable to your organization you can use the BadItemLimit parameter of the New-MoveRequest cmdlet to skip these message. I recommend a small number, eg 10.

The other corruption cases I’ve seen were corruption in Out of Office message or the Outlook Rules.

In the log file the Move operation fails on the IDestinationFolder.SetRules operation:

21-9-2011 9:24:03 [vCAS002] Fatal error MapiExceptionInvalidParameter has occurred.
Error details: MapiExceptionInvalidParameter: Unable to modify table. (hr=0x80070057, ec=-2147024809)
Diagnostic context:
    Lid: 55847   EMSMDBPOOL.EcPoolSessionDoRpc called [length=192]
    Lid: 43559   EMSMDBPOOL.EcPoolSessionDoRpc returned [ec=0x0][length=660][latency=15]
    Lid: 23226   --- ROP Parse Start ---
    Lid: 27962   ROP: ropModifyRules [65]
    Lid: 17082   ROP Error: 0x80070057
    Lid: 27745
    Lid: 21921   StoreEc: 0x80070057
    Lid: 27962   ROP: ropExtendedError [250]
    Lid: 1494    ---- Remote Context Beg ----
    Lid: 1238    Remote Context Overflow
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x67AA000B
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x67870102
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x668F0040
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x67F60040
    Lid: 48851
    Lid: 21970   StoreEc: 0x8004010F PropTag: 0x67F60040
    Lid: 51077   dwParam: 0x80000000
    Lid: 65267
    Lid: 40691
    Lid: 5559    StoreEc: 0x80070057
    Lid: 65015
    Lid: 65439
    Lid: 4302    StoreEc: 0x80070057
    Lid: 1750    ---- Remote Context End ----
    Lid: 26849
    Lid: 21817   ROP Failure: 0x80070057
    Lid: 29150
    Lid: 20446   StoreEc: 0x80070057
   at Microsoft.Mapi.MapiExceptionHelper.ThrowIfError(String message, Int32 hresult, SafeExInterfaceHandle iUnknown, Exception innerException)
   at Microsoft.Mapi.MapiModifyTable.ModifyTable(ModifyTableFlags flags, ICollection`1 rowList)
   at Microsoft.Mapi.MapiFolder.AddRules(Rule[] rules)
   at Microsoft.Mapi.MapiFolder.SetRules(Rule[] rules)
   at Microsoft.Exchange.MailboxReplicationService.LocalDestinationFolder.Microsoft.Exchange.MailboxReplicationService.IDestinationFolder.SetRules(RuleData[] rules)
   at Microsoft.Exchange.MailboxReplicationService.DestinationFolderWrapper.<>c__DisplayClass31.b__30()
   at Microsoft.Exchange.MailboxReplicationService.ExecutionContext.Execute(GenericCallDelegate operation)
   at Microsoft.Exchange.MailboxReplicationService.DestinationFolderWrapper.Microsoft.Exchange.MailboxReplicationService.IDestinationFolder.SetRules(RuleData[] rules)
   at Microsoft.Exchange.MailboxReplicationService.FolderRecWrapper.WriteRules(IDestinationFolder targetFolder)
   at Microsoft.Exchange.MailboxReplicationService.MailboxCopierBase.CopyFolderProperties(FolderRecWrapper folderRec, ISourceFolder sourceFolder, IDestinationFolder destFolder, FolderRecDataFlags dataToCopy)
   at Microsoft.Exchange.MailboxReplicationService.MailboxMover.<>c__DisplayClass2.<>c__DisplayClass4.b__1()
   at Microsoft.Exchange.MailboxReplicationService.ExecutionContext.Execute(GenericCallDelegate operation)
   at Microsoft.Exchange.MailboxReplicationService.MailboxMover.<>c__DisplayClass2.b__0(FolderRecWrapper folderRec, EnumFolderContext ctx)
   at Microsoft.Exchange.MailboxReplicationService.FolderMap.EnumSingleFolder(FolderRecWrapper folderRec, EnumFolderContext ctx, EnumFolderCallback callback, EnumHierarchyFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.FolderMap.EnumSingleFolder(FolderRecWrapper folderRec, EnumFolderContext ctx, EnumFolderCallback callback, EnumHierarchyFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.FolderMap.EnumSingleFolder(FolderRecWrapper folderRec, EnumFolderContext ctx, EnumFolderCallback callback, EnumHierarchyFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.FolderMap.EnumSingleFolder(FolderRecWrapper folderRec, EnumFolderContext ctx, EnumFolderCallback callback, EnumHierarchyFlags flags)
   at Microsoft.Exchange.MailboxReplicationService.MailboxMover.FinalSyncCopyAllFolders()
   at Microsoft.Exchange.MailboxReplicationService.MoveBaseJob.b__4b(MailboxMover mbxCtx)
   at Microsoft.Exchange.MailboxReplicationService.MoveBaseJob.ForeachMailboxContext(MailboxMoverDelegate del)
   at Microsoft.Exchange.MailboxReplicationService.MoveBaseJob.FinalSync(Object[] wiParams)
   at Microsoft.Exchange.MailboxReplicationService.CommonUtils.CatchKnownExceptions(GenericCallDelegate del, FailureDelegate failureDelegate)
Error context: --------
Operation: IDestinationFolder.SetRules

Both Outlook Rules and Out Of Office Settings are stored in the Associated Contents Folder of the Inbox and can be fixed with a MAPI tool, MFCMapi or OutlookSpy.

I used OutlookSpy because it’s easier to than MFCMapi (and because it’s a rocking cool tool), opened the mailbox and clicked the Inbox and then IMAPIFolder:

image

Select the Associated Contents Tab and inspect the Rows. If the PR_MESSAGE_CLASS property has the value “IPM.Note.Rules.OofTemplate.Microsoft” then you have found the Out of Office Object:

image

Outlook Rules have a PR_MESSAGE_CLASS of “IPM.Rule.Message”:

image

Both can be deleted via the Delete button, but before you do that you may want to backup the Outlook rules:

image

 

That’s it for now, I will continue in Part 2 with more info.

Was once an enthusiastic PepperByte employee but is now working elsewhere. His blogs are still valuable to us and we hope to you too.