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.

But 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:

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:

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:

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

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

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:

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:

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, opened the mailbox and clicked the Inbox and then IMAPIFolder:

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:

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

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

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