Public Folder Migration to Exchange Online (500k Folders) Part 7 — Completing the Batch
Quick Jump Guide
Part 1 — Preparing for Migration (1/2)
Part 2 — Preparing for Migration (2/2)
Part 3 — Starting the Migration Request
Part 4 — Monitoring and Fixing the Sync (1/3)
Part 5 — Monitoring and Fixing the Sync (2/3)
Part 6 — Monitoring and Fixing the Sync (3/3)
Part 7 — Completing the Batch
Part 8 — Testing & Unlocking Public Folders
Part 9 — Post-Migration Issues (Hierarchy Update)
Part 10 — Post-Migration Issues (Access Denied Deleting)
Part 11 — Post-Migration Issues (Add/Remove Permissions)
Part 12 — Decommissioning on-premises Public Folders
Part 13 — Troubleshooting Hierarchy Issues
This part seems to be extremely straight forward, and it would be for a small migration. As throughout this entire migration we hit upon bugs and limitations due to the size of our data, I knew this final part wouldn’t be as easy as it sounded.
Step 14 — Locking out Public Folders
On our legacy Exchange 2010 server, I made the change to lockout all users from Public Folders. Microsoft are unable to say exactly how long this process will take. We had nine servers and this took just over an hour to replicate.
You will know when it’s complete as you will be unable to expand All Public Folders in Outlook.
Step 15 — Complete the Batch (Downtime Required)
Once you run this command, you cannot stop it. So check, and double check you are all good to go before completing the migration batch.
Now, something I didn’t realise during this process is that while the TechNet article says “It is common for the migration batch to take a few hours before its status changes from Synced to Completing, at which point the final synchronisation will begin”, it doesn’t go into detail.
I completed the batch at 8pm, Friday 4th May 2018. By midnight there was no change. Given that we only had a weekend to migrate this data and we knew it would take a substantial amount of time to cutover, at 2am I gave in and called Microsoft Premier and logged a SEV A.
After hours of investigation I was told it was working and to wait (I wasn’t convinced but I had to wait). At 7am we still had no change but Premier were still saying the same thing. Luckily during our syncing issues over the last year I had some contact details of the Microsoft Exchange Product Group.
After emailing them (and luckily they replied), they were now involved and boy we needed them to be…
To cut a long story short our migration finally went into a Completing state at 1am, Sunday 6th May 2018… an incredible 53 hours after running Complete-MigrationBatch.
Completion Issues
Friday 4th May 2018
Microsoft Premier were informed of a delay to the completion process. We were told it was working and to wait.
Saturday 5th May 2018
Escalated to the Microsoft Exchange Product Group where is was found that the MRS hadn’t yet picked up our request and we were in the queue. This was due to the Bank Holiday weekend and the MRS servers being under heavy load. They escalated our request priority so that the MRS would select our request next. This failed to work and the MRS would simply not select our job.
Escalated to Microsoft Redmond at 2pm, Saturday 5th May 2018.
After investigation it was found that due to our migration size we’d hit a limitation in MRS scripts. Basically the MRS would only process a certain number of Mailboxes and as we had 605, it reached a certain number then simply stopped, completely breaking the batch as it went.
Redmond manually synced all 605 mailboxes to get over the required timestamp so the completion process can begin (more on this below).
Sunday 6th May 2018
At 1am all mailboxes were over the timestamp, and we were in a Completing state. Mailboxes were now completing…
Exactly when does it switch from Synced to Completing?
When you run the Complete-MigrationBatch cmdlet, it updates the TriggerAction from SyncAndHold to SyncAndComplete. It also timestamps when you ran that command.
Basically in order for your migration to switch from Synced to Completing, all mailboxes have to have it’s LastSuccessfulSyncTimestamp after this time. You can use the Get-PublicFolderMailboxMigrationRequestStatistics cmdlet for these values.
Step 16 — Complete the Batch (Continued…)
Even though it’s now just a waiting game until all your mailboxes reach that Completed state, you may still end up with one or two that do fail. A common issue (or if you forgot), and you haven’t set the Bad Item and Large Item count correctly in Batch as well as the mailboxes… some will fail.
We had five that failed, so step 1 find out which mailboxes they are…
Step 2, collect the logs from that mailbox using the PowerShell commands I explained earlier in this guide. In our cases it was all down to some large emails that has appeared (in excess of 100mb).
While the Large Item limit was correctly set on the mailbox jobs, it wasn’t set on the Migration Batch.
After you examine the file, you can see what the issue is. In our case, it was the Large Item count setting on the Migration Batch, which was still set to 0.
You can fix this by running the below command…
Once you’ve fixed and resumed the failures, you should be nearly home and dry…
Then finally, you can relax (for now). All mailboxes have completed successfully after nearly 72 hours. I should point out for anyone looking to do a similar number of folders, that 72 hours doesn’t show the whole story. During the completion process it runs a clean-up script on the Microsoft servers which (from as far as I can see) always fails. If the Exchange Product Group hadn’t made manual changes to the to reduce the failure times the total completion time would have been over 4.5 days to finish.
