Export (0) Print
Expand All

Planning for Public Folder Management


Topic Last Modified: 2006-07-18

Your network infrastructure, security requirements, and administrative model determine the decisions that you make regarding public folder administration. Public folder management encompasses not only public folders, but also system folders. One of these system folders is the free/busy folder, which controls whether you can see other users' free/busy information when setting up a meeting. Generally, it is recommended that you have a good understanding of your existing infrastructure and the issues that affect your administrative model.

The following features of public folders help you control how public folders are managed and administered:

  • Replication   A public folder can be configured to have copies (replicas) on multiple servers. Replicas are useful for distributing the user load on servers, distributing public folders across geographical areas, and backing up public folder data. You can set up a replication schedule based on how often data in the public folder changes. You can set this schedule for all public folders or for a specific public folder.
  • Public folder referrals   When a client computer must use an alternate server to access public folder content, Exchange uses the routing group configuration to refer the client computer to another server. This alternate server may reside in a different routing group. The public folder referral process lets the user access content wherever it exists, even when the specific server that contains the data is not known. This process also eliminates the need for a cost-based referral list because the cost information is determined based on the routing group connector costs.

A public folder can be configured to have replicas on multiple public folder servers. Replicas are useful for distributing the user load on servers, distributing public folders geographically, and providing redundancy for public folder data. All replicas of a public folder are equal, so there is no master replica.

During public folder replication, the public folder hierarchy is replicated to every server that has public folders in the Exchange organization, but the contents are replicated only to servers on which an administrator has set up replicas. Changes that were made to items in a replica are sent to all other replicas of the public folder throughout the organization. Changes that were made to the folder, the folder's properties, or the public folder hierarchy are replicated to all servers.

When more than one replica of a public folder exists, connections that users make are distributed across all replicas in an organization. If a replica of the folder is on the user's public folder server, the first connection attempted is to that replica. If a connection to the replica cannot be made because a server is unavailable or because a network connection cannot be made, a connection to a different server in the routing group is attempted. If routing connectors enable public folder referrals, connections to servers in other routing groups are attempted.

This section provides specific planning considerations and recommendations for public folders.

The public folder store relies on mail transport for delivery of replication messages. The public folder store does not replicate messages based on topology details. If the content of a public folder is modified and it has five replicas, then a single replication message is generated and addressed to all five other public folder stores. For this reason, your routing topology has a great effect on how efficiently public folders are replicated.

Generally, to separate public folder replication traffic from mail traffic, it is recommended that you deploy a dedicated public folder server for administrative groups that contain more than three servers. Deploying a dedicated public folder server reduces replication traffic and simplifies the administration of public folders. After you set up a dedicated public folder server, remove the public folder stores from the mailbox servers. The public folder server, in turn, does not have to host any mailboxes, but it does require a mailbox store to allow for mail-enabled public folders. Then configure users' mailbox stores to use the dedicated public folders server as the default public folder store.

If your organization consists of multiple remote locations, you have two options for public folder placement. You can put public folder replicas on local Exchange servers so that each location has a replica of public folders from other locations. Or, you can store all public folder information in a central server in the data center or hub so that you maintain a single, accurate source of data. The choice of options is based on the balance between accuracy and convenience, it and depends on user requirements and usage patterns.

If you plan to centralize your Exchange servers, you may decide not to install an Exchange public folder server in remote sites. However, you should be aware that, if the sites are connected by low-bandwidth, high-latency network connections, public folder access does not benefit from Cached Exchange Mode the way that mailbox access does. Unlike mailbox data, public folder data is not cached locally on the client computer (unless you add a public folder to your offline "Favorites," which are kept synchronized with the server's data). Therefore, requests for public folder data are directed over the remote connection to an Exchange server in the data center. Therefore, access to public folders is subject to the latency that is part of your network connections.

When no local Exchange public folder server exists and access to a server is available over a low-bandwidth, high-latency connection, it is recommended that users access public folders by using Outlook Web Access 2003. Compared to Outlook, Outlook Web Access usually provides faster access to public folders when there is no local Exchange public folder server.

If you use Cached Exchange Mode, public folder data is not cached locally for Outlook 2003 users. Requests for public folder data are directed over the remote connection to an Exchange server, so these requests are also subject to the latency in the connection. In most cases, the need for instantaneous access to public folder information is not a requirement. However, this need is a factor you should consider when testing your Exchange infrastructure and then use it to determine whether the degree of latency is acceptable for your organization.

By default, each public folder store contains system folders invisible in Exchange System Manager. (To view system folders, right-click the Public Folders container under Folders, and then click View System Folders.) Among the system folders are the following folders:

  • Schedule+ free/busy folder
  • Offline address book folder

The Schedule+ free/busy folder contains information that Outlook users use to view the availability of others when scheduling meetings. Each administrative group has one free/busy folder. If your administrative model requires multiple administrative groups, you can configure the Schedule+ free/busy folder to maintain replicas of free/busy folders from any of the other administrative groups. Replication occurs just as it does for public folders. Because each administrative group has one free/busy folder and an administrative group can span multiple routing groups, you may need to add a folder replica in each routing group. Adding this folder makes sure that free/busy information is always local. Be sure to verify that the routing group connectors allow public folder referrals.

Access to free/busy information is one of your most important considerations. First, consider network connectivity and bandwidth issues. Then, balance these issues with how users schedule meetings and determine the level of delay acceptable to your business. For free/busy information, if users do not have access to a local copy of free/busy folder data, they may experience a delay in receiving other users' free/busy information when scheduling meetings. If it is very important that users in a specific location always have access to up-to-date scheduling information, you should host free/busy folders in a centralized location, even if it results in delays for users who access the information over low bandwidth connections. If the need for up-to-date information is not as critical as fast access to free/busy information, you can host free/busy folders on local Exchange servers.

If you decide to host free/busy information on local Exchange servers, you need to consider whether to put copies of free/busy folders from other locations on the local server. If users in different locations rarely schedule meetings with each other, you do not necessarily have to keep local replicas of free/busy folders from other locations.

As with public folder data, if you use Cached Exchange Mode, free/busy data is not cached locally for Outlook 2003 users, so free/busy requests are subject to any latency in the remote connection.

The offline address book folder contains subfolders that store offline address lists. You should select an appropriate server to generate and update offline address lists. For increased server performance, select a server that is not busy performing other tasks.

If you use Cached Exchange Mode, you should consider the effect on the server when users download offline address lists. This effect could be significant, not only the first time that users download offline address lists, but daily. You may want to consider setting up one or two servers to handle offline address books.

Like Exchange 2000, public folder referrals in Exchange 2003 are transitive. This means that if public folder referrals are allowed between routing groups A and B, and between routing groups B and C, public folder referrals are automatically allowed between routing groups A and C. In Exchange 2000, if you wanted to control traffic to public folders, you had to create separate routing groups to contain the public folder servers. This is because the ability to allow or not allow public folder referrals was available only at the routing group connector level. In Exchange 2003, however, you can configure referrals at the server level instead of the connector level. For each Exchange 2003 server, you can select a list of other servers to which referrals are allowed. Therefore, you no longer need to create separate routing groups for the sole purpose of controlling public folder referrals.

In a topology characterized by fast network connections, referral traffic may not be an issue. By default, a server can make referrals to any other server and, as long as the connections are fast and reliable, no traffic issues result. However, if you have Exchange servers with public folder replicas in remote sites with high-latency connections, you may want to refine the public folder referral model by identifying specific servers that can accept referrals.

The following requirements need to be addressed before you can successfully access public folders in Exchange System Manager (ESM).

  • The default Web site should be bound to the first IP address, if there is more than one IP bound to the network adapter.
  • The /Exadmin and /public virtual directories must exist in the default Web site. If these two directories do not exist in the Web site that is bound to the first IP address, you will receive a series of errors when you access public folders in Exchange System Manager. When you access the public folders through ESM, the actual information is called through the /Exadmin virtual directory in the Exchange HTTP virtual directory. In a stand-alone Exchange server, it will appear under the Default Web Site.
  • For the default Web site, Windows Integrated authentication and HTTP Keep-Alive should be enabled.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

© 2014 Microsoft