Legacy Public Folders to Exchange 2013 migration tips
A couple of weeks ago I performed a Public Folder migration from Exchange 2007 (aka legacy) towards the modern Public Folders of Exchange 2013. As you may know, the traditional migration method using Public Folder replica's isn't available due to a radical redesign of the Public Folder architecture. Instead of dedicated databases, the hierarchy and data are now stored in mailboxes. The biggest benefit is that Public Folders can now be protected via a Database Availability Group, the downside is that the multi-master model is now defunct as only one DB copy can be active one server in one location.
The radical redesign also means that the migration process is vastly different. Microsoft has done it's best to describe the process via this article. However, as always, there are some gotchas you might encounter along the way. While I was in the process of migrating, I tweeted my progress using the hashtag #PFMigrationWatch. This post is for on-premises deployments/migrations, although some tips might be valueable in either cases.
But let’s take a look at the required steps (the numbers correspond with the numbers from the article) and I’ll add some helpful tips not mentioned in the article:
- Download the scripts.Well, that’s easy. You have to have the scripts on a legacy server (i.e. 2007 or 2010) and the 2013 server. Some you will use on the legacy servers, other only on the Exchange 2013 servers.
- Export the current structure, statistics and permissions of the legacy public folders in order to verify the migration. Perform this on a legacy server.If you had plans to clean up you Public Folders, do this beforehand! Or use the provided information, but rerun these scripts again after clean up. Furthermore, these can take a long while to complete, depending on the amount of public folders and customization. Better plan this some time before the actual migration, but not too long as the organization might require changes that won’t be recorded. You could inform the organization that a feature freeze has occurred and temporarily change some permissions. Discuss this with the organization.
Next to inventory important PF information, you should also check on trailing spaces or backlashes in the Public Folder names and remove them. Otherwise the migration might not start or fail.
As a final check, look whether there has been a migration request submitted already or if there are already Public Folders present on the Exchange 2013 server. If the latter is the case, you have to remove them (probably best to save the information, unless it’s clear it can be deleted without issue).
Remember; if you have multiple Public Folder databases, wait for replication of all changes before moving forward. - Generate CSV filesNow you will create CSV files that will determine the distribution of your Public Folders within the Public Folder Mailboxes. The first script (Export-PublicFolderStatistics.ps1) will create an inventory on how large each folder is. The second script (PublicFolderToMailboxMapGenerator.ps1) determines which folder will be located in which mailbox, based on the CSV output of the previous script. This is presented in the mapping file, it basically says which folder and/or subfolders are placed in which public folder mailbox. How it is distributed will be dependent on the maximum mailbox size you will enter. It is possible that a main folder is in Mailbox1 and some of the subfolders in Mailbox2. User won’t notice this, as Exchange will present the whole hierarchy as if it were in one location.
Please note the Public Folder limits, you can find the most recent limits here. For this particular step the follow limit is important: each Public Folder mailbox must not exceed 100GB (soft limit), but to allow growth be sure to enter a lower number. With this particular migration I had 5 databases, so I divided the total amount of Public Folder storage by 5 (the number of databases) in order to get a nice distributed scenario with each database containing a Public Folder Mailbox. In this case it left more than enough growth for each mailbox.
Unfortunately, it seems as if some of the limits of Modern Public Folders are lower than what has been expected. Although Microsoft has announced upcoming increases of limits, do check for them before going forward and take action when required. It might be necessary to clean up even more and redo steps 2 and 3. - Creating Public Folder Mailboxes in Exchange 2013. Perform this on an Exchange 2013 server.This is quite simple, just remember to use the same mailbox name as what is used in the mapping file from the previous step. You can change the names in the mapping file if required, as long as they correspond with the names you use in this step.
Remember to create the mailboxes in the correct database or move the mailbox afterwards. Furthermore, don’t forget to set adequate mailbox quota’s. If you do not, the Public Folder mailboxes will default to the database quota settings which are probably a lot less than required for Public Folders. If you do not set it correctly, users possibly cannot edit/add items and mail will possibly be bounced. Luckily the migration will continue and will be completed, even if the quota has been reached during this process. - Start the Migration requestThis is the first initial synchronization of the hierarchy and data from legacy to modern public folders. Users will still be able to access legacy public folders (also from 2013 mailboxes).
Be sure to monitor the progress regularly, there are several reasons a request might fail. Too many bad items, for instance. Or too large items, which would result in the error code TooManyLargeItemsPermanentException. You can monitor the request with:Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport
If you forgot to configure those values at the start, don’t panic. Just change the request and add the parameters afterwards (with Set-PublicFolderMigrationRequest using the identity of the existing but suspended/failed request) and then rerun the same migration request again (by Resume-PublicFolderMigrationRequest). Note that setting/raising the BadItemLimit or LargeItemLimit still doesn’t force migrate those items, but it means the request will continue despite encountering issues (which are skipped). Check the report of the migration request to see which items are affected. Especially with large items, I tend to copy them out of the legacy public folder for safe keeping. You could check whether the TransportConfig MaxReceive size setting is something you want to adjust to a higher value, but I hadn't had the need in this particular case.
- Lock down legacy Public FoldersNow the real migration begins! When the legacy Public Folders are locked, no one can access Public Folders legacy or modern. User might experience credentials pop-ups in Outlook. So, this is something for a maintenance window and requires informing you users.
Furthermore, mail-enabled folders won’t receive mail anymore. That mail will be queued and delivered when the migration will be finalized. So, keep an eye on those queues and the amount free disk space of the legacy servers! - Finalize migrationImmediately after locking down the folders, you can finalize the migration. How long this will take depends on the amount of changes since the initial replication that have to be migrate. You can perform delta synchronizations (as long as the migration request parameter PreventionCompletion is $true) with:
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration
This is ideal if you want to prepare the Public Folder migration a relatively long time ahead of the actual migration, while keeping the finalization time to a minimum. Especially with large and/or highly active Public Folder implementations this is a way to keep downtime to a minimum.
- Test and unlock modern Public FoldersSo, now everything is over, data, permissions and whether a folder is mail enabled (and thus mail addresses) are all migrated. And yes, the mail flow for mail-enabled folder is immediately active after the migration has been finalized in step 7 (that means mail flow from your legacy mail servers to Exchange 2013 should’ve been working before finalizing).
You can now check whether everything has been migrated properly, perhaps using the exports made in step 1. You might want to consider letting some key users test it. Before unlocking it for the organization, you can unlock the modern Public Folder on a per mailbox basis. Do note that any changes (don’t forget mail enabled Public Folders!) aren’t replicated back to legacy folders, take that in mind if you require a rollback.
So that’s it. It’s not a completely painless operation, but the Microsoft article is clear and adequate even if it’s missing some tips I’ve mentioned. In some regards I feel as if I have more control compared to the legacy Public Folder replication. 
Let me know if you have additional tips!