Update: If you are migrating to the modern public folders in Exchange 2013 you may want to check out this article instead. This is the new and improved method for migrating public folders. However, it requires Exchange 2013 CU7 or later. As of CU11 the method below still works if you prefer to use it. But it will eventually be deprecated.
If you are in the planning stages for migration to Exchange 2013, then you have probably seen this TechNet article.
At first, it may seem daunting.
So many scripts. So many PowerShell commands.
If you are not comfortable with PowerShell it may seem a bit overwhelming.
Plus, it is vastly different than any previous migration process.
Why the change?
Public Folders underwent a major architectural change in Exchange 2013.
Gone is the Public Folder database. And hello are the new Public Folder Mailboxes.
No more Public Folder Replication. Boy, did that used to be a pain!
With Public Folders stored as a mailbox, that mailbox can now be part of a Database Availability Group (DAG). And with that, all the benefits of Windows Failover Clustering.
This makes the migration process vastly different.
On a high level, it is the process of moving all data out of a database and into a special mailbox. That is where the scripts come in. I’ll explain along the way.
Let’s get started!
Note: Before you get started with any migration process it’s always good to do a backup. For Exchange, it is imperative to use a solution that is Exchange-aware. Whichever solution you use, be sure to back up that Public Folder Database.
Step 1: The Prerequisites
Before we get started we need to download the migration scripts. These can be downloaded from here. Save these to your old server. Be sure to get all four files.
Save them to an easily accessible directory. Such as C:\PFScripts. The end result should look like this.
Next, we need to make sure our source servers are fully patched. At a minimum, we need to be at the following levels.
Of course, these are only the minimum patch levels. It’s always best practice to get the latest update available.
In addition, be sure to patch your Exchange 2013 server as well. At the time of writing Cumulative Update 6, was the latest release for 2013.
Note: If running Exchange 2007, be sure you have PowerShell 2.0 and WinRM 2.0 installed. Download here.
Step 2: Running the scripts
The first script we need to run is the Export-PublicFolderStatistics.ps1 script. To do this open the Exchange Management Shell on your 2010 server. Change to your scripts directory. Run the following command. Be sure to include the period and backslash.
You will then be prompted to enter an output file name. I called this PublicFolderStats.csv.
You are then prompted for a source server that contains your Public Folder database. In my lab, the 2010 server is called EXCHANGE.
This will create the file called PublicFolderStats.csv in the scripts folder. If we open the file, we can see all the folders it discovered and their sizes in bytes.
Next, we need to run the PublicFolderToMailboxMapGenerator.ps1 script.
This script will input the PublicFolderStats.csv file we just created. It will then determine how many Public Folder Mailboxes need to be created.
The script will prompt for the desired size of each Public Folder Mailbox. Remember, this is entered as bytes.
For a 20GB mailbox, this would be 21474836480 bytes. There are a lot of calculators out there. I recommend this one from whatsabyte.com.
We are then asked for the file we created with the previous script. We had called this PublicFolderStats.csv.
Next enter the name of the map file we want to create. I made this FolderToMailbox.csv.
As you are sizing the Public Folder mailboxes, keep in mind any quotas you have in place in 2013. Like user mailboxes, public folder mailboxes follow the same quota scheme.
Let’s open the FolderToMailbox.csv file and see what it recommends.
In my case, the script determines I only need one Public Folder Mailbox. In my lab, I have very little data. Your result could be quite different. The Map Generator script may determine you need several Public Folder Mailboxes.
The Map Generator names these Public Folder Mailboxes generic names of Mailbox1, Mailbox2 and so on. If you want to utilize a different naming convention then change the name here and save the file.
In my case, I will change this to “Public Folder Mailbox 1” and save the file. If I had a requirement for a second mailbox I would call it “Public Folder Mailbox 2” and so on.
Step 3: Data Migration
We are done on the 2010 side at this point. Time to switch gears and log into our 2013 server.
Copy the FolderToMailbox.csv file over to the 2013 server. Be sure to put the file in an easily accessible directory. Such as C:\PFMigration.
We need to create the Public Folder mailboxes using the Exchange Management Shell. Their names must match the names saved in the FolderToMailbox.csv file.
Open the Exchange Management Shell and issue the following command.
Change the -Database switch to match the name of one of your 2013 databases. In my case, my database is called “Time Travel Research”.
C:\> New-Mailbox -PublicFolder "Public Folder Mailbox 1" -HoldForMigration:$true -Database "Time Travel Research"
Repeat this command for any other mailboxes.
Now we need to create a migration request.
From the Exchange Management Shell issue the following command.
Change the -Server switch to the name of your 2010 server. In my case this is EXCHANGE.
C:\> New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server EXCHANGE) -CSVData (Get-Content C:\PFMigration\FolderToMailbox.csv -Encoding Byte) -AcceptLargeDataLoss -BadItemLimit 100
The -AcceptLargeDataLoss and -BadItemLimit switches allow for the migration process to skip any corrupted items.
These switches are required if your source is 2007. Exchange 2013 will determine the 2007 OWAScratchPad and SchemaRoot folders to be bad (more info here from Microsoft).
To check the progress of the move issue the following command.
C:\> Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | fl
The progress may report Queued. That is fine. We need to wait for the progress to report AutoSuspended. Then we can proceed.
Depending on how much data you have this process could take a very long time.
Step 4: Completing the Migration
Now that the data is copied we need to flip the switch.
Please note: This will take your Public Folders offline. Users will not be able to access Public Folders. You may wish to schedule this outside of business hours.
Also note: Prior to completing these last steps I would recommend all your users are moved to Exchange 2013.
Let’s switch back to the 2010 server.
From the Exchange Management Shell run this command. Users will be blocked from accessing Public Folders.
C:\> Set-OrganizationConfig –PublicFoldersLockedForMigration:$true
All set? Okay. Let’s switch back to the 2013 server again.
From the Exchange Management Shell run the following two commands.
C:\> Set-PublicFolderMigrationRequest –Identity \PublicFolderMigration -PreventCompletion:$false
C:\> Resume-PublicFolderMigrationRequest –Identity \PublicFolderMigration
These two commands will not produce any output. They only return you to a prompt.
It can take quite some time for the PublicFoldersLockedForMigration and PreventCompletion flags to trigger.
Grab a cup of tea.
Check your fantasy football team.
Watch an episode of Doctor Who.
And then check back.
Let’s reissue the Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics | fl cmdlet and check our progress.
We should see a status of Completed.
We also need to make sure we reroute any messages destined for mail-enabled Public Folders to the new server.
Issue the following command from the 2010 Exchange Management Shell.
C:\> Set-OrganizationConfig -PublicFolderMigrationComplete:$true
Now we need to test.
You can access Public Folders with either Outlook or Outlook Web App.
To access with Outlook Web App, right-click on Favorites in the left pane. Select Add Public Folder from the context menu. Pick your Public Folder and click the Add button.
Verify access. Verify permissions. Verify mail flow.
You are done!
Once you are ready to remove the old Public Folder Databases check this article.
Did this post help you? Let us know how we are doing by leaving us a comment. Your feedback is always important to us!