Public Folder Migration to Exchange Online (500k Folders) Part 12 — Troubleshooting Hierarchy Issues (1000 Mailboxes, Auto-Split, Missing Folders)
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
Welcome back everyone… I’d like to explain two pieces of information we have experienced over the last few months, and while most of you won’t have this particular issue I think it’s important to explain this current limitation and the troubleshooting steps you’ll need to take in order to restore service to your Public Folder estate.
1,000 Public Folder Mailboxes Exceeded
The first issue we experienced is because we surpassed the ExO limits of 1000 Public Folder mailboxes. The limits are explained here, and it does mention “you are limited to”, however you may well exceed this depending on auto-split. We actually have 1008 at the time of writing this and were 1032 before a little cleanup.
The error we were seeing was this one “The number of ‘Mailbox’ objects in the organization ‘Domain.onmicrosoft.com’ has reached or exceeded the resource quota (1000) enforced by policy ‘Recipient Quota Policy: PublicFolderMailboxCountQuota’”
As you are limited to a 1000 PF mailboxes. auto-split can no longer work. As soon as you exceed that policy, no more mailboxes can be created, and even if you have empty autosplit mailboxes no data will be moved into them because of this policy.
So how does auto-split work?
Auto-split is actually a really nice feature and has helped us greatly in restoring all EV emails. Auto-split will automatically split the emails into 5 new public folder mailboxes (20GB each) once the mailbox reaches split value. Now depending on where you look on the internet some reference it’s the warning quota threshold. We aren’t seeing that as our limits are quite high and auto-split is definitely kicking in before that. When I asked Microsoft this question they said it 70% of the quota, now you know.
Why isn’t auto-split working for mailboxes over 70%?
Good question and one I’m sure you’ll be asking yourself if you have mailboxes that are near capacity. One very important nugget of information here, is that in order for auto-split to work it must have completed it’s initial sync after being created or cutover from migration.
UPDATE: As of December 2018 Microsoft informed me that they have made an improvement to the auto-split process which they are currently testing. This change no longer requires the mailbox to have completed it’s initial hierarchy sync. Good news all round and helps greatly if like us you have lots of data and PF mailboxes. I guess this change will be made available to everyone in 2019.
You can check this by looking at the diagnostics logs in the PowerShell commands below. While you are also in there, take a look at all the other information in the SyncInfo export. It contains lots more then just these three entries and is good for troubleshooting if mailboxes haven’t updated for a while.
Users are complaining they aren’t seeing newly created folders?
What’s this I see, lots of incidents from disgruntled users complaining that their colleagues have created new folders but no one else can see them…
One way to quickly identity if you have hierarchy issues is to set the user who cannot see the folder to the Public Folder mailbox, Mailbox1. This is the primary and holds the definitive copy. If after about 30 minutes (and a restart of Outlook) the user can see the folder, bingo you have hierarchy issues.
If your users are now working after being assigned to Mailbox1, then it’s likely their original default PF mailbox has not updated for a while. To check this run the below commands. This will show you all the serving mailboxes you have in the estate and the last update times.
If you have loads that are not updated, it’s likely the cause is down to throttling Microsoft’s side. You can check this out by looking at the SyncInfo log I explained above and checking the LastSyncFailure value (SyncInfo.LastSyncFailure). You will probably see something like server health issues such as Disk Latency, CPU etc.
So what can I do to resolve?
Well, sadly all options will require a call to Microsoft as currently they don’t give customers access to the relevant PowerShell commands. What you can do however is do some of the donkey work for them and try to isolate the cause.
A common reason for this failure is you are overloading Mailbox1 and that is being throttled. So first off, make sure your users haven’t got their DetaultPublicFolderMailbox set to Mailbox1. This value should be blank.
Second, it’s probably that the overload is being caused by the sheer number of PF mailboxes you are trying to sync. In our case, we have over 320 that were enabled for syncing. We reduced that to 130 and the issue was fixed.
Now when you ask Microsoft to reduce the number of syncing PF mailboxes (ask them to set IsHierarachySyncEnabled to False), you must provide them with all the mailboxes that are serving as well (script above). Microsoft must not disable syncing for any serving mailboxes, if they do then your users will not be connecting to serving mailboxes that are no longer sync enabled.
The below script will export all hierarchy information for all PF mailboxes.