This document covers the frequently asked questions and other relevant general Public Folder migration advice. 

Supported Systems

We support the following versions of Exchange for Public Folder migration:

• ​Exchange 2007.
• Exchange 2010.
• Exchange 2013.
• Exchange 2016.
• Microsoft 365 Exchange Online.​

Credentials

​In order to properly migrate Public Folders, admin credentials are required for both the Source and the Destination.

Specifically:

At the Source:

• Read-only access to all Public Folders is required.

At the Destination:

• ADMIN privileges are required for the migrating "admin" account so that all fields can be set at the Destination.
• ​​Ownership of Public Folders are required on the Destination so that new subfolders can be created.

The Exchange Management Shell commands that are used are only available to an Exchange Administrator, so if you are using a user that is not an administrator when performing a Public Folder migration, you will get an error stating: "The account being used is not an administrator.  Please elevate the user to an administrator in order to mail-enable public folders."

This error will not cause your migration to fail, but the folder will not be mail-enabled.

Administrator account permissions

Change the user name in the cmdlet to be the name of the administrator account that is performing the Public Folder migration.

Being a member of the Public Folder Management Group does not provide enough permissions to perform a Public Folder migration.

When migrating from a Hosted Exchange provider (Source), you will need to ask their support department to run this PowerShell cmdlet for you. If they do not want to provide "owner" access rights, then ask them to add "read" access rights. In many situations, "read" access may grant enough access for the Source Public Folders to be read properly, however, if issues are encountered, "owner" permissions will be required.

"Owner" permissions are required for the Destination in order for the administrator to create the necessary items.

Run the following cmdlet to ensure that the administrator account that is being used for your Public Folder migration has the necessary permissions on all Source Public Folders:

Exchange 2007 and Exchange 2010:

Get-PublicFolder –Server <ServerName> -Recurse -ResultSize Unlimited | Add-publicfolderclientpermission –Server <ServerName> -User "domain.local/user/migrationwiz" –accessrights "owner"

Exchange 2013:

Get-PublicFolder –Recurse -ResultSize Unlimited | Add-PublicFolderClientPermission –User O365Admin –AccessRights Owner

Microsoft 365:

For Microsoft 365 it is recommended that you set permissions from the admin portal as the operations to add the permissions might not complete during a PowerShell session.  

Assigning admin role "Organizational Management" 

When setting certain fields in Exchange, the user performing a migration needs to be assigned the correct permissions through assigned admin roles. In most cases, the admin role for migration is relatively straightforward. For Public Folders, however, the role is not so obvious.​

In most cases, the assumption is that simply creating a new admin role and assigning the 'Public Folders' and 'Mail Enabled Public Folders' roles to the group would allow any users in that group to have full access to the Public Folders and be able to set all of the appropriate fields. However, this is not the case. In terms of read-only fields, such as the received date, simply having these two permissions is not enough. If these are the roles set, and if a read-only field such as the received date is set in the message being migrated, it is ignored and the current date and time are set instead of the value passed in.

In order to allow read-only fields to be set, an elevated admin role has to be assigned to the user performing the migration. The role that is recommended is 'Organization Management', which provides all of the necessary permissions to set fields like the received date without any problems.

Click here to learn more about the Organization Management role, and how to add it.

This can be set via the Exchange Administration Center (EAC) or via PowerShell.

Via Exchange Administration Center:

• In the Exchange Administration Center (EAC), navigate to Permissions then Admin Roles.
• Select the group: Organization Management and then click Edit  .
• In the Members section, click Add  .
• Select the users, USGs, or other role groups you want to add to the role group, click Add, then click OK.
• Click Save to save the changes to the role group.

​Via PowerShell:

• Enter command:
  
  Add-RoleGroupMember "Organization Management" -Member username

To migrate from Exchange 2007, elevate the permissions of the admin to be part of the Exchange Organization Administrator role. To add the user to the role, follow the TechNet article How to Add a User or Group to an Administrator Role.

If migrations are performed with an account that does not have this elevated admin role level assigned, then the received date will change to the current time, after the migration of Public Folder content.

​Items in Public Folder Migrations

Adding Items

Public Folders can either be added in two ways:

Adding a Public Folder (steps):

Once a Public Folder Project has been created, click on the Add button and then click on Quick Add. To only migrate all Public Folders, just enter a slash -- which signifies the root of all Public Folders. Otherwise, when defining the path of the Public Folder, there is no need to add a slash at the beginning of the string: simply enter the folder name followed by a slash and then add sub-folder names. Backslashes are not allowed when defining the Public Folder path. Spaces are allowed in the Public Folder name. The path to the Public Folder must exactly match the path in Exchange for that Public Folder. When in doubt, you can always use the discovery functionality.

Folder Types

In order for items to be migrated between Source and Destination Public Folders, the types of the folders must be correct. This means that when migrating email, both the Source and Destination must be set up as email folders. The same holds true for calendars, contacts, tasks, and most other item types.

However, when creating new Public Folders through the Exchange Admin Center, they are always created as email folders.  This means that if you create a folder at the Destination that has the same name as the Source, and the Source folder is not an email folder, then no data will be transferred between the Source and the Destination.

We detect this condition and throw an error stating: "Source folder type does not match Destination folder type."

If you see this error, it is likely that you have created your Public Folder with the incorrect type (e.g., it was created as an email folder when it should be a calendar folder or contact folder).

In order to fix this error, you have to either delete the existing folder at the Destination and allow the migration process to create the folder, or you have to create the folder as the expected type. This can currently only be done through OWA or Outlook, and not within the Exchange Admin Center or through PowerShell.

Splitting large folders

Prior to migrating your Public Folders we recommend the following actions:

• Any single source folders larger then 20 GB should be broken down into smaller folders.
• When migrating to Exchange Online (Microsoft 365), ensure that all of your Public Folders are within the stated limits for public folders​. 
• Purge old or unused data. This will save on your migration costs, and also save some space in the target environment.

Folder hierarchy

There is no need to create the folders before performing a Public Folder migration, unless migrating more than 20 GB of data to Exchange Online, in which case, BitTitan support will need to provide scripts to create the IPF.Note folders and additional public folder mailboxes before migrating. MigrationWiz will create all folders from the root to the folder being migrated. However, only the folder being migrated will have proper permissions set and will be mail-enabled (if appropriate).

One thing to note is that the source and destination folder type must match. This means that if you are migrating a Contacts or Calendar folder, then the destination folder has to be created as a Contact or Calendar folder. Folders other than IPF.Note (Email) folders can only be created correct through EWS, which is what MigrationWiz uses for migrating public folders. If the folder is not of the correct type, then no items will be migrated into it (e.g., mail items cannot go into a Contacts folder, and vice versa).

Migrating Permissions

Permissions for Public Folders can only be migrated from Exchange 2010+ (i.e., they cannot be migrated from Exchange 2007).

The account for the Source needs to either be an Owner of the Public Folder or be in the Public Folder Management Role Group. The Role group method resolves issues of missing ownership of a folder.

In order for Public Folder permissions to be migrated correctly, the users on the Source and Destination must be created and set up and not hidden from the address book. When we migrate permissions for a Public Folder, we attempt to match on three criteria:

• username portion of the source email address to a username on the destination
• direct match of the entire source email address to a user email address on the destination
• display name of the user on the source to a user on the destination
  You can force MigrationWiz to match on the Display Name by adding this command to the Support Options in the Advanced Options: UseDisplayNamePermissionMatching=1

By default, Public Folder permissions are migrated for folders that do not exist.  If folders already exist, permissions are not migrated.

If you would like to force permissions to be migrated when a folder already exists, you will need set the Advanced Option to migrate permissions for New folders and existing folders. Additionally, if you are using Public Folder mapping scripts provided by BitTitan Support, you need to set the option to New folders and existing folders. This setting can be found under Source/Destination in the advanced options of the project.

Rules, such as Assistant Rules, are not migrated with Public Folder migrations. Default and Anonymous permissions are not supported. These will need to be set manually in the destination.

Advanced Options for Public Folder Migrations

Migrating multiple item types

Different projects are not necessary.  The same project can be used when migrating folders containing different item types.

The default behavior for Public Folder migrations is to only migrate items that match the folder type of the Public Folder.

If you have Public Folders that contain item types that do not match the folder type of the Public Folder, such as mail items in a Calendar folder, these can be migrated by adding an Advanced Option to your project.

Steps:

• Click Edit Project.
• Click Advanced Options.
• On the bottom right of your dashboard is the Support section.
• Under Support Options, enter RemoveFilterBasedOnFolderType=1

Security group permissions

Public Folder MigrationWiz projects support an Advanced Option flag to allow Security Groups permissions to be migrated. The Security Groups must already be created in the destination.  When we migrate permissions for a Public Folder, we attempt to match on three criteria:

• Alias portion (to the left of @)of the source SMTP email address to an Alias on the destination
• direct match of the entire source email address to a Security Group email address on the destination

The caveat to enabling this flag to allow Security Groups permissions to be migrated is that any folder that contains a Distribution List will not have any permissions migrated. Therefore, when using this flag, you should either remove Distribution Lists from the Source or filter out the Distribution Lists from the Destination so that they cannot be resolved. The Security Group must not be hidden from the address book.

To set this Advanced Option for a project:

1. Sign in to your MigrationWiz account.
2. Click Go to My Projects.
3. Click on the name of your Project in the list.
4. Click the Edit Project button.
5. Click Advanced Options.
6. Under Support, in the Support options text field, enter AllowAllMailboxTypesForPFPermissions=1 and click on the "+".
7. Click Save Options.
8. Submit your Public Folders for migration.

This support option will not work if SkipImportFolderWhenPublicFolderExists=1 is set under Advanced Options

Migration Speeds

Identical calls to Public Folders tend to be slower than the same identical calls to mailboxes.

This is often a result of the following factors:

1. Size:

Public folders are generally much larger than individual mailboxes.

• Average range for a mailbox is 2 – 10GB.
• Average range for a Public Folder is 10GB – 100GB.

This means that the migration will run for a longer period of time, and that there is more possibility of errors during migration, for the following reasons:

• Simple connection problems
• Maintenance issues
• Other intermittent, infrequent problems

The intermittent problems cause MigrationWiz to focus only on the first part of the data (e.g., the first 25GB) because every time MigrationWiz starts a (Full/Delta Pass) migration, it has to check if any of the items have changed or have not been previously migrated.

This problem can be overcome by adding two project Advanced Options, which will prevent the Full/Delta Pass code from executing on folders that have completed in a previous migration.

These need to be added in the Support section, under Support Options.

The Advanced Options to add are:

• MaintainWatermarkCompletionState=1

• SkipImportFolderWhenPublicFolderExists=1

2. Number of folders retrieved:

There are differences in the structure of Public Folder databases and mailboxes. This results in a lower number of Public Folders being retrieved at a timeThere are limitations on Public Folder EWS calls that do not exist for normal mailboxes.

• When attempting to retrieve the folder structure for a mailbox, you can retrieve all folders at once across the hierarchy. EWS calls are designed this way because mailboxes generally only have hundreds of folders, which is manageable for such calls.
• When retrieving the folder structure for Public Folders, you can only retrieve one level at a time. This is especially troublesome when a Public Folder has thousands (or tens of thousands) of folders, which is not uncommon.

3. Permissions:

The number of permissions being migrated with Public Folders are normally much higher than with mailbox migrations. Permissions have to be retrieved for each folder on both creation and update, unless the Advanced Option has been set to only retrieve them for creation.

• For mailbox migration, we only retrieve and migrate permissions for the well-known folders (Inbox, Sent Items, Deleted Items, etc.). Custom folders do not have permissions migrated.
• For Public Folders, each folder has custom permissions that have to be migrated. This ensures that only trusted users have access to the given folder.
• A separate call, in addition to the call for the initial retrieval of the folders, has to be made to retrieve permissions (i.e., it cannot include permission in the initial list of properties to retrieve). This means that not only do we need to make a call to the Exchange server to retrieve all the folders at the current point in the hierarchy, but we have to make a separate call *per folder* to Exchange to retrieve that folder's current permissions.  Due to the large number of folders, this can significantly increase the initial folder retrieval and migration.  However, this can be skipped by setting the Advanced Option SkipImportFolderWhenPublicFolderExists=1.

If a large number of folders are mail-enabled, this can add time to the migration. The good news here is that this is only ever done on the first pass when a folder is created.

There have been reports that Microsoft throttles Public Folder EWS calls more than EWS calls that go against mailboxes. 

Connections to Public Folders do not seem to be as stable as connections to mailboxes. ​

Estimating Public Folder Size

The simplest way to determine the size of your Source Public Folders is to run a PowerShell query to obtain the size-related statistics from your Public Folders.

Here is an example script that will pipe the results into a file named PFStatistics.csv. You can then use this information to break up your Public Folders into smaller-sized Public Folders. Add up the total item size for all folders to determine the total approximate amount of data being migrated.

Get-PublicFolderStatistics | Select-Object Name, FolderPath, ItemCount, TotalItemSize | Export-csv .\PFStatistics.csv -NoTypeInformation

If your Source is Exchange 2007, and any Public Folders contain more than 20,000 items, these should be broken into multiple Public Folders.

If your Source is Exchange 2010 or later, and any Public Folders contain more than 100,000 items, these should be divided into multiple Public Folders.

The Microsoft TechNet article here provides further detail on Microsoft Public Folder size limitations.

Discovering item quantities

In order to determine the number of mail, calendar and contact items that are in your public folders, you'll need to run the following PowerShell script.

1. This script can be run to count the number of items that exist in all public folders starting at the root.
   Set the execution policy: Set-ExecutionPolicy Unrestricted -Force
2. Retrieve the credentials: $LiveCred = Get-Credential
3. Create and import the PowerShell session for Exchange Online: $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirection Import-PSSession $Session
4. Recursively go through all public folders counting the items:
   Get-PublicFolder -Recurse | Get-PublicFolderItemStatistics | Group-Object -Property ItemType -NoElement
5. End Script.

This will generate output giving the count and item name (IPM.Note for mail, IPM.Contact for contacts, and IPM.Appointment for calendar items).

Mail Enabling Public Folders

If you are using a hybrid scenario for your migration, you may wish to wait until a migration has completed before you mail-enable your Public Folders.

Public Folders can only be mail-enabled through the Exchange Management Shell. This means that only email servers with remote administration enabled can be automatically mail-enabled during Public Folder migration.

For Exchange On-Premises as a Destination, remote administration has to be configured in order to allow for this. 

For Microsoft 365 Exchange Online, remote administration is always on, so Public Folders are always mail-enabled when migrating to Microsoft 365.  If you are not using a Global Administrator account to perform your migration, you will need to make sure that the account being used is a member of either the Organization Management or Recipient Management role group.  More information on these role types can be found in the following TechNet article: Sharing and collaboration permissions​​

Be sure to update your email address policy on the Destination so that email will be delivered to the correct Public Folder. If you do not change your email address policy, the email address for the Public Folders will be created with the .onmicrosoft.com email address by default.

1. Access the projects Advanced Options, and add the support option: DoNotMailEnablePublicFolders=1
2. Perform your migration.
3. Once the migration has completed, access the projects Advanced Options and remove the support option DoNotMailEnablePublicFolders=1
4. Under the Destination settings, change Migrate permissions for to New folders and existing folders.
5. Reset Item statistics for all folders. 
6. Submit another migration pass for all items.

Migrating mail-enabled public folders

By default, MigrationWiz does not migrate any email addresses that are assigned to a mail-enabled public folder. This means that the primary or alternate email addresses assigned to a public folder that is mail-enabled at the source will not be set up properly at the destination. Rather, only the default primary email address is set, which is the name of the public folder (without spaces), plus the default email domain for not having the email address policy set. (for example, myPublicFolder@myDomain.onmicrosoft.com ).

If you wish to also migrate the primary and alias email addresses, use the following PowerShell scripts. The scripts export and import SMTP addresses only:

1. Export the email addresses from all mail-enabled public folders at the source by running the PowerShell script Export-mail-enabled-public-folder-email-addresses.ps1. (Link to script in GitHub.)
2. The resulting CSV file from running the export script will be used by the import script to create the addresses in the destination. Do not change the name of the CSV file.
3. Import the email addresses for all mail-enabled public folders at the destination by running the PowerShell script Import-mail-enable-public-folder-email-addresses.ps1. (Link to script in GitHub.)

Root Level Folders

Root folders vs. Top Level folders

In most organizations, the top few levels of the Public Folder structure are designed with some hierarchy in mind. This is done to organize the information, and also to control the replication of information across the network. Generally, the first few levels are designed with a department or geographic organization. Most Exchange administrators usually lock down the top-level folders to prevent the hierarchy from being corrupted by users. Only users in the following group can create top-level Public Folders: Public Folder Management role group.

The term "top-level folder" can be a little confusing when you look at the view of Public Folders in Outlook. At first glance, a top-level folder appears to be a third-level folder, but this is only because the Exchange Server retains the ownership of certain folders that are created during the installation setup process.

Top-level folders are created under All Public Folders.

Since our licensing is based on either the root folder or the top-level Public Folders, here are some simple examples to make it clear what is considered the root and a top-level folder. 

1) The root folder is the folder below the "Public Folders" entry, but above the top-level folders. In the diagrams below, it is both referred to as "All Public Folders" and 'Default Public Folders'.  In order to add the root Public Folder to your migration, simply enter a single forward slash ("/") and all Public Folders below that will be migrated. If the size of the folders is greater than 10GB, then multiple licenses will be required to complete your migration, and you should set the "Max. licenses to consume per item per pass" to the expected size you will be migrating (e.g., if you are migrating 55GB of Public Folder data, then six licenses will be required).

2) Here is an example screenshot of how Public Folders are displayed from within Outlook:

3) Here is an example screen shot of how Public Folders are displayed from an On-Premises Exchange 2010 Public Folder (lab) server. The top-level Public Folders are circled in yellow. In this example, if you were migrating from the top-level folders, then you would need to purchase Public Folder licenses for each of the folders circled in yellow. If any of them are more than 10GB in size, you need to purchase the necessary number of additional 10GB Public Folder licenses to accommodate for this size. For example, if the jamesb folder is 24GB in size, then three Public Folder licenses are required in order to migrate this.

4) Here is an example of how Public Folders look when using a Hosted Exchange provider. In the example below the xxxxx.com Public Folder would be considered the only top-level Public Folder, since this is how Hosted Exchange providers structure their Public Folders. Therefore, if xxxxx.com folder was less than 10GB in size, you would only need to purchase one license. If the total of all these folders was, say, 54GB, then six Public Folders licenses would need to be purchased in order to migrate all the folders.

Migrating from the root down

1. From your Public Folder project, click on the green Quick Add button, or click the Add menu and select Quick Add.
2. In Root Folder Path enter "/".
3. Click the green Save Item And Close button.

If the size of the folders is greater than 10GB, then multiple licenses will be required to complete your migration and you should set the Maximum licenses to consume per item per pass to the number needed for the expected amount of data you will be migrating (e.g., if you are migrating 55GB of Public Folder data, then 6 licenses will be required). 

Public Folder Licensing

To obtain an estimate of the number of Public Folder migration licenses required for a migration project, you must first download and install the BitTitan SDK. This provides you with two components: the BitTitan PowerShell, and the BitTitan Management Console. The BitTitan Management Console is the component you will be using.

Ensure that you have a MigrationWiz Public Folder migration project created.

Once you have the migration project created:

1. At the Run command, launch the console by typing: bittitan management console.
2. ​At the Select environment prompt, press Enter to accept the default environment, BT (default).
3. In the pop-up window, enter your BitTitan credentials.
4. Select Option 3 - Manage local Exchange Server.
5. Select Option 6 - Export public folder data. This produces output similar to the screen shown in Figure 1, below:
   
   
   Figure 1
   
6. Enter a number that matches the name of the MigrationWiz Public Folder migration project that you created. You will then see a report similar to the one shown in Figure 2 below. The Public Folder license estimate is shown in the area circled in red.

Troubleshooting Public Folder Migrations

Folder path hidden due to trailing spaces

If MigrationWiz fails to locate a Public Folder path that you know exists, the problem may stem from a trailing space in the folder's file path. To discover whether this is the case, run the following PowerShell command. From the Exchange Management Shell on the migration Source computer, run the following:

Get-PublicFolder -Recurse -ResultSize Unlimited | select Identity | Export-Csv -Encoding Unicode Z:\folders.csv​This will identify locations in the Public Folder file path where there may be names with trailing spaces, and will output the information to a CSV file.

Granting access to legacy folders

The Configure legacy on-premises public folders for a hybrid deployment article explains how to configure legacy On-Premises Public Folders for a hybrid deployment.

This is useful in the following scenarios:

• Configuring a hybrid deployment for Microsoft 365 for a temporary reason, and the hybrid configuration will be rolled back at a later date.
• Migration of legacy Public Folders, with a plan to maintain a hybrid environment.

Follow the directions in the TechNet article and complete step 4, where you run this command:

Set-OrganizationConfig -PublicFoldersEnabled Remote -RemotePublicFolderMailboxes PFMailbox1,PFMailbox2,PFMailbox3

"Send As" permissions will not work in this scenario. A workaround is to set up a shared mailbox On-Premises, and then use this shared mailbox as the mailbox for "Send As" permissions.

If migrating the On-Premises Public Folders to Microsoft 365, configure the admin account to look at Microsoft 365 folders by default, while all other users look at On-Premises Public Folders.

Why is this needed? After running the PowerShell script in Step 4 of the TechNet article, the script will configure the organization on Microsoft 365 to use On-Premises Public Folders. By specifying the remote Public Folder mailboxes, the "DefaultPublicFolderMailbox" parameter will be configured on all user mailboxes on Microsoft 365, including the account used for the MigrationWiz migration. If that parameter is configured for the account performing the migration, each time a migration is performed, there will be an error stating that "no Public Folder mailbox was found on the Destination."

Here is an example script to change the DefaultPublicFoldermailbox parameter for the MigrationWiz account:

Set-mailbox –identity migrationwiz@domain.onmicrosoft.com –defaultpublicfoldermailbox 365PFMBX

Change the identity to match the migration account, and change the defaultpublicfoldermailbox to match the Microsoft 365 default Public Folder mailbox.

Migrating Mail Enabled Public Folders in Hybrid Mode

Before performing a public folder migration in a hybrid environment, the steps for setting up mail flow between the source mail-enabled public folders and the destination tenant for coexistence was most likely followed. The steps for setting this up include running a script named “Sync-MailPublicFolders” or “Sync-ModernMailPublicFolders” that enables Exchange Online users to send emails to on-premises mail enabled Public Folders, by creating mail objects in Exchange Online with the primary and all other SMTP addresses that those folders have in the on premises environment.

The Microsoft scripts are useful for coexistence but do not take into account using a migration solution outside of Microsoft tools for migrating public folders. This causes an issue during the migration where we try to mail-enable the Public Folders, and because the mail-enabled attribute already exists in the Destination, the Alias gets a 1 appended to it and the Name gets a random numeric value appended to ensure they are unique in the tenant.

For example, before using MigrationWiz, a mail-enabled folder that was synced prior to migrating using one of the above scripts will create a mail contact in the destination like the following:

Name: Folder A
Alias: FolderA
DisplayName: Folder A

If you use MigrationWiz to migrate the mail-enabled public folder that belongs to the contact in the example above, while it still exists in the destination tenant, the migrated folder will be mail-enabled using the following example format:

Name: Folder A 15701766
Alias: FolderA1
DisplayName: Folder A
PrimarySMTPAddress: FolderA1@domain.onmicrosoft.com

To avoid this behavior, the mail-enabled public folder contacts that exist in the destination must be removed before using MigrationWiz to mail-enable the migrated public folders. It is important to plan a window for this as it will break mail flow until the SMTP addresses have been added back to the newly migrated mail-enabled folders at the destination. We give the steps for removing the mail-enabled contacts below.
Important Note: This article does not replace the Migration Guide for a specific scenario. There are specific steps and settings detailed in the Migration Guides that are not listed here. This article is specifically about handling synced mail-enabled contacts within a Hybrid Public Folder migration.

Removing the synced mail-enabled public folder contacts

If there is a scheduled task to sync the source and destination mail-enabled public folders, it will need to be disabled before removing the contacts from the destination. After this has been completed run the following in a powershell session against the destination:

Get-MailPublicFolder -ResultSize Unlimited | Disable-MailPublicFolder

Once the commands have finished running against the destination, there should be 0 folders returned when running the following:

Get-MailPublicFolder -ResultSize Unlimited

Special Circumstances

Migrations over 20GB

 ​Microsoft 365 has several hard limits for Public Folders.
Although the size limit of Public Folder mailboxes can goes up to 100GB, however, when a Public Folder mailbox gets close to the 20GB size limit, Microsoft 365 will detect this and create another Public Folder mailbox, and then run a rebalancing operation in order to keep the aggregate size of all folders in a given mailbox below its limit. This auto-split operation can take up to two weeks to complete and can block access to the affected public folders.
When migrating data, we add items to Public Folders much faster than Microsoft 365 is expecting them.
In order to avoid triggering the auto-split operation, an operation has to be performed before a migration begins that will properly pre-allocate Public Folders mailboxes to cater for all the migrating data.

If running a Public Folder migration, and there is more than 20GB of data that you are migrating, contact BitTitan Support so that we can generate the PowerShell scripts necessary to properly provision the Public Folder mailboxes, as well as the script necessary to allocate the Public Folders to the correct Public Folder mailboxes to keep the aggregate size below the 20GB limit.

​If this is not done, once the 20GB limit in the primary Public Folder mailbox is reached, it will be necessary to wait for the rebalancing operation (by Microsoft) to complete before continuing the migration, which can take up to two (2) weeks.

Here is the correct sequence of events to follow when performing a Public Folder migration, if the total of the Public Folders is greater than 20GB:

1. Create a Public Folder migration project.
2. Select the Source and enter admin credentials.
3. Select the Destination and enter admin credentials.
4. Specify the Source path for the project.
5. Submit a ticket to Support. In the ticket description notes, add the name of the Public Folder migration project, and specify that the total of the Public Folders is greater than 20GB.
6. Upon receipt, Support will send you a confirmation.
7. Support will then run scripts that will allocate Public Folders to the correct Public Folder mailboxes in order to allow the mailboxes to stay below the 20GB limit. This can take several days to complete. For example, if the total Public Folder size is greater than 100GB, it will likely take more than two (2) days. This script will query the Source environment to calculate the size of each item, the number of items in each folder, etc. 
   Important:  Any new folders created after the Public Folder split is initiated will not be in scope for the migration. 
8. Once the Public Folder mapping script has completed, Support will provide two (2) PowerShell scripts. These will be supplied via the Support ticket system. These must be run by you against the Office 365 environment. Instructions will be included with the scripts. These scripts will complete within a matter of minutes.
9. If running Public Folders in hybrid mode, refer to Why do I get an error when I try to run the Public Folders mapping script? prior to running these scripts; the article will explain the required steps to follow in order to be able to run the scripts successfully.
10. Once complete, the Destination environment will be ready to begin the Public Folder migration.
11. Now log in to MigrationWiz, select the Public Folder project that was previously set up. Then follow the steps in the relevant Public Folder Migration Guide; for example, when the Source is On-Premises Exchange, refer to Exchange 2007+ (Hosted and On-Premises) to Office 365 Migration Guide.

Auto Split

Auto Split is triggered at the 20% threshold for the Primary PF Mailbox, and at 70% for Secondary PF Mailboxes. This is performed earlier against the Primary PF Mailbox to ensure that resources required to master the PF hierarchy are not strained.
PF mailbox size 100 GB - only putting data in the primary PF mailbox – auto-split at 20% - 20 GB
PF mailbox size 100 GB - putting data in the secondary PF mailboxes – auto-split at 70% - 70 GB

Migrating more than 1,000 folders

If migrating more then 1,000 public folders (including sub-folders), it is important to work with BitTitan Support so that the migration can be split up, based on migration points after every 1,000 folders.

Here are the steps to follow:

• Create a Public Folder migration project.
• Select the Source endpoint and enter admin credentials.
• Select the Destination endpoint and enter admin credentials.
• Submit a ticket to BitTitan Support. In the ticket description notes, add the name of the Public Folder migration project, and specify that the Source Public Folders have more than 1,000 folders. The title of ticket should include the following text: "Request to split Public Folder migrations based on child Public Folder count."  In addition, run the following  PowerShell command in your Source Exchange Management Shell (EMS) or Source Microsoft 365 PowerShell environment and include the results of the command, by providing the folders.csv file, generated from running the script, to the ticket:

Get-PublicFolder -Recurse -Resultsize Unlimited | select Identity | Export-Csv -Encoding Unicode C:\folders.csv

• BitTitan Support will then create a new MigrationWiz project on your behalf, and configure the new migration points as needed. 

Further details on what the split process will do:

• It will create a new MigrationWiz project called (project)_SPLIT.
• It will create additional "migration points" in addition to the top-level folders already configured. These are created in Microsoft 365. The extra migration points will assist with processing the migration expeditiously.
• It will count the number of subfolders from the root, and then create a new migration point after every 1,000 folders from the top-level folder.
• It will also configure folder filters. These are used to start and stop the migration points.

Important:

• Any new folders created after the Public Folder split is initiated will not be in scope for the migration.
• The original project will not be affected or changed, and will remain in your list of MigrationWiz projects. However, do not continue the Public Folder migration project from the original project.
• Once the tool is complete, you should run the migration from the new project, and can then delete the original project.