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.

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.
    
    

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:

• Cluster Continuous Replication
  
  
• Local Continuous Replication
  
  
• Standby Continuous 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.

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:

• Understanding Public Folder Referrals
  
  
• Managing Public Folder Referrals
  
  

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.

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.

This section provides considerations for implementing and managing public folders in a mixed Exchange 2007 and Exchange 2003 organization.

Setup

Management

Outlook Web Access

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.

Note:
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

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

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.

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:

• 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

For more information about how to manage public folders from Exchange 2007, see the following topics:

• Managing Public Folders
  
  
• Configuring Public Folder Permissions
  
  
• Scripts for Managing Public Folders in the Exchange Management Shell
  
  
• Routing Messages to Public Folders