Due to the architecture of modern public folders, the distribution data across public folder mailboxes must be designed and established before and ahead of any data synchronization. Priasoft provides an automated task that can analyze source data to determine both the number of required content mailboxes as well as the assignment of initial folders to those mailboxes.
As mentioned previously the contents of a modern public folder will only ever exist on one public folder mailbox at a time. Modern public folders do not have a “waterfall” feature for data, meaning that if a public folder content mailbox reaches its maximum size all folders assigned to that mailbox immediately become effectively read-only. If any of the folders on such a mailbox are mail-enabled, mail delivery will fail, and a non-delivery message will be returned to the sender. This will remain true for as long as the mailbox is at limit. As such data must be carefully distributed across a series of content mailboxes and with consideration of future growth patterns.
Office 365 Auto-Split
Note that Office 365, in contrast with on-premises Exchange, has an “auto split” action that will occur if a public folder content mailbox reaches 80GB of data. This action is something that should be avoided if possible as it is very disruptive to end users and mail delivery. When a public folder mailbox is auto-split, all of the folders assigned to that mailbox become inaccessible, meaning that attempts to read the contents in any way will fail. If the mailbox is a hierarchy serving mailbox – meaning it is connected to by outlook clients to expand the folder tree – such users will not be able to browse the hierarchy.
There is no prior notice of an auto-split nor is there any option to choose to accept now or to delay the action. The duration of the split action takes considerable time – hours, days, or possibly weeks – and is influenced by the total number of folders in the entire hierarchy, the number of folders’ contents hosted on the mailbox, and the total number of items stored on the mailbox. For large environments – those with 10s of 1000s of folders – this process can easily take more than a week to complete.
When the auto split action starts there is no ability to pause or cancel the action. There is no progress bar or indication of progress of any meaning and so there is no way to forecast how long the process will take to complete. If this were to occur in the middle of the migration, all migration activities would need to stop until the split completes. It is for this reason that Step Zero is so critical and necessary. Failing to complete Step Zero will affect the ability to properly analyze the source data and the distribution of that data across mailboxes.
In an on-premises environment things are a little more forgiving. One can simply increase the mailbox size limit temporarily until data can be deleted or moved and the reset back to the original limit. However, there is risk of increasing the limit beyond Microsoft supported limit and having issues for which Microsoft could choose not to help. Additionally, on-premises Exchange allows an administrator to move the contents of one or more public folders from one mailbox to another (ref: New-PublicFolderMoveRequest). However, this does not exist in Office 365. In order to move the contents of a public folder, a support ticket must be raised with Office 365.
Initial Data Loading
Priasoft recommends assigning between 20-25GB of data to each public folder mailbox in order to leave 75-80GB of free space for organic growth following the migration. Hopefully this quantity of free space is sufficient for many months or years to prevent the Office 365 ‘auto split’ action from occurring and from an on-premises public folder mailbox from filling up.
The Priasoft task that maps source data to target public folder mailboxes produces a PowerShell script as its output that is then executed against the target environment (on-premises or Office 365). The script will create any additional content mailboxes needed as well as folder assignments to those mailboxes.
The execution of this script is inherently slow, primary due to PowerShell being a single-threaded process. On average it takes between 6-20 seconds per folder to process. The variance in duration per folder is relative to the depth of the folder. A root-level folder takes less time to process than a folder with 5 parents in its path. A script with 1000s of folders to be created can take many hours or a few days to complete and may require restarts due to disconnects of the Exchange PowerShell session.
The created script, by design, does not assign or created every folder in the hierarchy. Given the slowness of the PowerShell actions and the lack of multi-threading, Priasoft limits its use to only perform those actions necessary to assign data to mailboxes. Since creating a child folder inherits the content mailbox setting it is unnecessary to create all the child folders of a given subtree if that subtree’s total size is small enough to fit onto a specific mailbox. For example, if a parent folder named \Sales\California has a subtree of several dozen folders and the entire ‘California’ subtree size is only 2GB, the script will only create and assign the ‘California’ parent folder to a content mailbox. When the Priasoft structure sync occurs, the create of the child folders will naturally inherit the same content mailbox. It is common for the PowerShell script create only 25% to 50% of the entire hierarchy.
Non-Default Folder Types
As many are likely aware, Microsoft Exchange allows a user to create folders of specific content types such as calendar and contact folders. Technically such folders can contain any kind of content, but a mail client has the option to render the user interface based on the expected type of items. A calendar folder will default to rendering in a calendar view with days, weeks, or months shown while a contact folder will show lists of people and recipients as a contact sheet.
Unfortunately, there is no ability to create a non-default folder type using PowerShell; this can only be done with the Outlook client (excluding 3rd party tools). This means that one cannot use the PowerShell command New-PublicFolder to create a calendar or contact folder or any other type. The script referenced in the previous paragraphs is not able to overcome this either and if a source folder must be created on a specific public folder mailbox, it will initially be a “mail message” folder type. In such cases, the script will append the folder path to a text file which is used as an input source to the Priasoft PF Toolbox “Bulk Modify Folder Types” feature. This feature will modify the folder types (using MAPI) to match the original type found in the source environment. The script will prompt at the start and end of its execution with reminders about the need to perform this additional step, if needed.
From a post-migration management perspective, the above should be remembered and thought about regarding how one would overcome this. For example, if a user wanted to create a new calendar folder and wanted that folder’s contents to be contained on a specific public folder mailbox, there doesn’t appear to be a way to do this without 3rd party tools (like Priasoft’s). The only feasible way to do this is as follows:
- Create a new standard folder targeting the specific public folder mailbox. (PowerShell)
- Create the calendar folder as a child of the new folder. (Outlook)
- Optional: Move the new calendar folder to a different parent folder. Moving a folder to a new parent does not change the content mailbox setting.
Hierarchy Serving Mailboxes
A note about “Hierarchy Serving Mailboxes”: modern public folder mailboxes can be set with a Boolean property named IsExcludedFromServingHierarchy. When this value is FALSE, Exchange AutoDiscover is free to hand out the mailbox in response for an Outlook client to use as the initial connection to public folders and is used for the navigation of the public folder hierarchy. When a user accesses the contents of a folder, mapi will negotiate the connection to the proper content mailbox on its own.
If a public folder mailbox is set to TRUE for the IsExcludedFromServingHierarchy an administrator can still point users statically to the mailbox, but the Outlook client may not see the entire hierarchy unless the hierarchy has been fully synchronized to the mailbox before excluding it from serving the hierarchy.
Furthermore, recent changes to Exchange 2016/2019/Office365 show that if a public folder mailbox is set to not serve the hierarchy, the same mailbox will not receive a full copy of the hierarchy. Priasoft recommends determining the total quantity of necessary hierarchy serving mailboxes be made in advance and in consideration of the 2000 max connection limit. For example, if the distribution of data only requires 2 public folder mailboxes but the organization has 5000 users, a third empty public folder mailbox needs to be created so that the max connection count is not exceeded. User connections can then be evenly distributed across 3 mailboxes to about 1700 users per mailbox.
Dust Clouds
As an analogy to how the hierarchy replication of modern public folders work, Priasoft uses the idea of a dust cloud that is created when a large quantity of folder-level actions occurs in a short period of time. The “dust cloud” is simply an unordered queue of work that must be processed in order to replicate the hierarchy. A “dust settling” period is simply a duration in which no new activity is started that so that all queued actions can complete.
After running the PowerShell script, a “dust settling” period should be used to allow for all the newly created folders to be replicated between all of the public folder mailboxes. During this delay, no changes to the target public folders should be made and the environment should be allowed to be as idle as possible during that time.
When a public folder is created – by script, Outlook, OWA, or any other action – the folder is initially created on the content mailbox, then on the Primary Hierarchy mailbox, and then distributed down to all the other hierarchy serving secondary content mailboxes. When creating 10s or 100s or 1000s of folders in a short period of time – as the referenced PowerShell script will do – it will create a queue of actions at the primary hierarchy mailbox. This has a cartesian effect on the duration of time before all public folders mailboxes are “in sync”. If the distribution of data requires 4 hierarchy serving public folder mailboxes and the script creates 50,000 folders, this equates to 200,000 transactions that must occur before all public folder mailboxes are in sync. From testing and monitoring it has been found that the hierarchy sync process has a run rate of approximately 45,000 transactions per hour. In the above example it the duration of “waiting for dust to settle” can be as long as 4-5 hours or more. During this waiting period, one should avoid doing other large-scale actions against public folders. In larger scenarios this can require several days of waiting. From a previous customer experience with over 100,000 folders in the hierarchy, the waiting period was nearly one week.
Progress of the hierarchy sync can be observed through the use of the following single line PowerShell command:
Get-Mailbox -PublicFolder | Get-PublicFolderMailboxDiagnostics | Select identity, @{n='FolderCount';e={[int32][regex]::match($_.hierarchyinfo,'(?<=TotalFolderCount:\s*)[0-9,]+').value}} | Out-GridviewThe above command will output each public folder mailbox and the current folder count to a gridview window that can be sorted. Once all hierarchy serving mailboxes match the folder count of the primary hierarchy mailbox the synchronization is complete.
Failing to wait until the hierarchy sync completes will lead to issues with further steps in this process.
