Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Topic Last Modified: 2009-12-07
Public folder replication is the process by which public folder content and the public folder hierarchy are replicated across multiple servers for efficiency and fault tolerance purposes. When multiple public folder databases located on separate servers support a single public folder tree, Microsoft Exchange uses public folder replication to keep the databases synchronized. Public folder content exists only in Exchange stores configured to have a replica of a specific folder. Content and hierarchy information are replicated separately. Each public folder database retains a copy of the hierarchy, which includes lists of the other public folder databases that retain content replicas of each folder. Content replicas exist only on the public folder databases that you specify. For more information about how to configure public folder replication, see Configure Public Folder Replication.
 Note: |
|---|
| Unlike in Exchange Server 2007, you can't use continuous replication in Exchange Server 2010 to replicate public folders. In Exchange 2010, continuous replication is for mailbox databases only. A public folder database can be hosted on a Mailbox server in a database availability group (DAG), but you must use multiple public folder databases and public folder replication for data redundancy. |
Public folder databases replicate two types of public folder information:
- Hierarchy Hierarchy replication occurs
when the properties of the folders and organizational information
about the folders have been modified. All public folder databases
have a copy of the hierarchy information. Modifying the following
public folder information results in hierarchy replication:
- Folder name
- Replica list
- Folder's position in the public folder tree (including any
parent and child folders)
- Permissions
Note:Hierarchy replication doesn't occur when you change the e-mail addresses for a mail-enabled public folder. The e-mail addresses are stored on the directory object in Active Directory. Only by changing the properties within the public store database does hierarchy replication occur.
- Folder name
- Content Content replication occurs when
messages are sent to public folders or when data is added. For
example, sending e-mail messages to a mail-enabled public folder or
adding an organizational form to a public folder results in content
replication. To replicate content, you must configure a folder to
replicate its content to a specific public folder database or list
of databases. Only the databases that you specify will have copies
of the content. A copy of the folder that includes content is
called a content replica.
Contents
How Public Folder Replication Works
Backfill Requests and Backfill Messages
Examples of Replication Cycles
Best Practices for Implementing Replication
Looking for management tasks related to public folders? See Managing Public Folders.
How Public Folder Replication Works
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 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.
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 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:
- A user modifies the public folder.
- The local public folder database records the change.
- 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 can't 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.
- 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).
- 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.
- 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.
- 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
can't pack hierarchy updates into the same replication message as
content updates, and each content replication message contains
updates for a single folder.
- 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 doesn't 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.
- The public folder database receives the replication
message.
- The receiving public folder database unpacks the update and
status information from the replication message.
- 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 hasn't previously received.
- The database applies the new updates to the appropriate folder
replicas.
- 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.
Replication Messages
The replication process uses the Active Directory attributes of the public folder databases, and 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 aren't bound by the restrictions 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 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
| Message type* | When used |
|---|---|
|
Hierarchy (0x2) |
Replicates hierarchy changes from the local public folder database to all other public folder databases that support the same hierarchy. Although Exchange handles hierarchy changes separately from changes to content replicas, it treats the hierarchy as if it was another folder. In some event messages and other operations, Exchange 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 database. This includes hierarchy and content change numbers. |
|
Backfill response (0x80000002 or 0x80000004) |
Sends missing data in CNSets to a database that requested missed updates. |
|
Status (0x10) |
Sends the current CNSet of a folder to one or more replicas of that folder. This includes hierarchy and content change numbers. |
|
Status request (0x20) |
Requests CNSets to be replicated or status messages to be returned. This includes hierarchy and content change numbers. |
Replication State Table
Each public folder database maintains a replication state table to track the status of each replica in the database. The replication state table stores the following information:
- Basic information required to construct updates to each
replica.
- Information about the last update to each replica that
originated in the local database, 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 for all updates in a group is
called a CNSet. Update information is passed from one database to
another as part of the replication process.
The following tables provide an example of how replication state tables function. In this example, the public folder databases on Server A and Server B both have replicas of a folder named 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 determines whether its replica of Projects folder is synchronized with the replica of the Projects folder 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 folder on Server A (local replica) |
Last update sent: A-100 |
|
Projects folder on Server B |
A-100 received B-50 received |
Sample data from the replication state table for Server B
| Replica | Data |
|---|---|
|
Projects folder on Server A |
A-100 received B-50 received |
|
Projects folder on Server B (local replica) |
Last update sent: B-50 |
By combining the lists of public folder databases that contain content replicas with the information in the replication state table, each public folder database can determine how up to date it is compared to the other public folder databases that support the public folder tree.
Backfill Requests and Backfill Messages
Backfilling occurs when a public folder database determines that it hasn't 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 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
| Type of request | Content exists on a database in the local Active Directory site | Content exists on a database in a remote Active Directory site |
|---|---|---|
|
Initial backfill |
6 hours |
12 hours |
|
First backfill retry |
12 hours |
24 hours |
|
Subsequent backfill retries |
24 hours |
48 hours |
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:
- Sort according to server status. Servers that are down or
unavailable drop to the end of the list.
- 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 don't need a preferred backfill server. Microsoft
Customer Service and Support can provide a script that sets a
preferred backfill server if your deployment requires it.
- Sort according to transport cost (lowest to highest). Servers
in the same routing group have priority over servers in remote
Active Directory sites.
- Sort according to Exchange version (newest to oldest).
- Sort according to the number of necessary changes available on
the server (largest to smallest). Servers that don't have any of
the missing changes are dropped from the list.
If one server doesn't 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 doesn't respond to the backfill request, the database marks that server as unavailable and repeats the selection process. Servers marked as unavailable move to the end of the list.
Status Requests and Status Messages
In addition to the status information in each replication message, Exchange uses status requests and status messages to determine whether public folders must issue backfill requests.
A public folder database sends a status request under the following circumstances:
- The database is notified of a change to the list of databases
that hold replicas of a folder. For example, if you add a database
to the list or remove a database from the list, Exchange replicates
this change by using hierarchy update messages. In this case, the
database sends a status request that requires every database that
contains a replica of the folder to respond.
- A new database has started for the first time. In this case,
the database requests the status of the public folder hierarchy.
The database sends a status request that requires every database
that supports the public folder tree to respond.
- A database that has been restored by using Windows Server
Backup starts for the first time after the restore completes. In
this case, the database requests the status of the public folder
hierarchy and all of the folders for which the database contains
content replicas. This status request lists two or three databases
as required responders. Required responders are databases that
support this hierarchy and, according to an internal selection
process, are dependable sources of folder content.
To indicate the current state of a particular folder on the sending database, the public folder database sends a status message to another database under the following circumstances:
- In response to a status request sent by another database. The
status message is sent only to the requesting database and only if
the following are true:
- The database that received the status request is in the
requests list of required responders.
- The replication state table indicates that the database that
received the status request has updates that are missing from the
database that sent the request.
- The database that received the status request is in the
requests list of required responders.
- If there have been no subsequent updates 24 hours after the
most recent update to a folder was received. Each time the database
receives an update for a specific folder, the timer is reset to 24
hours. This status message is sent to the other public folder
databases that contain replicas of the updated folder.
If a public folder database receives a status message indicating that the sending database has more recent information about the folder, the receiving database 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 database starts for the first time, it sends status request messages to each database that supports the public folder hierarchy. Each database responds with information about the status of the hierarchy (as tracked by that database). The new database uses this information to identify which replicas (if any) it should have. The new database can then send backfill requests as needed to fill in the replica content.
Examples of Replication Cycles
The following figure illustrates a simplified two-server scenario that shows the sequence of events that occurs 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.
The details of the process are as follows:
- Working on ExServ01, an administrator adds ExServ01 to a
folder's replica list.
- ExServ01 sends a hierarchy message.
- ExServ02 adds ExServ01 to the local copy of the folder's
replica list.
- ExServ01 sends a status request to ExServ02.
- ExServ02 sends a status message to ExServ01 that includes the
full CNSet of the folder.
- ExServ01 determines that all the folder content is missing and
records the appropriate entries in the backfill array.
- If the content is still missing when the backfill time-out
elapses, ExServ01 creates a backfill request and sends it to
ExServ02.
- ExServ02 compiles the content messages and sends them to
ExServ01.
- ExServ01 uses the incoming content messages to update the
folder content and related tracking information.
- 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 occur 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.
The details of the process are as follows:
- Working on ExServ01, an administrator removes ExServ01 from a
folder's replica list.
- 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.
- ExServ01 sends a hierarchy message.
- 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.
- ExServ01 sends a status request to ExServ02.
- ExServ02 sends a status message to ExServ01. If the replica on
ExServ02 isn't up to date, ExServ02 places the appropriate entries
in the backfill array. Within five minutes, ExServ02 sends the
corresponding backfill request to ExServ01.
- ExServ01 checks that the folder replica on ExServ02 contains
all of the information that the delete pending replica does. If it
doesn't, 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 doesn't result in a loss of content.
- ExServ01 marks its replica as delete now. The next
maintenance cycle will remove the replica from ExServ01.
- ExServ01 sends a hierarchy message.
- ExServ02 removes ExServ01 from its copy of the folder's replica
list.
Best Practices for Implementing Replication
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's 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.