Common Scenarios for FRS

FRS is widely used by Windows 2000 and Windows Server 2003 for a variety of scenarios, from SYSVOL replication to application and document distribution.

SYSVOL

In a Windows 2000 or Windows Server 2003 Active Directory domain, there are two important folders shared out by each domain controller:

• \\<domain_name>\SYSVOL, used by Windows XP and Windows 2000 clients to obtain Group Policy.
• \\<domain_name>\NETLOGON, used by the Windows logon process and by clients accessing legacy logon scripts and policy

Distributed File System (DFS) is automatically used to create this \\domain_name\... network name. These file shares actually map via DFS to shared folders hosted by each of the domain controllers in the domain domain_name. For example, the DFS link resolves to the file shares \\domain_controller_X\SYSVOL and \\domain_controller_X\NETLOGON.

Active Directory requires the contents of these individual file shares to be consistent throughout the domain, and FRS is used to achieve this goal.

In large domains, the SYSVOL replica set can span hundreds or even thousands of computers. SYSVOL is used for a key part of Active Directory infrastructure, including default domain policy and other parts of group policy. For this reason, there are specific recommendations for the type of data that should and should not be stored in SYSVOL:

• Policy files and login scripts should be kept in SYSVOL.
• Login scripts should be designed so that clients do not hold them open for indefinite periods of time. For example, do not use login scripts that can be delayed while waiting for a user to press a key to continue.
• Application or hotfix install points should not be kept in SYSVOL. We recommend that you set up a separate DFS namespace for these.

For SYSVOL, FRS uses the same connection topology that is manually or automatically created for Active Directory replication. Because the connection objects are the same, the schedule and topology for intrasite and intersite replication are the same for FRS and Active Directory. Like Active Directory replication, FRS compresses all replicated content between sites, uses a trigger replication scheme, and implicitly uses an always-on schedule between members in the same site. However, unlike Active Directory replication, FRS also compresses replicated content within a site.

Replicating DFS Link Targets

Unlike SYSVOL replication, which is enabled by default, you must explicitly enable replication in a DFS namespace by using the Distributed File System snap-in. Only targets of roots and links in a domain-based DFS can use FRS; stand-alone DFS does not support automatic file replication using FRS.

You can enable replication of files and folders between computers by using the Configure Replication Wizard in the Distributed File System snap-in. The replication policy can be different for each root and link in the DFS namespace. You must have at least two targets configured before you can enable replication.

Important

• We recommend that you enable FRS replication only on DFS links. Avoid enabling replication on DFS roots.

Publishing Applications

FRS and DFS are two separate services that can be combined to build a way of distributing and publishing applications. DFS provides the means to construct a global namespace spanning multiple servers and file shares. It provides the capability to have any portion of the namespace (DFS links) hosted by multiple servers (DFS link targets) in one or more sites. In this way it provides availability, load balancing, and reduced latency and bandwidth usage by referring the client to a server in a local or nearby site.

In the DFS/FRS publication scenario, a distribution topology is defined (typically hub-and-spoke, a multilevel tree, or a redundant hub-and-spoke) and by convention, new applications are deployed or updated on a single computer (usually the hub or root of the topology or another centrally located computer), and FRS then propagates the changes to the spoke computers.

These configurations have proven very effective in the field, as long as the rules described in the Designing an FRS Deployment are adhered to.

Note

• Some organizations have adopted a policy whereby they run applications from a network file share instead of installing them onto local systems. For this scenario, and where Windows XP clients are in use, administrators can take advantage of Offline Folders in order to cache application files on the local hard disks on client computers and thus reduce server load and increase application availability.

Publishing Data

An almost identical scenario is publication of data across an enterprise. Common examples include documents, diagrams, operational procedures, and historical/test result data. This scenario follows the same advice given for publication of data.

Another method of publishing data is known as reverse publication, where the data flows from a number of dispersed computers to a centralized data collection server. One typical scenario is when collections of log files and reports generated on individual computers are collected to a central site. Another similar scenario when data is collected to a central server for backup purposes.

Typically this is configured using a replica set for each (hub, remote site) pair, because the intent is that the data flows to the central data collection server, and not to each of the servers generating the data. This is sometimes described as a petal topology, because the diagram for such a configuration shows a central hub and each replica set looks like the petal of a flower replicating between the hub and a single computer.

Ensuring the Availability of User Data

An alternate set of scenarios revolve around supporting a large number of independent users who want to read and write data in their own personal folders on a file server. To provide availability against disk or system failure, it is possible to use FRS as a way to replicate data for the purpose of data availability and use DFS to provide failover

However, these scenarios need more careful consideration since they are not a core scenario for DFS/FRS; instead, it is a core scenario for Microsoft Cluster Services (MSCS).

• FRS uses a "last writer wins" algorithm for files. This algorithm is applied in two situations: when the same file is changed on two or more servers, and when two or more different files with the same name are added to the replica tree on different servers. The most recent update to a file in a replica set becomes the version of the file that replicates to the other members of the replica set, which might result in data loss if multiple masters have updated the file. In addition, FRS cannot enforce file-sharing restrictions or file locking between two users who are working on the same file on two different replica set members. (Note that deletes are a "last write" event and can ripple through all members of the set, taking a single, directory or the entire tree with it.)
• FRS uses a "last writer wins" algorithm when a folder on two or more servers is changed, such as by changing folder attributes. However, FRS uses a "first writer wins" algorithm when two or more identically named folders on different servers are added to the replica tree. When this occurs, FRS identifies the conflict during replication, and the receiving member protects the original copy of the folder and renames (morphs) the later inbound copy of the folder. The morphed folder names have a suffix of "_NTFRS_xxxxxxxx," where "xxxxxxxx" represents eight random hexadecimal digits. The folders are replicated to all servers in the replica set, and administrators can later merge the contents of the folders or take some other measure to reestablish the single folder.

Temporary data inconsistency due to replication latency is more likely to occur in geographically diverse sites with infrequent replication across slow WAN links. If you want to use replication among servers in the same site, consistency is probably not an issue, because the replication can occur quickly after the file changes — assuming that only one user makes changes to the data. If two users make changes to the data, replication conflicts occur and one user loses those changes.