Export (0) Print
Expand All

Migrate public folders to Exchange 2013 from previous versions

 

Applies to: Exchange Server 2013

This topic describes how to migrate your public folders from Exchange Server 2010 SP3 or Exchange 2007 SP3 RU10 to Microsoft Exchange Server 2013 within the same forest.

NoteNote:
This topic refers to the Exchange 2010 SP3 and Exchange 2007 SP3 RU10 servers as the legacy Exchange server.

You’ll perform the migration by using the *PublicFolderMigrationRequest cmdlets (which use the Microsoft Exchange Mailbox Replication service to perform the migration tasks), in addition to the following PowerShell scripts:

  • Export-PublicFolderStatistics.ps1   This script creates the folder name-to-folder size mapping file.

  • Export-PublicFolderStatistics.psd1   This support file is used by the Export-PublicFolderStatistics.ps1 script and should be downloaded to the same location.

  • PublicFolderToMailboxMapGenerator.ps1   This script creates the public folder-to-mailbox mapping file.

  • PublicFolderToMailboxMapGenerator.strings.psd1   This support file is used by the PublicFolderToMailboxMapGenerator.ps1 script and should be downloaded to the same location.

Step 1: Download the migration scripts provides details about where to download these scripts.

For additional management tasks related to public folders, see Public folder procedures.

For details about how to migrate public folders to Exchange Online, see Migrate legacy public folders to Office 365 and Exchange Online.

Exchange supports moving your public folders from the following legacy versions of Exchange Server:

  • Exchange Server 2010 SP3

  • Exchange Server 2007 SP3 RU10

You can’t migrate public folders directly from Exchange 2003. If you’re running Exchange 2003 in your organization, you must move all public folder databases and replicas to Exchange 2007 SP3 RU10 or later. No public folder replicas can remain on Exchange 2003.

  • You must be assigned the following permissions before you can perform this procedure:

    • In Exchange 2013, you must be a member of the Organization Management role group. For details, see Manage role groups.

    • In Exchange 2010, you must be a member of the Organization Management or Server Management role groups. For details, see Add Members to a Role Group.

    • In Exchange 2007, you need to be assigned the Exchange Organization Administrator role or the Exchange Server Administrator role. In addition, you must be assigned the Public Folder Administrator role and local Administrators group for the target server. For details, see How to Add a User or Group to an Administrator Role.

  • Before you migrate, you should consider the Limits for public folders.

  • Before you begin, we recommend that you read this topic in its entirety as downtime is required for some steps.

  • Before you migrate your public folders, we recommend that you first move all user mailboxes to Exchange 2013. For details, see Mailbox moves in Exchange 2013.

  • The Exchange 2010 server must be running SP3 or later.

  • The Exchange 2007 server must be running SP3 RU10 or later.

  • On the Exchange 2007 server, upgrade to Windows PowerShell 2.0 and WinRM 2.0 for Windows Server 2008 x64 Edition.

  • For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.

TipTip:
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Server, Exchange Online, or Exchange Online Protection.

  1. Download all four of the Microsoft Exchange 2013 public folder migration scripts.

  2. Save the scripts to the local computer on which you’ll be running PowerShell from. For example, C:\PFScripts.

Perform the following prerequisite steps before you begin the migration.

Prerequisite steps on the legacy Exchange server

  1. For verification purposes at the end of migration, we recommend that you first run the following Shell commands on the legacy Exchange server to take snapshots of your current public folder deployment.

    1. Run the following command to take a snapshot of the original source folder structure.

      Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml
      
    2. Run the following command to take a snapshot of public folder statistics such as item count, size, and owner.

      Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml
      
    3. Run the following command to take a snapshot of the permissions.

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

    Save the information from the preceding commands for comparison at the end of the migration.

  2. If the name of a public folder contains a backslash \, the public folders will be created in the parent public folder when migration occurs. Before you migrate, we recommend that you rename any public folders that have a backslash in the name.

    1. In Exchange 2010, to locate public folders that have a backslash in the name, run the following command:

      Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like "*\*"} | Format-List Name, Identity
      
      
    2. In Exchange 2007, to locate public folders that have a backslash in the name, run the following command:

      Get-PublicFolderDatabase | ForEach {Get-PublicFolderStatistics -Server $_.Server | Where {$_.Name -like "*\*"}}
      
    3. If any public folders are returned, you can rename them by running the following command:

      Set-PublicFolder -Identity <public folder identity> -Name <new public folder name>
      
  3. Make sure there isn’t a previous record of a successful migration. If there is, you’ll need to set that value to $false. If the value is set to $true the migration request will fail.

    The following example checks the public folder migration status.

    Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete
    

    If the status of the PublicFoldersLockedforMigration or PublicFolderMigrationComplete properties is $true, run the following command to set the value to $false.

    Set-OrganizationConfig -PublicFoldersLockedforMigration:$false -PublicFolderMigrationComplete:$false
    
    WarningWarning:
    After resetting these properties, you must wait for Exchange to detect the new settings. This may take several minutes. .

For detailed syntax and parameter information, see the following topics:

Prerequisite steps on the Exchange 2013 server

  1. Make sure there are no existing public folder migration requests. If there are, clear them. This step is a prerequisite and isn’t required in all cases. It’s only required if you think there may be an existing migration request in the pipeline. In any case, the following command below won’t affect the new migration. The following example removes any existing public folder migration requests.

    Get-PublicFolderMigrationRequest | Remove-PublicFolderMigrationRequest -Confirm:$false
    
  2. To make sure there are no existing public folders on the Exchange 2013 servers, run the following commands.

    Get-Mailbox -PublicFolder 
    Get-PublicFolder
    

    If the above commands return any public folders, use the following commands to remove the public folders.

    Get-Mailbox -PublicFolder | Where{$_.IsRootPublicFolderMailbox -eq $false} | Remove-Mailbox -PublicFolder -Force -Confirm:$false
    Get-Mailbox -PublicFolder | Remove-Mailbox -PublicFolder -Force -Confirm:$false
    

For detailed syntax and parameter information, see the following topics:

  1. On the legacy Exchange server, run the Export-PublicFolderStatistics.ps1 script to create the folder name-to-folder size mapping file. The file will contain two columns: FolderName and FolderSize. The values for the FolderSize column will be in displayed bytes. For example, \PublicFolder01,10000.

    .\Export-PublicFolderStatistics.ps1 <Folder to size map path> <FQDN of source server>
    
    • FQDN of source server equals the fully qualified domain name of the Mailbox server where the public folder hierarchy is hosted.

    • Folder to size map path equals the file name and path on a network shared folder where you want the .csv file saved. You’ll need to access this file from the Exchange 2013 server. If you specify only the file name, the file will be generated in its current location.

  2. Run the PublicFolderToMailboxMapGenerator.ps1 script to create the public folder-to-mailbox mapping file. This file is used to create the correct number of public folder mailboxes on the Exchange 2013 Mailbox server.

    NoteNote:
    If the name of a public folder contains a backslash \, the public folders will be created in the parent public folder. We recommend that you review the .csv file and edit any names that contain the backslash.
    .\PublicFolderToMailboxMapGenerator.ps1 <Maximum mailbox size in bytes> <Folder to size map path> <Folder to mailbox map path>
    
    • Maximum mailbox size in bytes equals the maximum size you want to set for the new public folder mailboxes.

      NoteNote:
      When specifying this setting, be sure to allow for expansion so the public folder mailbox has room to grow.
    • Folder to size map path equals the file path of the .csv file you created when running the Export-PublicFolderStatistics.ps1 script.

    • Folder To mailbox map path equals the file name and path of the folder-to-mailbox .csv file that you’ll create with this step. If you specify only the file name, the file will be generated in its current location.

WarningWarning:
The name of the public folder mailboxes that you create must match the name of the TargetMailbox in the mapping file. You can edit the TargetMailbox names in the mapping file to match your organization’s naming conventions.
  1. Run the following command to create the first public folder mailbox on the Exchange 2013 Mailbox server. Public folder mailboxes contain the hierarchy information for a public folder, whereas the public folder contains the actual content. The first public folder mailbox that you create will be the master hierarchy mailbox. You need to create the first public folder mailbox in HoldForMigration mode.

    New-Mailbox -PublicFolder <Name> -HoldForMigration:$true
    
  2. Run the following command to create additional public folder mailboxes as needed based on the .csv file generated from the PublicFoldertoMailboxMapGenerator.ps1 script. For example, if you open the .csv file, the public folders are named Mailbox1, Mailbox2, etc. If your last public folder is named Mailbox13, you’ll need to create 13 public folder mailboxes.

    If you need to create several public folder mailboxes, you can write a script to help automate the process. This example creates 25 public folder mailboxes.

    $numberOfMailboxes = 25; 
    for($index =1 ; $index -le $numberOfMailboxes ; $index++)
    {
        $PFMailboxName = "Mailbox"+$index;  if($index -eq 1) {New-Mailbox -PublicFolder $PFMailboxName -HoldForMigration:$true -IsExcludedFromServingHierarchy:$true;}else{New-Mailbox -PublicFolder $PFMailboxName -IsExcludedFromServingHierarchy:$true}
    }
    
    

For detailed syntax and parameter information, see New-Mailbox.

The steps for migrating Exchange 2007 public folders are different from the steps for migrating Exchange 2010 public folders. Make sure that you follow the correct procedure.

Migrate Exchange 2007 public folders

  1. Legacy system public folders such as OWAScratchPad and the schema-root folder subtree in Exchange 2007 won’t be recognized by Exchange 2013 and will be treated as bad items. This will cause the migration to fail. As part of the migration request, you must specify a value for the BadItemLimit parameter. This value will vary depending on the number of public folder databases you have. The following commands will determine how many public folder databases you have and compute the BadItemLimit for the migration request.

    $PublicFolderDatabasesInOrg = @(Get-PublicFolderDatabase)
    
    $BadItemLimitCount = 5 + ($PublicFolderDatabasesInOrg.Count -1)
    
  2. From the Exchange 2013 Mailbox server, run the following command:

    New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server <Source server name>) -CSVData (Get-Content <Folder to mailbox map path> -Encoding Byte) -BadItemLimit $BadItemLimitCount
    
  3. To verify that the migration started successfully, run the following command.

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

    You’ll know that the command started successfully when the migration request reaches a status of Queued or InProgress. Depending on how much data is contained in the public folders, this command can take a long time to complete. If migration isn’t being throttled due to the load on the destination server, the typical data copy rate can be 2 GB to 3 GB per hour.

  4. You can periodically run the preceding command to check the status of the migration request. When the status reaches AutoSuspended, you can move to Step 6: Lock down the public folders on the legacy Exchange server for final migration (downtime required).

Migrate Exchange 2010 public folders

  1. From the Exchange 2013 Mailbox server, run the following command:

    New-PublicFolderMigrationRequest -SourceDatabase (Get-PublicFolderDatabase -Server <Source server name>) -CSVData (Get-Content <Folder to mailbox map path> -Encoding Byte)
    
  2. To verify that the migration started successfully, run the following command.

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

    You’ll know that the command started successfully when the migration request reaches a status of Queued or InProgress. Depending on how much data is contained in the public folders, this command can take a long time to complete. If migration isn’t being throttled due to the load on the destination server, the typical data copy rate can be 2 GB to 3 GB per hour.

  3. You can periodically run the preceding command to check the status of the migration request. When the status reaches AutoSuspended, you can move to Step 6: Lock down the public folders on the legacy Exchange server for final migration (downtime required).

For detailed syntax and parameter information, see the following topics:

WarningWarning:
The amount of downtime required depends on how much new content was generated since the migration reached the AutoSuspended state. If a long time has passed between the migration request reaching an AutoSuspended state and when you can finalization the migration, we recommend that you run the following command so you can synchronize the changes made since the original synchronization. This will reduce the amount of downtime required to finalize the migration.
Resume-PublicFolderMigrationRequest \PublicFolderMigration

Until this point in the migration, users have been able to access public folders. The next steps will log users off from the public folders and lock the folders while the migration completes its final synchronization. Users won’t be able to access public folders during this process. Also, any mail sent to mail-enabled public folders will be queued and won’t be delivered until the public folder migration is complete.

On the legacy Exchange server, run the following command to lock the legacy public folders for finalization.

Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

For detailed syntax and parameter information, see Set-OrganizationConfig.

If your organization has multiple public folder databases, you’ll need to wait until public folder replication is complete to confirm that all public folder databases have picked up the PublicFoldersLockedForMigration flag and any pending changes users recently made to folders have converged across the organization. This may take several hours.

By default, when you run the Set-PublicFolderMigrationRequest cmdlet, it won’t complete until you remove the PreventCompletion flag and resume the migration request.

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

For detailed syntax and parameter information, see Set-PublicFolderMigrationRequest and Resume-PublicFolderMigrationRequest.

After you finalize the public folder migration, you should run the following test to make sure that the migration was successful. This allows you to test the migrated public folder hierarchy before you switch to using Exchange 2013 public folders.

  1. Run the following command in the Shell on the Exchange 2013 server to assign some test mailboxes to use any newly migrated public folder mailbox as the default public folder mailbox.

    Set-Mailbox -Identity <Test User> -DefaultPublicFolderMailbox <Public Folder Mailbox Identity>
    
  2. Log on to Outlook 2007 or later with the test user identified in the previous step, and then perform the following public folder tests:

    1. View the hierarchy.

    2. Check permissions.

    3. Create and delete public folders.

    4. Post content to and delete content from a public folder.

  3. If you run into any issues, see Roll back the migration later in this topic. If the public folder content and hierarchy is acceptable and functions as expected, run the following command to unlock the public folders for all other users.

    Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
    
  4. On the legacy Exchange server, run the following command to indicate that the public folder migration is complete:

    Set-OrganizationConfig -PublicFolderMigrationComplete:$true
    
  5. After you've verified that migration is complete, run the following command in the Shell on the Exchange 2013 server to make sure that the PublicFoldersEnabled parameter on Set-OrganizationConfig is set to Local:

    Set-OrganizationConfig -PublicFoldersEnabled Local
    
    

In Step 2: Prepare for the migration, you were instructed to take snapshots of the public folder structure, statistics, and permissions before the migration began. The following steps will help verify that your public folder migration was successful by taking the same snapshots after the migration is complete. You can then compare the data in both files to verify success.

  1. Run the following command to take a snapshot of the original source folder structure.

    Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\New_PFStructure.xml
    
  2. Run the following command to take a snapshot of the public folder statistics such as item count, size, and owner.

    Get-PublicFolderStatistics | Export-CliXML C:\PFMigration\New_PFStatistics.xml
    
  3. Run the following command to take a snapshot of the permissions.

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

After the migration is complete, and you have verified that your Exchange 2013 public folders are working as expected, you should remove the public folder databases on the legacy Exchange servers.

If you run into issues with the migration and need to reactivate your legacy Exchange public folders, perform the following steps:

WarningWarning:
After the migration is complete, any email to mail-enabled public folders, any change in public folder permissions or hierarchy, or content posted to public folders that occurred after the migration to Exchange 2013 will be lost. As a result, if you roll back the migration, you may lose public folder data or changes made on Exchange 2013 servers. To save this content, export the public folder content to a .pst file before you perform this procedure, and then import the .pst file after your rollback to the legacy public folders.
  1. On the legacy Exchange server, run the following command to unlock the legacy Exchange public folders. This process may take several hours.

    Set-OrganizationConfig -PublicFoldersLockedForMigration:$False
    
  2. On the Exchange 2013 server, run the following command to delete the public folder mailboxes.

    Get-Mailbox -PublicFolder | Where{$_.IsRootPublicFolderMailbox -eq $false} | Remove-Mailbox -PublicFolder -Force -Confirm:$false
    Get-Mailbox -PublicFolder | Remove-Mailbox -PublicFolder -Force -Confirm:$false
    
    
    
    
  3. On the legacy Exchange server, run the following command to set the PublicFolderMigrationComplete flag to $false.

    Set-OrganizationConfig -PublicFolderMigrationComplete:$False
    
 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft