Microsoft KB Archive/812857

From BetaArchive Wiki
Knowledge Base


XADM: Public Folder Backfill of a New Exchange 2000 Public Folder Server

Article ID: 812857

Article Last Modified on 10/27/2006



APPLIES TO

  • Microsoft Exchange 2000 Server Standard Edition



SUMMARY

This article describes the public folder replica backfill algorithm process that occurs when a new Exchange 2000 public folder server is added to a multi-site wide area network (WAN) that also contains Microsoft Exchange Server 5.5 public folder servers.

MORE INFORMATION

When you add a new Exchange 2000 public folder server to a site, you also add a replica of an existing public folder to be replicated to that new server. The Exchange 2000 public folder server uses the replica backfill algorithm to retrieve missing data so that the public folder on the new server contains the same data as the other public folder servers. The algorithm gives preference to Exchange 2000 servers outside the site over Exchange Server 5.5 servers in the site. When you deploy a new Exchange 2000 server in a multi-site WAN that also contains Exchange Server 5.5 public folder servers, it may help you to understand what occurs during the backfill process.

When a server sends any kind of replication mail to another server, the originating server includes information about the set of changes it has received and stored. The receiving server compares this set of changes with its own set of changes and checks to see if it is missing any data. For each folder in the public folder, each server maintains a set of change numbers it has recorded as received and stored, and the set of change numbers reported by each of the other servers in the network. These changes are referred to as CN sets.

If the CN set on the receiving server does not equal the CN set on the originating server, the receiving server must ask for backfill. The backfill set is made up of the reportedly-owned CN sets on the other servers minus the already-owned CN set on the receiving server. It is expected that one server will have this whole set of changes. To obtain the most up to date public folder replica, Exchange 2000 searches the organization in the following order to find the first server that meets the requirements for the backfill operation:

  1. All Exchange 2000 servers in the same site, sorted by the time of the last backfill with the oldest times used first.
  2. All Exchange 2000 servers outside the site, sorted by cost with the lower-cost connections used first.
  3. All Exchange 2000 servers outside the site that have no affinity setting, sorted by transmission time with the shorter transmission times used first.
  4. All pre-Exchange 2000 servers (for example, Exchange Server 5.5) in the same site, sorted by the time of the last backfill with the oldest times used first.
  5. All pre-Exchange 2000 servers outside the site, sorted by cost with the lower-cost connections used first.
  6. All pre-Exchange 2000 servers outside the site that have no affinity settings, sorted by transmission time with the shorter transmission times used first.

During this process, any partial matches are discarded, and a backfill request is sent only if there was a partial match in the last search group. However, because the receiving server contains "change numbers" that it has previously received from another server, a full match should be found on the server that sent the "change numbers."

If the replication state table indicates that another server has all the missing CN sets, the receiving server sends a backfill request to this server. If multiple servers have the missing data, the lowest cost server is chosen, and preference is given to an Exchange 2000 server over an Exchange Server 5.5 server. If the replication state table shows that no single server has all the missing CN sets, then the receiving server sends backfill requests to multiple servers until all the entries in the backfill array for that folder have been received.

However, instead of expecting updates from every server, Exchange 2000 places a responder list in the status request that specifies which servers must respond with their status. Up to three servers are placed in the responder list, unless there are fewer than three servers in the replica list (for example, if there are just two servers in the replica list, both of these servers are listed as status request responders). Exchange 2000 uses the following algorithm to select the servers in the responder list:

  1. Intrasite, sorted by replica that has not been backfilled from for the longest time. After this server is chosen, the backfill time is updated so that this server effectively moves to the end of the queue. This prevents replication from prompting the same server(s) for status request.
  2. Intersite, sorted by affinity and referral cost from servers that are known to be active (that have sent replicas).
  3. Intrasite, regardless of previous backfilled data.
  4. Intersite, sorted by affinity and referral cost, regardless of known activity.
  5. Intersite by transmission time. This is based on the requesting server's estimate of how long it takes to receive updates from a remote server. This estimate is not particularly accurate, but is used to make an more efficient decision about which server to request status from.
  6. Intersite, regardless of transmission time .

After this process is complete, the replication engine calculates which server has the oldest copy of the replica. If this server is not already in the responder list, Exchange 2000 adds it to the list. This extra safety measure ensures that status requests are not sent to new servers that may only have partial details. These servers respond to the status requests and send any missing CN sets back to the requestor. Preference is given to Exchange 2000 servers over Exchange Server 5.5 servers and to full matches over partial matches.

This overview illustrates that the algorithm that is described earlier in this article may result in backfill requests outside the site. Microsoft recommends that you plan accordingly and replicate small batches of content at a time, so that you do not saturate the queues between the remote sites.

For additional information about how Exchange 2000 Server determines the preferred public folder replica for a backfill, click the following article number to view the article in the Microsoft Knowledge Base:

812223 XADM: How Exchange 2000 Server Determines the Public Folder Replica from Which to Backfill




Keywords: kbinfo kbbug KB812857