When you modify a public folder or its contents, the public folder database that contains the replica of the public folder that was changed sends a descriptive e-mail message to the other public folder databases that host a replica of the public folder. To reduce traffic on your network, Exchange includes information about multiple changes in one e-mail message. The amount of information that is included in these messages depends on the size limit you set for replication messages. If any message exceeds the specified size limit, that message is sent as a separate replication message. Exchange routes these replication messages the same way that it routes other e-mail messages. For more information about public folder routing, see Routing Messages to Public Folders.

If you make changes to the public folder hierarchy that affect several folders, the replication process may require considerable network bandwidth. For example, to move public folders from one server to another, you must create new replicas on the server to which you want to move the public folders, wait for the hierarchy changes to replicate to the original server, and then wait for the content to replicate to the new replicas. After the replicas are synchronized, you must remove the replicas from the old server. Even removing the replicas from the old server generates network traffic because removing replicas must replicate as a hierarchy change. To learn more about how these changes to the public folder hierarchy can affect your system, see "Status Requests and Status Messages" later in this topic.

Basic Hierarchy and Content Replication Process

The following figure and the explanatory text that follows describe the basic process by which public folder hierarchy and public folder content are replicated.

The details of the process are as follows:

1. A user modifies the public folder.
   
2. The local public folder database records the change.
   
3. At the next scheduled replication cycle (which is determined by the replication interval that you set for the public folder database), the public folder database checks the folder properties to determine which other servers contain a replica of that folder. If other replicas exist, the database determines what information must 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. Because the database that replicates the change cannot assume that all of the receiving replicas are up-to-date, it must replicate the entire object. The implications for the different types of replication are as follows:
   
   • Hierarchy replication   The replication of new hierarchy changes occurs when a public folder is created or deleted, or when a change is made to the properties of a public folder (such as a change to the replica list, client permissions, description, administrative note, or storage limits).
     
   • Content replication   If a new message is posted or an existing message is modified, the update includes the entire message and its properties.
     
4. The public folder database 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.
   
5. The public folder database packs updates into a replication message. The change numbers of all of the updates in the message are called a change number set (CNSet).
   Along with the updates, the public folder database packs information from the folder's entries that are in the Replication State Table, including the CNSets that were previously applied to the replica. For more information about the Replication State Table, see "Replication State Table" later in this topic.
   
6. To reduce mail traffic, the public folder database packs multiple hierarchy updates into a single replication message. Likewise, the database packs multiple content updates for the same folder into a single replication message. However, the database cannot pack hierarchy updates into the same replication message as content updates, and each content replication message contains updates for a single folder.
   
7. The public folder database addresses the replication message to the other public folder databases that host replicas of the updated folder. The database sends the message, along with any other messages that have been packed since the previous replication cycle.
   To deliver replication messages, the public folder database relies on the internal routing components in Exchange. The database does not 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 database generates a single replication message and addresses it to all five databases that host those replicas. The routing components determine how to route and deliver the message.
   
8. The public folder database receives the replication message.
   
9. The receiving public folder database unpacks the update and status information from the replication message.
   
10. The database compares the change numbers of the new updates to the list of change numbers that it already contains, and then identifies which updates it has not previously received.
    
11. The database applies the new updates to the appropriate folder replicas.
    
12. For each updated replica, the database updates the Replication State Table with the change numbers of the current update 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 replicas on this database, the database records the CNSets that are missing in a location called the backfill array, and then prepares to send a backfill request. For more information about backfill requests, see "Backfill Requests and Backfill Messages" later in this topic.
    

The replication process uses the Active Directory attributes of the public folder databases, not the Active Directory attributes of individual public folders. The Active Directory attributes for individual public folders are used only to send regular e-mail messages to or from the folders. A public folder database object is configured and maintained automatically and resides in the Configuration container in Active Directory.

Replication messages differ from other e-mail messages in that Exchange treats replication messages as system messages. This means that replication messages are not bound by the restrictions that are applied to user e-mail messages (such as size and delivery restrictions). 

The following table lists the different types of replication messages that Exchange uses.

Note:
The values that are listed in parentheses in the following table are the hexadecimal notation of the message types. These notations are used in events and logs. You can use the hexadecimal value to troubleshoot replication issues.

Types of public folder replication messages and when they are used

Replication State Table

Backfilling occurs when a public folder database determines that it has not received all the updates for a replicated folder (or for the hierarchy) and must therefore retrieve the missing updates from another public folder database.

To streamline the backfill process, Exchange 2007 stores information about missing updates in the backfill array.

The following events may alert a public folder database to missing updates that need to be backfilled:

• The status information in an incoming replication message indicates that the replica on the public folder database that sent the message has updates that are missing on the receiving database. The receiving database identifies the missing change numbers and stores them in its backfill array.
  
• A public folder database starts for the first time. The new database sends status requests to get information about the other databases in the hierarchy. After the corresponding status messages arrive, the database populates its Replication State Table and, if necessary, the backfill array. The backfill array may contain entries for both the hierarchy and for any content replicas that the database must host.
  
• An incoming hierarchy message indicates that a new content replica is to be placed in the public folder database. The new database sends status requests to get information about content that might be available for this replica in the other databases in the hierarchy. After the corresponding status messages arrive, the database populates the Replication State Table and, if necessary, the backfill array.
  

The backfill array stores this information for a specified length of time (called the backfill time-out). If the missing updates arrive in subsequent replication messages during this time, they are removed from the backfill array. The following table lists the default backfill time-out values, which depend on where the missing updates exist and whether they were previously requested.

Default time-outs used for backfill requests

If the backfill time-out expires, and the updates are still missing, Exchange creates one or more backfill requests and determines which servers to use as backfill sources.

To select servers to use as a backfill source, Exchange first creates a list of all the servers that have replicas of the folder and then sorts the list according to the following sequence of criteria:

1. Sort according to server status. Servers that are down or unavailable drop to the end of the list.
   
2. Sort according to preferred backfill server (if any). Exchange checks the public folder database object in Active Directory for a preferred backfill server. This setting is seldom used. In most circumstances, the backfill process operates most efficiently if Exchange selects a backfill server automatically. Most deployments of Exchange do not need a preferred backfill server. Microsoft Product Support Services can provide a script that sets a preferred backfill server if your deployment requires it.
   
3. Sort according to transport cost (lowest to highest). Servers in the same routing group have priority over servers in remote Active Directory sites.
   
4. Sort according to Exchange version (newest to oldest).
   
5. Sort according to the number of necessary changes that are available on the server (largest to smallest). Servers that do not have any of the missing changes are dropped from the list.
   

If one server does not have all the necessary changes, Exchange selects the next server in the sorted list and sends a backfill request to that server as well. This process is repeated until all of the changes are requested.

If the selected server does not respond to the backfill request, the database marks that server as unavailable and repeats the selection process. Servers that are marked as unavailable move to the end of the list.

Status Requests and Status Messages

The following figure illustrates a simplified two-server scenario that shows the sequence of events that you trigger when you add a content replica to a public folder database. This action adds the public folder database to the folder's replica list. Note that the sequence of steps depends on factors such as the timing of the replication intervals and the routing topology.

Sequence of events when you add a replica to a public folder database

The details of the process are as follows:

1. Working on ExServ01, an administrator adds ExServ01 to a folder's replica list.
   
2. ExServ01 sends a hierarchy message.
   
3. ExServ02 adds ExServ01 to the local copy of the folder's replica list.
   
4. ExServ01 sends a status request to ExServ02.
   
5. ExServ02 sends a status message to ExServ01 that includes the full CNSet of the folder.
   
6. ExServ01 determines that all the folder content is missing and records the appropriate entries in the backfill array.
   
7. If the content is still missing when the backfill time-out elapses, ExServ01 creates a backfill request and sends it to ExServ02.
   
8. ExServ02 compiles the content messages and sends them to ExServ01.
   
9. ExServ01 uses the incoming content messages to update the folder content and related tracking information.
   
10. If change numbers still appear to be missing, ExServ01 waits 24 hours, and then sends an updated backfill request. If a server other than ExServ02 is available, ExServ01 might send the request to that server.
    

The following figure illustrates a simplified two-server scenario that shows the sequence of events that you trigger when you remove a replica from a public folder database. (This action removes the public folder database from the folder's replica list.) Note that the sequence of steps depends on factors such as the number of servers in the topology.

Sequence of events when you remove a replica from a public folder database

The details of the process are as follows:

1. Working on ExServ01, an administrator removes ExServ01 from a folder's replica list.
   
2. ExServ01 marks its replica (the copy of the folder on ExServ01) as delete pending.
   Clients can no longer access the folder by using this database.
   
3. ExServ01 sends a hierarchy message.
   
4. ExServ02 updates its copy of the folder's replica list to show that the folder is in the delete pending state on ExServ01.
   ExServ02 no longer refers clients that are looking for this folder to ExServ01.
   
5. ExServ01 sends a status request to ExServ02.
   
6. ExServ02 sends a status message to ExServ01. If the replica on ExServ02 is not up to date, ExServ02 places the appropriate entries in the backfill array. Within five minutes, ExServ02 sends the corresponding backfill request to ExServ01.
   
7. ExServ01 checks that the folder replica on ExServ02 contains all of the information that the delete pending replica does. If it does not, ExServ01 sends the appropriate content updates and returns to Step 5. Otherwise, ExServ01 continues to Step 8.
   This process ensures that as long as other replicas exist, deleting a single replica does not result in a loss of content.
   
8. ExServ01 marks its replica as "delete now." The next maintenance cycle will remove the replica from ExServ01.
   
9. ExServ01 sends a hierarchy message.
   
10. ExServ02 removes ExServ01 from its copy of the folder's replica list.
    

Public folder replication in Exchange can be a resource-intensive operation. Replication requires network, CPU, and disk resources to operate. By implementing a solution that enables efficient public folder replication, especially in organizations with heavy public folder usage, you may greatly improve network, CPU, and disk load in your Exchange organization.

Generally, it is a best practice to minimize replication across the organization. By minimizing replication, you minimize the amount of data that travels over your network. Additionally, by minimizing replication, you can help make sure that multiple users are less likely to access different versions of data on multiple replicas. However, you should note that by minimizing replication, you decrease availability of the public folder data because fewer replicas of the folder are available to clients if a public folder database fails. If availability on a large scale is required for data in a specific public folder, you may require more replication.

Continuous replication and public folder replication are two very different forms of replication that are built into Exchange. Due to interoperability limitations between continuous replication and public folder replication, there is specific guidance for combining public folder replication with continuous replication. To review this guidance, see Planning for Cluster Continuous Replication, Planning for Local Continuous Replication and Standby Continuous Replication.

To learn more about public folders, see Understanding Public Folders.

For more information about how to manage public folders, see Managing Public Folders.

For more information about how to manage public folder databases, see Managing Public Folder Databases.