Hi Hazem_Embaby
Thank you for the info’s.
I was aware about the docs you linked, except the PublicFolderInvalidDumpsterFixingProcessor (and the others not officially documented).
Here it is mentioned that "The exact reason for this might not be known, but the issue typically happens after public folders are migrated from on-premises servers using PSTs or third-party migration tool."
In fact, now it sounds 'logical' that a migration done with "-excludedumpsters" will cause the PublicFolderInvalidDumpsterFixingProcessor to touch every folder after the migration.
This should be clearly mentioned within the official migration docs and in here. (not only referring to pst and/or 3rd party tool migrations)
Right after the migration (using -excludedumpsters for ~242k Public folders in 100 source PF mailboxes) all target PF mailboxes were IsExcludedFromServingHierarchy:$false (except the primary hierarchy) and IsHierarchyReady:$true.
But checking the hierarchy after the migration (as described in “Introduction to Public Folder Hierarchy Sync”) showed that almost no PF mailbox was in sync, even the attribute IsHierarchyReady was $true.
It looks like that we are currently having issues hierarchy sync issues… and my feeling is that this is being caused by the size of the hierarchy and the number of mailboxes trying to pull the hierarchy from the primary hierarchy.
So, I am interested in the relationship between the different attributes, sync states in PF diagnostic logs, conditions, which will trigger a Public Folder mailbox to become HierarchyReady and being offered to the end-user.
If the PublicFolderInvalidDumpsterFixingProcessor created and attached 242k “dumpster” right after the migration… my understanding is that this also is some kind of hierarchy change, which has to be replicated to every pf mailbox?
Regards
Alex