Export (0) Print
Expand All

Migrate legacy public folders to Office 365 and Exchange Online

Exchange Online
 

Applies to: Exchange Server 2013, Exchange Online

This topic describes how to migrate your public folders in a cutover or staged migration from Exchange Server 2010 Service Pack 3 (SP3) or Exchange 2007 SP3 RU10 to Office 365 or Exchange Online. For more information about migrating legacy public folders to Exchange Server 2013, see Migrate public folders to Exchange 2013 from previous versions.

NoteNote:
This topic refers to the Exchange 2010 SP3 and Exchange 2007 SP3 RU10 servers as the legacy Exchange server. Also, the steps in this topic apply to both Exchange Online and Office 365. The terms may be used interchangeably in this topic.

We recommend that you don’t use Outlook’s PST export feature to migrate public folders to Office 365 or Exchange Online. Office 365 and Exchange online public folder mailbox growth is managed using an auto-split feature that splits the public folder mailbox when it exceeds size quotas. Auto-split can’t handle the sudden growth of public folder mailboxes when you use PST export to migrate your public folders and you may have to wait for up to two weeks for auto-split to move the data from the primary mailbox. We recommend that you use the cmdlet-based instructions in this document to migrate public folders to Office 365 and Exchange Online. However, if you elect to migrate public folders using PST export, see the section Migrate Public Folders using PST files later in this topic.

You’ll perform the migration by using the *PublicFolderMigrationRequest cmdlets, in addition to the following PowerShell scripts:

  • Export-PublicFolderStatistics.ps1   This script creates the folder name-to-folder size mapping file. You’ll run this script on the legacy Exchange server.

  • 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 by using the output from the Export-PublicFolderStatistics.ps1 script. You’ll run this script on the legacy Exchange server.

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

  • Export-MailPublicFoldersForMigration.ps1   This script exports the mail-enabled public folder objects from the on-premises organization’s Active Directory into a .csv file. You’ll run this script on the legacy Exchange server.

  • Import-MailPublicFoldersForMigration.ps1   This script uses the .csv file generated by the Export-MailPublicFoldersForMigration.ps1 script to import the mail-enabled public folder objects into Office 365 or Exchange Online. You’ll run this script in Office 365.

  • MailPublicFolder.strings.psd1   This is a support file used by the Import and Export scripts and should be copied to the same location as the preceding scripts.

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.

Exchange supports moving your public folders to Office 365 and Exchange Online from the following legacy versions of Exchange Server:

  • Exchange 2010 SP3 or later

  • Exchange 2007 SP3 RU10 or later

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.

  • In Office 365 and Exchange Online, you must be a member of the Organization Management role group. This role group is different from the permissions assigned to you when you subscribe to Office 365 or Exchange Online. For details about how to enable the Organization Management role group, see Manage role groups.

  • In Exchange 2010, you must be a member of the Organization Management or Server Management RBAC 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.

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

  • Before migration, if any public folder in your organization is greater than 2 GB, we recommend either deleting content from that folder or splitting it up into multiple public folders. If either of these options isn’t feasible, we recommend that you do not move your public folders to Office 365 and Exchange Online.

  • In Office 365 and Exchange Online, the default limit is 50 public folder mailboxes. Office 365 will allow you to automatically upgrade to 100 public folder mailboxes if you exceed this amount. If you need to exceed 100 public folder mailboxes, contact Office 365 support to request additional public folder mailboxes and your request will be evaluated.

  • Before you migrate your public folders, we recommend that you first move all user mailboxes to Office 365 and Exchange Online. For details, see Mailbox Migration to Exchange Online.

  • Outlook Anywhere must be enabled on the legacy Exchange server. For details about enabling Outlook Anywhere on Exchange 2010 servers, see Enable Outlook Anywhere. For details about enabling Outlook Anywhere on Exchange 2007 servers, see How to Enable Outlook Anywhere.

  • You can’t use the Exchange admin center (EAC) or the Exchange Management Console (EMC) to perform this procedure. On the legacy Exchange servers, you must use the Exchange Management Shell. For Exchange Online, you must use Exchange Online PowerShell. For more information, see Connect to Exchange Online using remote PowerShell.

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

  • 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. For example, C:\PFScripts.

  3. Download the following scripts from Microsoft Exchange 2013 Public Folders Directory Sync Support Scripts:

    1. Export-MailPublicFoldersForMigration.ps1

    2. Import-MailPublicFoldersForMigration.ps1

    3. MailPublicFolder.strings.psd1

  4. Save the scripts to the same location you did for step 2. For example, C:\PFScripts.

Perform the following prerequisite steps before you begin the migration.

Prerequisite steps on the legacy Exchange server

  1. On the legacy Exchange server, make sure that routing to the mail-enabled public folders that will exist in Office 365 or Exchange Online continues to work until all DNS caches over the Internet are updated to point to the Office 365 or Exchange Online DNS where your organization now resides. To do this, run the following command to configure an accepted domain with a well-known name that will properly route email messages to the Office 365 or Exchange Online domain.

    New-AcceptedDomain -Name "PublicFolderDestination_78c0b207_5ad2_4fee_8cb9_f373175b3f99" -DomainName contoso.onmicrosoft.com -DomainType InternalRelay 
    
  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.

    1. The following example checks the public folder migration status.

      Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete
      
    2. 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 up to two hours to complete.
  4. 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 -ResultSize Unlimited | 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.

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

Prerequisite steps in Office 365 or Exchange Online

  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 won’t affect the new migration. The following example removes any existing public folder migration requests.

    ImportantImportant:
    Before removing the migration request, it is important to understand why there was an existing one. You can run the following command to determine when a previous request was made and diagnose any problems that may have occurred. You may need to communicate with other administrators in your organization to determine why the change was made.
    Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List
    Get-PublicFolderMigrationRequest | Remove-PublicFolderMigrationRequest -Confirm:$false
    
  2. Make sure no public folders or public folder mailboxes exist in Office 365.

    ImportantImportant:
    If you do see public folders in Office 365 or Exchange Online, it is important to determine why they are there and who in your organization started a public folder hierarchy before removing the public folders and public folder mailboxes.
    1. In Office 365 or Exchange Online PowerShell, run the following command to see if any public folders mailboxes exist.

      Get-Mailbox -PublicFolder 
      
    2. If the command didn’t return any public folder mailboxes, continue to Step 3: Generate the CSV files. If the command returned any public folders mailboxes, run the following command to see if any public folders exist:

      Get-PublicFolder
      
    3. If you have any public folders in Office 365 or Exchange Online, run the following PowerShell command to remove them.

      Get-MailPublicFolder | where {$_.EntryId -ne $null}| Disable-MailPublicFolder -Confirm:$false 
      Get-PublicFolder -GetChildren \ | Remove-PublicFolder -Recurse -Confirm:$false
      
    4. After the public folders are remvoved, run the following commands to remove all public folder mailboxes.

      $hierarchyMailboxGuid = $(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid
      Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -ne $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false
      Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -eq $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -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. This script must always be run by a local administrator. The file will contain two columns: FolderName and FolderSize. The values for the FolderSize column will be displayed in 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. Later in this topic, you’ll need to use the Exchange Online PowerShell to access this file. If you specify only the file name, the file will be generated in the current PowerShell directory on the local computer.

  2. Run the PublicFolderToMailboxMapGenerator.ps1 script to create the public folder-to-mailbox mapping file. This file is used to calculate the correct number of public folder mailboxes in Exchange Online.

    .\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. In Exchange Online, the maximum size of public folder mailboxes is 50 GB. We recommend that you set this setting to 15 GB so that each public folder mailbox has room for growth. If you have one single public folder that exceeds 2 GB, that public folder won’t get added to the .csv file. The following are some options for how you can fix this issue:

      • Before you run the script, delete public folder content to reduce the size to 2 GB or less.

      • Before you run the script, split the public folder into multiple public folders that are each 2 GB or less.

      • If the public folder is greater than 2 GB but no more than 30 GB, you can manually add it to the .csv file after you’ve run the script. The public folder will be created in Exchange Online.

      NoteNote:
      If the public folder is greater than 30 GB and deleting content or splitting it into multiple public folders isn’t feasible, we recommend that you don’t move your public folders to Exchange Online.
    • 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 the current PowerShell directory on the local computer.

WarningWarning:
The names 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 primary public folder mailbox in Exchange Online. The first public folder mailbox that you create will be the primary hierarchy mailbox. You must create the first public folder mailbox in HoldForMigration mode. In addition, Exchange will automatically exclude the public folder mailboxes from the serving hierarchy so that the public folders won’t be available to Exchange Online users.

    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. The maximum number of public folder mailboxes that you can create is 50.

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

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

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

  1. On the legacy Exchange server, run the following command to create the .xml file that will export the set of mail-enabled public folders from Active Directory.

    .\Export-MailPublicFoldersForMigration.ps1 <mail_publicfolders.xml>
    
  2. On the legacy Exchange server, get the following information that’s needed to run the migration request:

    1. Find the LegacyExchangeDN of the user’s account who is a member of the Public Folder Administrator role. This will be the same user whose credentials you need in step 3 of this procedure.

      Get-Mailbox <PublicFolder_Administrator_Account> | Select-Object LegacyExchangeDN
      
    2. Find the FQDN of any Mailbox server that has a public folder database.

      Get-ExchangeServer <public folder server> | Select-Object -Expand ExchangeLegacyDN
      
    3. Find the FQDN of the Outlook Anywhere host name. If you have multiple instances of Outlook Anywhere, we recommend that you select the instance that is either closest to the migration endpoint or the one that is closest to the public folder replicas in the legacy Exchange organization. The following command will find all instances of Outlook Anywhere:

      Get-OutlookAnywhere | Format-Table Identity,ExternalHostName
      
  3. In Office 365 PowerShell, run the following commands to pass the information that you was returned in the previous step to variables that will then be used in the migration request.

    1. Pass the credential of a user who has administrative permissions on the legacy Exchange server into the variable $source_credential. The migration request that’s run in Exchange Online will use this credential to gain access to your legacy Exchange servers to copy the content over.

      $source_credential = Get-Credential <source_domain\PublicFolder_Administrator_Account>
      
    2. Use the ExchangeLegacyDN of the migration user on the legacy Exchange server that you found in step 2a and pass it into the variable $source_remoteMailboxLegacyDN.

      $source_remoteMailboxLegacyDN = "<paste the value here>"
      
    3. Use the ExchangeLegacyDN of the public folder server that you found in step 2b above and pass it into the variable $source_remotePublicFolderServerLegacyFQDN.

      $source_remotePublicFolderServerLegacyFQDN = "<paste the value here>"
      
    4. Use the External Host Name of Outlook Anywhere that you found in step 2c above and pass it into the variable $source_OutlookAnywhereExternalHostName.

      $source_OutlookAnywhereExternalHostName = "<paste the value here>"
      
  4. In Exchange Online PowerShell, run the following command to import the migration .xml file.

    .\Import-MailPublicFoldersForMigration.ps1 <mail_publicfolders.xml>
    
  5. Finally, in Exchange Online PowerShell, run the following command to start the migration request.

    NoteNote:
    The authentication method in the following shell example needs to match your Outlook Anywhere settings, otherwise the command will fail.
    New-PublicFolderMigrationRequest -OutlookAnywhereHostName: $source_OutlookAnywhereExternalHostName -CSVData (Get-Content <folder_mapping.csv> -Encoding Byte) -RemoteCredential: $source_credential -RemoteMailboxLegacyDN: $source_remoteMailboxLegacyDN -RemoteMailboxServerLegacyDN: $source_remotePublicFolderServerLegacyFQDN -AuthenticationMethod Basic 
    

    Where the <folder_mapping.csv> file is the file that was generated in Step 3: Generate the .csv files.

  6. To verify that the migration started successfully, in Exchange Online PowerShell, 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 or network performance, the typical data copy rate can be 2 GB to 3 GB per hour. The actual data speeds may vary depending on server configuration and network latency of the on-premises organization.

  7. 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 finalize the migration, we recommend that you run the Resume-PublicFolderMigrationRequest cmdlet from Exchange Online PowerShell 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 legacy 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 in the Office 365 or Exchange Online PowerShell, 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 the following topics:

Set-PublicFolderMigrationRequest

Resume-PublicFolderMigrationRequest

Set-OrganizationConfig

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 Office 365 or Exchange Online public folders.

  1. In Office 365 or Exchange Online PowerShell, 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:

    • View the hierarchy.

    • Check permissions.

    • Create and delete public folders.

    • 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 Exchange Online PowerShell command to unlock the public folders for all other users.

    Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false
    
    ImportantImportant:
    Don’t use the IsExcludedFromServingHierarchy parameter after initial migration validation is complete as this parameter is used by the automated storage management service for Exchange Online.
  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 Exchange Online PowerShell to make sure that the PublicFoldersEnabled parameter on Set-OrganizationConfig is set to Local:

    Set-OrganizationConfig -PublicFoldersEnabled Local
    
    

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

Set-Mailbox

Get-Mailbox

Set-OrganizationConfig

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. In Exchange Online PowerShell, run the following command to take a snapshot of the new folder structure.

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

    Get-PublicFolderStatistics -ResultSize Unlimited | Export-CliXML  C:\PFMigration\Cloud_PFStatistics.xml
    
  3. In Exchange Online PowerShell, 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\Cloud_PFPerms.xml
    

After the migration is complete, and you have verified that your Exchange Online 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:
If you roll your migration back to the legacy Exchange servers, you will lose any email that was sent to mail-enabled public folders or content that was posted to public folders after the migration. To save this content, you must export the public folder content to a .pst file and then import it to the legacy public folders when the rollback is complete.
  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. In Exchange Online PowerShell, run the following commands to remove all Exchange Online public folders.

    $hierarchyMailboxGuid = $(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid
    Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -ne $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force
    Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -eq $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false -Force
    
  3. On the legacy Exchange server, run the following command to set the PublicFolderMigrationComplete flag to $false.

    Set-OrganizationConfig -PublicFolderMigrationComplete:$False
    

We recommend that you don’t use Outlook’s PST export feature to migrate public folders to Office 365 or Exchange Online if your on-premises public folder hierarchy is greater than 30 GB. Office 365 online public folder mailbox growth is managed using an auto-split feature that splits the public folder mailbox when it exceeds size quotas. Auto-split can’t handle the sudden growth of public folder mailboxes when you use PST export to migrate your public folders and you may have to wait for up to two weeks for auto-split to move the data from the primary mailbox. In addition, consider the following before using Outlook PST to export public folders to Office 365 or Exchange Online:

  • Public folder permissions will be lost during this process. Capture the current permissions before migration and manually add them back once the migration is completed.

  • If you use complex permissions or have many folders to migrate, we recommend that you use the cmdlet method for migration.

  • Any item and folder changes made to the source public folders during the PST export migration will be lost. Therefore, we recommend that you use the cmdlet method if this export and import process will take a long time to complete.

If you still want to migrate your public folders by using PST files, follow these steps to ensure a successful migration.

  1. Use the instructions in Step 1: Download the migration scripts to download the migration scripts. You only need to download the PublicFolderToMailboxMapGenerator.ps1 file.

  2. Follow step 2 of Step 3: Generate the .csv files to create the public folder-to-mailbox mapping file. This file is used to calculate the correct number of public folder mailboxes in Exchange Online.

  3. Create the public folder mailboxes that you’ll need based on the mapping file. For more information, see Create a public folder mailbox.

  4. Use the New-PublicFolder cmdlet to create the top-most public folder in each of the public folder mailboxes by using the Mailbox parameter.

  5. Export and import the PST files using Outlook.

  6. Set the permissions on the public folders using the EAC. For more information, follow Step 3: Assign permissions to the public folder in the Set up public folders in a new organization topic.

WarningWarning:
If you’ve already started a PST migration and have run into an issue where the primary mailbox is full, you have two options for recovering the PST migration:
  1. Wait for the auto-split to move the data from the primary mailbox. This may take up to two weeks. However, all the public folders in a completely filled public folder mailbox won’t be able to receive new content until the auto-split completes.

  2. Create a public folder mailbox and then use the New-PublicFolder cmdlet with the Mailbox parameter to create the remaining public folders in the secondary public folder mailbox. This example creates a new public folder named PF201 in the secondary public folder mailbox.

    New-PublicFolder -Name PF201 -Mailbox SecondaryPFMbx
    

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft