How Replication Works
When multiple public folder stores—each located on a separate server—support a single public folder tree, Exchange Server 2003 uses public folder replication to keep the stores synchronized.
Public folder content exists only in stores that are configured to have a replica of a specific folder. Content and hierarchy information are replicated separately. Each store keeps a copy of the hierarchy, which includes lists of which other stores hold content replicas of each folder. Content replicas exist only on the stores that you specify.
Each public folder store maintains a Replication State Table to track the status of each replica in the store. The Replication State Table stores the following information:
Basic information that is required to construct updates to each replica.
Information about the last update to each replica that originated in the local store, including the change number of the update.
Groups of updates that have been applied to all other known replicas of the folder. Change numbers identify the updates in each group. The set of change numbers of all of the updates in a group is called a CNSet. Update information is passed from one store to another as part of the replication process.
The following tables provide a simplified example of how Replication State Tables work. In this example, public folder stores on Server A and Server B both have replicas of a folder called Projects. On each server, the Replication State Table tracks not only the status of the replica on that server, but also the status of the replica on the other server. Using this information, Server A can determine whether its replica of Projects is synchronized with the replica of Projects on Server B. Server B can likewise track its status relative to Server A.
Sample data from the Replication State Table for Server A
| Replica | Data |
|---|---|
Projects on Server A (local replica) |
Last update sent: A-100 |
Projects on Server B |
A-100 received B-50 received |
Sample data from the Replication State Table for Server B
| Replica | Data |
|---|---|
Projects on Server A |
A-100 received B-50 received |
Projects on Server B (local replica) |
Last update sent: B-50 |
By combining the lists of stores that hold content replicas and the information in the Replication State Table, each public folder store can determine how up-to-date it is compared to the other stores that support the public folder tree. For information about how public folder stores use this information, see Backfill Requests and Backfill Messages.
When a folder or its contents are modified, the store that hosts the replica that was changed sends an e-mail message of the change to the other stores in the form of a replication message. Exchange Server 2003 routes the replication message the same way that it routes other e-mail messages. For replication to work properly:
The Recipient Update Service must be able to stamp e-mail attributes on the store objects in the Active Directory directory service (such as mail and proxyAddresses). Usually, Exchange Server 2003 automatically creates the recipient policies that the Recipient Update Service follows to update the store objects.
Exchange Server 2003 must be able to route e-mail messages between the replicating servers. Replication messages can be routed through different types of e-mail links (such as routing group connectors and X.400 connectors).
Note
The replication process uses the Active Directory attributes of the public folder stores, not of individual public folders. The Active Directory entries for individual public folders are only used to send regular e-mail messages to or from the folders. The following figure shows a public folder store object in Active Directory. A public folder store object is configured and maintained automatically, and resides in the Configuration container in Active Directory.
Public folder store objects in Active Directory
.gif "7a8e9d93-a998-494d-99c2-92fda45613d0")
Replication messages differ from other e-mail messages in that Exchange Server 2003 treats replication messages as system messages. This means that replication messages are not bound by the normal restrictions that are applied to user e-mail messages, such as size and delivery restrictions. In the Exchange Server 5.5 directory, replication messages were also system messages.
The following table lists the different types of replication messages that Exchange Server 2003 uses.
Types of public folder replication messages and when they are used
| Message type* | When used |
|---|---|
Hierarchy (0x2) |
Replicates hierarchy changes from the local public folder store to all other public folder stores that support the same hierarchy. Although Exchange Server 2003 handles hierarchy changes separately from changes to content replicas, it otherwise treats the hierarchy as if it was another folder. In some event messages and other operations, Exchange Server 2003 refers to the hierarchy as Folder 1-1. |
Content (0x4) |
Replicates content changes from one replica to all other content replicas of that folder. A content message only contains information that applies to a single folder. |
Backfill request (0x8) |
Requests missing data (in CNSets) from another store (both hierarchy and content change numbers). |
Backfill response (0x80000002 or 0x80000004) |
Sends missing data (in CNSets) to a store that requested missed updates. |
Status (0x10) |
Sends the current CNSets of a folder to one or more replicas of that folder (both hierarchy and content change numbers). |
Status request (0x20) |
Requests CNSets to be replicated, or status messages to be returned (both hierarchy and content change numbers). |
* The value in parentheses is the hexadecimal notation of the message type, which is used in events and logs. Use the hexadecimal value when you are troubleshooting replication issues. For more information about troubleshooting replication issues, see Troubleshooting and Repairing Exchange Server 2003 Store Problems.
Basic Hierarchy and Content Replication Process
When a user modifies a public folder, the following process occurs on the server that holds the replica of the folder to which the user is connected:
The public folder store records the change.
At the next scheduled replication cycle (which is determined by the replication interval set for the public folder store), the public folder store checks the folder properties to determine which other servers hold a replica of that folder. If other replicas exist, the store determines what information needs to be replicated to them. This information becomes the update to the replicas.
Public folder replication is object-based. If one property of an object is modified, the entire object must be replicated. The store that is replicating the change cannot assume that all of the receiving replicas are up-to-date, so it must send the whole object. The implications for the different types of replication are as follows:
Hierarchy replication If a new folder is created or if a folder property (such as its display name) is changed, the update includes all of the folder's properties.
Content replication If a new message is posted or an existing message is modified, the update includes the entire message and its properties.
The public folder store assigns a change number to the update.
When a folder replicates an update to another server, the change number is included with the update. The receiving server then uses the change number to determine whether the update represents a new change, and whether the server is missing any data.
Change numbers are similar to the Update Sequence Numbers (USNs) used in Active Directory replication. However, in most other aspects, public folder replication is different from Active Directory replication.
The public folder store packs updates into a replication message. The change numbers of all of the updates in the message are referred to as a CNSet.
Along with the updates, the public folder store packs information from the folder's entries in the Replication State Table, including the CNSets that were applied to the replica previously. This means that the replication message includes the status of the sending folder.
To reduce mail traffic, the public folder store packs multiple hierarchy updates into a single replication message. Likewise, the store packs multiple content updates for the same folder into a single replication message. However, the store cannot pack hierarchy updates into the same replication message as content updates, and each content replication message holds updates for a single folder.
The public folder store addresses the replication message to the other public folder stores that host replicas of the updated folder. The store sends the message, along with any other messages that have been packed since the previous replication cycle.
The public folder store relies on the internal routing components in Exchange Server 2003 to deliver replication messages. The store makes no attempt to split replication messages based on topology details. If the contents of a folder are modified and the folder has five other replicas, the store generates a single replication message and addresses it to all five stores that host those replicas. It is up to the routing components to determine how to route and deliver the message.
When a public folder store receives a replication message, the following process occurs:
The public folder store unpacks the updates and status information from the replication message.
The store compares the change numbers of the new updates to the list of change numbers that it already has, and identifies which updates it has not received previously.
The store applies the new updates to the appropriate folder replicas.
For each updated replica, the store updates the Replication State Table with the change numbers of the current updates and the folder status information from the replication message.
If the information in the Replication State Table indicates that other CNSets have been applied to other replicas of the folder but not to this store's replica, the store records which CNSets are missing in a location called the backfill array and prepares to send a backfill request. (For details, see Backfill Requests and Backfill Messages.)
Warning
If you make changes to the public folder hierarchy that affect several folders at once, the replication process may require considerable network bandwidth. For example, in order to move public folders from one server to another, you need to create new replicas on the new server, wait for the hierarchy changes to replicate to the original server, and wait for content to replicate to the new replicas. After the replicas have synchronized, you need to remove the replicas from the old server. Even this operation generates network traffic, because the fact that the replicas have been deleted must replicate as a hierarchy change. To gain a better understanding of how such changes will affect your system, see "Status Requests and Status Messages" later in this topic and Backfill Requests and Backfill Messages.
Status Requests and Status Messages
In addition to the status information in each replication message, Exchange Server 2003 uses status requests and status messages to determine whether public folders need to issue backfill requests.
A public folder store sends a status request under the following circumstances:
The store is notified of a change to the list of stores that hold replicas of a folder. For example, you used Exchange System Manager to add a store to the list or remove a store from the list. Exchange Server 2003 replicates this change using hierarchy update messages. In this case, the store sends a status request that requires every store that holds a replica of the folder to respond.
A new store has started for the first time. In this case, the store requests the status of the public folder hierarchy (which for status purposes is treated as a special folder called Folder 1-1). The store sends a status request that requires every store that supports the public folder tree to respond.
A store that has been restored using Microsoft Windows Backup starts for the first time after the restore completes. In this case, the store requests the status of the public folder hierarchy and all of the folders for which the store holds content replicas. This status request lists two or three stores as required responders. Required responders are stores that support this hierarchy and according to an internal selection process, are dependable sources of folder content.
A store has been restarted with the Replication Flags registry key set. For more information about using this registry key, see Microsoft Knowledge Base article 813629, "Update to Send Status Request Messages in Microsoft Exchange 2000 Server." In this case, the store requests the status of the public folder hierarchy and any content replicas that appear to be missing updates. This request lists two or three stores as required responders.
A store has been restarted with the Enable Replication Messages On Startup registry key set. For more information about using this registry key, see Microsoft Knowledge Base article 321082, "How to Send Replication Status Request Messages in Exchange 2000 Server." In this case, the store requests the status of the public folder hierarchy and all content replicas. This request lists two or three stores as required responders.
A store sends a status message to another store to indicate the current state of a particular folder on the sending store. A store sends a status message under two circumstances:
In response to a status request sent by another store. The status message goes only to the requesting store, and only if both of the following are true:
The store that received the status request is in the requests list of required responders.
The Replication State Table indicates that the store that received the status request has updates that are missing from the store that sent the request.
Twenty-four hours after the most recent update to a folder was received, if there have been no subsequent updates. Each time the store receives an update for a specific folder, the timer is reset to 24 hours. This status message goes to the other public folder stores that have replicas of the updated folder.
A store follows a set schedule for checking whether it needs to send status messages. By default, this check runs at 00:15 and 12:15 Coordinated Universal Time (Greenwich Mean Time). As a result, after a folder has been updated, a store might send a status message as many as 36 hours later.
If a public folder store receives a status message regarding a folder that indicates that the sending store has more recent information about the folder, the receiving store creates a backfill request. If the change numbers are shown to be equal (or the change numbers on the receiving server are more recent), no action is taken.
For example, when a new public folder store starts for the first time, it sends status request messages to each store that supports the public folder hierarchy. Each store responds with information about the status of the hierarchy (as tracked by that store). The new store uses this information to identify which replicas (if any) it should have. The new store can then send backfill requests as needed to fill in the replica content.