Migrating Public Folders to Exchange 2013

Xavier Mustin

Administrator
Staff member
#1
In this two-part article, the author will talk about and demonstrate how to migrate Public Folders from Exchange 2010 into Exchange 2013.

Introduction
Now that Exchange 2007 SP3 RU10, Exchange 2010 SP3 and Exchange 2013 CU1 have been released, administrators can start deploying Exchange 2013 in a coexistence scenario with these two previous versions of Exchange.

Part of many transitions from Exchange 2007/2010 to 2013 will include the migration of Public Folders (PFs). Because of all the major changes made to PFs, discussed in the Exchange 2013 Preview - Public Folders article, legacy Exchange mailboxes are unable to access the PF hierarchy on Exchange 2013 servers. However, mailboxes on Exchange 2013 can connect to legacy PFs.

Unlike migrating PFs between previous versions of Exchange, PFs on Exchange 2013 and legacy PFs cannot coexist in an Exchange organization, which means that migrating PFs to Exchange 2013 is a one-time cut-over process.

Because legacy mailboxes cannot access PFs in Exchange 2013, it is recommended that all mailboxes are first moved to Exchange 2013 and only then PFs migrated.

Advertisement

Overall Process
The high level process for migrating Public Folders from Exchange 2007/2010 is as follows:

  1. Migrate user mailboxes to Exchange 2013 before migrating PFs;
  2. Snapshot current PF environment for comparison when migration is complete (folders, sizes and permissions);
  3. Create CSV file, manually or using scripts (Export-PublicFolderStatistics.ps1 andPublicFolderToMailboxMapGenerator.ps1). End result is a CSV file mapping PFs to new PF mailboxes;
  4. Create PF mailboxes using New-Mailbox –PublicFolder cmdlet;
  5. Migrate PF content using New-PublicFolderMigrationRequest cmdlet;
  6. Lock down Exchange 2007/2010 PFs for final migration using the following cmdlets:
    a.
    Code:
    Set-OrganizationConfig –PublicFoldersLockedForMigration $True (Exchange 2010)
    b.
    Code:
    Set-OrganizationConfig –PublicFolderMigrationComplete $True (Exchange 2013)
    c.
    Code:
    Set-PublicFolderMigrationRequest <name> -PreventCompletion $False (Exchange 2013)
    d.
    Code:
    Resume-PublicFolderMigrationRequest <name> (Exchange 2013)
  7. Test new PFs;
  8. Snapshot Exchange 2013 PFs and compare with Exchange 2007/2010 PF snapshots;
  9. Roll back, if necessary, by running
    Code:
    Set-OrganizationConfig –PublicFoldersLockedForMigration $False and Set-OrganizationConfig –PublicFolderMigrationComplete $False;
  10. Remove Exchange 2007/2010 PFs and PF databases.
Scenario Information
For this article I set up a lab with the following characteristics:

  • Only one PF database on an all-in-one Exchange 2010 server;
  • 307 PFs with approximately 10500 items in total;
  • Although in this article I am migrating PFs from Exchange 2010 to 2013, the process for Exchange 2007 is identical;
  • Exchange 2010 server name: AIO
  • Exchange 2013 server name: AIO13
It is worth highlighting a few notions just in case you are not aware:

  • Only Outlook 2007, Outlook 2010 and Outlook 2013 can access PFs;
  • PFs cannot be accessed through Exchange 2013 OWA at this stage;
  • There is no mailbox audit logging against PF mailboxes at this time;
  • If the master hierarchy PF mailbox becomes unavailable, users can view but not write to PFs;
  • It is not possible to change which PF mailbox is the master hierarchy mailbox;
  • When you migrate PFs, PF rules are migrated along with the data and are kept as PF rules. They are not converted to mailbox rules.
Prepare for Migration
Before we start migrating PFs across to Exchange 2013, there a number of recommended steps that need to be performed beforehand.

It is recommended to first create a “snapshot” of all the current PFs by exporting to CSV files their structure, permissions and statistics. This will allow us to later compare this snapshot with the end result in Exchange 2013 at the end of migration, simply for verification purposes.

So, on the Exchange 2010 server, we run the following three cmdlets:


Figure 1.1:
Public Folder Snapshot

The first cmdlet takes a snapshot of the original PF structure:

Code:
Get-PublicFolder -Recurse | Export-CSV C:\PFs\2010_PFStructure.csv -NoTypeInformation
The second cmdlet takes a snapshot of the PF statistics such as item count, size, owner, etc.:

Code:
Get-PublicFolder -Recurse | Get-PublicFolderStatistics | Export-CSV C:\PFs\2010_PFStatistics.csv -NoTypeInformation
Finally the third cmdlet takes a snapshot of all the PF permissions:

Code:
Get-PublicFolder -GetChildren | Get-PublicFolderClientPermission | Select Identity, User -ExpandProperty AccessRights | Export-CSV C:\PFs\2010_PFPerms.csv -NoTypeInformation
Note that I am not using –ResultSize Unlimited as I know I have less than 1000 PFs. I also like to use –NoTypeInformation (or simply –NoType) to automatically remove that first row with information that the Export-CSVcmdlet puts on CSV files by default.

Still on Exchange 2010 server, we now need to make sure there is not a record of any previous PF migration. If there is, we need to set that value to False because if it is set to True the migration request will fail.


Figure 1.2:
Public Folder Migration Record

If either PublicFoldersLockedforMigration or PublicFolderMigrationComplete are set to True, run the following cmdlet to set them to False:

Code:
Set-OrganizationConfig –PublicFoldersLockedforMigration $False –PublicFolderMigrationComplete $False
In this case, we will need to wait for Exchange to detect the new settings, which might take several minutes. To speed up this process, we can restart the Microsoft Exchange Information Store service.

Now we move onto Exchange 2013. Here, we need to make sure there are no existing PF migration requests as well. This is only required if there are any existing migration requests in the pipeline. Run the following cmdlet to remove any existing PF migration requests:


Figure 1.3: Removing Public Folder Migration Requests

Another pre-requite is that there are no PFs on any Exchange 2013 server. These will be automatically created as part of the migration process. Run the following cmdlet to make sure there are no PFs and no PF mailboxes on 2013:


Figure 1.4: Checking for Public Folder and Public Folder Mailboxes

Because in this case this is an out-of-the-box deployment of Exchange 2013, there are no PFs at all. If you happen to have created any, then you need to remove them before you proceed.

Map Public Folders
The following procedures can be skipped and you can go straight to manually creating a CSV file which tells Exchange which PF mailbox to use for each PF. However, I strongly recommend you follow these steps, if not at least to understand the overall process and to help you in producing the final CSV.

The first step is to create a CSV file which maps PF name-to-folder size. This CSV file will contain two columns,FolderName and FolderSize (displayed in bytes) and will be used later to decide on how many PF mailboxes to use so that each one of them falls under a specified (by you) size limit.

Copy the files Export-PublicFolderStatistics.ps1 and Export-PublicFolderStatistics.strings.psd1 from your Exchange 2013 server (<install_dir>\Exchange Server\V15\Scripts\) into your Exchange 2010 server, and then, from the 2010server, run the script to generate the mapping file. The parameters to use with this script are:

.\Export-PublicFolderStatistics.ps1 <Folder to size map file path> <Source server>

  • Folder to size map file path: the file name and path where you want the CSV file to be created. You will need to copy this file into your Exchange 2013 server;
  • Source server: the name of the Mailbox server where the public folder hierarchy is hosted.

Figure 1.5: Creating Name-to-Folder Mapping

Once complete, the CSV file will list all your PFs and their corresponding size (in bytes):


Figure 1.6:
Public Folder Sizes

Now we run the PublicFolderToMailboxMapGenerator.ps1 script on Exchange 2013 server to create the PF folder-to-mailbox mapping file based on the CSV we just generated. The new CSV is used to create the correct number of PF mailboxes on Exchange 2013, as explained earlier.

For simplicity, I copied the PFmapNameToSize.csv file we generated on the previous step into the C:\PFs\ folder on the Exchange 2013 server as well as the PublicFolderToMailboxMapGenerator.ps1 andPublicFolderToMailboxMapGenerator.strings.psd1 files from the Exchange 2013 scripts folder.

This script is run with the following parameters:

\PublicFolderToMailboxMapGenerator.ps1 <Maximum mailbox size in bytes> <Folder to size map path> <Folder to mailbox map path>

  • Maximum mailbox size in bytes: the maximum size you want to set for the new PF mailboxes. However, you can use the standard size suffixes, as shown in the example below. Be sure to allow for expansion so the PF mailboxes have room to grow;
  • Folder to size map path: the file name and path of the CSV file we generated earlier when running the Export-PublicFolderStatistics.ps1 script;
  • Folder To mailbox map path: the file name and path of the folder-to-mailbox CSV file that will be generated by this script.

Figure 1.7: Creating Name-to-Size Mapping

In this case, I chose a maximum size of 100MB for any PF mailbox. However, because all my PFs together take less space than that, the script came out with a single PF mailbox, Mailbox1, under which it places all PFs:


Figure 1.8: Public Folder-to-Mailbox Mapping

If I had specified a PF mailbox size of 100KB instead of 100MB, just for illustrative purposes, several more PF mailboxes would be created. In this case, Exchange would spread PFs across all of them in order to achieve the maximum size limit I specified (this is where the first CSV file is used):


Figure 1.9: Public Folder-to-Mailbox Mapping 2

However, because in my scenario we are talking about a (imaginary) multinational organization where each top-level PF will be hosted in different servers across the globe, I want to place all the Asia PFs in a PF mailbox, all the America PFs in another PF mailbox, and so on. This will allow me to place the Asia PF mailbox in a database hosted by a Database Availability Group (DAG) in Asia, the America PF mailbox in a database hosted by a DAG in America, etc. Obviously, if all PFs for America take up 120GB of space, for example, I can split them into multiple PF mailboxes and even multiple databases.

To achieve this, and so we can meet the organization’s requirements, we can manually edit this CSV file. Alternatively, since we now know its format and how it is used, we can skip the previous steps and manually create this CSV file from scratch.

In my case, I updated the TargetMailbox field with the names of the PF mailboxes I want to use. Remember that, at this stage, there are no PF mailboxes created yet.

The end result is as follows (note that most lines have been hidden so you can see the overall distribution of PFs):


Figure 1.10: Final Public Folder-to-Mailbox Mapping

Important:As explained before, this CSV file is used to determine the mapping between the source hierarchy and the destination mailbox. It contains “only” the top-level folders because child folders under the top-level folders are automatically migrated. As such, if a new child folder is added, it is migrated during the process. If a new top-level folder is created, it will be created in the mailbox that contains the writable copy of the hierarchy.

The reason why Exchange included child PFs in this CSV (Figure 1.9), is because of the very low size limit I set. Otherwise, only top-level folders would be referenced.

This CSV is critical to ensure each PF and each PF mailbox is placed in the appropriate geographic location, ensuring they are near the target users. This is more important than ever because now we can only have one active PF in the entire organization, meaning that if a user in Europe wants to access a PF in America, he/she will be accessing the PF in America and not a local copy as before.

You can also see that I am creating a PF mailbox dedicated to the PF hierarchy, which is not required.

Create Public Folder Mailboxes
In this step we create the required PF mailboxes to hold all the PFs being migrated. We have to create a PF mailbox for all the names we mentioned in the TargetMailbox field of the mapping file otherwise Exchange will try to copy PFs to a PF mailbox that does not exist.

Remember that the first PF mailbox that we create will be the master hierarchy mailbox. This first PF mailbox, and only this, must be created in HoldForMigration mode. This parameter prevents any user, with the exception of the Microsoft Exchange Mailbox Replication service process, from logging into a PF mailbox.

We also create all PFs but exclude them from serving hierarchy so that e-mails are not delivered to them during this phase and to prevent users from accessing them.

To create all the necessary PF mailboxes, we use the New-Mailbox cmdlet:

Code:
New-Mailbox -PublicFolder PF-Hierarchy –Database DB01 -IsExcludedFromServingHierarchy $True –HoldForMigration

New-Mailbox -PublicFolder PF-Asia –Database DB01 -IsExcludedFromServingHierarchy $True

New-Mailbox -PublicFolder PF-America –Database DB02 -IsExcludedFromServingHierarchy $True

New-Mailbox -PublicFolder PF-Europe –Database DB03 -IsExcludedFromServingHierarchy $True

New-Mailbox -PublicFolder PF-Antartica –Database DB04 -IsExcludedFromServingHierarchy $True

New-Mailbox -PublicFolder PF-Australia –Database DB05 -IsExcludedFromServingHierarchy $True

New-Mailbox -PublicFolder PF-Africa –Database DB06 -IsExcludedFromServingHierarchy $True
If we now check the Exchange Admin Center, we should be able to see all the PF mailboxes we have just created:


Figure 1.11: Public Folder Mailboxes in the EAC

However, there are no PFs yet as these will be created automatically during the migration process:


Figure 1.12:
Public Folders in the EAC

Conclusion

In the first part of this article series, we had a look at the overall process of migrating Public Folders from Exchange 2007/2010 to Exchange 2013. We started the process by preparing for the migration and by mapping which Public Folders will go into each Public Folder mailbox. In the second and final part we will start and finalize the migration, and see how we can roll back the process if needed.



Second Part

In this second and final part of this article series we will start and finalize the migration, and see how we can roll back the process if needed.

Introduction
In the first part of this article series, we had a look at the overall process of migrating Public Folders from Exchange 2007/2010 to Exchange 2013. We started the process by preparing for the migration and by mapping which Public Folders will go into each Public Folder mailbox. In this second and final part we will start and finalize the migration, and see how we can roll back the process if needed.


Start Migration
We now have everything in place to start migrating Public Folder (PF) content from Exchange 2010 into 2013. Using the New-PublicFolderMigrationRequest cmdlet and the PFmapFolderToMailbox2.csv file we produced earlier, Exchange will create the required PFs and start moving data across.

From the Exchange 2013 Mailbox server, run the following cmdlet (if you know the name of the source PF database, you can simply use –SourceDatabase <PF DB Name>):


Figure 2.1:
Creating Public Folder Migration Request

Although the full name is not shown in the screenshot above, the name of this migration request isPublicFolderMigration. This will be needed later on.

To verify that the migration has started successfully and to keep an eye on its progress, we can use the
Code:
Get-PublicFolderMigrationRequest and Get-PublicFolderMigrationRequestStatistics
cmdlets:


Figure 2.2:
Public Folder Migration Request Statistics

Once StatusDetail reaches a status of InProgress or CopyingMessages, we know that the cmdlet has started successfully and content is being copied across to Exchange 2013. The amount of time required will obviously depend on how much data you are copying as well as the location of the source and target server(s).

To get even more details, we can have the
Code:
Get-PublicFolderMigrationRequestStatistics
cmdlet generate a detailed report:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | FL

From this report we can follow every single step of the migration process: from the Exchange Mailbox Replication service examining the migration request, to connecting to both the target and the source databases, to creating the PF hierarchy, to creating all the PFs in Exchange 2013, etc.:


Figure 2.3:
Public Folder Migration Request Statistics Report

When the status of the migration finally reaches a status of AutoSuspended, we can proceed to the next step:


Figure 2.4:
Public Folder Migration Suspended

Finalize Migration (downtime)
Up until this point, users have been able to access PFs on Exchange 2010 server(s), including during the initial migration. If we look at the Connection Status of an Outlook user (already on Exchange 2013), we see that Outlook connects to both Exchange 2010 (for PFs) and 2013:


Figure 2.5:
Outlook 2013 Public Folder Connection

In order to finalize the migration, we need to log users off from the PFs on Exchange 2010 and lock these PFs so they cannot be used while the migration completes its final synchronization.

Important:Users will not be able to access PFs folders during this process. Ideally this would be performed outside business hours, which might not be so straightforward for international companies whose PFs are dispersed throughout the globe.

From the Exchange 2010 server, run the following cmdlet which will lock users out from accessing down level PF servers:


Figure 2.6: Locking Public Folders for Migration

If there are multiple PF databases in the environment, we need to wait until PF replication is complete to confirm that all PF databases have picked up the PublicFoldersLockedForMigration flag. To bypass this waiting period, we can restart the Microsoft Exchange Information Store service.

Once this cmdlet is run, users will not be able to access any PF:


Figure 2.7:
Outlook 2013 Public Folder Connection Error

Note:The amount of downtime required depends on how much new content was generated since the migration reached theAutoSuspended state.

In order to complete the migration process we now need to set the PublicFolderMigrationComplete property to True, as shown below, which might be a little misleading as the migration does not get completed with just this cmdlet.

On the Exchange 2013 server, manually set the PublicFolderMigrationComplete property to True:


Figure 2.8: Finalizing Public Folder Migration

However, in order to complete the migration we still need to remove the PreventCompletion flag from the PF migration request and then resume it:


Figure 2.9: Resuming Public Folder Migration

Once this is done, Exchange will synchronize any last changes made to PFs in Exchange 2010 after the initial synchronization (in the Start Migration section) but before we locked users out. This also allows us to import any non-top level PFs created since the original migration request took place.

At this stage the source PFs are still locked and inaccessible to users because we set thePublicFoldersLockedForMigration flag to True. This lock remains in place to prevent users from accessing the source PFs after migration completes. Although we can release this lock, it is not recommended to do so because any changes will not be synced to Exchange 2013.

We can track the migration progress using the same cmdlets as before:


Figure 2.10: Public Folder Migration Statistics

As you can see, the migration still hasn’t completed because the PF mailboxes are locked due to the IsExcludedFromServingHierarchy parameter we used when creating them. If we look at the migration report we will see a “Relinquishing job because the mailbox is locked” warning.

Test New Public Folders
At this stage, we are ready to test if the migration has been successful until this point and before we enable PFs to all users. To do so, first we need to unlock at least one PF mailbox. For this test, I am going to use the PF-Europe PF mailbox for testing but I also need to unlock the PF-Hierarchy as this is the master hierarchy mailbox:


Figure 2.11: Unlocking Public Folder for Testing

If we now check the EAC, we can see all the PFs already created on Exchange 2013:


Figure 2.12: Public Folders in the EAC

Next, we set a test mailbox to use the PF mailbox PF-Europe as its default PF mailbox. This is done using theDefaultPublicFolderMailbox parameter which assigns a specific PF mailbo+x to a user’s mailbox. By default, the PF mailbox used by a user is automatically selected by an algorithm that load-balances users across all PF mailboxes.


Figure 2.13: Setting Default Public Folder Mailbox

Once this is done, the user will be able to access the PF, this time located on Exchange 2013:


Figure 2.14: Accessing New Public Folders in Exchange 2013

Once we confirm everything is working as expected, we can unlock all the other PFs:


Figure 2.15: Unlocking Remaining Public Folder Mailboxes

If we now check the migration, it should be complete:


Figure 2.16: Public Folder Migration Complete

Although on the surface everything might seem to be fine, you should still verify that your PF migration was successful by taking the same snapshots of the new PFs and compare them to the ones we took in the beginning of the entire process. As such, follow the instructions in the Prepare for Migration section but this time for the PFs in the new Exchange 2013 environment. You should compare all snapshots in order to ensure all items have been copied and that permissions have been honored.

Remove Public Folder Database from Exchange 2010 Servers
Once the process is complete and you have verified that the Exchange 2013 PFs are working as expected, the final step to a successful migration is to remove the PF database(s) on the legacy Exchange server(s). This is a well-documented process and, as such, there is no reason to repeat it here.

Roll Back the Migration
Unfortunately not every migration goes according to plan and you might need to roll back the migration and reactivate the PFs on Exchange 2010. To do so, first you need to unlock the legacy Exchange PFs and set thePublicFolderMigrationComplete flag to False by running the following cmdlet on the Exchange 2010 server:

Set-OrganizationConfig –PublicFoldersLockedforMigration $False –PublicFolderMigrationComplete $False

Important:Any changes made to PFs in Exchange 2013 will not be reflected in the legacy Exchange PFs because there is no two-way replication as with PF migrations in previous editions of Exchange. As a result, you may lose PF data if you roll back the migration.

Once the change takes effect, you will be able to access the PFs in Exchange 2010, but your users (who should be in 2013 already) will continue to access the 2013 PFs.

At this stage, remove all PFs from your Exchange 2013 servers so that users (even those already on Exchange 2013, with the exception of the test user) can continue to use the PFs in the Exchange 2010 server(s) as if nothing ever happened:


Figure 2.17: Removing Public Folders from Exchange 2013

Conclusion
In this two-part article, we saw how to migrate Public Folders from Exchange 2007/2010 into Exchange 2013.
 
Haut