Exchange 2016: Public Folder migration made easy

If you are in the planning stages for migration from Exchange 2010 to Exchange 2016, 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?

Architecture

Beginning with Exchange 2013–and continued with 2016–public folders underwent a major architectural change.

This new architecture is referred to as Modern Public Folders. The old architecture is now known as Legacy Public Folders. But its much more than a name change. Gone is the Public Folder database. And hello are the new Public Folder Mailboxes.

The benefit?

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!

Works with 2013: This process also works with migrations to Exchange 2013 (from 2007 SP3 RU15 or 2010 SP3 RU8). It requires Exchange 2013 be on Cumulative Update 7 or later. If not, you will need to perform the older serial migration method documented here.

Step 1: The Prerequisites

Caution: 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 have a good working backup of your Public Folder Database.

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 six 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.

Exchange Server 2010 SP3 and SP3 RU8.

Of course, these are only the minimum patch levels. It’s always best practice to get the latest update available. At the time of writing Exchange 2010 SP3 RU12 is the latest release.

In addition, be sure to patch your Exchange 2016 server as well. At the time of writing, there is no cumulative update for Exchange 2016.

Tip: It is important to migrate public folders after you migrate all users to 2016. Users on legacy versions of Exchange will not be able to access the modern public folders of Exchange 2016.

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 .\Export-PublicFolderStatistics.ps1 script. Be sure to include the period and backslash.

You may be prompted to allow the script to run. Pick [R] to run once, or, [A] to always run.

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 EX10.

 C:\PFScripts>.\Export-PublicFolderStatistics.ps1

cmdlet Export-PublicFolderStatistics.ps1 at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
ExportFile: PublicFolderStats.csv
PublicFolderServer: EX10
[3/8/2016 11:23:21 AM] Enumerating folders under NON_IPM_SUBTREE...
[3/8/2016 11:23:23 AM] Enumerating folders under NON_IPM_SUBTREE completed...6 folders found.
[3/8/2016 11:23:25 AM] Retrieving statistics from server EX10
[3/8/2016 11:23:25 AM] Retrieving statistics from server EX10 complete...7 folders found.
[3/8/2016 11:23:25 AM] Total unique folders found : 7.
[3/8/2016 11:23:25 AM] Exporting statistics for 7 folders
[3/8/2016 11:23:25 AM] Exporting folders to a CSV file
[PS] C:\PFScripts>

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. In my lab, I only have six folders. All of which are empty. The size column is measured in bytes.

Next, we need to run the PublicFolderToMailboxMapGenerator.ps1 script. To do this run the .\PublicFolderToMailboxMapGenerator.ps1  script. Be sure to include the period and backslash.

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.

 C:\PFScripts>.\PublicFolderToMailboxMapGenerator.ps1

cmdlet PublicFolderToMailboxMapGenerator.ps1 at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
MailboxSize: 21474836480
ImportFile: PublicFolderStats.csv
ExportFile: FolderToMailbox.csv
[3/8/2016 11:31:57 AM] Reading public folder list...
[3/8/2016 11:31:57 AM] Loading folder hierarchy...
[3/8/2016 11:31:57 AM] Allocating folders to mailboxes...
[3/8/2016 11:31:57 AM] Trying to accomodate folders with their parent...
[3/8/2016 11:31:57 AM] Exporting folder mapping...
[PS] C:\PFScripts>

As you are sizing the Public Folder mailboxes, keep in mind any quotas you have in place in 2016. Like user mailboxes, public folder mailboxes follow the same quota scheme. That said, if you have a massive public folder deployment, you may want to create a dedicated database that only contains your public folder mailboxes.

This recommendation may seem contradictory to the architecture changes mentioned earlier as the public folders would be once again in a dedicated database. But keep in mind that the database is using Windows Failover Clustering as its shipping mechanism and not public folder replication (Yay!).

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. And will vary based on the size you specified when running the mapping script. 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.

Now we need to switch gears and log onto our Exchange 2016 server. Once logged on, copy the entire contents of the C:\PFScripts folder from the old Exchange server to the same location on the 2016 server.

Open PowerShell and change to the C:\PFScripts directory. Run the .\Create-PublicFolderMailboxesForMigration.ps1 script. Be sure to include the preceding period and backslash.

You may be prompted to allow the script to run. Pick [R] to run once, or, [A] to always run.

You will then be prompted to enter the name of our mapping file we created on the old server. This should have come across when you copied the PFScripts folder. We had called this FolderToMailbox.csv.

You will then be asked for an estimate of your concurrent users who access public folders. Microsoft states this is less than your actual user count. Microsoft’s recommended limit for concurrent connections to a single public folder mailbox is 2,000. So, for an environment with less than 2,000 users, it really doesn’t matter what you enter here. For a large environment with more than 2,000 users, you want to make sure that you have one public folder mailbox for every 2,000 concurrent connections. You may wish to correct your map file, if you have too few mailboxes, before proceeding.

The script will validate the contents of the CSV map file and ask if you wish to proceed. Hit enter to accept the default of [Y] Yes.

 C:\PFScripts>.\Create-PublicFolderMailboxesForMigration.ps1

Do you want to run software from this untrusted publisher?
File C:\PFScripts\Create-PublicFolderMailboxesForMigration.ps1 is published by CN=Microsoft Corporation, OU=MOPR,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US and is not trusted on your system. Only run scripts from trusted publishers.
[V] Never run [D] Do not run [R] Run once [A] Always run [?] Help (default is "D"): a

cmdlet Create-PublicFolderMailboxesForMigration.ps1 at command pipeline position 1
Supply values for the following parameters:
(Type !? for Help.)
FolderMappingCsv: FolderToMailbox.csv
EstimatedNumberOfConcurrentUsers: 100

Public Folder mailbox updates.
Creating 1 Public Folder mailbox(es) and updating 0. Total mailboxes to serve hierarchy will be 1. Would you like to
proceed?
[Y] Yes [N] No [?] Help (default is "Y"):
Total mailboxes created: 1. Total mailboxes updated: 0. Total serving hierarchy: 1.
Here is a list of Public Folder mailboxes created:

Name                    IsServingHierarchy IsMigrationTarget
----                    ------------------ -----------------
Public Folder Mailbox 1 True               True

[PS] C:\PFScripts>

The script then lists all the public folder mailboxes it created. It should be every mailbox you had in your map file. In our case, it was just the one which we had renamed Public Folder Mailbox 1.

Next Steps

That’s it for part one of our public folder migration series to Exchange 2016. Check out part two where we migrate our public folder data and finalize the migration.

NEXT: Exchange 2016: Public Folder migration Part 2