Understanding Public Folders
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Public folders, introduced in the first version of Microsoft Exchange, are designed for shared access and provide an easy and effective way to collect, organize, and share information with other people in your workgroup or organization. Public folders are hierarchically organized, stored in dedicated databases, and can be replicated between servers running Exchange.
Public folders aren't designed for the following purposes:
Archiving data Public folders aren't designed for archiving data. Users who have mailbox limits sometimes use public folders instead of their personal folders (.pst) files to archive data. This practice isn't recommended because it affects storage on public folder servers and undermines the goal of mailbox limits.
Document sharing and collaboration Public folders aren't designed for document sharing and collaboration. Public folders don't provide versioning or other document management features, such as controlled check-in and check-out functionality, and automatic notifications of content changes.
In Exchange Server 2010, public folders are an optional feature. If all client computers in your organization are running Microsoft Outlook 2010 or Office Outlook 2007, there are no dependencies on public folders for features such as free and busy information and offline address book (OAB) downloads. Instead of using public folders for OAB downloads and free and busy information, in Exchange 2010, these features are serviced by the Autodiscover service, the Microsoft Exchange System Attendant service, and the Microsoft Exchange File Distribution service.
Until all client computers in your organization are running Outlook 2010 or Outlook 2007, you should continue using public folders.
Contents
Public Folder Database Creation During Setup
Public Folder Trees
Public Folder Replication
Public Folder Referrals
Mail-Enabled Public Folders
Public Folder Access
Considerations with Mixed Exchange 2010 and Exchange 2007 Organizations
Considerations with Mixed Exchange 2010 and Exchange 2003 Organizations
Updating the Public Folder Hierarchy
Public Folder Content Replication
Best Practices
Public Folder Database Creation During Setup
Computers running Outlook 2003 and earlier or Microsoft Entourage require a public folder database (previously called the public folder store) to connect to Exchange. Therefore, in a pure Exchange 2010 organization, as you install the Mailbox server role on the first server, Setup prompts you with the question: Do you have any client computers running Outlook 2003 and earlier or Entourage in your organization? If the answer is yes, a public folder database is created. If the answer is no, a public folder database isn't created.
When you install the second server, you aren't prompted with the question, and Setup doesn't create a public folder database. Whether a public folder database is needed in the organization is decided only when you install the first server. After that, all public folder databases are optional. If you don't create a public folder database during Setup, you can always create one anytime after Setup is complete. For more information about how to create a public folder database, see Create a Public Folder Database.
In a mixed Exchange organization, Setup doesn't prompt you with the question. In these organizations, to ensure backward compatibility to Exchange versions prior to Exchange Server 2007, a public folder database is created by default. Specifically, because Exchange 2010 is installed in its own administrative group, this public folder database will support legacy Schedule+ free and busy functionality.
For more information about installing Exchange 2010, see Deploying Exchange 2010.
Return to top
Public Folder Trees
The MAPI folder tree is divided into the following subtrees:
Default public folders (also known as the IPM_Subtree) Users can access these folders directly by using client applications such as Outlook.
System public folders (also known as the Non_IPM_Subtree) Users can't access these folders directly by using conventional methods. Client applications such as Outlook use these folders to store information such as free and busy data, OABs, and organizational forms. Other system folders contain configuration information used by custom applications or by Exchange. The public folder tree contains additional system folders, such as the EFORMS REGISTRY folder, that don't exist in general purpose public folder trees. System folders include the following:
EFORMS REGISTRY and Events Root By default, one content replica of each of these folders resides in the default public folder database on the first Exchange server installed in the first administrative group. This is the location where organizational forms are stored for legacy Outlook clients (clients using an Outlook version earlier than Outlook 2007).
Offline Address Book and Schedule+ Free Busy The Offline Address Book folder and the Schedule+ Free Busy folder automatically contain a subfolder for each administrative group (or site) in your topology. By default, a content replica of a specific administrative group folder resides on the first server installed in the administrative group. These folders are used to store legacy free and busy information and OAB data for legacy Outlook clients. Legacy Outlook clients don't support the new features in Exchange 2010 or Exchange 2007 that manage free and busy information and OAB data. (These features include the Availability service, the Autodiscover service, and OAB distribution on Client Access servers.)
OWAScratchPad Each public folder database has an OWAScratchPad folder, which is used to temporarily store attachments that are being accessed by using Microsoft Office Outlook Web App. Don't modify this folder.
StoreEvents Each public folder database has a StoreEvents folder, which holds registration information for custom Exchange database events. Don't modify this folder.
Other folders To support internal Exchange database operations, a tree may contain several other system folders, such as schema-root. Don't modify these folders.
Return to top
Public Folder Replication
Public folder databases replicate two types of public folder information:
Hierarchy Properties of the folders and organizational information about the folders (including the tree structure). All public folder databases have a copy of the hierarchy information. For a specific folder, the public folder database can use hierarchy information to identify the following:
Permissions on the folder
Servers that hold content replicas of the folder
Folder's position in the public folder tree (including its parent and child folders, if any)
Content Messages that form the content of the folders. To replicate content, you must configure a folder to replicate its content to a specific public folder database or list of databases. Only the databases that you specify will have copies of the content. A copy of the folder that includes content is called a content replica.
Note
Public folder content replication isn't controlled by database availability groups (DAGs). You can have public folder databases on servers that have DAGs; however, the public folders will use their own public folder replication methods outside of the DAG.
To learn more about public folder replication, see Understanding Public Folder Replication.
Return to top
Public Folder Referrals
When a client application, such as Outlook, attempts to open an Exchange public folder, the Exchange server determines which folder replica the client application should access. This process is called public folder referral. If a replica of the requested content exists on the Exchange server that serves the request, the client application accesses the local replica. If the replica doesn't exist on the local server, Exchange attempts to locate a replica in the same Active Directory site. You can modify the flow of user traffic to allow referrals over certain connectors by specifying a list of referral servers and assigning a routing cost to each server.
For more information about public folder referrals, see Understanding Public Folder Referrals.
Return to top
Mail-Enabled Public Folders
Mail-enabling a public folder provides an extra level of functionality to users. In addition to being able to post messages to the folder, users can send e-mail messages to, and sometimes receive e-mail messages from, the folder. If you're developing custom applications, you can use this feature to move messages or documents into or out of public folders.
A mail-enabled folder is a public folder that has an e-mail address. Depending on how the folder is configured, it may appear in the global address list (GAL). Each mail-enabled folder has an object in Active Directory that stores its e-mail address, address list name, and other mail-related attributes.
Because mail sent to public folders is directed to the public folder database instead of to a mailbox in the mailbox database, Exchange routes e-mail messages by using a method that's slightly different from the method used to route e-mail messages to a regular mailbox.
Return to top
Public Folder Access
In Exchange 2010, the following client applications can access public folders:
Outlook 2010
Outlook 2007
Outlook 2003
For more information about how to create and manage public folders by using Outlook 2007, see Create and share a public folder.
For more information about how to create and manage public folders by using Outlook 2003, see Using Public Folders.
Return to top
Considerations with Mixed Exchange 2010 and Exchange 2007 Organizations
In a mixed Exchange 2010 and Exchange 2007 organization, you need to manage your public folders and public folder databases from Exchange 2010. Exchange 2007 servers don't recognize Exchange 2010 public folder databases due to Active Directory schema changes. The following table describes the expected behaviors when performing certain public folder management tasks on Exchange 2007 servers and Exchange 2010 servers.
| Tasks | Exchange 2007 servers | Exchange 2010 servers |
|---|---|---|
Create a public folder database |
If any Exchange 2010 mailbox databases are in your organization and don't have the msExchHomePublicDB attribute populated, the Exchange 2007 server can't update the Exchange 2010 mailbox database's msExchHomePublicDB setting. Although you receive an error message, the public folder database is created. After you create the public folder database, you need to change the default public folder database. You need to perform this procedure from an Exchange 2010 server. For details, see Change the Default Public Folder Database for a Mailbox Database. |
Always works. |
Remove the default public folder database |
If any mailbox databases are pointing to the public folder database that you're trying to remove, you receive an error message advising that you need to change the default public folder database. To change the default public folder database, perform the following steps:
Note If the new default public folder database that you're pointing the mailbox databases to is an Exchange 2010 public folder database, see "Set an Exchange 2010 public folder database as the default public folder database for an Exchange 2007 mailbox database" later in this table. |
Works on both Exchange 2007 and Exchange 2010 servers provided that no mailbox databases have the public folder database that you're trying to remove as the default public folder database. |
Remove the last public folder database in the organization |
If this is the last Exchange 2007 public folder database in the organization, the Remove-PublicFolderDatabase cmdlet needs to update the msExchFirstInstance property on the Exchange 2010 public folder database to Run the Remove-PublicFolderDatabase cmdlet from the Exchange 2010 server. |
Works on both Exchange 2007 and Exchange 2010 servers provided that no mailbox databases have the public folder database that you're trying to remove as the default public folder database. |
Set an Exchange 2010 public folder database as the default public folder database for an Exchange 2007 mailbox database |
Changing the default public folder database doesn't work on an Exchange 2007 server if either the mailbox database or the public folder database is an Exchange 2010 database. Because Exchange 2007 servers don't recognize the Exchange 2010 public folder databases, the Set-MailboxDatabase cmdlet must be run on an Exchange 2010 server. On the Exchange 2010 server, change the default public folder database for the Exchange 2007 mailbox database. For details, see Change the Default Public Folder Database for a Mailbox Database. |
Always works and should be used to change the default public folder databases if your public folder database and your mailbox database are associated with different versions of Exchange. |
Return to top
Considerations with Mixed Exchange 2010 and Exchange 2003 Organizations
When you install Exchange 2010 in an Exchange 2003 organization, Setup automatically creates an administrative group and routing group within the Exchange 2003 organization. The Exchange 2010 servers added to your organization are included in the new administrative group and routing group. As previously mentioned, Setup also installs a public folder database on the first Exchange 2010 Mailbox server. In that public folder database, Setup creates a free and busy folder for the new administrative group. The legacyExchangeDN property for users whose mailboxes were created on an Exchange 2010 server (and not migrated from Exchange 2003) maps to the Exchange 2010 administrative group name, and therefore also maps to the Free/Busy folder. By default, to facilitate free and busy searches from Outlook 2003 and earlier client users whose mailboxes reside on an Exchange 2003 server, the client users' free and busy information is posted to the Free/Busy public folder.
Management
In a mixed Exchange 2010, Exchange 2007, and Exchange 2003 organization, you can use Exchange System Manager to manage public folders. The following scenarios are supported:
Exchange System Manager should only connect to the Exchange 2003 public folder database for administration. From there, changes replicate to Exchange 2010.
In a pure Exchange 2010 environment or a mixed Exchange 2010 and Exchange 2007 organization, you can't reinstall Exchange System Manager to manage public folders. You must use the Exchange Management Shell.
When verifying hierarchy replication or when viewing the Local Replica Age Limit value on a folder, we recommend using Exchange System Manager for public folders that exist on an Exchange 2003 server and using the Shell for public folders that exist on an Exchange 2010 or Exchange 2007 server.
Outlook Web App
In a mixed Exchange 2010, Exchange 2007, and Exchange 2003 organization, one of the Exchange 2010 and Exchange 2007 Client Access servers has a virtual directory named /public. You can fully access public folders from Outlook Web App without having to use the /public virtual directory.
Important
Exchange 2010 Outlook Web App clients can’t view public folders that reside on Exchange 2003 servers.
In addition, the following public folder features are available in Outlook Web App:
Full access to public folders on Exchange 2010 Mailbox servers without having to keep an Exchange 2003 Mailbox server available for public folder access from Outlook Web App
Public folder search capabilities
Web Parts support
Return to top
Updating the Public Folder Hierarchy
If you notice that the public folder hierarchy on one server is different from the public folder hierarchy on other servers, you may want to synchronize the hierarchy. In Exchange 2003 Service Pack 2 (SP2), the Synchronize Hierarchy command is used to synchronize the public folder hierarchy on an Exchange 2003 server with the other servers in your organization. In Exchange 2010, the Update-PublicFolderHierarchy cmdlet is used to synchronize the public folder hierarchy on the Exchange 2010 server with the rest of the servers in your organization.
Note
You can't run the Synchronize Hierarchy command on an Exchange 2010 server. Similarly, you can't run the Update-PublicFolderHierarchy cmdlet on an Exchange 2003 server. However, running either command updates the public folder hierarchy in your entire organization.
For more information, see Update a Public Folder Hierarchy.
Return to top
Public Folder Content Replication
To help stop public folder content replication errors in your organization, you can suspend the replication of public folder content. Suspending replication allows you to reconfigure the public folder hierarchy and replication schedules.
To suspend or resume the replication of public folder content in a mixed organization, on an Exchange 2010 server, run the Suspend-PublicFolderReplication cmdlet or the Resume-PublicFolderReplication cmdlet in the Shell. Although you run these cmdlets on an Exchange 2010 server, they will suspend or resume the replication of public folder content on all servers in your mixed organization. For information about using the Shell to suspend or resume the replication of public folder content, see the following topics:
Return to top
Best Practices
This section provides the best practices to consider when performing the following public folder tasks in your Exchange organization:
Creating public folder databases
Designing the public folder hierarchy
Performing nightly maintenance
Creating Public Folder Databases
When you plan how many public folder databases to create in your organization, consider the following best practices:
For large enterprise topologies where public folders are heavily used, deploy dedicated public folder servers. This best practice stems from the general best practice of dedicating CPU resources and disk resources to isolated server functions.
Having fewer larger public folder databases scales better and is more easily managed than having several smaller public folder databases. By reducing the number of public folder databases, you can decrease the time required to back up and restore many smaller databases. You also reduce the amount of background replication traffic. Additionally, online maintenance of fewer larger databases is quicker than online maintenance of many smaller databases. Also, it is easier to manage a smaller number of public folder databases from the perspective of applying permissions and content access, and implementing efficient replication and referrals.
The best practice of having fewer larger public folder databases is especially helpful when you consider your topology from the organization level. However, at the server level, some management and maintenance tasks, such as backup and restore processes, can be more quickly performed if you have several smaller databases. Ultimately, the number of public folder databases that you deploy must address your business requirements. As you determine the number of databases that you want to deploy, you must balance the cost of replication traffic against the costs of database backup, maintenance, and restore times.
Designing the Public Folder Hierarchy
As you design your public folder hierarchy, you must recognize the effect of hierarchy replication in your environment. Deep public folder hierarchies scale better than wide hierarchies. A deep hierarchy consists of many vertically nested folders, instead of many higher-level folders. A wide hierarchy consists of many higher-level folders with fewer vertically nested subfolders.
For example, consider how 250 folders might be arranged in a specific hierarchy. A wide hierarchy might have 250 direct subfolders under one parent folder. A deep hierarchy might have five top-level folders, each with five direct subfolders. Inside each of those subfolders may be 10 subfolders.
In both these examples, there are 250 folders (5 × 5 × 10 = 250). However, the deep hierarchy offers better performance than the wide hierarchy for the following reasons:
The way that replication handles folders that have different permissions applied to them is more efficient in deep hierarchies.
Client computer actions (such as sort, search, and expand) against a folder that has 10 subfolders is much less expensive than a folder that has 250 subfolders.
Although deep hierarchies scale better than wide hierarchies, it's a best practice not to exceed 250 subfolders per folder. Exceeding 250 subfolders likely will cause an unacceptable client experience when a client computer requests access.
A factor to consider as you implement a hierarchy is the effect that permissions have on the experience users have when they want to gain access to public folders. When each public folder subfolder has its own access control list (ACL) entries defined, every time that the Exchange server receives a new public folder replication message, the ACL for the parent public folder must be evaluated to determine which users have rights to view the changes to the parent public folder. If the parent public folder has a large discretionary access control list (DACL) entry, it may take a long time to update the view for each public folder subscriber.
Note
The DACL for the parent folder consists of the sum of the DACLs of all the public folder subfolders.
You may have many megabytes (MB) of DACL data that must be parsed if the following conditions are true:
There are many subfolders under a single parent public folder.
Each of those subfolders has its own ACL defined.
This DACL data must be parsed so that the display can be updated for all the public folder subscribers every time that a public folder replication message is received.
Therefore, we recommend that you arrange your public folder hierarchy according to the user sets that gain access to the parent folders. Additionally, don't implement complex permission models for your public folder hierarchies.
Performing Nightly Maintenance
To make sure that your databases continue to operate efficiently, we recommend that you perform nightly maintenance on mailbox databases and public folder databases. Exchange Mailbox servers automate the tasks based upon the schedule that you set.
Return to top
© 2010 Microsoft Corporation. All rights reserved.