Migrating Public Folders to Exchange 2016



In this article we will go through the steps to migrate public folders from Exchange 2010 to Exchange 2016.  Keep in mind this same process works for migrating to Exchange 2013 as well, the steps are identical.

Change In Architecture

Let’s start first with the changes in the public folder setup that began in 2013, what Microsoft calls “Modern Public Folders”.  Legacy Public Folders, or public folders from a version of Exchange previous to 2013 went largely unchanged.  There were public folder databases that were stored on a mailbox server.  To provide high availability and redundancy, you could create public folder databases on multiple mailbox servers.  Then, on a per folder basis establish replica’s of that folder so that copies were on more than one server.

Anyone that has dealt with legacy public folder replication issues can tell you the process is not that fun to troubleshoot.  It’s also not exact, as the quickest the folders can replicate is 15 minutes.  This can certainly cause issues if you have a group of users collaborating and they are each connected to a separate copy of the public folder data, there can be delays or collisions in the data sets.  Also, public folder databases could not be protected in a DAG, so they were not able to benefit from the same availability designs as normal mailboxes.

Exchange 2013 change the architecture so that public folder data is now stored in mailbox’s designated as “Public Folder Mailboxes” instead of using dedicated public folder databases.  The benefit of this model was that public folders could not be placed into normal user mailbox databases, which would mean they not benefit from the DAG architecture.  Also, there is now only one writeable copy of the folder, so data integrity is more accurate. 

This means that there is a migration process that must occur from the legacy public folders to the modern public folders.  What we will aim to do in this article is highlight how we do that migration, and also how the user connections to the modern public folder changes as well.

For this article we will leverage a simple two server architecture.

PHDC-SOAEXC01 – 2010 Multirole Server hosting Legacy Public Folders

PHDC-SOAE16MBX2 – 2016 Server that will host the mailbox databases that will contain the Modern Public Folders

Download the Migration Scripts

First we need to download the pre-built migration scripts from Microsoft.  Download them to C:\PFMigration on both your legacy public folder server, and your 2013 Mailbox Server


Run Export Commands for Reference:

On the Legacy Public Folder Server, run the following commands:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

This will allow you to backup the folder structure, statistics and the client permissions for reference.  This will be useful if you find your migration does not go well and you need to reference how things looked before the migration.

Check Folder Names

We need to check if any folder in the hierarchy has a backslash “\” in its name.  If it does, it will cause the migration to inadvertently place that folder in the root.  For example, if we had a folder named named “P/E Assets” that was a subfolder of the top level folder “Departments”, the migration would cause the P/E Assets folder to be placed in the root directory alongside Departments instead of under it.  To check, run the following command on the Legacy Public Folder Server:

Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Manually rename any folder found here to something without the backslash character.

Generate CSV Files

Next, we need to use the downloaded scripts from Microsoft to generate two CSV files.  The first one will be PublicFolderStatistics.CSV.  This will simply list all of the folders and their respective sizes.

In the Exchange Management Shell on the Legacy Public Folder server, navigate to the C:\PFMigration folder and run the below command:

.\Export-PublicFolderStatistics.ps1  c:\PFMigration\PFFolderStatistics.csv legacyservername

Replace LegacyServerName with the name of your legacy public folder server, such as:


The script will output the number of folders and their statistics to a CSV file, like below:


It will list the path, and the folder size on the right hand side.

The second script we run, is the Mailbox Mapping script.  What this does is take the PFFolderStatistics.csv file as an input, and also the max size you want a public folder mailbox to be as an input and tells you how many Public Folder Mailboxes you need, and what their names should be.

For instance, in our environment, we don’t want any Public Folder mailbox to be over 1 GB in size.  So we run the following command:

.\PublicFolderToMailboxMapGenerator.ps1 1073741824 c:\PFMigration\PFFolderStatistics.csv c:\PFMigration\PFMailboxMapping.csv

The first input is the max size of each Public Folder Mailbox in bytes.  That is our 1073741824 value.  Note that we are doing this in a lab and in real applications, you want your Public Folder mailbox max size to be something larger.  The next input is the path to our PFFolderStatistics.csv file we generated above.  Finally, we put the path that the script should output our PFMailboxMapping.csv file to.  Running this command looks like the following:


Note that if your Max Public Folder Mailbox size is smaller than the any one folder in and of itself this script will return an error.  Simply increase the max size until the error stops appearing.

The CSV file will look like the following:


Notice the left hand side is the folder paths, and on the right hand side is the corresponding Public Folder Mailbox that they will be migrated into.  The script uses generic names, so we can see, its lists Mailbox1 through Mailbox10.  This means I need at least 10 Public Folder Mailboxes for this migration.

Also to note, the names of the Public Folder Mailboxes are important.  If we leave the CSV file as is, our Public Folder Mailbox name has to match these.  In our case, we want to change our structure.  We want the following Public Folder Mailboxes:











Note that the first Public Folder Mailbox created will be known as the root public folder mailbox and will be the mailbox responsible for keeping the hiearchy.  The rest will replicate the hiearchy from this mailbox, but are available for data to be stored in.  Since we are changing the names, we need to manually edit the CSV file to reflect that.  Note that the root public folder mailbox must be assigned to the folder “\”.

After editing our CSV file looks like this:


Create the Public Folder Mailboxes

On the Exchange 2016 server, create the public folder mailboxes, ensuring they have the same name as in the CSV file:

New-Mailbox PublicFolder-RootMailbox -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-1 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-2 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-3 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-4 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-5 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-6 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-7 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-8 -PublicFolder -HoldForMigration
New-Mailbox PublicFolder-NY-9 -PublicFolder -HoldForMigration

This is important, ensure that you have an Email address policy that applies to the public folder mailboxes.  If they do not receive an email address, the migration will fail, but also users wont be able to connect to them later on.  We’ll explain why.

Start the Migration:

Copy the contents of C:\PFMigration to the same location on your Exchange 2016 server.  From an Exchange Management Shell, run the following command:

New-MigrationBatch -Name PFMigration -SourcePublicFolderDatabase (Get-PublicFolderDatabase -Server LegacyServerName) -CSVData (Get-Content C:\PFMigration\PFMailboxMapping.csv -Encoding Byte) -NotificationEmails youremail@comapny.com -BadItemLimit 1000 

Replace LegacyServerName with the hostname of your 2010 Public Folder server, and youremail@company.com with the email address of who should get notified when the migration is done.  The command in our set up looks like this:


Next, we can start it from the command line with:

Start-MigrationBatch PFMigration


Of by logging into ECP and starting it from there:


Now we wait for the Migration to get to the status of “Synced” and then we are ready to look at doing the final cutover.  Notice there is a migration for each public folder mailbox, in our case a total of 10.  

Also remember that Migration Batch’s will do incremental sync’s every 24 hours so you can start the initial sync in advanced and let the system sync up every 24 hours.

Lock Down Migration (Downtime Starts!)

The start of this next section is when the users will no longer be able to connect to Public Folders through Outlook.  They will receive an error if they try to expand the public folder section in outlook.

Once the migration reaches a status of Synced your ready for the next step:


Run the following command to lock the public folders for migration, this needs to be run on the Legacy Exchange Server:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true


If you have multiple Legacy Exchange Servers, this can take some time to complete.  During this time, all emails destined for Mail Enabled Public folders will queue until the migration is completed.

Next you need to run the following commands to complete the Public Folder sync.  Note this will not yet release the folders for the end users:

Set-OrganizationConfig -PublicFoldersEnabled Remote
Complete-MigrationBatch PFMigration


Or you can complete the MigrationBatch in the GUI:



Testing the Folder Hierarchy

Once the migration completes, you can unlock the hierarchy for a test user, just to validate the folder structure is there:

Set-Mailbox -Identity pponzeka@accessabac.us -DefaultPublicFolderMailbox PublicFolder-RootMailbox


If the folder structure looks good and your ready to unlock for everyone, run the below set of commands:

Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
Set-OrganizationConfig -PublicFolderMigrationComplete:$true
Set-OrganizationConfig -PublicFoldersEnabled Local


Modern Public Folder Connectivity

This brings us to an important part of the process, discussing the connectivity changes for Modern Public Folders.  In previous versions of Exchange, an outlook client made a direct connection to the Public Folder Server.  Your connection logic was handled by the Exchange Server that accepted your connection for your mailbox, informing you of how to connect to public folders.  Well, starting with Exchange 2013 all traffic was forced through either Outlook Anywhere or MAPI/HTTP.  With Modern Public Folders, all connections to public folders, since they are essentially mailboxes, are handled just like a users mailbox, through autodiscover!

Taking our example public folder mailboxes from above:


Notice how they each have an email address of @accessabac.us.  Now lets say that we have a user, and their email address is PPonzeka@Mailbox.com.  When this user connects to their mailbox, their Outlook will actually perform two autodiscover requests.  One to the mailbox.com domain, and the second to the accessabac.us domain.  This is why you need to ensure the public folder mailboxes have a valid SMTP address, but also that you have valid autodiscover records for that domain.  Remember, if you set the email address to something internal, external users will not be able to access public folders!

If we use the Test Email Auto Configuration tools on our Outlook and check the XML value we will see the public folder mailbox that we our getting in our autodiscover response to connect to: