Manage Learn to apply best practices and optimize your operations.

Part 3: What content should you replicate in Exchange public folders?

Learn about the many different issues you need to consider when choosing what content to replicate in Exchange public folders, including time sensititivity of the data, latency, replication traffic, and fault tolerance.

There are many different issues you need to consider when choosing what content to replicate in Exchange public folders.

Time sensitivity of public folder data

The first thing that you need to consider is the time sensitivity of the data within the public folder. For example, suppose you have a public folder that is used to store the very latest information about your customers and their accounts. If your company uses the data in that folder to make business decisions, and depends on the data being as up-to-date as possible, then the folder probably is not a good candidate for replication.

Latency

There is always latency involved in the Exchange public folder replication process. The amount of latency varies depending on a number of factors. For example, if the network connection between the servers containing the replicas of the public folder is running at gigabit speeds, there will be less latency than there would be if the replicas were separated by a WAN link (other factors besides network throughput also contribute to latency).

The point is that you can never get away from having at least some latency. If your employees are counting on the data within the Exchange public folder being as current as possible, it is probably a bad idea to replicate that folder. Otherwise, the employees will never know if there are looking at the most current folder content, or a public folder replica that has not yet synchronized with the primary folder.

Public folder replication traffic

The more frequently that a public folder is updated, the more often the data has to be replicated to any folder replicas that might exist.

Anytime that data has to be replicated, replication traffic is sent out over the network. This replication traffic probably isn't a big deal if there is a reliable, high-speed network connection between all the Exchange public folder replica servers. However, if the replicas are separated by a WAN link, replication traffic becomes a serious consideration.

In most cases, if an administrator goes through the trouble of creating a public folder replica to an Exchange server in a remote location, it's to prevent users from accessing public folder data from across the WAN link.

Because WAN connections have limited amounts of bandwidth, it is important to conserve as much of it as possible. If an Exchange public folder is not updated excessively, it is usually more efficient to replicate the folder's contents to a server at the remote site.

Having users at the remote site access the folder's contents from across a WAN link is less efficient. But, if the public folder is updated excessively, there might be so much replication traffic generated that it would be more efficient to simply allow the users to access the public folder from across the WAN link.

Ultimately, you have to figure out what makes the most sense for your Exchange Server organization. If your remote location has a large user base, and those users are constantly accessing the public folder in question, then it will almost definitely be more efficient to replicate the folder to a server at the remote location, even if the folder receives excessive updates.

Fault tolerance

Most of the issues I've talked about so far revolve around scalability and efficiency. When you're deciding whether or not to replicate a particular Exchange public folder though, you cannot overlook the issue of fault tolerance.

Creating a replica of an Exchange public folder provides fault tolerance, because the failure of a single replica will not cause public folder content to become inaccessible (unless some of the content on the failed server has not yet been replicated).

If your organization relies heavily on Exchange public folders, you may want to consider creating replicas of those folders solely for fault tolerant purposes. After all, if a public folder server fails, and replicas of the folders on the server do not exist, your only recourse may be to restore a backup. You will probably recover most of your data that way -- but with significant downtime.


TUTORIAL: EXCHANGE PUBLIC FOLDER REPLICATION

 Home: Introduction
 Part 1: An overview of the Exchange public folder replication process
 Part 2: The Exchange public folder replication methodology explained
 Part 3: What content should you replicate in Exchange public folders?
 Part 4: How to create Exchange public folder replicas
 Part 5: Related resources on Exchange public folder management

ABOUT THE AUTHOR:   
Brien M. Posey, MCSE
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Exchange Server, and has previously received Microsoft's MVP award for Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.

Dig Deeper on Exchange Server setup and troubleshooting

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close