How Exchange Online automatically cares for your public folder mailboxes (via AutoSplit)

Published Jan 11 2021 01:32 PM 11.1K Views

When your public folder content migration to Exchange Online is complete or you create public folders for the very first time, you do not have to worry about managing many aspects of public folders. As you previously read, Modern public folders starting with Exchange Server 2013 are stored within a new mailbox type in the mailbox database. Our on-premises customers have to create public folder mailboxes, monitor their usage, create new public folder mailboxes when necessary, and split content to different public folder mailboxes as their content grows over time. In Exchange Online we automatically perform the public folder mailbox management so you may focus your time managing the actual public folders and their content. This is what we refer to as ‘AutoSplit’. If we were to peek behind the Exchange Online curtain, we would see two automated processes always running to make this happen:

  • Automatic public folder moves based on public folder mailbox quota usage
  • Automatic public folder mailbox creation based on active hierarchy connection count

Let’s go through each one of them, shall we?

Automatic public folder moves based on public folder mailbox quota usage

This process actively monitors your public folder mailbox quota usage. The goal is to ensure you do not inadvertently overfill a public folder mailbox and stop it from being able to accept new content for any public folder within it.


How does it work?

We have a time-based assistant (known as PublicFolderSplitProcessor) actively monitoring the public folder mailbox quota usage. The assistant scans each public folder mailbox every hour to ensure we do not inadvertently overfill a public folder mailbox and stop it from being able to accept new content for any public folder within it.


Public folder mailbox’s quota for any new mailboxes has been set to the following (regardless of a mailbox plan or policy which may apply to user mailboxes):

  • ProhibitSendQuota = 99GB
  • ProhibitSendReceiveQuota = 100GB

For public folder mailboxes to undergo a split, the size should exceed the following percentage of the ProhibitSendQuota:

  • Primary mailbox = 40%
  • Secondary mailboxes = 80%

During the split, public folders from source PF mailbox (the one that is reaching its size limit) are moved to either a new target PF mailbox (which is created automatically by the system) or an existing PF mailbox that still has space to accommodate new content.




In the above example from tenant audit logs, the system created a new public folder mailbox “AutoSplit_GUID” and initiated a new public folder move request for public folder data to move to the newly created target AutoSplit mailbox.

When creating a new mailbox, Exchange online will always exclude it from serving hierarchy since a newly created public folder mailbox would not have the folder hierarchy synced yet.

If the total mailbox count is > 90% of the PublicFolderMailboxCountQuota (count > 900, with current Exchange Online limits), the system randomly chooses an existing mailbox (if any exist) with < 50% of the quota used where there is no moveRequest (by AutoSplit) to/from this mailbox. Else, we proceed to AutoSplit a mailbox with name: AutoSplit_<random guid (without “–“ in between)> until PublicFolderMailboxCountQuota ”1000” has been reached.

Naming of the new target mailbox

The system created new public folder mailbox has the following naming convention. The guid has some information regarding the source mailbox from which the split happened.


In this example, public folder mailbox “PFMBX” had crossed the split threshold; the Exchange guid of this source mailbox is 3a40f5da-0e0a-42f3-910f-1849580ff25d, the first part of the guid is always shared with the name of the target AutoSplit mailboxes.

If we had to find out the AutoSplit targets of a source mailbox, we can use following command in EXO PowerShell:

Get-Mailbox -PublicFolder “AutoSplit_3a40f5da*”



In a single move, a maximum of 20GB (in total size) or 2000 (+2000 dumpster) folders are moved (whichever is lower in size). There can be multiple moves to the same target mailbox if the target mailbox’s size is still lower than 30 GB, else the system would choose a new target mailbox. Public folders are chosen with consideration of their subtree structure, so there is no guarantee that 20GB or 2000 folders will be moved every time.

To help illustrate this, here is an example; let's say we have 4 PFs in the public folder mailbox where AutoSplit process is taking place:

\PF1 = 13 GB
\PF2 = 1 GB
\PF3 = 3 GB
\PF4 = 4 GB

Here, \PF1,\PF2 & \PF3 are going to be chosen as they are up to the limit of 20GB and were chosen while considering folder hierarchy.

In another scenario, let's say we have 4 PFs in the public folder mailbox where AutoSplit process is taking place:

\PF1 = 13 GB
\PF1\PF4 = 7 GB (PF4 is a subfolder of PF1 and the size of PF4 content is 7 GB)
\PF2 = 1 GB
\PF3 = 3 GB

Here, \PF1 and \PF1\PF4 are going to be chosen as they are up to the limit of 20GB and were chosen with consideration of subtree structure.

Note that the AutoSplit process will drain the source mailbox entirely, moving the contents completely to other mailboxes.

For example: 80GB public folder mailbox might copy the contents inside to 4 or more new target AutoSplit mailboxes (providing we are not above 900 mailboxes total). The source mailbox will eventually become empty once the moved folders are deleted after the item retention. Then our empty mailbox removal processor may remove it, if it is not serving hierarchy and no new public folder was added to it.

Automatic public folder mailbox creation based on active hierarchy connection count

This is the second automated process to help maintain the most optimal user experience accessing public folders in Exchange Online. Exchange Online will actively monitor how many hierarchy connections are being spread across all of your public folder mailboxes. If this value goes over a pre-determined number (2000), we will automatically create a new public folder mailbox. Creating the additional public folder mailbox will reduce the number of hierarchy connections accessing each public folder mailbox by spreading user connections across a larger number of public folder mailboxes. If you have a small amount of public folder content in Exchange Online, yet you have an extremely large number of active users, then you may see the system create additional public folder mailboxes regardless of your public folder content size.


In the above example, public folder mailbox “PFMBX-005” was created by the service to overcome the measured high load of user connections to existing PF mailboxes serving hierarchy.

The public folder mailboxes created by the system for balancing hierarchy connections will be named “PublicFolderMailbox_(Date)”.


In this example, public folder mailbox “PublicFolderMailbox_2020_05_25” was created by the service on the date of 25th May 2020 to address the user connection load.

Daily auto-generated public folder mailboxes

If there is a user traffic spike, or if you have a tenant with recently migrated public folders, the system might create multiple hierarchy sync mailboxes. We do not create all mailboxes that might be needed in a single day; the system creates these mailboxes once per day, to avoid provisioning lots of auto-generated mailboxes together. The creation would stop once we have enough mailboxes to serve hierarchy to users.


In this example, multiple public folder mailboxes with naming convention “PublicFolderMailbox_Date” were created by the service to overcome the user spike on 25th May 2020 till 12th June 2020 to maintain the optimal user experience accessing public folders in Exchange Online.

Common issues with AutoSplit

The following are some of the scenarios under which the AutoSplit process may encounter issues and also tips on how to deal with these scenarios.

Giant folder and auto-split:

A single public folder occupying more than 40-80% space of the public folder mailbox could be called a “Giant folder”. The AutoSplit process is not helpful in giant public folder scenarios, since it can only distribute the folders into multiple mailboxes. If a single folder taking up all the space, the problem (the folder size) remains the same wherever that folder goes. Remember, a single folder cannot span multiple public folder mailboxes.

When there is only a single resident giant folder+dumpster residing in a mailbox, and total mailbox size has exceeded split threshold (size/quota>=80%), system checks to see if the ratio of the (resident giant folder size/total mailbox size) exceeds 99% and will split only if it is less. This is to ensure that large amounts of mailbox data which is under move retention does not cause the mailbox to hit quota, and cause a data loss for the giant folder.

Action for tenant administrators:

In such a scenario, tenant admin must advise affected public folder owners to either delete or move items from that giant folder to reduce the size of that public folder to an appropriate size. A general recommendation is that individual public folder size shouldn’t exceed 20GB.

MRS related issues causing AutoSplit failure

AutoSplit uses Mailbox Replication Service (MRS) framework to move the public folders from source PF mailbox (mailbox that is getting full) to target PF mailbox (new empty PF mailbox). If MRS issues are transient in nature, the AutoSplit will be delayed but will complete.

Tenant administrators can track the MRS related failures using Get-PublicFolderMailboxDiagnostics command under AutoSplitInfo section.

In the following example, MRF:0 reads Move Requested Failed 0 times (other example could be like MRF: 2 means Move Request Failed 2 times), and can be seen in get-publicfoldermailboxdiagnostics under AutoSplitInfo section:


When something fails in AutoSplit, we handle the exception and increment the bucket counter with the hope that AutoSplit auto recovers in the next attempt. When these bucket counts hit certain thresholds, the AutoSplit state becomes Halted. This is temporarily stopping AutoSplit attempts, as they failed too many times.


Action for tenant administrators:

In such cases, please raise a support request with Microsoft and include Get-PublicFolderMailboxDiagnostics output for the affected public folder mailbox.

Moveditemretention and AutoSplit

We have seen some support tickets where users might complain to Admins that they are not able to post new items to a public folder or send an email to it (folder was mail-enabled). We found the ProhibitSendQuota was reached and by checking publicfoldermailboxdiagnostics, also saw that ReducedStateProgressState “auto-split process status” was SplitCompleted and ReducedStateTargetMailboxWhenCreatedUTC “date of creation of target public folder mailbox where the data of source public folder mailbox was split to it” was recent.

Action for tenant administrators:

First, find out PF mailbox that is at full quota:

$PFmbx = Get-Mailbox -PublicFolder
$PFmbx | ft Name,Prohibit*Quota*


The public folder mailbox PFMBX1 where ProhibitQuota values were modified to smaller values 

$PFmbxstats = $PFmbx | Get-MailboxStatistics
$PFmbxstats | fl DisplayName,TotalItemSize


PFMBX1 total item size has exceeded ProhibitSendQuota value

If TotalItemSize is less than a quota, there is no further action since AutoSplit completed successfully and data is moving. Otherwise, proceed to next step.

Then, Check if MovedItemRetention is keeping the mailbox full. Even though AutoSplit completed successfully, you might reduce DefaultPublicFolderMovedItemRetention to be 1 day and then invoke mailbox assistant to process the mailbox.


Set-OrganizationConfig -DefaultPublicFolderMovedItemRetention 1.00:00:00


Update-PublicFolderMailbox <AffectedPFMailbox>


After a few hours, check again:

$PFmbxstats = $PFmbx | Get-MailboxStatistics
$PFmbxstats | fl DisplayName,TotalItemSize


PFMBX1 total item size has been reduced

Finally, check if this TotalItemSize has now reduced. If the size is reduced, then the issue is fixed, and you may set the MovedItemRetention back to default value of 7.00:00:00. Otherwise, please raise a support request with us for further investigation.

Public folder content not accessible during AutoSplit

During the move, the source mailbox will continue to serve the content; however, as PublicFolderMoves are auto-complete in nature, the cut-over (copying the delta, updating content mailbox info on primary, source and target, directory updates in case of mail enabled public folders, etc.) may cause temporary service interruptions. The content access will be resumed as soon as the move completes.

In closing

We hope this has been a useful view into processes that we have that will help you manage your public folder content! In most cases, we hope that you never have to do anything with this. But if you see some public folder mailboxes that you do not recognize, this post hopefully explains why!

Special thanks to the public folder experts who reviewed and contributed to this post: Bhalchandra Atre, Dheeraj Ram, Deepak Sadan, Nino Bilic.

Hazem Embaby


Thanks for the detailed explanations. This is a tricky topic when migrating legacy public folders to modern public folders in Exchange Online using a 3rd-party tool in a non-hybrid scenario.

Senior Member

Thanks for this article, very interesting!

Didn't know the auto-split process would also create new PF mailboxes when those serving hierarchy are overloaded. Is there a way for Exchange Online administrators to get current number of hierarchy connections to public folders mailboxes?




The only way that you can identify that a specific public folder mailbox is exhausted serving hierarchy to a bunch of users are these properties EffectivePublicFolderMailbox & DefaultPublicFolderMailbox which can be retrieved using Get-Mailbox Command.
Hope that helps!
Senior Member

After migrating a big infrastructure (320k public folder with about 25TB, legacy with native scripts and not third party) three weeks ago, I encounter another issue with the autosplitting. The mailbox never goes into sync state and therefore always fails to autosplit.


ReducedStateProgressState: PrepareSplitPlanCompleted

ReducedStateAutoSplitRetryCounters: MRF:1;MRTTLTC:0;MRIB:0;MRNI:0;MRFF:0;SRF:0;CNM:False;SSBM:False;XRFS:False;XRFT:False;Error: Folder hierarchy is in inconsistent state at source mailbox. Please run Update-PublicFolderMailbox cmdlet on source to fix this problem.


Running the update-publicfoldermailbox is not changing it.


Microsoft has now increased the quota for this Mailbox to 135GB and closed the ticket. The Mailbox is still growing and the splitting is not working. What would be the next steps for debugging here? 


@tonire Let's agree 1st that you have a huge Public Folder environment 320K here, so for the affected public folder mailbox, did you manage to see how many folders is that public folder missing ? ,cause if the out of sync hierarchy is huge that might take a lot of time and even if you did invoke the sync that is going to be splitted in to several iterations of 500 each taken in to consideration that throttling will apply to maintain a fair usage of our servers.

In addition to that AutoSplit would slowly move out folders, even if the sync didn't complete.

It would choose only 20 folders at a time, and sync those folders, and move those folders, that occurs when MRF value incremented to a certain number.
So you might keep monitoring that affected mailbox for hierarchy changes and wait for Autosplit status to change.


Senior Member

@Hazem_Embaby  Thank you for your answer.


Yes, we definitly can agree that it is a huge environment. How can I check the hierarchy sync for a mailbox that is excluded from serving hierarchy? For the Hierarchyserving mailboxes, they are all on hierarchy ready $true.


I can see a lot of hierarchy sync errors in the diagnostics for Mailbox1:


Failed to resolve mail public
folder. Folder : 0000000073A217EBDDCA3A4D877A199F008AD1040100258EE17F54982A49913C835704EB1F67000048DD47


Maybe this is causing hierarchy sync issues? Before migrating the public folders, we have been in a public folder hybrid deployment with the "Sync-MailPublicFolders.ps1" script. Can it be that the objects created by the script beforehand are causing a kind of duplicate now?


Even you mention that the split will also work slowly if the sync didn't complete, I still see that the mailbox is just growing for about 200MB a day. We will soon run into new problems with that mailbox and SEV A is unfortunately just acting by increasing the qouta which is not fixing the problem itself but just the symptoms.


@tonire Sorry for my late replay, It doesn't matter if the mailbox is serving hierarchy or not, you can check and compare the PF hierarchy on a secondary PF MBX with primary PF MBX by running that command twice Get-PublicFolderMailboxDiagnostics -IncludeHierarchyInfo check that article for more details.


It doesn't matter If you were on a PF coexistence since you are going to run that script several times during migration to sync any MEPF updates "add new MEPFS, delete non-existent MEPFs,...etc" to EXO, so for such an error "failed to resolve" I would start to check for that EntryId by running get-publicfolder & get-mailpublicfolder may be there's a discrepancy on the EntryIDs populated or even it's not a MEPF any more.


We are raising the quota to give space for the mailbox to be able sync the data inside to the target mailbox using the PFmoverequest created by the system, if that scenario recurred several times we would check the PFmoverequested if it was about to complete then we'll wait else we can remove that PFmoverequest and create a new one containing the largest PFs on that source mailbox to allow some space for the source mailbox without the need here to increase the quota.






Regular Visitor

Now that one one of public folders have autosplit it is no longer using the Primary SMTP address to send mail.  It's coming into our users as From: AutoSplit_e6eca071583c44de Sent: Thursday, March 25, 2021 11:50 AM


How do you get it to make it use the Primary SMTP address of that folder again?


@Jodee Hayka Do you mean a mail enabled public folder hosted on Autosplit Public folder mailbox is using primary smtp address of the Autosplit public folder mailbox to reply back for an outlook autoreply rule ? if yes

Try to disable the mail public folder then re-enable it back again and it shall solve your issue!

#Connect to EXO powershell

Disable-MailPublicFolder "replace with affected public folder ex.\PF1"

Enable-MailPublicFolder "replace with affected public folder ex.\PF1"


Occasional Visitor

@Jodee Hayka @Hazem_Embaby @The_Exchange_Team  We are also seeing the issue of emails being sent or


We've raised a Unified Support ticket for this months ago but despite weekly chasing and making it high severity it will apparently be July before this is fixed by the product group :(  With hundreds of mail enabled public folders, many of which have multiple SMTP addresses and folder assistant rules associated with them, I'm reluctant to start messing about with them.


Our customers have pretty much given up on us being able to send an email to them with the correct email address on it.  It's not a good advert for Microsoft's email platform or their ability to fix issues which are seriously impacting to their customers.


@Jodee Hayka Did you try the enable/disable and did it resolve the issue?

Senior Member

@The_Exchange_Team @Hazem_Embaby 

We face a new issue and no one at Microsoft Support with SEV A can help us.


Currently it is not possible to delete content from an autosplit mailbox. The mails is gone in Outlook after removal but after few seconds it appears again a script with EWS is showing the same behavior. On OWA it seems to work.

Now we have this amazing issue that all the autosplit mailboxes are running full and can not receive any new mails :( .

The support we get from Microsoft regarding this is unbelievable bad. We collect the same logs every day and there is no progress or at least a confirmation that this is currently a known issue. In fact they pretend that everything is working as expected. :cry:

@tonire What is the velocity of inbound emails received by the email-enabled public folders? 
Do those folders receive so many emails that the auto-split process cannot follow up?


Senior Member

@Thomas Stensitzki 

Let me explain more in detail


1x autosplit Public Folder Mailbox

3x folder (folder A (mailenabled), folder B, folder C) hosted on the autosplit mailbox.


We now receive a mail in folder A. Normally the employees are then moving the mails based on their workflow in folder B or folder C. The mail gets moved to folder B or C and gets deleted in folder A. Currently the mails can not get deleted in folder A (they come back after 2 seconds) but get copied to folder B or C. So instead of a move it is more of a copy as Outlook or EWS can not remove items.


This behavior is only happening with folders on Autosplit Mailboxes. On regular public folder mailboxes it is not happening.


With the time the folder A becomes a "giant folder" and can not get splitted anymore and therefore we can not receive and mail anymore.


@tonire To get this right so you are using EWS script to take actions on emails received on PF A "delete & move", PF B "create new item", PF C "create new item", If I get you correctly the issue is with deletion process which made Folder A a giant one but why isn't PF B & C are giants since all of them are having same input "email items" with same size?

one more point have you modified DefaultPublicFolderDeletedItemRetention across the organization (least value is 1 day) or even across that PF A "RetainDeletedItemsFor" (you can specify zero days here) where deletions are taking place to ensure that these items are always purged constantly.

Can you share with me your request in a DM?



@punsontherun Unfortunately our engineering team are still investigating that issue but as I mentioned earlier the workaround to disable the re-enable back MEPF shall work and solve your issue.


You can try that on one MEPF and check if that solved your issue!


Sorry for my late reply!

Senior Member

@Hazem_Embaby I sent you more details as DM. Thanks for your help

Version history
Last update:
‎Jan 11 2021 01:35 PM
Updated by: