Best practices for public folder preparation before migrations

We wanted to share some best practices to prepare the on-premises public folders for migration to Exchange Online. The document will walk you through the overview of process to migrate public folders to Exchange Online, using the native tools as well as talk about best practices and tools used for trouble free migration.

A quick overview of how the native migration process works follows. The intention here is not to walk through details of each step of native migration, that is already done here and here.

Preparation is the key step, and we will be spending majority of this post on that part, which will ensure you face minimal issues during the actual migration.

As part of preparation you will:

• Find out stale/unwanted public folders and remove them
• Validate existing public folders for known issues and fix any issues found
• Check the size of existing public folders and public folder items and ensure they are not too large
• Create the mapping file and target PF mailboxes

Out of scope of this post: once all the preparation is completed, creation of a migration batch using a mapping file and starting of the migration batch.

Before we dive into the details of preparation, here are some of the highlights of the native migration process:

• There is no option to migrate only some public folders, therefore:
  • You must remove unwanted public folders if you don’t want them to be migrated.
  • If you wish to migrate some public folders to Microsoft 365 Groups, you should do this before you migrate the rest of your public folders to Exchange Online.
• Only one migration batch is allowed – all public folders will be migrated in a single batch.
• Once the migration is completed, no more data from source public folders can be copied over to Exchange Online public folders.
• Maximum of 250,000 public folders can be migrated to Exchange Online.

As the famous quote goes “By failing to prepare, you are preparing to fail”; this applies to public folder migration. Let us now explore detailed steps of preparing the public folders at source.

Cleanup

We need to start with inventory. This is the time to take inventory of public folder deployment at the source. Find out stale public folders out there and decide if those folders are really needed? Do you really need to migrate data that has not been accessed for years?

The following commands show public folders that do not have user activity for last two years:

Exchange 2010:

$date=(Get-date).AddMonths(-24)
Get-PublicFolderStatistics -ResultSize unlimited | ?{$_.LastUserAccessTime -le $date}

Exchange 2013+:

$date=(Get-date).AddMonths(-24)
Get-PublicFolderStatistics -ResultSize unlimited | ?{$_.LastModificationTime -le $date}

Note: LastUserAccessTime is available only in Exchange 2010, not in later versions.

On public folder replicas (legacy public folders)

On a simple side of things, an organization might have a single (or two) public folder databases on two servers, with actual public folder data (replicas of actual content) on both servers. This can then scale to organizations that have 10s of public folders servers with complicated replication strategy.

The best chance of success to have timely migration can be achieved by having as few copies of same public folder data (replicas) as possible. Consider that during the migration stage, users are still using public folders as they currently are. The more replicas of public folder content there are, the more places we have where public folder data can be written to or changed. This then results in public folder replication process between different replicas. Many an Exchange administrator has spent lots of time troubleshooting legacy public folder replication – which can be challenging even if there is no migration going on at the same time!

Our recommendation therefore is to consider that in a large public folder environment, it might be worth it to consolidate / remove some folder replicas and therefore reduce complexity / data churn during the migration finalization stage. Also, you want to make sure that all the public folder databases are mounted (dismounting the database is not a way to try work around this complexity!)

Public folder size and item size

A lot of public folder migrations fail and get delayed because the individual items were too large, or a very large public folder was being migrated.

It is best to:

• Keep the maximum individual public folder size between 15 to 25 GB.
  • Use Export-PublicFolderStatistics.ps1 to get public folder size information. If you have any public folders larger than 25 GB, you should break them up to be less than 25 GB.
  • If you are planning to migrate large public folders, ensure to change the default public folder post limit in Exchange Online.

For public folder items:

The default MaxReceiveSize on public folder mailboxes in Exchange Online is 35MB. You should find out the public folder item sizes at the source. The following command example can help:

$pf=Get-PublicFolder -Recurse -ResultSize unlimited;foreach ($i in $pf) {$s=Get-PublicFolderItemStatistics $i.EntryID;foreach ($r in $s) {if ($r -gt “38600”) {$r.MessageSize,$r.PublicFolderName}}}

If you have public folder items that are large then 35MB, change the MaximumSend/ReceiveSize on target public folder mailboxes, once they are created in Exchange Online.

If public folder items are larger than 150 MB, you must remove these items before migration. See “Message limits” here.

Validate – SourceSideValidation.ps1

The following are major causes for migration slowness or failures, when it comes to public folder data issues:

• Bad ACLs
• Issues related to Mail Enabled Public Folders (MEPF)
• Health of dumpster folders
• Source exceeding limitations (things like folder depth etc.)

The Source Side Validation (SSV) script was developed to analyze the on-premises public folder deployment and report issues found along with providing guidelines to fix them. The script must be run from Exchange 2010 or Exchange 2013+ server, depending on where the public folders are deployed. Use the script before the start of migration process but after you have cleaned up the source environment from folders you do not need to migrate.

To get the script to perform all the checks:

.SourceSideValidations.ps1

To get the script to perform only public folder permission related validations:

.SourceSideValidations.ps1 -VerifyMEPF $false -VerifyDumpsterMapping $false -CheckLimits $false -CheckPermissions $true

Mail enabled public folders (MEPF)

The following are common issues encountered during migration of MEPFs:

• Orphaned MEPFs
• Non_Ipm_Subtree public folder is mail enabled

The .ValidateMailEnabledPublicFolders.ps1 script will help you find such MEPFs and provide you readily usable output to fix such MEPFs.

Target public folder mailboxes

Planning how many public folder mailboxes you need in Exchange Online is a critical task as well. You don’t want to create a ton of unnecessary public folder mailboxes and at the same time you don’t want to overload each target mailbox so that it might fill up during the migration (or soon after).

Some guidelines to remember:

• Do not place any content in the primary hierarchy mailbox, nor point any users directly to this mailbox. You can read more about public folder deployment best practices here.
• Plan to fill up to 50% of maximum allowed size of PF mailboxes during migration. Current maximum size of PF mailbox is 100GB. So, the “Total public folder size at source in GB”/50 should give you an idea of how many public folder mailboxes you need in Exchange Online.

So, for example, if you have 2 TB (2000 GB) of public folder data at source, you will need around 40 public folder mailboxes in Exchange Online.

The .ModernPublicFolderToMailboxMapGenerator.ps1 file can help you get idea of how many PF mailboxes are required in Exchange Online and also provides you the mapping file.

Mapping file

The Mailbox Replication Service uses the mapping file to place source public folders into specific target public folder mailboxes. The following are some guidelines on well-defined mapping file:

 

• Ensure the primary hierarchy mailbox is mapped to the root folder “”
• If you wish to place specific folder into a specific public folder mailbox, add the entry exclusively
• Once the entry is added, the folder and subfolders below it will be migrated to the target mailbox specified
• Ensure each folder that is present directly on the root has explicit mapping in the file and is mapped to a non-primary hierarchy public folder mailbox; this ensures the primary hierarchy mailbox serves only hierarchy
• Finally, ensure the target public folder mailbox names are correct

Connectivity

Migrations can fail or produce unexpected results if connectivity to source server is unreliable.

Migration from Exchange Server 2010 works using Outlook Anywhere (RPC/HTTP), even if you have Exchange Server 2013 (or higher) acting as a FrontEnd server.

It is best to ensure the service account being used to migrate public folders can access Exchange 2010 public folders from the internet using Outlook for desktop client or Microsoft Remote Connectivity Analyzer.

You can use the Test-MigrationServerAvailability command to ensure connectivity.

If your environment uses a load balancer, it is best not to use the load balancer for MRS related traffic as this is handled by EWS and the MRSProxyEnabled property on that Virtual Directory.

Finally, if you have a firewall with very stringent inbound connectivity, ensure that Exchange Online IP addresses are whitelisted.

Changing the default quota in Exchange Online

The default prohibit post quota to public folders in Exchange Online is 2GB. The migration may not fail if your individual public folders are larger than this size, but users might not be able to post or email items to public folders as soon as the migration is complete.

The default quota can be changed at organization level:

Set-OrganizationConfig –DefaultPublicFolderProhibitPostQuota 25GB -DefaultPublicFolderIssueWarningQuota 20GB

Note: Do not set the default quota above 25 GB as it may result in giant public folders, which might cause issues with the auto-split process in the future. You can read more about auto-split feature here.

Also by default, the MaxReceiveSize and MaxSendSize on public folder mailbox is configured at 35MB. You must increase this limit to accommodate largest public folder items from on-premises:

Set-Mailbox -PublicFolder -MaxReceiveSize 50MB -MaxSendSize 150MB 

ExcludeDumpsters

The deleted public folders are stored under Non_IPM_Subtree, also affectionately referred to as the Dumpster.

Excluding this data can help you scale your public folder migration if you do not need the data to come over. This will result in faster public folder migration as the amount of data that will need to be migrated is going to be smaller. In some cases, corrupted dumpster folders can cause migration to fail.

Migration of public folders in dumpsters can be skipped using ExcludeDumpsters parameter.

This option is available only for migrations from Exchange Server 2013+ to Exchange Online and must be specified at the time of batch creation.

Example:

New-MigrationBatch -Name PublicFolderMigration -CSVData <mapping file> -SourceEndpoint $PfEndpoint.Identity -SourcePfPrimaryMailboxGuid <GUID> -ExcludeDumpsters

That’s it!

The goal of this article was to ensure the source is prepared for a successful and hassle-free migration. Once you are done with preparation, we recommend you follow each of the migration steps from here for a trouble-free migration experience.

Bhalchandra Atre