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

Outlook 2007, Outlook 2010, and Outlook 2013 users can access public folders.

Hierarchy records are typically a few KB in size. About a million records will take up one GB of space. So a large number of hierarchy records stored in a public folder mailbox shouldn’t pose a problem.

Run the following command:

	Copy Code
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.

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

For more detail, see Create a Public Folder.

There is no database-level setting in Exchange 2013. Exchange 2013 has a mailbox-level ability to specify the public folder mailbox, but by default Exchange auto-calculates the per-user hierarchy mailbox.

In Exchange 2013, you can use Get-PublicFolderStatistics and Get-PublicFolderItemStatistics cmdlets to get public folder metrics data. This is the same solution that we had in Exchange 2010, so nothing has changed here. Public folders don’t require additional reporting add-ons.

In Exchange 2013, public folder permissions are managed by using Role Based Access Control (RBAC). Access control lists (ACLs) aren’t used in Exchange 2013. 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.

Public folders function similar to mailbox quotas. You can specify large quotas, but similar to mailboxes, at some point the public folders will fill up. The mailbox size limit in Exchange 2013 is 100 GB. The combination of all public folders within the mailbox can’t exceed the mailbox size quota. To control mailbox size, we recommend separating your public folders into multiple public folder mailboxes.

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 Step 1 of Set Up Public Folders in a New Organization.

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

	Copy Code
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 is available for public folders in Exchange 2013. However, you can’t search across multiple public folders.

This section contains frequently asked questions about public folder migration. For more information, see Migrate Public Folders to Exchange 2013 From Previous Versions.

After migration, what happens to the hierarchy on the source Exchange 2010 servers?

When you migrate public folders, what happens to existing public folder rules?

What happens if hierarchy changes are performed on the source after the initial .csv file was generated? How would these reflect on the destination?

During migration to Exchange 2013 public folders, if there’s a long window of time between suspension and finalization, how can I force a delta sync so that users can access public folders during the final sync?

You can force a delta sync to occur before finalization (prior to locking the source) by running the following Shell command:

	Copy Code
Resume-PublicFolderMigrationRequest \PublicFolderMigration

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

For the migration of a geo-distributed hierarchy, how can I make sure that the public folders are created in the location nearest to the target users?

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:

	Copy Code
.\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>

Do existing public folder permissions migrate?