Public Folder Migration to Exchange Online (500k Folders) Part 9— Post-Migration Issues (Hierarchy Update)
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’re running on Exchange Online Public Folders with an estate that’s closing in on 500k folders. Overall, our users are “OK” with the performance. It’s not as quick as it was when it was hosted on-prem, but it’s certainly usable online.
Post-Migration — Issue 1 (Hierarchy Update)
During our sync the Public Folder hierarchy was pushed to six mailboxes (Mailbox1 as the master copy). After the migration the hierarchy is synced to more mailboxes automatically as the system determines the current load from your users. If the current aren’t enough to serve the users quickly enough, more mailboxes will be brought online and serve them.
The issue here is down to load on the Microsoft servers, and it’s huge.
These commands will give you more details about your hierarchy state.
As you can see from out environment, we have lots of mailboxes that are “serving” the users. You’ll also see that only one is showing the IsHierarchyReady has completed.
From here, we can see 28 mailboxes that are “trying” to sync the hierarchy from Mailbox1. I say trying because I’ll show you below exactly what I mean. Due to Microsoft’s throttling, this process is extremely slow…
The end result is we only have a single mailbox (other than Mailbox1) that is ready to server a fully synced hierarchy to our users.
The effect for our users…
After the migration all users will have their DefaultPublicFolderMailbox value blank, meaning the system will automatically allocate a mailbox to them. While this is fine, as you can see from the first screenshot we only have one mailbox outside the master (Mailbox1) as ready to serve.
The result it when users create new folders, their colleagues do not see them. This is because they are on a default mailbox that hasn’t completely synced as yet.
The solution? If you can’t wait for more mailboxes to become synced, you will have to manually assign users to a working hierarchy mailbox using the Set-Mailbox “xxxxx” -DefaultPublicFolderMailbox Mailbox “xxxxx” cmdlet.
My advice… Try and limit what you assign to Mailbox1 as the more you have assigned there will make the entire situation worse, as you will be pilling more load on an mailbox that is already being throttled.
Sadly, Microsoft do not give customers access to their to change these hierarchy settings. These are Microsoft only commands…
Checking the Hierarchy Status
Below there are some PowerShell commands so you can see the status of your Hierarchy sync.
When you examine the SyncInfo results, you will likely see this “Failed to sync public folder hierarchy after 6 attempts due to transient failure. Last error: The remote server is unhealthy due to DiskLatency”
Annoyingly, you cannot see the total number of folders that are synced (even though SyncInfo shows a “NumberOfFoldersSynced”). This is only the number of folders synced from the current batch and not the total folders. Only Microsoft can give you this information.
