Thursday, August 7, 2014

How To: Migrating to Modern Public Folders. Easier Than it is Hard. #MSExchange #iammec

Recently, the Exchange migrations that I have completed can be categorized in two different camps. First, I encounter the enterprise that has made extensive use of legacy public folders. This company has integrated mail-enabled public folders into many home grown applications and virtually every department has some sort of reliance on data housed in their convoluted public folder structure. The second organization has already been through a painful public folder migration (let’s say 2003-2007) years ago and actively started to decommission them in favor of another solution like SharePoint. This company decided that one migration was painful enough and just bringing up the subject makes them grumpy. As a consultant, I can quickly determine what camp the customer falls into just by mentioning the subject and looking at facial expressions. True story…

My job becomes easier and coincidently a lot cheaper when dealing with the second type of organization. I’ve argued that migrations for companies that fall into the first camp (lots of public folders) should really be approached as a two-phase project. The first phase is preparing, introducing, configuring, and migrating to Exchange 2013 from their legacy infrastructure. You know – the traditional migration tasks. The second phase and really a standalone project is migrating their legacy public folders to modern public folders. Once completed, the final legacy decommission work can begin. The process to migrate public folders is often very time consuming and can become very expensive when paying a consultant to complete this work (much like mailbox migrations) and babysit synchronization processes. Many organizations that have in-house staff opt to have me train them how the process works so they can complete the modern public folder migrations on their own timetable. This method ends up saving the client money and allows me to come back at a later time to decommission the remaining legacy environment.

So if you fall into the second camp and have a ton of legacy public folders that cannot be easily removed from the Exchange environment you will need to understand the steps required for migration. Microsoft has provided excellent documentation on the steps required to complete a migration to modern public folders. The bad news is that the process is still very time consuming and you are faced with some hard down time during the process when public folders are locked for migration.

The good news is that migrating to modern public folders is easier than it is hard! I say that in jest because there is still a measure of complexity to the process. So let’s walk through the process required to migrate from Exchange 2010 legacy public folders to Exchange 2013 modern public folders. In my lab there is a legacy Exchange 2010 server (srv2) that houses the public folder hierarchy. I also have an Exchange 2013 multi-role server (srv4) that holds my test user mailboxes and will be the target for the modern public folder mailbox.

There are several important items that you need to understand and address prior to beginning the migration process.

  1.     Currently there are predefined limits to the number of public folders that Exchange 2013 can host. This quickly becomes a limiting factor for large enterprises that have more than 10,000 public folders within their environment. Microsoft heard the public outcry around this limitation and has been working hard to introduce additional scale. The Office 365 environment has already been scaled to support 100,000 folders while on premise customers will see improvements when CU6 is released. Microsoft has stated that they are looking to scale to 1 million folders for on premise customers.
  2.     Secondly, the active directory account being used for the public folder migration needs to be part of the Organization Management role group for any Exchange 2013/2010 environments. If you still have Exchange 2007 hosting public folders then your account will require the Organization Administrator role.
  3.        Next, any users that will access modern public folders should have their mailbox migrated to Exchange 2013 first. This detail ensures that the public folder migration exercise will almost always be at the tail end of a legacy to 2013 Exchange migration.
  4.     Any Exchange 2010 servers’ host public folders need to have at least SP3 installed.
  5.     Any Exchange 2007 servers’ host public folders need to have at least SP3 RU10 installed along with PowerShell 2.0 and WinRM 2.0.
Once the items above are addressed we can begin our public folder migration process. First, we need to download the PowerShell scripts that Microsoft has provided. These scripts can be found here. I like to download these scripts to a newly created c:\pfmigration folder on the legacy Exchange server that hosts the public folder hierarchy.

Next, we need to take a snapshot of the current legacy public folder environment and export the data to a file so we have something to compare against after the move to 2013 is complete. In order to do this we need to run a series of commands. To obtain the folder structure we can run:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml

To obtain the size of items and owner we run:

Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml

Next, to obtain the permissions for the public folders we run:

Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

You will need to ensure that any existing public folders do not contain a backslash (\) within the name. In an Exchange 2010 environment you can look for this by using:

Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity

Lastly, you will need to ensure that Exchange 2013 does not have an existing record of a public folder migration. If so, the public folders will be locked and subsequent migration attempts will fail. The values returned from the command below should be set to false in order to proceed.

Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete

You can see a screenshot of these commands run successfully below.

Next, you will need to ensure that Exchange 2013 does not have any public folder mailboxes already setup.

Get-Mailbox -PublicFolder

It is also a good idea to make sure that Exchange 2013 does not have any existing public folder migration requests in the pipeline.

Get-PublicFolderMigrationRequest | Remove-PublicFolderMigrationRequest -Confirm:$false

On the legacy Exchange server we will need to run one of the downloaded PowerShell scripts (Export-PublicFolderStatistics.ps1) to create a name-to-folder-size mapping. The syntax will need to contain the folder location for the newly created .csv file and also the FQDN of the legacy Exchange server that hosts the public folder hierarchy.

.\Export-PublicFolderStatistics.ps1 c:\pfmigration\statistics.csv srv2.constoso.local

Continuing on the legacy Exchange server we need to run the second downloaded script (PublicFolderToMailboxMapGenerator.ps1). The syntax for this script will require the max size for the modern public folder mailbox, the path for the statistics file created above (c:\pfmigration\statistics.csv) and the path for the newly created map path file.

.\PublicFolderToMailboxMapGenerator.ps1 10000 c:\pfmigration\statistics.csv c:\pfmigration\MapPath.csv

The MapPath.csv file will contain the number of public folder mailboxes (TargetMailbox) that are required to house all your legacy public folder data based on the item counts and sizes that the c:\pfmigration\statistics.csv file recorded. If all your legacy public folder data exceeded the max size specified above then you will see in the MapPath.csv file will reflect multiple public folder database names. I went into the MapPath.csv file and changed the name to PFMailbox1 for a preferred naming convention. For my small lab there will only be one public folder mailbox created.

From an Exchange 2013 mailbox server we will need to create the public folder mailboxes specified (TargetMailbox) in the MapPath.csv file. If you do not use the same names (TargetMailbox) then the migration will fail. In my lab I will create one public folder mailbox called PFMailbox1.

New-Mailbox –PublicFolder PFMailbox1 –HoldForMigration:$true

The next step is to begin the migration process from the Exchange 2013 side. From an Exchange 2013 server we will run the command below. Take note that we will need to provide the unc path to the MapFile.csv file we created on the Exchange 2010 server.

New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server srv2 -CSVData (Get-Content \\srv2\c$\PFMigration\MapPath.csv -Encoding Byte

Now we will need to check that Exchange has picked up the public folder migration request and has started to work on the copy. We will initially see the status set to “Queued.”

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

If you have GB’s or TB’s of public folder data to copy over to 2013 do not expect this process to complete quickly. In fact, go ahead and start making your plans for the weekend. This process takes awhile.

Tip From The Field: About half the time I get to this process the status will not change from “Queued” to “InProgress.” In my lab for instance, the migration request stayed in a “Queued” status for 6 hours. This is a problem since my lab only had several MB’s of data. The trick here is to restart the Microsoft Exchange Mailbox Replication Service. In my case after restarting the Microsoft Exchange Mailbox Replication Service the public folder request status promptly changed to “InProgress.”

Once all the data from the legacy public folders have been copied to 2013 the migration request will change to a status of “AutoSuspended.” We can verify this with the following command:


Up to this point we have not introduced any downtime to our clients by locking access to the legacy public folders. The next step that we will need to take is to lock out all users from the legacy public folders and then complete a final sync to obtain any new changes from when our migration request reached the “AutoSuspended” state. This means hard downtime for our clients and the proper end user notifications and change controls need to be provided ahead of time. For this next step I cannot stress enough how important planning and end user communication will be.

Additionally, this means if several weeks have passed since the migration request reached the “AutoSuspended” state this next step may take a little time to complete. Once you are ready to begin the actual cutover (end users are on 2013 and change controls and end user notifications have been sent) the following command will need to be run from the legacy Exchange 2010 server that holds the public folder hierarchy:

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

Now to complete the public folder migration request the flag that prevents completion will need to be changed from $true to $false.

Set-PublicFolderMigrationRequest -Identity \PublicFolderMigration -PreventCompletion:$false
Resume-PublicFolderMigrationRequest -Identity \PublicFolderMigration

During this process we can run the following command to check the status:

Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

We can confirm completion when the status changes to “Completed.”

At this point clients are still locked out from accessing public folders. Before allowing all end users to access to the newly migrated modern public folders we will need to test. You can run the following command to change specific users only to utilize the newly migrated modern public folders and not 2010.

Set-Mailbox -Identity jharris -DefaultPublicFolderMailbox PFMailbox1

Now I can log into Outlook (2007 or later) and verify that the public folders can be opened, hierarchy viewed, permissions on folders visible, and the ability to post new messages. Once a few users have tested these items we are ready to set the public folder migration as completed on Exchange 2010. From the legacy Exchange 2010 server that holds the public folder hierarchy:

Set-OrganizationConfig -PublicFolderMigrationComplete:$true

Now when end users connect to Exchange 2013 they will be instructed to access the new modern public folders for the hierarchy.

Now comes the manual part of this exercise. One of the first steps was to create snapshots of the legacy public folder environment. Now we need to take these same snapshots of the 2013 environment and compare the files to ensure we are not missing a massive amount of data. Keep in mind though that if there was several days/weeks in between the “AutoSuspended” state and when we locked the migration for completion there could be a substantial variance in these numbers. This of course would depend on how active your users are with creating and deleting content within public folders. Common sense should be used when comparing the before and after snapshots. To create the after snapshots run the following commands:

Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\New_PFStructure.xml

Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\New_PFStatistics.xml

Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\New_PFPerms.xml

Once you have verified that all the data that should be in the 2013 modern public folders is present, and the databases they reside on have been backed up, you can remove the legacy public folders databases.

Microsoft has provided instructions in case disaster happens and you need to roll back to your legacy public folders here.

As you can see the migration from legacy public folders to modern public folders is complex enough that sufficient planning and testing will need to be completed. Even though Microsoft has made great strides to simplify public folders. Let’s be honest though - even with these enhancements public folders are still a pain to deal with. A special thank you to all those customers that have already decommissioned public folders and use SharePoint instead. At least the public folder migrations are now easier than they are hard. Sigh.


1 comment:

  1. Its an extraordinary delight perusing your post.Its loaded with data I am searching for and I want to post a remark that "The substance of your post is marvelous" Great work.