When creating the PF sync job, a question is presented regarding the discovery of new folders created after the initial creation of the hierarchy:
Due to the nature of modern public folders, the creation of child folders under a parent folder will inherit the content mailbox setting of the parent. It can happen that after the destination parent folder has already been assigned to a given public folder mailbox that new data and subfolders are added to a source folder by natural user or automatic actions and that can cause the target PF mailbox to grow in size as a result and possibly grow to the configured size limit of that mailbox. For example, a source folder named SALES along with its subtree has 20GB of data. At the start of the project, the SALES folder is assigned to a specific public folder mailbox on the target side. After the sync has started, users add 80GB of new data to the SALES folder thru a combination of items and new folders. If no other options are used the sync will cause the target public folder mailbox reach 100GB.
As an option to avoid the above situation, the sync can look at the created date of source folders as they are scanned and if the creation time is greater than the date of the target parent’s creation time, the sync can skip the folder and produce it in a separate PowerShell script so that it can be manually created on a specific public folder mailbox and thereby ensure that the new data will be diverted to an accommodating resource versus potentially filling up a mailbox.
Do you want use this option to prevent unsync’d newly created folders from being processed?
This is a unique and valuable feature currently found only in the Priasoft toolset. Priasoft recommends answering YES to this question unless it known with high confidence that source data is static and unchanging. Failing to consider this aspect can cause the migration project to stop due to either Office 365 auto-splitting a mailbox or a public folder mailbox reaching it max capacity.
If the option was enabled (by answering YES) and if any new folders were found during the sync, they will be listed in a PowerShell script in the sync job’s folder. The script should be edited to make specific public folder mailbox assignments for the listed folders and executed against the target environment. Once executed, a short “dust settling” period should be observed so that the new folders can be replicated to the secondary public folder mailboxes.
Priasoft recommends creating new public folder mailboxes for the identified folders and along the same pattern of distribution used in step #1. If a 20GB initial loading was used, then one should follow that same pattern and assign the folders in the script to new empty mailboxes on 20GB increments.
A reminder that creating a new empty public folder mailbox – if it is also set as a hierarchy serving mailbox – at this stage can take many hours or a few days to be ‘ready’ since the new mailbox needs to receive a full copy of the hierarchy before performing the data sync.
After this script has been executed, the same sync job that created the script should be restarted so that it will process the updated folders. Note that if a large quantity of data or folders has been created since the start of the project, the delta sync that is restarted in this step may take substantial time to complete. Do not move to Step #7 until this delta sync has completed.
