Backfill Requests and Backfill Messages

 

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

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

The following events might alert a public folder store to missing updates that need to be backfilled:

• The status information in an incoming replication message indicates that the replica on the public folder store that sent the message has updates that are missing on the receiving store. The receiving store identifies the missing change numbers and stores them in its backfill array.

• A public folder store starts for the first time. The new store sends status requests to get information about the other stores in the hierarchy. After the corresponding status messages arrive, the store populates its Replication State Table and, if necessary, the backfill array. The backfill array might contain entries for both the hierarchy and for any content replicas that the store needs to host.

• An incoming hierarchy message indicates that a new content replica is to be placed in the public folder store. The new store sends status requests to get information about content that might be available for this replica in the other stores in the hierarchy. After the corresponding status messages arrive, the store 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 have been requested before.

Default time-outs used for backfill requests

Type of request	Content exists on a store in the local routing group	Content exists on a store in a remote routing group
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 Server 2003 creates one or more backfill requests and determines which servers to use as backfill sources.

To select a server (or servers) to use as a backfill source, Exchange Server 2003 first creates a list of all of 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 Server 2003 checks the public folder store 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 Server 2003 selects a backfill server automatically. Most deployments of Exchange Server 2003 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 routing groups. The transport cost of a server is calculated by the Exchange Server 2003 routing engine and is normally used to calculate the most efficient way to deliver a message.

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 of the needed changes, Exchange Server 2003 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 have been requested.

If the selected server does not respond to the backfill request, the store marks that server as down and repeats the selection process. Servers marked down drop to the end of the list.

Advantages Provided by Exchange Server 2003 Backfill

The backfill process is more efficient in Exchange Server 2003 than in previous versions of Exchange. This improved efficiency results from a stronger emphasis on transport cost in the selection criteria for backfill servers, and from the ability to send backfill requests to more than one server at a time. The following provides details of the improvements:

• Transport cost has priority over Exchange version.

  Consider an Exchange Server 5.5 deployment of several sites that must be upgraded to Exchange Server 2003. Each site contains multiple servers that each replicate public folders. Add one server running Exchange Server 2003 to each site. In each site, the Exchange Server 2003 server backfills its public folders from the local Exchange Server 5.5 servers, rather than searching for a newer server in one of the remote sites.

• Transport cost has priority over the number of updates available.

  For example, if some updates are available on a server with a lower transport cost, that server is selected to backfill those updates, even if the rest of the updates must be obtained from other, higher cost, servers. In previous versions of Exchange, a server that holds all of the necessary updates is chosen over a server that holds only some of the updates, regardless of transport cost.

Another improvement to the Exchange Server 2003 backfill process is the ability to send backfill requests simultaneously to different servers after the initial 6-hour time-out period (or 12 hours for sending requests to servers in remote sites). This process is much faster than that of previous versions of Exchange, which send backfill requests to one server at a time if no single server holds all of the missing updates for a specific folder. After each request, previous versions of Exchange wait for the retry time-out (from 24 through 48 hours) to elapse before sending the next request. For more information about backfill time-outs, see the default time-outs used for backfill requests table earlier in this topic.

Example Replication Cycles

The following figure is a simplified two-server scenario that shows the sequence of events that you trigger when you add a content replica to a public folder store. This action adds the public folder store 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 store

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 of 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 is a simplified two-server scenario that shows the sequence of events that you trigger when you remove a replica from a public folder store. (This action removes the public folder store 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 store

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 using this store.

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 will no longer refer 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 will send 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 with 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.