Public Folder Migration FAQ

Root vs. top-level 

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. Note: 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. 

The root folder is the folder below the "Public Folders" entry, but above the top-level 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).

To manually add a folder:

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.

 

Migrating from the root level 

  1. From your Public Folder project, click on the green Quick Add button, or click on 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). How do I enable consumption of multiple licenses for a single item? provides more information on how to set this.

There are specific settings needed for Public Folder migrations. We have migration guides available for most migration scenarios. You can select the guide for your migration from all the Public Folder Migration Guides here: Public Folder Migration Guides.

 

Migrate multiple 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.

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

This option only allows the migration of mail items into a non-Mail folder; calendar and contact items cannot be migrated to Mail folders.

Only items that EWS understands will be migrated, i.e., email, contacts, appointments.

If a non-mailbox item has been directly added to the Public Folder, such as an Excel spreadsheet, that item will not be migrated, even when using this Advanced Option, because EWS does not understand that item type.

Email with attachments, like Excel spreadsheets or Word documents, will get migrated.

EWS refers to Exchange Web Services. This is the protocol that is used by MigrationWiz to communicate with Exchange 2007+ in order to perform migrations.

 

Locate hidden path

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 Exchange Management Shell on the migration Source computer: 

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.

 

Source and Destination type 

Yes. 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 EWS or Outlook, and not within the Exchange Admin Center or through PowerShell or through OWA.

 

Supported Scenarios

Public Folders can be migrated into other Public Folders or shared mailboxes.

You cannot migrate any Source other than a Public Folder, into a Public Folder.

Also, the only Source email system that is supported for MigrationWiz Public Folder migrations by MigrationWiz is On-Premises Exchange or Exchange Online (Office 365). No other Source can be used during Public Folder migration, such as G Suite, Zimbra, or even an Exchange mailbox.

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

​Exchange 2007.

Exchange 2010.

Exchange 2013.

Exchange 2016.

Office 365 Exchange Online.​

We do not currently support migrating Public Folders from Exchange 2003.

 

Administrator account permissions

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

For further details, read this article about creating an administrator account for login.

Note: Once you have created an account with administrative credentials, you will also need to set full permissions for Public Folders explicitly for the administrator.

Exchange 2007 and Exchange 2010:

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:

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

Exchange 2013:

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

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.

 

'Organization Management' rights

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:

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

​Via PowerShell:

  1. The PowerShell command to add this is:

    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.

 

Migrate Public Folder 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. 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
Note: you can force MigrationWiz to match on the Display Name by adding this command to the Support Options in the Advanced Options: UseDisplayNamePermissionMatching=1

Note: 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.

Rules, such as Assistant Rules, are not migrated with Public Folder migrations.

Access legacy On-Premises 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 Office 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

Note: "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 Office 365, configure the admin account to look at Office 365 folders by default, while all other users look at On-Premises Public Folders.

After running the PowerShell script in Step 4 of the TechNet article, the script will configure the organization on Office 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 Office 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

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

 

 

Security Groups permission migration

Public Folder MigrationWiz projects support an Advanced Option flag to allow Security Groups permissions to be migrated.


Note: 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.

To set this Advanced Option for a project:

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

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

 

Destination Exchange 2010: lost timestamps

This is a Microsoft code defect in Exchange 2010. Because of the code defect, MigrationWiz cannot preserve the correct timestamps for any item in a Public Folder when the Destination is Exchange 2010.

MigrationWiz will instead replace the creation date timestamp with a timestamp showing the date of migration.

Note: This Microsoft code defect only comes into effect when the Destination for a Public Folder migration is Microsoft Exchange 2010.

 

Mail-enable Public Folders

​In order to automatically mail-enable Public Folders, the migrating user must be an Exchange Administrator.

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.

Mail-enable Public Folders for use at a later time

For Office 365 Exchange Online, remote administration is always on, so Public Folders are always mail-enabled when migrating to Office 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​​

Note: 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.

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.

  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.

 

Migrate 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. There are two options for this process. We give the steps for removing the mail-enabled contacts and steps for both migration options 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.

Migration Option 1

Remove the mail-enabled contacts from the destination before migrating and mail-enabling public folders. This option is best suited for smaller migrations.

Remove the mail-enabled public folder contacts from the destination. 

Perform the migration using MigrationWiz as described in the appropriate Migration Guide. This will mail-enable the migrated public folders at the destination.
Note: The SMTP addresses will not be migrated, the only address assigned to the mail-enabled folders will be the default @domain.onmicrosoft.com address.

Export and import the SMTP addresses using the steps outlined in the following KB: Migrating mail-enabled Public Folder email addresses.

Migration Option 2

Remove the mail-enabled contacts from the destination after migrating and perform an additional pass to mail-enable the migrated public folders. This option is best suited for larger migrations, or for migrations with a higher mail-enabled folder count.

  1. Perform the migration using MigrationWiz as described in the appropriate Migration Guide.
  2. When setting up the first pass Advanced Options, add in the advanced support option DoNotMailEnablePublicFolders=1 to skip mail-enabling of public folders at the destination during the migration.
  3. Click Edit Project.
  4. Select Advanced Options.
  5. Under Support Options add: DoNotMailEnablePublicFolders=1
  6. Before running the Security Pass, remove the mail-enabled public folder contacts from the destination. Specific steps can be found below.
  7. Remove the advanced support option DoNotMailEnablePublicFolders=1 from the project.
  8. Reset the item statistics for the project using the steps outlined in the following KB: How do I reset statistics for my item(s)?
  9. Perform an additional full migration pass to mail-enable the migrated folders. (Note: The SMTP addresses will not be migrated, the only address assigned to the mail-enabled folders will be the default @domain.onmicrosoft.com address)
  10. Export and import the SMTP addresses using the steps outlined in the following KB: Migrating mail-enabled Public Folder email addresses.
  11. 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 | Remove-SyncMailPublicFolder

If the above commands do not work, the following commands can also be used:

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

 

Migrating to Shared Mailboxes

The following Destinations are supported for Public Folder migration projects:

  • Public Folders
  • Shared Mailboxes

If migrating to Public Folders, then the steps in the relevant Public Folder migration guide should be followed. If migrating to Shared Mailboxes, then the steps in the relevant Public Folder migration guide should still be followed. However, the "Prepare Destination Environment" steps will be different. The Shared Mailbox will need to be created on the Destination, prior to migration. The steps to create these are defined in the following TechNet article here.

If migrating to a Shared Mailbox, the admin account being used for the migration must have a valid mailbox, an assigned license for that mailbox, and full access permissions to the shared mailbox.

When migrating to Shared Mailboxes, the MigrationWiz project Advanced Option for Destination Settings needs to be changed to Shared Mailbox, from the default setting of Public Folder as shown in the screenshot below:

In addition, in order to migrate Public Folder permissions to a shared mailbox, this Advanced Option must be added: MustMigrateAllPermissions=1. This Advanced Option allows you to migrate all folder permissions, not only the system folders when migrating from Exchange 2010+ mailboxes where, by default, only systems folder permissions are migrated. A Public Folder to shared mailbox migration can also be used to migrate the permissions.

 

Shared Mailboxes on Office 365 have a mailbox size limit of 50GB. Therefore, if the Source Public Folders are larger than 50GB, then a prerequisite to migration will be to split up the Source Public Folder structure into smaller Public Folders, create the necessary number of Shared Mailboxes on the Destination, and then add the Public Folders into the MigrationWiz project.

When adding the Public Folders to your project, both the Source root folder and the Destination email address of the Shared Mailbox will need to be set.

 

Find the size of source folders

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.

 

Migration >20GB to Office 365

 ​Office 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, Office 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 Office 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 by following the directions in How do I get support for your products?. 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.

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. 

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.

Once complete, the Destination environment will be ready to begin the Public Folder migration.

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.

 

Public Folder 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:

  • 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
  • Number of folders
  • Permissions
  • Other intermittent, infrequent problems

Intermittent 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

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 time. There 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.

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. 

 

 

 

Was this article helpful?
0 out of 0 found this helpful