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:
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:
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.
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 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!)
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:
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.
Please check if any of source public folders have MaxItemSize configured:
By default, MaxItemSize is set to unlimited on individual public folders. However, if MaxItemSize is configured on individual public folder(s) and if the public folder has items larger than this size, the migration will fail.
Use the following command to identify if any individual public folder has MaxItemSize configured:
Get-PublicFolder \ -Recurse | where {$_.MaxItemSize -ne "Unlimited"}| FT Identity, MaxItemSize
Then, the use following command to change the MaxItemSize to Unlimited:
Set-PublicFolder <\PF1> – MaxItemSize Unlimited
OR
Get-PublicFolder \ -Recurse | where {$_.MaxItemSize -ne "Unlimited"} | Set-PublicFolder –MaxItemSize Unlimited
The following are major causes for migration slowness or failures, when it comes to public folder data issues:
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
The following are common issues encountered during migration of MEPFs:
The .\ValidateMailEnabledPublicFolders.ps1 script will help you find such MEPFs and provide you readily usable output to fix such MEPFs.
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:
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.
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:
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.
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
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.