FAQ about public folder migration

This article contains frequently asked questions about public folder migrations.

To learn more about public folders, see Public folders.

For more information on public folder migrations, see:

• Use batch migration to migrate Exchange 2010 public folders to Exchange 2016
• Migrate public folders from Exchange 2013 to Exchange 2016 or Exchange 2019
• Use batch migration to migrate legacy public folders to Microsoft 365, Office 365, or Exchange Online
• Use batch migration to migrate Exchange Server public folders to Exchange Online
• Use batch migration to migrate Exchange Server public folders to Microsoft 365 Groups

The following list details the available options for migrating public folders to Exchange or Exchange Online.

• Exchange 2010 public folders (SP3 RU8 or later) can be migrated to Exchange 2016, Exchange Online, or Microsoft 365 groups.

• Exchange 2013 public folders (CU15 or later) can be migrated to Exchange 2016, Exchange 2019, Exchange Online, or Microsoft 365 groups.

• Exchange 2016 public folders (CU4 or later) can be migrated to Exchange Online or Microsoft 365 groups.

• Exchange 2019 public folders can be migrated to Exchange Online or Microsoft 365 groups.

Currently only migrations to Exchange 2016 or Exchange 2019 in the same Active Directory forest are supported. The cross forest migration of public folders from Exchange 2013, Exchange 2016 or Exchange 2019 to another Exchange On-Premises organization is not supported.

During the finalization stage in migration, a lock is placed on the source server to make it inaccessible to users. This lock remains in place to prevent users from accessing the source public folders after migration completes. Although you can release this lock, we don't recommend doing so because the changes can't be synced to Exchange 2016.

Public folder rules are migrated along with the data and are kept as public folder rules. They aren't converted to mailbox rules.

The .csv file is used to determine the mapping between the source hierarchy and the destination mailbox. It contains only the top-level folders. Child folders under the top-level folders are automatically migrated. Therefore, if a new child folder is added, it's migrated during the process. If a new top-level folder is created, it will be created in the mailbox that contains the writable copy of the hierarchy.

As part of the migration process, a .csv file is generated (using the publicfoldertomailboxmapgenerator.ps1 script). This file contains the folder-to-mailbox mapping for the new hierarchy. You can use this .csv file to create public folder mailboxes in the appropriate geographic location and modify the file to place the required folders in the appropriate mailbox so they are near the target users.

The input .csv file can be generated by running the script AggregatePFData.ps1, located in the directory < Exchange Installation Directory>\V15\Scripts. Run the script as follows:

.\AggregatePFData.ps1 | Select-Object -property @{Name="FolderName"; Expression = {$_.Identity}}, @{Name="FolderSize"; Expression = {$_.TotalItemSize.Value.ToBytes()}} | Export-CSV -Path <Path followed by the name of the CSV>

Yes, permissions automatically migrate at the folder level with the data. You don't have to perform this step separately.

No. Public folders are great for Outlook integration, simple sharing scenarios, and for allowing large audiences to access the same data.

The currently supported Outlook clients for Exchange Server can access public folders. However, users with mailboxes on Exchange 2016 servers can't connect to Exchange 2010 public folders using Exchange Web Services (EWS) clients (for example, Outlook 2016 for Mac). We recommend that you migrate Exchange 2010 public folders to Exchange 2016 to maintain access for those users.

Public folder access works from Outlook for Windows desktop and Outlook for Mac. However, smart phone client apps including Outlook for Android or Outlook for iOS do not support connecting to public folders.

If you would like to have functionality similar to public folders with content accessible on mobile devices, consult Learn about Microsoft 365 Groups for an alternative.

Outlook on the web (formerly known as Outlook Web App) is supported, but with some limitations. You can add and remove public folders to your Favorites (if they are Mail, Post, Calendar, or Contact public folders) and perform item level operations, such as creating, editing, deleting posts, and replying to posts. But, you can't do the following in Outlook on the web:

• Create or delete public folders

• Drag-and-drop content

• Access public folders located on servers running previous versions of Exchange

In a hybrid scenario, Outlook on the web isn't supported for cross-premises public folders. Users must be in the same location as the public folders to access them with Outlook on the web. Outlook 2016 for Mac users can access public folders in a hybrid scenario if the following conditions are true:

• You've followed the procedures at Hybrid Deployment procedures.

• The April 2016 update for Outlook 2016 for Mac has been installed on all clients.

For more information about public folder storage limits, see Limits for public folders.

Run the following command:

Get-OrganizationConfig | Format-List RootPublicFolderMailbox

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

Run the following command to create the first master hierarchy public folder mailbox and the secondary hierarchy mailboxes.

New-Mailbox -PublicFolder -Name <name of public folder>

For more detail, see Create a public folder.

There's no longer a database-level setting. Instead, Exchange has a mailbox-level ability to specify the public folder mailbox, but by default Exchange auto-calculates the per-user hierarchy mailbox.

You can use Get-PublicFolderStatistics and Get-PublicFolderItemStatistics cmdlets to get public folder metrics data. This same solution hase been available since Exchange 2010, so nothing has changed here. Public folders don't require additional reporting add-ons.

Starting in Exchange 2013, public folder permissions are managed by using role-based access control (RBAC); access control lists (ACLs) no longer used. You can use Get-PublicFolderStatistics and Get-PublicFolderItemStatistics cmdlets to keep track of accounts that are performing administrative tasks and then audit access accordingly. To learn more about RBAC, see Understanding Role Based Access Control.

No. Not at this time.

If you would like to have functionality similar to public folders with audit logging, consult Learn about Microsoft 365 Groups for an alternative.

For more information about public folder limits, see Limits for public folders.

In previous versions of Exchange, you could split public folders across public folder databases. You can decide whether to split the content of a public folder mailbox to a mailbox on the same mailbox database or a different database. Typically, a split is recommended to be on a separate database, because you want to balance storage and I\O.

Just like in previous versions of Exchange, you can set retention limits on items. For details, see Limits for public folders.

In Exchange 2010, you could specify which users had access to specific public folders. In Exchange 2013 or later, you can set the default public folder mailbox per user. To do so, run the Set-Mailbox cmdlet with the DefaultPublicFolderMailbox parameter. For example:

Set-Mailbox -Identity kweku@contoso.com -DefaultPublicFolderMailbox "PF_Administration"

If the master hierarchy public folder mailbox goes down, users can view but not write to public folders. To help prevent the hierarchy from going down, we recommend that you include your public folders in a database availability group (DAG). To learn about DAGs, see Database availability groups.

No. If you try to change the master hierarchy mailbox, you'll receive an error.

Yes, full text search has been available for public folders since Exchange 2013. However, you can't search across multiple public folders.