Detailed Operation

FRS monitors the NTFS change journal for changes to its shares, applies a filter to exclude changes to nonreplicated files, places changes in a staging directory until they can be processed, and sends change notifications so that replication partners can pick up their changes. When the partners retrieve the staging file, it is considered replicated and deleted from the staging directory.

A list of partners is specified for each replica set. For SYSVOL, it is created automatically by the KCC (Knowledge Consistency Checker), which runs periodically on Windows 2000 domain controllers, to optimize and adjust the topology for failed computers or lost connections. When FRS is used to replicate Dfs shares, KCC is not involved. You must define replica sets by using the Dfs snap-in.

The fundamental objects in a replica set are computers and replication links. The replication links that connect computers are unidirectional. A change flows in the direction of the link between two partners. To replicate changes in both directions, a pair of links is necessary.

Before taking a detailed look at FRS operation, it is necessary to clarify the terms inbound and outbound partners in a replica set. Assume that two computers, A and B, host a replica set and that replication is enabled. As shown in Figure 18.1, if a file has changed on Computer A and needs to replicate to Computer B, then Computer B is Computer A's outbound partner and Computer A is Computer B's inbound partner. If a change occurs on Computer B that needs to be replicated to Computer A, then a second link is needed. In this case, Computer B is the inbound partner for Computer A, and Computer A is the outbound partner for Computer B.

Figure 18.1 Inbound and Outbound Relationships

Figure 18.2 shows the detailed sequence of events that occurs when a file change introduced on Computer A replicates to Computer B.

Figure   18.2 Detailed FRS Operation

1. When a file in a replica set changes and the user closes the file, NTFS makes an entry in the NTFS change journal.
   The NTFS change journal records changes to all files on the NTFS volume such as file creations, deletions, and modifications. The journal is limited in size, but it is persistent across restarts and crashes.

2. FRS monitors the NTFS change journal for changes that apply to the replicated shares. Only closed files are checked. File and folder filters are applied against changes in the folders of interest, notably domain-based Dfs and SYSVOL replica sets.

3. The aging cache, a three-second delay designed to catch additional changes to a file, expires. This prevents file replication when the file is undergoing rapid updates.

4. Computer A records the change as a change order in an inbound log. It also creates an entry in the ID table so that recovery can take place if a crash occurs.
   The inbound log contains change orders arriving from all inbound partners. The change orders are logged in the order that they arrive along with the file data. Each change order contains information about a change to a file or folder on a replica member, such as the name of the file or the time it was changed, that is used to construct a message about the change.

5. A copy of the changed file is constructed in a local staging directory.
   The staging directory is an area where modified files are stored temporarily prior to being propagated to other partners. A staging file is used by FRS to encapsulate the data and attributes associated with a replicated file (or directory) object. It ensures that the file data can be supplied to partners regardless of any file activity that might prevent access to the original file.

6. Computer A updates the outbound log.
   The outbound log contains change orders generated for a specified replica. The changes can originate locally or come from an inbound partner. These change orders are eventually sent to all outbound partners.

7. Computer A sends a change notification to Computer B.

8. If it decides to accept the change order, Computer B asks for the modified file. Computer B writes to its inbound and ID logs.

9. Computer B copies the staging file to its staging directory. It then writes to its outbound log so other outbound partners can pick up the change.
   The staging directory is an area where propagated files are stored temporarily prior to being installed locally on the partner. This is done so that users do not see a file locked for an extended period of time while FRS is moving the file over a slow or congested link. In addition, if the link fails in the middle of the transfer, users do not see a partial file.

10. The altered file is constructed in a preinstallation area and moved to its final location on Computer B.