Understanding Public Folders
Microsoft Exchange Server 2007 will reach end of support on April 11, 2017. To stay supported, you will need to upgrade. For more information, see Resources to help you upgrade your Office 2007 servers and clients.
Applies to: Exchange Server 2007, Exchange Server 2007 SP1, Exchange Server 2007 SP2, Exchange Server 2007 SP3
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 Exchange servers.
Public folders are not designed for the following purposes:
Archiving data Public folders are not 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 is not recommended because it affects storage on public folder servers and undermines the goal of mailbox limits.
Document sharing and collaboration Public folders are not designed for document sharing and collaboration. Public folders do not 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 2007, public folders are an optional feature. If all client computers in your organization are running Microsoft 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 2007, these features are serviced by the Autodiscover service, Exchange Web Services, the Microsoft Exchange System Attendant service, and the Microsoft Exchange File Distribution service.
To connect to Exchange for OAB and Schedule+ free and busy functionality, all client computers running Outlook 2003, Outlook 2002, Outlook 2000, or Outlook 98 require public folders to be deployed. Exchange 2007 is the first version of Exchange that provides you with the option to not use public folders. However, until all client computers in your organization are running Outlook 2007, you should continue using public folders.
This topic provides the following information about public folders in Exchange 2007:
Public folder database creation during setup
Public folder trees
Public folder databases
Public folder replication
Public folder referrals
Mail-enabled public folders
Public folder access
Considerations with mixed Exchange 2007 and Exchange Server 2003 organizations
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 2007. Therefore, in a pure Exchange 2007 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 is not created.
When you install the second server, you are not prompted with the question, and Setup does not 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 do not 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 How to Create a New Public Folder Database.
In a mixed Exchange organization, Setup does not prompt you with the question. In these organizations, to ensure backward compatibility to Exchange versions prior to Exchange 2007, a public folder database is created by default. Specifically, because Exchange 2007 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 2007, see Deployment.
Public Folder Trees
Exchange 2003 supports the use of a non-MAPI folder tree, otherwise known as an Application folder tree or General Purpose folder tree. Exchange 2007 only supports the default MAPI folder tree. 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 cannot 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 that is used by custom applications or by Exchange itself. The public folders tree contains additional system folders, such as the EFORMS REGISTRY folder, that do not 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 2007 server that is 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 that is 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 do not support the new features in Exchange 2007 that manages 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 Outlook Web Access. Do not modify this folder. Outlook Web Access running on Exchange 2007 Client Access servers does not use these folders to store attachment data. However, this folder is created during a pure installation of Exchange 2007.
StoreEvents Each public folder database has a StoreEvents folder, which holds registration information for custom Exchange database events. Do not modify these folders.
Other folders To support internal Exchange database operations, a tree may contain several other system folders, such as schema-root. Do not modify these folders.
Public Folder Databases
The public folder database contains data that is available to all users who have mailboxes and appropriate permissions.
Cluster continuous replication (CCR), local continuous replication (LCR), standby continuous replication (SCR), and public folder replication are very different forms of replication built into Exchange. Due to interoperability limitations between continuous replication and public folder replication, if more than one Mailbox server in the Exchange organization has a public folder database, public folder replication is enabled and public folder databases should not be hosted in CCR, LCR, or SCR environments.
For more information about public folders and high availability options, see the following topics:
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
The 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.
To learn more about public folder replication, see Understanding Public Folder Replication.
For information about managing public folder replication, see Managing Public Folder Replication.
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 does not exist on the local server, Exchange attempts to locate a replica in the same Active Directory directory service 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 the following topics:
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 are 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 that is 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 is slightly different from the method that is used to route e-mail messages to a regular mailbox.
For more information about public folder routing, see Routing Messages to Public Folders.
Public Folder Access
In the RTM version of Exchange 2007, the following client applications can access public folders:
Microsoft Office Outlook 2007
Microsoft Office Outlook 2003
In Exchange 2007 SP1, the same client applications are used to access public folders, with the addition of Microsoft Office Outlook Web Access.
For more information about how to create and manage public folders by using Outlook 2007, see Public folders.
For more information about how to create and manage public folders by using Outlook 2003, see Using Public Folders.
For more information about how to create and manage public folders by using Outlook 2000, see Create an Office document library in an Outlook public folder.
Considerations with Mixed Exchange 2007 and Exchange 2003 Organizations
This section provides considerations for implementing and managing public folders in a mixed Exchange 2007 and Exchange 2003 organization.
When you install Exchange 2007 in a mixed Exchange 2007 and Exchange 2003 organization, Setup automatically creates a new administrative group and routing group within the Exchange 2003 organization. The Exchange 2007 servers that are 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 2007 Mailbox server. In that public folder database, Exchange 2007 creates a new free and busy folder for the new administrative group. The legacyExchangeDN property for users whose mailboxes were created on an Exchange 2007 server (not migrated from Exchange 2003) maps to the Exchange 2007 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.
In a mixed 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 2007.
In a pure Exchange 2007 organization, you cannot 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 Exchange Management Shell for public folders that exist on an Exchange 2007 server.
Outlook Web Access
In a mixed Exchange 2007 and Exchange 2003 organization, Exchange 2007 Client Access servers have a virtual directory named /public. In the Exchange 2007 RTM version, this virtual directory is used only to access legacy public folders. Specifically, the /public virtual directory will not connect to another Exchange 2007 Mailbox server because the Mailbox server does not support access to a /public virtual directory.
In Exchange 2007 SP1, you can fully access public folders from Outlook Web Access without having to use the /public virtual directory. In addition, the following public folder features are available in Outlook Web Access:
Full access to public folders on Exchange 2007 Mailbox servers without having to keep an Exchange 2003 Mailbox server available for public folder access from Outlook Web Access
Public folder search capabilities
Web Parts support
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 in your mixed Exchange 2007 and Exchange 2003 organization, 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 2007, the Update-PublicFolderHierarchy cmdlet is used to synchronize the public folder hierarchy on the Exchange 2007 server with the rest of the servers in your organization.
You cannot run the Synchronize Hierarchy command on an Exchange 2007 server. Similarly, you cannot 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 How to Update a Public Folder Hierarchy.
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 Exchange 2007 and Exchange 2003 organization, on an Exchange 2007 server, run the Suspend-PublicFolderReplication cmdlet or the Resume-PublicFolderReplication cmdlet in the Exchange Management Shell. Although you run these on an Exchange 2007 server, they will suspend or resume the replication of public folder content on all servers in your mixed organization. For information about using the Exchange Management Shell to suspend or resume the replication of public folder content, see the following topics:
This section provides the best practices to consider when performing the following public folder tasks in your Exchange 2007 organization:
Creating public folder databases
Designing the public folder hierarchy
Performing nightly maintenance
Creating Public Folder Databases
When you plan for 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 that is 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. Finally, 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 is 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 a user has 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.
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:
You have 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, do not 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 2007 Mailbox servers automate the tasks based upon the schedule that you set.
For more information about mailbox database and public folder database maintenance, see Maintaining Mailbox Databases and Public Folder Databases.
For more information about how to manage the public folder database maintenance schedule, see How to Set the Maintenance Schedule for a Database.
For More Information
For more information about how to manage public folders from Exchange 2007, see the following topics: