Some user's at the client had large Exchange mailboxes with > 4 GB data. I installed a 30 day trial copy of Backup Assist (BA), my favourite SMB backup solution on the source server. Part of the BA suite is an Exchange mailbox backup. I first made sure that the program is working okay, as there are always a few hurdles to overcome with setting up the right Exchange permissions for the user account that performs the backup.
On the days before the migration I performed a "manual" mailbox backup with the destination grouping method set to "yearly backup". This option exports all the user's mailbox contents to a number of .pst files, separated into folders for each calendar year.
I then created a batch file that renamed these files, appending the year and moving them to the users's home share on the new server. The most current year (2011) I kept for migration to the new Exchange server. On the night of the server migration, I ran the standard BA mailbox backup that archived all emails to the 2012-Q1 folder and transferred this folder to the new server.
I now had to import the user's last two (2011 and 2012) .pst files into the new Exchange 2010 server. This server was installed with SP1 and patched with the latest roll-up. All user's were then setup and email flow tested. After the change-over emails were already being received by the new server. Exchange offers the new "New-MailboxImportRequest" command that make merging the contents of a .pst file into a mailbox a smooth process.
When I used the command from a PS command prompt, I encountered an issue with the permission:
The term ‘New-MailboxImportRequest’ is not recognized as the name of a cmdlet, function, script file
It turns out that by default no account has the right to run this PS cmdlet. To enable it you need to assign a new role to a specific group. I added the rights for the domain admins by using this command:
New-ManagementRoleAssignment -Name “Import Export PST” -SecurityGroup “Domain Administrators” -Role “Mailbox Import Export”
Now we were ready to begin the actual import/merge of the user's .pst files:
New-MailboxImportRequest -Mailbox
This command was followed by a second set for all the 2012 email .pst files. I created another "batch" file, except this one was full of the above Powershell commands. Once I started this Powershell script the merge process took a good 1-2 hours. Along the way you can check progress by accessing the import queue using
Get-MailboxImportRequest
or to get more details
Get-MailboxImportRequest -Status Failed | Get-MailboxImportRequestStatistics -IncludeReport | Format-List > c:\netadmin\pstimport.txt
I encountered a few errors that were detailed by the above command. They all related to an issue with the mailbox message size:
Message (size 15.71 MB (16,474,863 bytes)) exceeds the maximum allowed size for
submission to the target mailbox. You can increase this limit by using the Set-Mailbox cmdlet in the Exchange Management Shell.
Error details: MapiExceptionMaxSubmissionExceeded: Unable to save changes. (hr=0x80004005, ec=1242)
I fixed this on the affected user's account by going to the user's mailbox properties:
- Go to mail flow settings, then set Message Size Restriction properties and set both Sending and Receive message size to a high value, say 50Mb.
- Re-run the failed "MailboxImportRequest" again, it should now be successful.
- Reverse the user's message size restriction back to its default value.
Overall I have found this approach to be much easier than trying to move mailbox databases from one domain to another. The other advantage is that user's mailboxes are archived and pruned. If the user needs an old .pst file, they can attached it themselves to their Outlook.
Reference: MS Exchange .org article
