How Exchange Online automatically cares for your public folder mailboxes (via AutoSplit)
Published Jan 11 2021 01:32 PM 40.5K 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.

pfautosplit01.jpg

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.

pfautosplit02.jpg

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.

pfautosplit03.jpg

 

pfautosplit04.jpg

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.

pfautosplit05.jpg

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*”

Example:

pfautosplit06.jpg

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.

pfautosplit07.jpg

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)”.

pfautosplit08.jpg

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.

pfautosplit09.jpg

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:

pfautosplit10.jpg

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.

pfautosplit11.jpg

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*

pfautosplit12.jpg

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

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

pfautosplit13.jpg

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.

Run:

Set-OrganizationConfig -DefaultPublicFolderMovedItemRetention 1.00:00:00

pfautosplit14.jpg

Update-PublicFolderMailbox <AffectedPFMailbox>

pfautosplit15.jpg

After a few hours, check again:

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

pfautosplit16.jpg

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

31 Comments

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.
-Thomas

Brass Contributor

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?

 

Microsoft

@momurray 

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!
Copper Contributor

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? 

Microsoft

@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.

 

Copper Contributor

@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
FB0000,,b56264df-bf5b-4b25-ab43-24e13afeca49,6246c9fe-79e6-4621-bcc2-e21d4805e60e

 

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.

Microsoft

@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.

 

 

 

 

 

Copper Contributor

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?

Microsoft

@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"

 

Copper Contributor

@Jodee Hayka @Hazem_Embaby @The_Exchange_Team  We are also seeing the issue of emails being sent fromAutosplit_GUID@TENANT.onmicrosoft.com or PF-MailboxX@TENANT.onmicrosoft.com

 

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?

Copper Contributor

@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?

-Thomas 

Copper Contributor

@Thomas Stensitzki 

Let me explain more in detail

Scenario:

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.

Microsoft

@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?

 

Microsoft

@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!

Copper Contributor

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

Copper Contributor

When replying with a read receipt, the sender, in our case the customer, receives an e-mail with the sender AutoSplit_*** instead of the PF address, which confuses the customer. Is there a remedy for this?

Microsoft

@francesco_caruso This is a known issue tracked here !

Copper Contributor

Great atricle for troubleshooting and still valid. Thank you very much.

For me, the issue was actually that "PublicFolderMailboxRemovalProcessor" was 6 days in the future. With the following commands the problem was taken care of within minutes, not hours.  The migration continues.

 

Set-OrganizationConfig -DefaultPublicFolderMovedItemRetention 1.00:00:00

Update-PublicFolderMailbox <affected pf-Mailbox> -Verbose

Microsoft

@grabery Thank you too for sharing that useful information!

executing Update-PublicFolderMailbox command is invoking all public folder processors to run across the affected PF MBX.

Brass Contributor

If you have a single Public folder of let's say 60GB in size (no subfolders) what would happen if you migrate that as is? Will the migration batch fail due its size being above 25GB? Also since it's a single folder I assume auto-split would also not trigger?

Microsoft

@brlgen I don't have a clear answer for your 1st question since it's out of Microsoft support recommendations however answering your 2nd question is on the same article for migration with PFs greater than 2GB we might need to modify the value for DefaultPublicFolderIssueWarningQuota DefaultPublicFolderProhibitPostQuota over Exchange online organization configuration to have greater relative values over the migrated PF size, 

answering your final question Autosplit will be triggered but it shall skip that PF as it's a Giant PF.

It's better to split that PF to smaller subfolders to have a better migration throughput and better management on EXO, for more information over migration best practices please check this article.

 

Copper Contributor

I've observed that if a new PF mailbox is created and is excluded from serving hierarchy it seems as if it never receives a full copy of the hierarchy. Is this by design, impatience, or an issue?

Is Microsoft able to comment on how the hierarchy sync between PF mailboxes is prioritized and scheduled? Is it ok for a non-hierarchy-serving mailbox to not receive a full copy of the hierarchy? I think not, but such detail does not seem to be exposed.

Microsoft

@Eriq VanBibber IsExcludedFromServingHierarchy is a switch to control whether the system assigns that PF MBX to users or not I assume it's not related here, what about the IsHierachyReady parameter for the PF MBX you mentioned? is its value set to True or False? 
Can you be more specific by sharing your exact repro steps so I can check on myside?

Copper Contributor

@Hazem_Embaby 

 

I'm quite familiar with the use of the IsExcludedFromServingHierarchy.  Its really an influencer for AutoDiscover responses.

 

however, what i have seen very recently is with a large customer.  They have several TB of PF data and in the process more than 100 PF mailboxes were needed to distribute data.  Our guidance has been to wait until all the PF mailboxes have received a copy of the hierarchy before doing any content sync actions.

 

 

What was observed was that the 100 hierarchy serving mailboxes received a copy of the hierarchy as expected and and normally seen, but the mailboxes marked as not-serving never received a full copy of the hierarchy.  The non-serving mailbox had *some* folders, likely only the folders that were assigned to that mailbox.  So, customer flip-flopped the hierarchy serving values between the 2 states and once done the mailboxes without a copy of the hierarchy started to sync.  Separate testing shows me that this is not exclusive to a large deployment.  Even a deployment with only a dozen mailboxes shows the same behavior if some of the mailboxes are excluded from serving the hierarchy.  The mailboxes initially set to not serve the hierarchy also seemed to report IsHierarchyReady as False until the switch-a-roo was performed.

 

This seems to be a different behavior than what i have previously experienced.  

 

So, it goes back to my question about expectations?  Should all PF mailboxes have a copy of the hierarchy?  I think so, especially since it is possible to statically set the DefaultPublicFolder mailbox of any user to any of the PF mailboxes, regardless of the hierarchy serving flag.

 

Maybe the non-serving mailbox will eventually get the hierarchy, but on a much longer timeline?  not sure and looking for more discrete clarity from Microsoft on this aspect.

 

 

 

Microsoft

Hello @Eriq VanBibber sorry for taking some time to reply to you as I have to validate such information with our engineering team.

 

Answering your question in 2 parts -> consider the scenario that you have 200 PF MBXs where 100 PF MBX are hierarchy serving mailboxes while the other 100 are content based PF MBXs on such a scenario it's normal that PF MBX 101 should not have a complete hierarchy as its function is content based PF MBX not hierarchy serving, for more information on EXO limits please check the below article.

You are limited to 1,000 public folder mailboxes, and the maximum total size of all public folder mailboxes is 100 TB. Hierarchy Serving mailboxes are limited to 100 public folder mailboxes. Exchange Online limits - Service Descriptions | Microsoft Learn

Consider another scenario that you had 40 PF MBXs where some of these PF MBXs have IsExcludedFromServingHierarchy set to True, when a PF MBX is excluded from serving hierarchy, it's set to have partial hierarchy, this is by design.
When you forcefully connect to such partial-hierarchy mailbox, it is Expected to see a partial hierarchy, toggling the IsExcludedFromServingHierarchy to false will invoke the sync across that PF MBX to acquire the complete hierarchy information.

Copper Contributor

Hello @Hazem_Embaby ,

 

Thank you for great article.

 

Is there any way to trigger a potential auto-split out of working hours? Or is there any BP how to prevent not accessible MEPF due to auto-split during working hours?

 

Thank you.

Copper Contributor

Hello @Hazem_Embab,

Thanks for the wonderful article which you specified at granular level for each every step on Public Folders. Really appreciated.

Please can you clarify below points as I am in the middle of migrating legacy PFs to EXO in EX2016 hybrid scenario.

1. It’s my understanding  that if we leave the folders in the Primary Hierarchy mailbox, then we are at risk that some day when those folders get too big, autosplit will take the primary hierarchy mailbox off line temporarily resulting in a full public folder outage. If all folders are in secondary hierarchy mailboxes, then when one fills up and autosplits, only those folder in that mailbox go off line.

2. I am told that New_PublicFolderMoveRequest is available to the Microsoft support teams, but not available to EOL powershell for tenant admins, so if we need folders moving we just need to raise a support request with Microsoft. Our request is to move all the folders whose data is currently in the MasterHierarchy mailbox to a new secondary hierarchy mailbox.

3. Is it possible if I would need to move the Public Folders Data manually from one PF mailbox to another PF mailbox as it's not mentioned anywhere in the article.

 

Please can you shed some light on it on above 3 points. Any help really appreciated.

I have also raised a case with MS on this issue, but still I don't have any update.

 

 

Regards

Anand Sunka

Microsoft

Hello @PetrSss ,

 

Am so sorry for my late reply I haven't received a notification on your comment, please find my answers inline.

 

Is there any way to trigger a potential auto-split out of working hours? Unfortunately, there's no control over that as that's hard coded value, but autosplit is a background process that shouldn't affect your PFs access if that's your question.

Or is there any BP how to prevent not accessible MEPF due to auto-split during working hours?  If your question here when Autosplit is halted unfortunately the only way is to contact Micorosft support.

Hope that answer your concerns and please feel free to reply back if you have others.

 

Regards,

Hazem

Copper Contributor

@ANAND_SUNKA 

 

As someone who has written software for the migration of public folders (Priasoft), i can tell you for sure that your point #1 is mostly true.   Users will be able to create a new folder on the hierarchy-serving mailbox to which they are connected, if the new folder is a child of a folder that is assigned to that mailbox.  Still not the most helpful thing, but hopefully adds some extra clarity.  However, even that being true, that new folder would not show up on the primary mailbox or any other hierarchy serving mailboxes until the primary comes back online and can replicate the change.

 

It is also my understanding that only MS support can execute the public folder move.  Sad because the command exists for on-premises environments.  I guess the reason is because of the impact of such a move.   You should know that if you do move a folder from one content mailbox to another that the source folder is inaccessible during the move and the ENTIRE target mailbox that will receive the new folder is inaccessible.   As such, if you do make move requests you should make those to a new and empty target mailbox so that you don't affect others.

 

The only manual option you have is very convoluted, but does work:
Consider the following:

Folder to Move:  \Sales\US\California

Folder's content mailbox:  Mailbox01

Desired destination mailbox: Mailbox04

Existing Folder on Mailbox04:  \Temp\MBX4  (or create this via New-PublicFolder -path \Temp -Name MBX4 -Mailbox Mailbox04)

 

1. Create NEW empty folder as a child of a folder whose content mailbox is already on Mailbox04.

        Example:  \Temp\MBX4\California

2.  Copy or move data from \Sales\US\California to \Temp\MBX4\California

        This will cause data to be created in Mailbox04.

3.  Copy the permissions from \Sales\US\California to \Temp\MBX4\California

4.  (if mail-enabled) Capture email address info from \Sales\US\California

5.  (if mail-enabled) Mail-disable \Sales\US\California (if mail-enabled)

6.  (if mail-enabled) Mail-Enable \Temp\MBX4\California and re-apply same values from original folder.

7.  Delete the \Sales\US\California folder.

8.  Move the \Temp\MBX\California folder to \Sales\US

 

This works because the content mailbox assignment is per-folder and doesn't change when you move a folder around.  

Like i said...its convoluted, but it works.   

 

The biggest side effect is that the items in the new folder are copies of the original, even if you do a move (a move is actually a copy followed by a delete).  A such the EntryIDs, created dates, and modifed times of the items change.

 

You can contact me at priasoft if you have more questions.

Microsoft

Hello @ANAND_SUNKA,

Am sorry for my late reply, please find below answers to your requested questions,

1. It’s my understanding  that if we leave the folders in the Primary Hierarchy mailbox, then we are at risk that some day when those folders get too big, autosplit will take the primary hierarchy mailbox off line temporarily resulting in a full public folder outage. If all folders are in secondary hierarchy mailboxes, then when one fills up and autosplits, only those folder in that mailbox go off line.
->So the interruption occurred here is at the last stage of the public folder move request and it's only temporarily "few seconds up to few minutes", what we always do recommend on our side is to leave the primary PF MBX away from disruptions by excluding it from serving hierarchy & avoid adding content on it so as to leave that PF MBX only available for it's main role/function which is writing PF hierarchy information.

2. I am told that New_PublicFolderMoveRequest is available to the Microsoft support teams, but not available to EOL powershell for tenant admins, so if we need folders moving we just need to raise a support request with Microsoft. Our request is to move all the folders whose data is currently in the MasterHierarchy mailbox to a new secondary hierarchy mailbox.
-> Unfortunately, you are correct, you can contact Microsoft support if the folders are too many or you can do it yourself by:
a.Use Outlook or content search to export the required PF on primary PF MBX "e.g. \PF1" 

https://learn.microsoft.com/en-us/purview/ediscovery-content-search#create-and-run-a-search

b.Create new PF "e.g.\PF1new" on the required content secondary PF MBX and import required data using Outlook client
c.Repeat the above steps for each required PF

3. Is it possible if I would need to move the Public Folders Data manually from one PF mailbox to another PF mailbox as it's not mentioned anywhere in the article.
->Answer is in the 2nd Question

Hope that answers your queries a bit and feel free to reply back if you have any concerns.

Regards,
Hazem

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