Lesson 2: Public Folder Replication Configuration

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:

  • Describe the features of public folder content replication.
  • Configure the replication per public folder and per public store.

Estimated time to complete this lesson: 60 minutes


Public Folder Replication Overview

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.

Network Topology Independence

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).

Public Folder Replication Agent

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.

Public Folder Contents Replication

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.

Granularity of Replication

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.

Granularity of Configuration

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.

Replication Configuration per Public Store

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).

click to view at full size

Figure 18.3 Pulling a public folder replica into a public store

Collecting Public Folder Instances

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.

Restricting Replica Requests

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.

Determining Replication Interval and Message Sizes

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.

Replication Configuration per Public Folder

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.

click to view at full size

Figure 18.4 Pushing a public folder replica into a public store

Configuring Replication Schedule and Status

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.

Configuring Age Limits per Replica

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.

Replication of System Folders

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

  • Events Root. Contains subfolders, which in turn hold scripts for the Exchange Server 5.5-compatible Event Service.
  • EFORMS REGISTRY. Contains forms (typically send forms) published via the Organization Forms Library, which is explained in Chapter 21, "Microsoft Outlook Forms Environment."
  • OFFLINE ADDRESS BOOK. Contains subfolders, which in turn store offline address books, which clients may download, as explained in Chapter 9, "MAPI-Based Clients."
  • SCHEDULE+ FREE/BUSY. Contains a subfolder per administrative group for Schedule+ free/busy information. Free/busy information allows Outlook users to view availability information of other users when composing meeting requests.
  • Schema. Contains definitions for properties of objects kept in the public store.
  • StoreEvents. Contains Exchange 2000 Server-specific global and internal event sinks for a specific server.

Offline Address Books and Schedule+ Free/Busy Information

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).

click to view at full size

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.

Moving a Public Folder Between Servers

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.

Replication Latency Issues

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.

Removing Public Folder Servers

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.

Exercise 1: Replicating Public Folder Resources

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.

Prerequisites

  • Complete Exercise 3 of Chapter 17, "Public Folder Management."
  • Start BLUESKY-SRV1, BLUESKY-SRV2, and BLUESKY-WKSTA.
  • Log on as Administrator to all machines.

To replicate public and system folders between servers in different routing groups

  1. On BLUESKY-SRV2, launch Exchange System Manager, expand Administrative Groups, then First Administrative Group, then Servers, then BLUESKY-SRV2, then First Storage Group, and then Public Folder Store (BLUESKY-SRV2).
  2. Right-click Public Folder Instances, point to All Tasks, and click Add Replica.
  3. In the Public Store dialog box, expand the public folder tree, and, under Public Folders (BLUESKY-SRV2), select BackDoor. Click OK.
  4. Right-click Public Folder Instances again, and select Refresh. Verify that the BackDoor public folder is listed in the details pane (see Figure 18.6).

    click to view at full size

    Figure 18.6 Adding a public folder instance to a public store

  5. On BLUESKY-WKSTA, launch Outlook 2000, make sure the folder list is displayed, expand Public Folders, expand All Public Folders, expand BackDoor, and then select the BackDoor folder. Notice that the content is displayed (the folder might be empty, but you are able to post items into it).
  6. On the toolbar, click New, and, under Subject, type Public folder replication settings are not automatically propagated to subfolders. Click Post. Verify that you are able to work with the public folder.
  7. In the folder list, select Sub-BackDoor. Outlook 2000 will be unable to display the folder because it was not replicated to the local routing group.
  8. In the Outlook toolbar, click Calendar.
  9. In the toolbar, click New. Under Subject, specify We need to provide access to the Schedule+ Free Busy Folder, and then click the Save And Close button.
  10. Verify that the appointment was created successfully, open the File menu, and select Exit And Log Off.
  11. A Microsoft Outlook dialog box will appear, informing you that the client is unable to update public free/busy data (see Figure 18.7). Click OK.

    click to view at full size

    Figure 18.7 Testing the unavailability of system folders

  12. On BLUESKY-SRV1, launch Exchange System Manager, expand Administrative Groups, then First Administrative Group, then Folders, and then Public Folders. Right-click BackDoor, point to All Tasks, and select Propagate Settings.
  13. In the Propagate Folder Settings dialog box, select the Replicas check box, and click OK.
  14. Right-click Public Folders, and select View System Folders.
  15. Expand the Offline Address Book container, right-click the first system folder underneath (/o=Blue Sky Airlines/cn=addrlists/cn=oabs/cn=Default Offline Address List), and select Properties. Click on the Replication tab, click Add, and, in the Select A Public Store dialog box, select the available public store from BLUESKY-SRV2 (see Figure 18.8). Click OK twice.
  16. Repeat Step 15 for all remaining offline address book folders (such as EX:/o=Blue Sky Airlines/ou=First Administrative Group), for the folder named EX:/o=Blue Sky Airlines/ou=First Administrative Group that is located under Schedule+ Free Busy, and the Schema folder.

    click to view at full size

    Figure 18.8 Replicating system folders

  17. On BLUESKY-WKSTA, launch Outlook 2000, and verify that you can work with the public folder called Sub-BackDoor.
  18. In the Outlook toolbar, click Calendar. In the toolbar, click New, and, under Subject, type Now we have access to the Schedule+ Free Busy Folder, and then click the Save And Close button.
  19. Open the File menu and click Exit And Log Off. Notice that Outlook exists without error messages.

Exercise Summary

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.



MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
MCSE Training Kit Exam 70-224(c) Microsoft Exchange 2000 Server Implementation and Administration
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net