In part 1 we briefly looked at the architectural changes made to modern public folders in Exchange 2013 as well as some of the things to you may want to consider as you prepare to migrate you public folders to Exchange Online. In this post we will step through the actual migration process in detail.
Let’s firstly take a look at the migration scripts. I typically place all these scripts in the same folder, c:\pfmigration for example. You should have the following scripts downloaded:
- Export-PublicFolderStatistics.ps1 - This script creates a .csv file that contains a folder name-to-folder size mapping.
- PublicFolderToMailboxMapGenerator.ps1 - This script uses the mapping file to create a public folder-to-mailbox mapping file which is also a .csv file.
- Export-MailPublicFoldersForMigration.ps1 - This script exports the mail-enabled public folder objects from the on-premises organization’s Active Directory into a .xml file.
- Import-MailPublicFoldersForMigration.ps1 - This script imports the mail-enabled public folder objects into Exchange Online.
Note: These scripts also have support files with a .psd1 extension, it is important that these support files are placed in the same folder.
Before starting the migration process, you should confirm that there are no existing public folder migration requests in Exchange Online. These would need to be removed before you can continue, but it is important to first understand why there are already there before removing them. You can easily see if there are any existing request by running the following cmdlet in Exchange Online:
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List
The first step in the migration process is to ensure that mail-flow to mail-enabled public folders will continue to work. The steps required to do this will depend on your configuration. If you already have an Exchange Hybrid configured (as I do), you will most likely not need to do anything as the Hybrid Configuration Wizard will take care of this step.
Next it is time to start using the migration scripts. We start with the Export-PublicFolderStatistics.ps1 script to create our name-to-folder size mapping file. This script is run on the legacy public folder server:
Export-PublicFolderStatistics.ps1
Once we have our size mapping file, we can run the PublicFolderToMailboxMapGenerator.ps1 script to create the public folder-to-mailbox mapping file which is used to calculate the correct number of public folder mailboxes that will be required in Exchange Online. This script is run on the legacy public folder server:
PublicFolderToMailboxMapGenerator.ps1
Note: The
I was having a discussion with a colleague of mine last week about public folder migration, more specifically how to selectively migrate only certain public folders. In the interest of full disclosure, I have not tested this (yet!), but in theory it should work. If you were to edit the size mapping file in Excel, you will notice that it contains two columns: ‘FolderName’ and ‘FolderSize’. Remove all the entries for folders that you don’t want to migrate before running the PublicFolderToMailboxMapGenerator.ps1 script and complete the rest of the process as documented. If you have tried this and have some feedback, let me know. I hope to be able to test it soon.
Moving on.. once we have our mapping files created, we should export our mail enabled public folders on our legacy public folder server:
Export-MailPublicFoldersForMigration.ps1
Next, we can connect to Exchange Online and create our new public folder mailboxes. The first public folder mailbox that is created will be the primary hierarchy mailbox and it must be created in ‘HoldForMigration mode’. This public folder mailbox should also be excluded from the serving hierarchy so that the public folders won’t be available to Exchange Online users.
New-Mailbox -PublicFolder
-HoldForMigration:$true -IsExcludedFromServingHierarchy:$true
We should also import our mail enabled public folders:
Import-MailPublicFoldersForMigration.ps1
We are now ready to submit the migration request, but before we do, let’s gather all the required information for the New-PublicFolderMigrationRequest cmdlet:
First we need our Outlook Anywhere hostname and authentication method:
Get-OutlookAnywhere | Format-List Identity, ExternalHostName, IISAuthenticationMethods
We also need the LegacyExchangeDN of the administrator mailbox:
Get-Mailbox
| Format-Table LegacyExchangeDN
Lastly, we need the ExchangeLegacyDN of the legacy public folder server:
Get-ExchangeServer –Identity
| Format-Table ExchangeLegacyDN
Given the length of the cmdlet and parameters, I recommend using variables. Using the information we have gathered, we can easily do this:
$OAHostname =
$Csv = Get-Content c:\PFMigration\pf2mbx.csv -Encoding Byte
$OnPremCred = Get-Credential
$Rmldn =
$Rpfsldn =
We can then run the New-PublicFolderMigrationRequest cmdlet using these variables. You’ll know that the command started successfully when the migration request reaches a status of ‘Queued’ or ‘InProgress’:
New-PublicFolderMigrationRequest -OutlookAnywhereHostName $OAHostName -CSVData $Csv -RemoteCredential $OnPremCred -RemoteMailboxLegacyDN $Rmldn -RemoteMailboxServerLegacyDN $Rpfsldn -AuthenticationMethod
Once the migration request kicks off it will copy the public folder data and will continue running until it reaches 95% at which point it will auto suspend the request. We can monitor the progress using the Get-PublicFolderMigrationRequest and Get-PublicFolderMigrationRequestStatistics cmdlets:
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List Status, SourceServer, SourceVersion, BytesTransferred, ItemsTransferred, PercentComplete, Message
In order to complete the migration request, we need to arrange downtime or a service outage as there will be period while the last bit of data is transferred where public folders will be unavailable to end users. The amount of downtime depends on how much new content has been generated since the migration was suspended. In large environments with a lot of changing content, I would recommend running the Resume-PublicFolderMigrationRequest cmdlet. This cmdlet can be run as often as required and will merely copy any new content and auto suspend at 95%, this will reduce the amount of downtime required.
Once we have scheduled a service outage and informed out end users, we need to lock the legacy public folder environment in order to prevent any further changes:
Set-OrganizationConfig –PublicFoldersLockedForMigration $true
Next we need to allow the migration request to complete, we do this by removing ‘PreventCompletion’:
Get-PublicFolderMigrationRequest | Set-PublicFolderMigrationRequest -PreventCompletion $false
We can now resume the migration request and this time it will run through to completion and not auto suspend at 95%:
Get-PublicFolderMigrationRequest | Resume-PublicFolderMigrationRequest
We monitor the request as before to verify that it has completed successfully:
Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List Status, SourceServer, SourceVersion, BytesTransferred, ItemsTransferred, PercentComplete, Message
Once we are happy that the migration has completed successfully, we allow the hierarchy to be served:
Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
The final set in the process is to set the migration as complete in the legacy environment:
Set-OrganizationConfig -PublicFolderMigrationComplete $true
It is possible to roll back the migration, however I would like to mention a few really important points about rolling back:
- The roll back process will not copy any changed data back to the legacy environment, this should be considered when deciding to roll back. It would be a really bad idea to try and roll back a change heavy environment after 3 weeks.
- Roll back will obviously require the original public folder databases to be online, I therefore recommend dismounting these for a period of time after the migration just in case you need them. This process is a lot more difficult if you delete the databases and then try and roll back.
For more information on the migration process, see the following article on TechNet: