posts - 104 , comments - 115 , trackbacks - 0

Exchange 2013: Public Folder Migrations

A little history…

For years Microsoft have been saying it would do away with public folders and for years administrators have been hoping it was true. Being introduced for the very first time in the very first version of Exchange they only became increasingly more complex in their usage patterns over the years causing anything from a mild headache to heart rhythm disorders.

So when Microsoft announced that with Exchange 2007 the public folders would discontinued in future products a collective sigh of relief reverberated through all who had dealings with public folders in one form or another.

And then reality struck us all, if public folders were going to go away, where would the business store the data that was present in public folders?! The obvious Microsoft answer was Sharepoint. Unfortunately there was no clear migration path to SharePoint from public folders.

So with no easy migration path and quite a large pushback from its customer base Microsoft was forced to keep Public Folders. Yet it was not possible to keep it in the form we all knew it in the Exchange 2010 and earlier releases. Northing much had changed since its first release and the new high availability features in Exchange 2007 (and 2010!) caused some "compatibility" issues.

Public folders are dead! Long live public folders!

Modern Public Folders are still Public Folders for the end users in the organization, yet in the backend things have changed quite a bit. The public folders are now contained in a new kind of mailbox and no longer require a dedicated database or a "special" replication mechanism for the data. It is now possible to take full advantage of the database availability group for high availability of the service, and the data.

In our legacy versions we were dependent on Multi-Master replication for high availability, with our DAG model we now only have one master and no longer have to worry about which public folder holds the most up to date version of its content. The downside of this is that we have only one master and Public Folder deployments now require more planning, for if you do not plan correctly, the consequences could be very grave indeed!

Two types of mailboxes

We have to distinguish between two different kinds of mailboxes in our modern public folders implementation. Hierarchy and content mailboxes.

A Hierarchy mailbox, as you would suspect, contain the hierarchy for the Public Folder deployment and there can be only one (usually the first mailbox you would create).

Of content mailboxes there can be as many as you require, and they will store secondary (read-only) copies of the Hierarchy. Make no mistake, that first mailbox (the hierarchy one!) can also contain content, it's just that this mailbox will have the only writable version of the Public Folder hierarchy!


The process

When we are looking at migrating public folders from legacy servers to the 2013 version there are a few things we need to know.

  1. There can be no coexistence: Quite literally, you are either hosting the Public Folders on the Modern (2013) version or on the legacy systems.
  2. Any mailbox hosted on the legacy systems cannot access Modern Public Folders. That's right, once you migrate your Public Folders they will only be available for users hosted on the Exchange 2013 servers. That means our public folder migration needs to wait until all the users have been moved over.
  3. There is downtime involved with migration: Because the process features a cutover where the public folders are not available you'll need to schedule some downtime for it to complete.

i - The stages of a migration from Legacy to Modern Public folders

Before you begin

You must be assigned the following permissions before you can perform this procedure:

  • In Exchange 2013, you must be a member of the Organization Management role group. For details, see Manage Role Groups.
  • In Exchange 2010, you must be a member of the Organization Management or Server Management role groups. For details, see Add Members to a Role Group.
  • In Exchange 2007, you need to be assigned the Exchange Organization Administrator role or the Exchange Server Administrator role. In addition, you must be assigned the Public Folder Administrator role and local Administrators group for the target server. For details, see How to Add a User or Group to an Administrator Role.
  • Download the migration scripts at:



In the mapping stage will perform a snap shot of the existing Public Folder environment and verify the prerequisites to starting the migration are in order. We take the snapshot so that, once our migration has been completed, we can verify the structure came across without issue.

Performing the snapshot

In order to get a snapshot of our legacy public folder the following command should be run:

    Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml

For a snapshot of the statistics, like item count, size, and owner this command should be run:

Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml

And lastly, to perform a snapshot of the permissions in place the following command should be run:

Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights


Before starting the process it is always a good plan to check if anyone attempted a public folder migration before:


Verifying no public folders exist on the exchange 2013 environment:

Get-Mailbox -PublicFolder

Generating the mapping files

This is where you'll need those scripts downloaded earlier. You'll need a copy on a legacy folder and on an Exchange 2013 server. We need to, firstly, generate a statistics file so that we have an output of the legacy public folders:


This will generate a file which we need to feed in to another script so the correct number of public folder mailbox can be created, as well as mapping that the right folder gets mapped to the mailbox.


If required you can open up "PFMap.csv" to change which folder maps to which mailbox and to change the mailbox names. This last one is something I personally do as I like my mailboxes to start with "PF".

This is what the output of our last script looks like. I changed all the mailbox names to "PFMailbox??" and placed the hierarchy mailbox in "PFHierarchy". If you decide to replace the names using "Find/Replace" make sure you fix the error I created here with "TargetMailbox" becoming "TargetPFMBX0"…

Creating the Mailboxes

The first mailbox (the Hierarchy mailbox!) needs to be created with the "HoldForMigration" parameter set to "$True". This parameter prevents any client or user to log on to the public folder mailbox, except for the Microsoft Exchange MRS process which is responsible for moving mailboxes. This action needs to be performed on the Exchange 2013 server as any legacy version would have no clue what these parameters mean:

New-Mailbox -PublicFolder -HoldForMigration:$true

The next step is to go and create all the other mailboxes which are required. As I don't like repetitive manual actions I use the following PowerShell code:

$MBXs = import-csv .\PFMap.csv


Foreach ($i in $MBXs){

        If ($i.targetMailbox -eq "PFHierarchy"){

            new-mailbox -publicfolder $i.targetMailbox -holdforMigration:$true


            new-mailbox -publicfolder $i.targetMailbox



Both items marked in bold need to be changed to reflect your own deployment. .\PFMAP.csv should be the path to the PFMap file you created with the PublicFolderToMailboxMapGenerator.ps1 script. "PFHierarchy" refers to the name of your first mailbox. Theoretically you could create all mailboxes with the "holdformigration" parameter set for true but this would cause extra manual actions to be required near the end of the migration.

Seeding the mailboxes

Our next action is a nifty one. We will start populating the data in the Modern Public folders so less time is required during our cutover process, which must be run on an Exchaneg 2013 server. This can run whilst users are still accessing the legacy Public Folders:

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server ) -CSVData (Get-Content -Encoding Byte)

Once this is up and running it could take quite a while to complete (dependent on the size of your legacy Public Folders). Take note that this request can be throttled so that could increase the seeding time as well!

In order to keep tabs on the process you can run "Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics" to view the progress. Once the request reaches "AutoSuspended" state we can continue on to the next step.

Note: If a large amount of time passes between this stage and the next it is possible to resume the request and seed any changes to the legacy Public Folders so that the final switchover doesn't take as long as it would otherwise:

Resume-PublicFolderMigrationRequest \PublicFolderMigration


Finally! The big moment has arrived! Now we are ready to begin the final steps in our migration process and we need to lock down our legacy Public Folders. By doing this we deny our end users access to any public folder infrastructure so best to schedule downtime for this operation!

We have to run our lockdown command on the legacy Exchange server:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

If you have multiple Public Folder databases in the organization a wait is required for replication to complete. You could also choose to bypass the wait by restarting the Microsoft Exchange Information Store on the legacy servers.

Resuming the migration request

Our final step in the migration process is to allow our migration request to complete. Once started it will begin an incremental sync and set the migration request to "Completed" once finished:

Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false

Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

Snapshotting the completed environment

Now that the migration request has completed it would be a good point to take snapshots of the Modern Public Folders environment and compare these against the earlier snapshots you took to verify the data was transferred successfully.

Get-PublicFolder -GetChildren | Format-Table Identity, ParentPath, MailEnabled, MaxItemSize, OriginatingServer

Get-PublicFolder -Recurse | Get-PublicFolderStatistics | Format-Table Name, ItemCount, TotalItemSize, OwnerCount, CreationTime, FolderPath

Get-PublicFolder -GetChildren | Get-PublicFolderClientPermission | Format-List Identity, User, AccessRights

Unlocking the Modern Public Folders

Now that we have verified the Public Folders have migrated successfully and all is well we can allow our Hierarchy mailbox to assume its task:

Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy:$false

Congratulations! If all went well you have now completed the migration from legacy to Modern Public Folders and your users are oblivious to it! Not only that, you have freed up tons of time in your own work day no longer having to deal with hierarchy and content SMTP messages, figuring out why that folder on that one server just won't sync or explaining to that manager why his teams data was overwritten for some obscure sync reason…

"Th-Th-Th-Th-Th-... That's all, folks." – Porky Pig

Oh by the way

If you ever encounter the Migration request being in "StalledDueToMailboxLock" status you can restart the MS Exchange information Store process on the legacy and 2013 servers in your environment. Theoretically this should not occur, but it might happen once in a while if you're too fast J.






Print | posted on Wednesday, September 10, 2014 4:27 PM | Filed Under [ Exchange ]



# re: Exchange 2013: Public Folder Migrations

Excellent steps. This is just awesome and thank you for taking time and sharing your knowledge.
1/30/2015 7:00 AM | Rajesh

# re: Exchange 2013: Public Folder Migrations

Thank you for sharing such an nice article. Here is another link for community reference which provides a general analysis about PF to SharePoint migration by

2/18/2015 2:14 AM | Peter

# re: Exchange 2013: Public Folder Migrations

Great Steps. Better than microsoft. Or maybe after running through theirs 5 times I am just getting a little better at this...
3/5/2015 10:31 AM | Kevin

# re: Exchange 2013: Public Folder Migrations

Awesome to hear that Kevin, Peter & Rajesh! Thank you for the comments :)!
3/5/2015 10:53 AM | Marc

# re: Exchange 2013: Public Folder Migrations

Funny Jhon,

Most of those functions that I can see from the sales website are included in Exchange already. I'm wondering what the added value of that product is?

3/25/2015 6:30 AM | Marc
Post A Comment

Powered by: