365 UC
Published in

365 UC

Public Folder Migration to Exchange Online (500k Folders) Part 12 — Troubleshooting Hierarchy Issues (1000 Mailboxes, Auto-Split, Missing Folders)

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?
UPDATED 13/06/19
Currently when auto-split kicks in, it creates 5 new mailboxes and moves 20GB into each one. Microsoft are currently working on reusing existing mailboxes to reduce companies exceeding the PF quota limit. Good news there.

Now auto-split only starts to work once the mailbox reaches 70% capacity. I see other articles stating it’s the quota settings, this is incorrect.

Why isn’t auto-split working for mailboxes over 70%?
UPDATED 13/06/19
Good question and one I’m sure you’ll be asking yourself if you have mailboxes that are near capacity. There is a setting under Get-PublicFolderMailboxDiagnostics which contains a value ‘AutoSplitInfo’. Now if you look at that for each of your mailboxes you’ll see it either showing a blank entry (meaning it hasn’t been auto-split before) or something like ‘Halted’ or ‘SplitComplete’ etc. Now if’s either of those two, then auto-split will no longer work and that value must be cleared in order for it to resume .

Now the bad news it the Update-PublicFolderMailbox -ClearAutoSplitState command is a Microsoft only one, meaning you will not be able to even find it. If you are on-prem 2013/2016 then you can but for us Exchange Online guys, you will have to go to Microsoft and get them to clear it.

I hope this clears up why auto-split doesn’t work for you…

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.

A list of all the PF serving mailboxes with their last update timestamp

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.

An example export of all PF hierarchy information



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store