The public folder hierarchy has been separated from the content to distribute information about public folders across the organization without the need to propagate large amounts of data at the same time. The hierarchy is replicated automatically; content replication requires an explicit configuration. Therefore, public folder replication usually refers to the process of replicating public folder contents.
This lesson explains the public folder replication process, beginning with an introduction to replication features. It covers the configuration of the replication process per public folder and per public store.
At the end of this lesson, you will be able to:
Estimated time to complete this lesson: 60 minutes
The public folder replication process follows the multimaster model. You can change the public folder hierarchy and the public folder contents from any location. In fact, you can't distinguish a copy from its original. Public folder replication guarantees that changes made on one instance overwrite earlier information in other instances to ensure the uniformity of data.
NOTE
The multimaster model allows you to distribute the workload of public folder servers because users can work on multiple servers, post new information to their local replica, and have the new information replicated to each other.
The replication of both the hierarchy and the contents are always performed using e-mail messages. Even within a single routing group, the Information Store service of the local server does not contact any Information Store running on other servers directly. The e-mail transport simplifies network communications because it abstracts the underlying network topology. If you are able to send a regular e-mail message to a destination server, you can create public folder replicas on that server. In other words, you can create a replica on any Exchange 2000 server in your organization.
NOTE
Public folder replication messages are addressed to the Information Store service, which has an e-mail alias in the form <Server Name>-IS (such as BLUESKY-SRV1-IS). Using Exchange System Manager, you can specify a priority for replication messages per public folder (via the Replication tab).
An internal component of the Information Store service, known as Public Folder Replication Agent (PFRA), is responsible for replicating the public folder content. It tracks changes, generates replication messages for other servers, and receives them from remote servers. The PFRA maintains state information for each item in each folder, which allows identification of the most recent changes as well as replication conflicts, as explained later in Lesson 3.
Too many replicas can increase network traffic and consume disk space unnecessarily, whereas too few copies affect the network bandwidth because users access the content elsewhere across the network.
The granularity of replication refers to the smallest unit that the public folder replication is able to transport, which is the e-mail message or public folder item. As soon as a user modifies an object in one replica, the entire item must be sent to all other replicas. The new object replaces the older version everywhere, accurately updating all copies. Especially when replicating document libraries, it might therefore be advisable to restrict the maximum item size. You can set the corresponding Maximum Item Size (KB) parameter in the Limits tab of the public store as well as for each public folder individually, as explained in Chapter 17, "Public Folder Management."
NOTE
The replication mechanism is not very efficient, and it introduces negative side effects if a replica contains huge documents. Public folders are most suitable if the number of items is large and the item sizes are small. If a public folder contains thousands of documents and you change one, only this document is replicated.
The granularity of configuration refers to the lowest level of public folder management, which occurs at the public folder level. Public folder configuration affects the entire content, but you cannot apply replication settings directly to single messages in the folder. Configuration changes are propagated to all servers as part of the hierarchy replication.
Using Exchange System Manager, you can configure public folder replication at the public store level, which can be compared to a situation where you pull public folder instances from other servers into your server. Most important in this scenario is the Public Folder Instances object underneath the container of the public store (see Figure 18.3).
Figure 18.3 Pulling a public folder replica into a public store
To add a public folder replica from another server to the public store on your server, right-click Public Folder Instances, point to All Tasks, and click Add Replica. This will launch the Public Store dialog box, displaying the associated public folder hierarchy. Expand the public folder hierarchy, select the desired folder, and click OK. If you right-click Public Folder Instances again and select Refresh, the added public folder instance will be listed in the details pane. Keep in mind that configuration changes are not automatically propagated to subfolders. If you want to replicate subfolders together with the parent folder, you need to repeat the configuration or propagate the changes of the parent folder.
NOTE
You can only replicate public folders to a public store that is associated with their hierarchy. It is impossible to add public folder instances from other hierarchies.
Pulling replicas into a server potentially allows any administrator to create an instance of any public folder on his or her servers. The administrator does not even need to communicate with the server that holds the public folder, because configuration changes are distributed using the hierarchy replication. If you do not want to allow every neighbor to replicate your public folders, you should restrict administrative access to the public store.
For example, let's say that you want to deny Carl Titmouse the right to configure the replication for the Public Folder Store (BLUESKY-SRV1)—provided that Carl was granted Administrative permissions in the Exchange 2000 organization beforehand. Right-click Public Folder Store (BLUESKY-SRV1), select Properties, click on the Security tab, select Carl Titmouse from the list of administrators, and then, in the list of permissions, select the Deny check box for the Modify Public Folder Replica List permission. It is possible to deny this permission per public store or per public folder (Administrative Rights). Denying this permission per public store is useful if you want to enforce a stand-alone public folder configuration by preventing creation of any replicas from this public store. It also prevents others from pushing public folders into your store, as explained later. Denying this permission per public folder allows you to enforce a global public folder replication strategy for all servers.
Every public store provides a Replication tab, where you can configure an interval and a size limit for replication messages. Typically, replication is performed every 15 minutes if changes have occurred. However, you can specify a different replication interval or specific times, which may be useful if your server is connected to the rest of the organization through a slow or dial-up network connection. Configure the replication to occur during off hours to minimize the impact of replication messages on interpersonal message transfer.
Keep in mind that the replication message size limit does not define a maximum limit for replication messages. It is actually the other way around: The replication message size limit determines that items smaller than the specified size should be combined until the replication message reaches the specified size. The default message size limit is 300 KB. It is important to note that the PFRA is unable to split larger items into smaller units; hence, if the PFRA needs to replicate a 10 MB Word document, the document is sent in one single message because it exceeds the specified limit.
NOTE
It is possible to define maximum message size limits per SMTP virtual server and routing group connectors. However, public folder replication messages are system messages, which are unaffected by these size limits. Because large replication messages can disrupt interpersonal message transfer, it is advisable to set appropriate maximum item sizes per replicated public folder or optimize the replication schedule.
Using Exchange System Manager, you can also push replicas of a particular public folder into specified servers in your routing group or in other routing groups (see Figure 18.4). Every public folder provides a Replication tab, where you can click Add to launch the Select A Public Store dialog box. Only those public stores that are associated with the public folder's hierarchy but don't hold a replica for the selected folder yet will be listed. As mentioned earlier, you need to have the Modify Public Folder Replica List permission for the public store where you want to add a folder; otherwise, you will receive an error message when you click OK.
Figure 18.4 Pushing a public folder replica into a public store
When you examine the Replication tab, you will notice the Public Folder Replication Interval check box, which allows you to schedule replication messages independently of the public store schedule. If your public folder contains large items, it might be a good idea to replicate the data during off hours. However, typically you want to set a common schedule for all public folder replicas at the server level through the public store object.
In the Replication tab, the Details button displays the Replication Status dialog box where you can examine the folder's replication status. All servers that hold a replica are listed in the Server Name column together with their Replication Status. In Sync indicates that the local replica has not been modified since changes were last sent. If a user has modified the contents of a replica and the changes have not yet been sent to the other servers, Local Modified is displayed. All servers will be In Sync as soon as the next replication cycle is complete. Another interesting category is Last Received Time, which provides information about the most recently received updates per server. The Avg. Trans. Time (Average Transmission Time) gives you an idea of the average time that it takes to send updates to a selected server.
TIP
It is also possible to examine the replication status for all replicas using the Replication Status container located underneath each public store object. The public store displays the status information in a server-centric way for all instances in the public store.
As explained in Chapter 17, "Public Folder Management," you can configure age limits per public store or per public folder. However, neither the public store nor the public folder level allows you to configure age limit exceptions. For example, let's say you want to configure a general item lifetime of 60 days for all instances of a particular public folder but have one server with an age limit of 10 days. To achieve this configuration, in the folder's Limits tab, clear the Use Public Store Defaults check box and, under Age Limit For Replicas (Days), type 60. Now you need to configure one exception for the replica on the server where you want to apply a limit of 10 days. Expand the corresponding server object's public store, and then select the Public Folder Instances subcontainer. Right-click the desired replica in the details pane, select Replica Properties, activate the Age Limit Of This Folder On This Public Store (Days) check box, and type 10 in the text box. The Effective Age Limit Of This Folder On This Public Store (Days) text box provides a summary about the effective item lifetime.
Every public store holds a number of system folders not visible in the hierarchy. Using Exchange System Manager, you can view a list of all system folders that exist when you right-click the desired hierarchy object under the Folders container and select View System Folders.
The following are important system folders and containers listed in the hierarchy (containers are in uppercase):
When you compare the content of the Public Folder Instances subcontainers under Public Folder Store (BLUESKY-SRV1) and Public Folder Store (BLUESKY-SRV2) with each other, you will notice a significant difference in available system folders. BLUESKY-SRV1 holds offline address books and Schedule+ free/busy information and BLUESKY-SRV2 doesn't. By default, only the first server installed in the administrative group holds these system folders. If you shut down this server for maintenance, users will not be able to download offline address books or update free/busy information. Outlook 2000, for instance, may display an error message when working with appointments (see Figure 18.5).
Figure 18.5 Unable to update public free/busy data
Figure 18.5 illustrates a situation where system folders must be replicated between servers in different routing groups. As indicated, public folder referrals are disallowed, which prevents users from accessing the folders on the first installed server across the routing group boundary (see Exercise 3 of Chapter 17, "Public Folder Management"). To avoid frustrating your Outlook users, replicate the offline address books and the Schedule+ free/busy information to a server in each routing group.
NOTE
To replicate system folders, push the folder into the public store of additional servers, as explained earlier in this lesson. You can right-click system folders in the hierarchy or underneath the Public Folder Store object in the Public Folders subcontainer, select Properties, and then click on the Replication tab.
It is not an easy task to move a public folder between servers, although it might seem simple at first glance. You only need to add a public folder replica to a new server and remove the old instance from the first machine. In the public folder's Replication tab, use the Add and Remove buttons for this purpose. You also could use the Public Folder Instances subcontainer. To remove a public folder via Public Folder Instances, right-click the replicated folder in the details pane, point to All Tasks, and click Remove Replica.
When moving public folders between servers, you can remove the original replica without waiting for the PFRA to complete its contents replication. The old replica remains on the old server until the replication has taken place and the contents are entirely transferred to the new replica. However, Exchange 2000 Server is a platform for the patient system administrator. Replication, for example, is not an exceptionally fast process, and, if you remove the original replica too quickly, users might end up with an empty folder in Outlook 2000. This effect disappears as the PFRA completes its replication, but, depending on the replication schedule and the importance of the folder, this could cause problems in the interim. You should leave the replica in the original public store and wait until the PFRA has completed the replication. Unfortunately, no feature currently exists to force the PFRA to replicate immediately.
You should move all system folders to a new server in advance if you plan to remove the first server installed in an administrative group. Be very patient if you want to remove a server after its public folders have been moved. Otherwise, you might end up with unpleasant Outlook 2000 problems. Outlook may cache the names of public folder servers, and, if a server has been removed, the client may hang when it is attempting to access the old server. To avoid this problem, wait until all Outlook users have accessed the folders on the new server. Otherwise, affected users may need to create a new MAPI profile for their Outlook clients to fix problems with public folder access.
NOTE
You should not uninstall a public folder server immediately after its resources have been moved. Unplug the server from the network, or stop the Exchange 2000 services and monitor the organization. If users have difficulty accessing public folders, start the old server again. Wait until you feel confident that it is safe to go ahead. Depending on the situation, this may take a week or longer.
In this exercise you will replicate public folders and system folders between servers in different routing groups. For better illustration of local public folder access, routing group connectors should disallow public folder referrals between the routing groups.
To view a multimedia demonstration that displays how to perform this procedure, run the EX1CH18*.AVI files from the \Exercise_Information\Chapter18 folder on the Supplemental Course Materials CD.
To replicate public and system folders between servers in different routing groups
Figure 18.6 Adding a public folder instance to a public store
Figure 18.7 Testing the unavailability of system folders
Figure 18.8 Replicating system folders
Using Exchange System Manager, you can configure public folder replicas in various ways. You can add replicas through the Public Folder Instances object or by means of each individual folder's Replication tab. Another option is to propagate replication settings to subfolders. System folders can be replicated between servers when adding available public stores from other servers to the list of stores with replicas. Public folder replication may require some time, but as soon as replicas are synchronized, all users have seamless access to the resources. For Outlook 2000 users, a public folder is always just a single object in the public folder tree.