File Replication Service

How FRS Works

FRS provides redundancy for the content of designated NTFS shares between Windows 2000 servers. The servers can be interconnected in any topology such as a ring or a star configuration. With an appropriate topology and sufficient network support, hundreds of computers can replicate the same set of files or folders. Conversely, one computer can be a member of multiple replica sets.

FRS also provides redundancy for SYSVOL and Dfs distribution by way of multiple distribution paths between the replicas in a replica set. If one replica is down, data flows using a different route. Dampening logic prevents a data file from being sent more than once to any particular replica.

Multimaster replication allows any domain controller or member server to propagate changes to replicated files and folders on any other domain controller or member server. There are no primary/secondary or master/slave relationships. When a replicated file is changed and closed, FRS submits that change to other members in the replica set. Those members decide whether to accept or reject the change according to certain criteria.

For example, suppose a replica set is composed of Computer A and Computer B. If File X on Computer A is updated and then closed, FRS notifies Computer B of the change.

If the event time associated with Computer A is more than 30 minutes later than the event time for Computer B, the change is accepted immediately and Computer B is updated. If the event time associated with File X on Computer A is more than 30 minutes earlier than the event time for File X on Computer B, the change is rejected.
An event time is associated with any change to a file. It denotes when the file was closed after being changed or was last replicated. The default event time window is 30 minutes.
If the event time of the change in the file on Computer A is within 30 minutes of the event time for the version of the file on Computer B, FRS checks the version numbers of the file. If the version number of the file on Computer A is greater than that of the file on Computer B, the change is accepted and the file is updated. If the version number of the file on Computer A is less than that of the file on Computer B, the change is rejected.
The version number is a numerical value FRS uses to track changes occurring to a replicated file. It is assigned by a counting mechanism similar to the update sequence number (USN) used by Active Directory. When a changed file is closed, its version number increments by one.
If the version numbers for the files are equal, the event time is checked again, this time without the 30-minute window. In other words, if the event time associated with the file on Computer A is later than the event time for the file on Computer B, the change is accepted and Computer B is updated. If the event time associated with the file on Computer A is earlier than the event time for the file on Computer B, the change is rejected.

FRS uses a "last writer wins" algorithm, which means that the last update to a file or folder in a replica set becomes authoritative for replication, regardless of the document version number or file size. It does not merge changes; rather, the most recent version of a particular file overwrites all older versions. This makes FRS well suited to replicate files that are updated infrequently, such as product specifications, software distribution points, and Web content.

Files that contain information that is updated more frequently must accommodate two scenarios: concurrent users and replication latency.

User A and User B open the same 100-page document on different replicas. User A adds 100 pages and saves the document first; user B deletes 80 pages and then saves the document. The 20-page document that was saved last becomes the authoritative file.
FRS cannot deny file sharing or enforce file locking between two users who are writing to the same file on two different replicas.
A user makes a change on a replicated Dfs share. Assume that the replication schedule for Dfs connection objects in Active Directory specifies that replication take place only at night. This means that updates originating on replicas in one site during the day are not available on replicas in other sites until the replication window opens in the evening.

FRS uses Active Directory to manage configuration information so you can administer computers containing replicated data offline. This means you can add or remove replicas, change connections between replicas, or modify replication schedules without needing to communicate with the affected computer.

Note

The Dfs administrative console does not support full remote administration; that is, the affected computer must be online.

To provide secure communications, authenticated remote procedure call (RPC) with Kerberos encryption is used over TCP/IP as the protocol between members for replication. NTFS file permissions are also replicated. Files that are locked by their owners are not replicated until they are unlocked.

FRS works only with Windows 2000 because it relies on the NTFS change journal to provide a persistent (that is, logged) record of files that have changed on a member computer. Files are replicated only after they have been modified and closed. As a result, FRS does not lose track of a changed file even if the system shuts down abruptly.