Lesson 3: Public Folder Replication Process

Public folder replication is a very complex process. When you add replicas to a public store, the PFRA must fill the new instances. As changes occur on any replica, those changes must be replicated and possible replication conflicts must be detected. If you remove a replica, the PFRA must stop sending replication messages to the affected public store. Likewise, a mechanism is required to handle lost replication messages and outdated servers that have been restored from an old backup.

This lesson explains the public folder replication process in depth and covers how the PFRA monitors replication changes. It also illustrates the backfill process as it is used to resynchronize "out-of-sync" folders, and the resolution of public folder replication conflicts.

---

At the end of this lesson, you will be able to:

• Describe the public folder replication process.
• Explain the purpose and mechanism of public folder backfilling.
• Determine causes of and solutions to replication conflicts.

Estimated time to complete this lesson: 75 minutes

---

The Replication Process

Public folder replication is an information distribution mechanism that allows you to synchronize copies of public folders between all servers that maintain a replica.

Public Folder Replication Transport Mechanism

As mentioned many times, content changes are replicated using e-mail messages, but the data must be secured because foreign messaging systems such as SMTP-based hosts on the Internet might be involved in message transfer. The slightest alteration can cause the replication to malfunction. A binary attachment called WINMAIL.DAT containing all of the information in transport-neutral encapsulation format (TNEF) provides the required protection mechanism even in cases where the message must travel through foreign systems. Messaging systems are not supposed to tamper with binary attachments.

PFRA Responsibilities

Per replica, the PFRA is responsible for maintaining a list of servers that is used to address replication messages to the required remote Information Store services. The initiating PFRA must generate replication messages, address them properly, and send them. The Exchange 2000 Server transport has to take care of the delivery. The receiving PFRA has to extract the TNEF attachment and must check if the modified item is more recent than its own to replace the older copy. Thus, replicas are synchronized again. This process is covered in more detail later in this lesson.

NOTE

---

By addressing more than one remote Information Store within a single replication message, the use of WAN connections and any other e-mail paths is optimized. Similar to an interpersonal message sent to multiple users, the Exchange 2000 Server transfers only one message. Messages are split into multiple instances at the very last point when separate paths must be used.

The following are the responsibilities of the PFRA:

• Addresses replication messages as determined by the public folder replication configuration
• Creates replication messages
• Monitors changes, additions, and deletions as they occur on replicas of public folders
• Receives replication messages and incorporates the changes into local replicas of public folders

Monitoring Message State Information

Message state information describes the collection of change numbers, time stamps, and predecessor change lists, which the PFRA uses to determine most recent items as they are replicated between public folder instances. Every public folder item provides message state information.

The following are the elements of message state information:

• Change number. Reflects the sequential modifications for all items of an information store
• Predecessor change list. Allows the detection of replication conflicts
• Time stamp. Identifies the most recent changes

Change Number

Change numbers identify public folder and content modifications. They are created using the globally unique identifier (GUID) of the information store and a server-specific change counter. The GUID is constant, which allows associating changes of an object with a particular public store. The server-specific change counter, in turn, identifies the most recent alteration, increasing whenever modifications are applied.

NOTE

---

The server-specific change counter reflects the sequential changes of all objects within the information store. In other words, whenever users create new public folders, change the design of existing ones, modify the contents of a replica, or perform other actions, the server-specific change counter is increased. The increased value is then assigned to the modified object to mark it as the most recent.

Predecessor Change List

The predecessor change list permits the PFRA to detect folder replication conflicts. It maintains a list of all Information Store services that have ever made changes to an object and their server-specific change counters. Public folder replication conflicts occur whenever multiple users modify the same object on two different locations at the same time. As long as the most recent changes have not been replicated to all other replicas, a chance for a replication conflict exists.

Figure 18.9 illustrates a situation in which the Administrator works with a public folder on BLUESKY-SRV2 while Carl Titmouse does the same using his local replica on BLUESKY-SRV1. Both users work with the same message item x. Item x contains an entry for BLUESKY-SRV1 in its predecessor change list. For simplification, let's say the Information Store ID is 999 (note that a real ID has far more digits), and the server-specific change counter is 2000. Because item x has so far never changed on BLUESKY-SRV2, an entry for BLUESKY-SRV2 is not yet present.

When both users save their changes at the same time, the predecessor change list is modified on both locations. The PRFA running on BLUESKY-SRV1 replaces its own entry with the current server-specific change counter—let's say 3000. Consequently, the predecessor change list of item x on BLUESKY-SRV1 is updated to 999-3000, while item x on BLUESKY-SRV2 still maintains only the entry 999-2000 because replication has not yet occurred. A new entry for BLUESKY-SRV2 is inserted into the predecessor change list—let's say 555-88888.

At this moment, two different copies of one particular message object exist, and both are the most recent copy. The most recent server-specific change number of BLUESKY-SRV1 cannot be found in the predecessor change list of item x on BLUESKY-SRV2. Conversely, the server-specific change number of BLUESKY-SRV2 is not present in the predecessor change list of item x on BLUESKY-SRV1. This is an indicator of a public folder replication conflict. Public folder replication conflicts and resolution are covered later in this lesson.

Figure 18.9 Monitoring replicated changes

Time Stamp

The time stamp provides information about when a particular item was last modified. It is used in conjunction with the change number to determine when an object was replicated most recently. Time stamps never decrease but always increase. In other words, if you modify a message within a public folder and the time stamp of the item is more recent than your computer time, the more recent time stamp is kept, meaning that the time stamp will not be changed.

Replicating Created and Deleted Messages

Whenever you create a new item in a particular public folder replica, this object must be created in all other existing replicas. Likewise, whenever you delete an object from a public folder, this object must be removed in all other locations.

Message Creation

New items receive the current change number, time stamp, and predecessor change list at the time of their creation. The PFRA handles the new object just like any other existing item, wrapping it in a replication message and sending it to all other existing instances (see Figure 18.10). The new object appears in all public folder replicas as soon as the replication cycle is completed.

Figure 18.10 Item creation, deletion, and expiration

Message Deletion

Replication of message deletions is performed using PFRA notification messages. The object to be deleted is indicated through its GUID, also known as the MAPI-based PR_ENTRYID property. Exchange 2000 Server assigns a permanent, unique PR_ENTRYID when an object is created. Every PFRA that receives the notification message identifies and deletes the object from its public folder replica.

Message Expiration

Message expiration refers to the automatic deletion of public folder items through defined age limits. In this case, notification messages are not generated or sent to any other replica. This permits the implementation of a different age limit for every public folder instance. In other words, each Information Store service is responsible for managing its own message expirations.

Replicating Item Modifications

All PFRAs exchange modifications directly with each other. It is possible that a particular replica receives old replication information, and, in this case, existing items should not be replaced.

Whenever a user modifies an item in a replicated public folder, a new change number is added to the modified item, its time stamp is updated, the predecessor change list is refreshed, and, finally, public folder replication is initiated. The PFRA places the message state information together with the modified item itself in a replication message, which it addresses to all servers that hold a replica.

As soon as a destination PFRA receives the replication message, message state information and modified item are extracted. The PFRA must double check the state information received with the state information from the local item. An item is replaced only if the change number of the local instance is included in the predecessor change list of the update message. In other words, the most recent changes of the local item are "old news" for the update message (see Figure 18.11).

Figure 18.11 Item modification replication

In the reverse order, the local item must not be replaced if its change number cannot be found in the replicated item's predecessor change list. In this case, it's possible that either the local item is more recent than the update message or that a replication conflict has occurred. If the replicated item's current change number is present in the local item's predecessor change list, the local item is more recent and is not replaced. However, if the local item's current change number cannot be found in the replicated item's predecessor change list, a replication conflict must be resolved, as explained later in this lesson.

Out-of-Sync Public Folders and Backfill

It is important to note that delivery confirmations are not exchanged between PFRAs because the e-mail-based transport is not suitable for sequencing and data acknowledgments. A nondelivery report might be the only hint that a replication message has not been transferred, but even that may not be received. The originating PFRA simply cannot determine whether a replication message is received. In fact, as soon as a replication message is sent, the local PRFA assumes that the replicas are synchronized. The local public folder status switches to In Sync right away. Therefore, there is a fair chance that the folders are not synchronized although their status indicates differently.

Status Messages

Status messages allow PFRAs to determine the real status of their replicas by comparing the message state information of the public folder instances themselves. Every public folder maintains a change number, time stamp, and predecessor change list, as do the items of its contents. Even if the contents of a particular replica have not been changed, status notifications are generated frequently to announce the replica's state to all other instances. The folder's message state information is included in these messages, and receiving PRFAs extract this information to check whether the remote change number is present in the local predecessor list. If it is, the replicas are synchronized. If it is not, the remote PRFA must update its replica. In this case, it sends a backfill request back to the other PFRA to receive all the changes that have not yet been incorporated. Backfill responses do not differ from regular replication messages.

NOTE

---

Status messages are exchanged periodically, at least once a day. Every replication message carries the status of the affected public folder as well.

Backfill

Backfilling allows PFRAs to resynchronize public folder replicas that are out of sync. When a PFRA determines that the current change number of a remote replica is not included in its own predecessor change list—in other words, if the remote replica contains more modifications than the local instance—a backfill request is returned to the remote PFRA, which includes the old replica-specific change number of the remote PFRA. The remote PFRA then sends all those changes that have a higher change number than indicated in the backfill request. As soon as the local PFRA receives these modifications, all replicas are synchronized again.

The following situations automatically initiate a backfill request:

• A public server has been restored from a backup.
• A public server was down while changes occurred.
• A replication message has been lost.

Accidental Deletion, Backfill, and a Workaround

Imagine that a user has accidentally deleted a replicated public folder. You decide to restore the public folder server from a recent backup. The messages are outdated again, but not for long. The backfill process ensures that all public folder replicas are brought up to date from the restored backup version. The most recent change (in this case, the accidental folder deletion) is replicated back into the restored server, and the folder once again disappears.

To work around this problem, you should restore the backup to a test machine that is not physically connected to the computer network. Then, log on using Outlook 2000, download the folder into a personal folder store (.pst) file, log off, include this .pst file in your actual messaging profile, and copy the folder back into the public folders tree. As you copy it, you create a new public folder containing all items. You will have to reconfigure the public folder replication, but the data was recovered. More information about personal folder store and messaging profiles is provided in Chapter 9, "MAPI-Based Clients."

Adding and Deleting Replicas

Whether you push or pull a new replica into a public store, the new replica will be empty and must be filled. Conversely, when you delete a particular public folder replica, you must ensure that all other servers stop sending update messages for this replica to your server.

Adding Replicas

The PFRA assigns the current change number, time stamp, and a fresh predecessor change list to each new object. It also does this for new public folder replicas. The change number of the new replica, however, does not yet exist on the predecessor change list of any other instance. Therefore, as soon as the first status message is sent to a remote PFRA maintaining a replica, the new out-of-sync replica is detected. The backfill process is launched to bring the new instance to the current state.

Deleting Replicas

You can eliminate public folder replicas by using the Administrator program, but this doesn't mean that you delete the entire public folder from the organization. Only one instance is removed from one server's public store. Other replicas remain, but they must be informed about the deletion to stop sending replication messages to the nonexisting instance.

The deletion of a replica eliminates its reference within the properties of the public folder object. This object is replicated as part of the hierarchy. Consequently, all servers with public stores associated with the hierarchy will be informed about the configuration alteration. Other servers maintaining an instance of the same public folder stop sending their public folder replication messages to the affected server.

Public Folder Conflict Resolution

The PFRA replaces older objects with more recent items, but which item does the PFRA replace in the event of a replication conflict, where two objects are both considered the most recent?

Conflicting Items

A replication conflict is detected if an incoming item does not include the current state of the local item, in other words, if the change number of the local item cannot be found in the predecessor list of the update message (see Figure 18.12).

Recovery

The PFRA cannot resolve replication conflicts; it simply doesn't know which item to prefer. Therefore, manual intervention is necessary. A conflict message, including the conflicting items as attachments, is generated and sent to the users that created the conflict and the public folder owners. This conflict message is also posted into the public folder and replicated to all other instances. You can open this message, check the items, and decide which one to keep to resolve the conflict: the local item, the update, or both items.

Conflicting Design Changes

A replication conflict can also occur when multiple public folder owners have changed the design of a particular public folder in two different locations at the same time. When this occurs, the public folder owners are notified about the design conflict, but no conflict message is posted into the public folder. The conflict message is only a notification that the last design change has been applied, which overwrites all previous changes automatically. It is a good idea to double check which configuration is in effect and readjust the design.

Figure 18.12 Resolving public folder replication conflicts

Exercise 2: Public Folder Conflict Resolution

In this exercise you will modify an item in two locations at the same time to create a public folder replication conflict. You will then use the resulting conflict message to keep both items in the public folder.

To view a multimedia demonstration that displays how to perform this procedure, run the EX2CH18*.AVI files from the \Exercise_Information\Chapter18 folder on the Supplemental Course Materials CD.

Prerequisites

• Complete Exercise 1, earlier in this chapter.
• Start BLUESKY-SRV1, BLUESKY-SRV2, and BLUESKY-WKSTA.
• Log on as Administrator to BLUESKY-SRV2.
• Log on as Carl Titmouse to BLUESKY-WKSTA.

To create and resolve public folder replication conflicts

1. On BLUESKY-WKSTA, launch Outlook 2000, make sure you are working with the mailbox of Carl Titmouse, and open the BackDoor public folder.
2. Right-click a free area on the desktop, point to New, and click Text Document.
3. Press ENTER to accept the default name of New Text Document, and then use the mouse to drag this item into the BackDoor public folder.
4. The document will be listed as a new item with a Subject of New Text Document. Wait for the public folder replication to distribute the new document to BLUESKY-SRV2. (Carl Titmouse is working with the default public store on BLUESKY-SRV1.)
5. On BLUESKY-SRV2, right-click My Computer on the desktop, and select Explore.
6. Expand the drive Exchange (M), expand Bluesky-inc-10.com, then Public Folders, and select BackDoor. If the New Text Document is not listed in the details pane, wait a few more minutes for the public folder replication to complete, then right-click the free area in the details pane, and click Refresh.
7. On BLUESKY-SRV2 and BLUESKY-WKSTA, open the New Text Document item at the same time. If Outlook 2000 displays an Opening Mail Attachment dialog box, select Open It, and click OK.
8. On BLUESKY-WKSTA, in Notepad, type This is a modification on BLUESKY-SRV1.
9. On BLUESKY-SRV2, in Notepad, type This is a modification on BLUESKY-SRV2.
10. On BLUESKY-SRV2 and BLUESKY-WKSTA, at the same time, open the File menu, and select Save. Close Notepad.
11. On BLUESKY-WKSTA, in Outlook 2000, wait until a replication conflict message is received. When the conflict is detected, the icon for the New Text Document item changes in the public folder (see Figure 18.13).
12. In the Outlook toolbar, click Inbox, and check that a new message with a subject of Conflict Message was received.
13. Open the BackDoor public folder again, and double-click the New Text Document item. The Conflict Message is opened, listing both versions of the New Text Document item. (Opening the Conflict Message from the Inbox has the same result.)
14. Double-click both items in the Conflict Message window to compare their content. Close the documents, and then, in the Conflict Message window, click Keep All. Notice that two New Text Document items are now displayed in the public folder.

    

    Figure 18.13 Resolving a public folder replication conflict in Outlook 2000

Exercise Summary

Public folder replication conflicts occur if users change the same item in different locations, thus creating two (or more) most recent versions of the item. The PFRA has no means to resolve this conflict and generates a conflict message, which contains the conflicting items. You can decide whether to keep one or all items. If you accept one item, the other objects are deleted from all public folder instances. If you decide to keep all items, two or more items appear in the public folder with the same subject line.