If you would like to read the first part in ths article series please go to Migrating Public Folders to Exchange 2013 (Part 1).
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 is PublicFolderMigration. 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 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 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 the AutoSuspended 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 the PublicFoldersLockedForMigration 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 the DefaultPublicFolderMailbox 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 the PublicFolderMigrationComplete 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.
If you would like to read the first part in ths article series please go to Migrating Public Folders to Exchange 2013 (Part 1).
