Public Folder Migration to Exchange Online (500k Folders) Part 6 — Monitoring and Fixing the Sync (3/3)
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
By now you’ve had a very relaxing few months letting all your data sync seamlessly yes? (yeah right!). You are nearly there, just a few mailboxes left to reach that mythical “Synced” state we read about…
While everyone’s environment is different, it’s likely that Mailbox1 will be your biggest pain point. This is because only Mailbox1 holds the master hierarchy so it syncs permissions and all mail-enabled Public Folders among others.
Step 13 — Fixing Mailbox1
After Mailbox1 has synced your folder hierarchy, synced the data and copied all folder permissions, you think yes! finally made it… Only then for it to run an Incremental Sync and fail.. NO….!
Examining the logs you will likely see lots of these ”FOLDER could not be mail-enabled. The error is as follows: ‘No mail public folder was found in Active Directory with OnPremisesObjectID=xxxxxxx’”
This is why Step 6 was so important to get right. Don’t panic though, it’s all fixable, and you can resume the failed job by using Resume-PublicFolderMailboxMigrationRequest.
As we can see from below, running Get-PublicFolder on the Exchange 2010 server for that folder, shows that MailEnabled is actually False…
So why is it trying to mail-enable that folder during the migration? Answer, because you still have the object in the MESO OU.
You have two options here to fix this.
1. Find and delete the object in the MESO OU
2. Either rerun the Sync-MailPublicFolders again to have it create the object if possible. It may fail due to the alias having a space in the name. Or create the alias manually yourself using the New-SyncMailPublicFolder cmdlet and linking it to the OnPremisesObjectID in the report.
In our case we only had a few that we’d missed, so a simple change in ADSIEdit to remove the space in the alias and a rerun of the Sync-MailPublicFolders script fixed the issue.
If everything then goes according to plan, after you resume Mailbox1 and wait for it to re-sync, you’ll see this!
“All mail public folders in Active Directory were successfully linked to their corresponding public folders”
After over twelve months and two failed sync attempts we were finally in this “Synced” state. You see… it does exist!
