Export (0) Print
Expand All

FAQ: Public folders

 

Applies to: Exchange Server 2013

Topic Last Modified: 2014-10-22

This topic provides you with a list of frequently asked questions regarding public folders in Exchange Server 2013. To learn more about public folders, see Public folders.

Have questions about public folders that aren’t answered here? Send us an email at Ex2013HelpFeedback@microsoft.com.

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, and Outlook 2011 for Mac users can access public folders. However, users whose mailboxes are on Exchange 2013 servers won’t be able to connect to Exchange 2007 or Exchange 2010 public folders from clients that use Exchange Web Services (EWS), such as Outlook for Mac. We recommend that you migrate legacy public folders to Exchange 2013 in order to maintain access for those users.

Outlook Web App is supported, but with some limitations. You can add and remove favorite public folders (if they are Mail or Post 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 Web App:

  • 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 Web App and Outlook 2011 for Mac aren’t supported for cross-premises public folders. Users must be in the same location as the public folders to access them with Outlook 2011 for Mac or Outlook Web App.

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

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

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.

During the finalization stage in migration, a lock is placed on the source server to make it inaccessible to user. 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 2013.

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.

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

Resume-PublicFolderMigrationRequest \PublicFolderMigration

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

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.

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