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:
- All Exchange 2000 servers in the same site, sorted by the
time of the last backfill with the oldest times used first.
- All Exchange 2000 servers outside the site, sorted by cost
with the lower-cost connections used first.
- All Exchange 2000 servers outside the site that have no
affinity setting, sorted by transmission time with the shorter transmission
times used first.
- 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.
- All pre-Exchange 2000 servers outside the site, sorted by
cost with the lower-cost connections used first.
- 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:
- 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.
- Intersite, sorted by affinity and referral cost from
servers that are known to be active (that have sent replicas).
- Intrasite, regardless of previous backfilled data.
- Intersite, sorted by affinity and referral cost,
regardless of known activity.
- 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.
- 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