Exchange Public Folder Best Practices: Implementing Replication
This article describes best practices for deploying and configuring public folder replication in Microsoft® Exchange 2000 Server and Exchange Server 2003. This article assumes that you have a good understanding of replication, the types of replication messages that Exchange Server uses, and sets of change numbers (CN sets). For a description of these concepts, see Controlling Exchange Server 2003 Public Folder Replication.
Public folder replication in Exchange Server can be a resource-intensive operation. Replication requires network, CPU, and disk resources to operate. By implementing a solution that enables efficient public folder replication, especially in organizations with heavy public folder usage, you may greatly improve network, CPU, and disk load in your Exchange Server environment.
Generally, it is a best practice to minimize replication across the Exchange Server organization. By minimizing replication, you minimize the amount of data that travels over your network. You also minimize the CPU and disk resource load on your Exchange servers. Additionally, by minimizing replication, you can help ensure that multiple users are less likely to access different versions of data on multiple replicas. However, you should note that by minimizing replication, you decrease availability of the public folder data because fewer replicas of the folder are available to clients if a public folder store fails. If availability on a large scale is required for data in a specific public folder, you may require more replication.
Planning for Efficient Replication
The first step in determining a solution that enables efficient public folder replication is to understand how users use each folder in a specific hierarchy. Most of the time it makes sense to distribute the content and reduce replicas as much as you can. In this context, "distributing content" means breaking up content so that it will be aggregated on each public folder store and not replicated to the other public folder stores.
For example, consider a routing group that has four Exchange servers. If each server in that routing group contains a replica of the same folders, every time that a replication cycle runs, the changes in the content are replicated to all four servers. This replication implementation causes increased network load because of the increased SMTP traffic and increased CPU and disk usage to process the replication messages. This replication implementation may make sense if all users in the routing group access a specific folder. However, if subsets of users access a specific folder, such replication is inefficient. In this example, you could save a significant amount of network, CPU, and disk load by distributing the content across the four Exchange servers and reducing the number of replicas.
You should note, however, that by distributing content across multiple replicas, you may increase the management overhead. In this example, load distribution will require more maintenance and monitoring than you would require for a single replica of the whole hierarchy. Therefore, be mindful of the effect on server management as you plan your replication solution.
In some organizations, the Schedule+ Free/Busy public folder is typically the most frequently accessed public folder. Therefore, you should pay special attention to how these folders are used.
In large enterprises with global facilities, it typically makes sense to replicate Schedule+ Free/Busy public folders according to region so that multiple replicas are available to local users, and large data replication traffic across wide area networks is minimized. This recommendation is optimal for organizations that have organized administrative groups according to regional local area networks.
If your Exchange Server infrastructure is not organized according to regional local area networks, a general best practice is to replicate the Schedule+ Free/Busy public folder from each administrative group to at least one server in each routing group. However, you should note that this best practice may not suit all deployments. You should always consider user access requirements and network latency when you plan your deployment.
Important
If your enterprise has large administrative groups, which may include hundreds of servers, and limited replicas, you may run out of paged pool memory on the Exchange servers that host the Schedule+ Free/Busy public folder. The average size of the users' Kerberos token may also increase the risk of running out of paged pool memory on the Exchange servers that host the Schedule+ Free/Busy public folder. Therefore, if your organization contains deeply nested security groups, the users' Kerberos token size will be large. For more information about paged pool memory issues and kernel memory issues in Exchange Server, see Ruling Out Memory-Bound Problems.
Another general best practice is to create one replica of the Schedule+ Free/Busy public folder for every 10,000 users.
Also, make sure that you pay special attention to how users from different regions schedule meetings with one another. If user groups on opposite sides of the globe rarely schedule meetings with each other, you may be able to justify pointing users to distant replicas of the Schedule+ Free/Busy folder by using public folder referral.
Note
When Microsoft Office Outlook® Web Access or Outlook Mobile Access requests free/busy information, the mailbox store uses one free/busy server to find the information. This limitation may cause problems if your topology has multiple sites, because in the default configuration, each free/busy server holds the free/busy data of only that site. You must configure the free/busy folders to replicate if you want data from multiple sites to be available to all users.
For more information about Free/Busy public folders, see Managing Exchange Server 2003 Free/Busy Folders.
To make sure that each server is handling approximately the same amount of traffic, you should consider taking the following actions on all replicas except the Schedule+ Free/Busy public folder that was described earlier:
Remove replicas of folders that do not receive much traffic.
Distribute content so that each server is handling about the same amount of traffic.
As you remove replicas, be sure to maintain sufficient redundancy for public folders that contain mission-critical information.
As you plan for public folder replication, try to standardize your solution for easier management and recoverability. Specifically, organize public folder trees so they are segmented logically. Ideally, logical segments, or public folder branches, coincide with regional user groups or LAN segments of your network.
It is a best practice to replicate public folder branches to specific servers. If you replicate a specific branch of public folders to multiple servers, it is more difficult to recover data because you must identify the servers that contain various branches of the data in the tree before you try to recover data.
This best practice does not mean that you should not create other replicas of folders in a branch. However, when you create other replicas of folders in a branch, make sure that these additional replicas are carefully managed instances in addition to a single server that holds a replica of the whole branch.
The second step in determining a solution that enables efficient public folder replication is to determine what replication latencies are allowed in your organization. It is likely that users who access mission-critical documents in one public folder require more frequent replication than users who access documents that are not mission-critical. In fact, sometimes when data is mission-critical, some users may not want to replicate the data at all. This approach assures that everyone accesses the same data and that the data is always guaranteed to be up-to-date. Of course, the advantages of this scheme must be weighed against the tradeoffs in disaster recovery. Specifically, if you opt to store only a single instance of the data, and that data is mission critical, be sure to back up the data so that it can be restored quickly and with a minimum of loss.
Note
In such scenarios, where versioning and recoverability of mission-critical documents is required, consider deploying Microsoft Windows® SharePoint® Portal Server. For more information about the differences between Exchange Server public folders and SharePoint Products and Technologies, see Selecting the Appropriate Public Folder Solution.
By monitoring public folder usage and defining an acceptable service level agreement with your organization or client, you can determine acceptable periods of replication latency for different types of public folders.
Important
Verify that replication actually finishes between intervals. If replication does not finish, replication queues grow. The larger the replication queue becomes, the more out of synchronization the content in the folders becomes. You can monitor replication queues by using the Performance Monitor to examine the MSExchangeIS Public\Replication Receive Queue Size performance counter. When replication queues grow, there is an increased load on resources when the replication does complete. Also, growing replication queues indicate that content on the server is outdated.
For more information about troubleshooting replication, see Exchange Public Folder Troubleshooting Resources.
For More Information
To learn more about public folders in Exchange Server, see the following resources: