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.


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

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:

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.


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.


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).

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.