Share via

What Is FRS?

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

In this section

  • Common FRS Scenarios

  • Technologies Related to FRS

  • FRS Dependencies

  • Related Information

File Replication service (FRS) is a technology that replicates files and folders stored in the SYSVOL shared folder on domain controllers and Distributed File System (DFS) shared folders. When FRS detects that a change has been made to a file or folder within a replicated shared folder, FRS replicates the updated file or folder to other servers. Because FRS is a multimaster replication service, any server that participates in replication can generate changes. In addition, FRS can resolve file and folder conflicts to make data consistent among servers.

By keeping files and folders synchronized across servers, FRS enables organizations to increase the availability of data. If one server becomes unavailable, the files are still available, because they exist on another server. Using multiple servers to host data also helps organizations that have offices in multiple geographic locations, because clients can access servers in or closest to their current site and do not need to use expensive WAN links to access data.

There are numerous methods for keeping files synchronized on servers. Although SYSVOL requires FRS, DFS shared folders can be kept synchronized by using methods other than FRS, such as manual copying, Robocopy, or other replication tools. FRS provides numerous benefits that other replication methods do not. These benefits include the following:

Authenticated RPC with encryption

To provide secure communications, FRS uses Kerberos authentication protocol for authenticated remote procedure call (RPC) to encrypt the data sent between members of a replica set.

Compression

To save network bandwidth, FRS compresses files in the staging folder by using NTFS compression. Files sent between servers participating in replication, known as replica members, remain compressed when transmitted over the network.

Conflict resolution

FRS resolves file and folder name conflicts to make data consistent among the replica members. If identically named files are created or modified on two or more replica members, FRS uses a “last writer wins” rule; this means that the most recently created or modified version of a file becomes the version that is replicated to the other replica members. If identically named folders are created on two or more replica members, FRS identifies the conflict during replication and renames the folder that was most recently created. Both folders are replicated to all servers in the replica set, and administrators can merge the contents of two folders or take some other measure to reestablish the single folder.

Continuous replication

FRS provides continuous replication, subject to replication schedule, server load, and network load. When a file or folder is changed and closed, FRS begins replicating the changed file or folder to other replica members within three seconds.

Fault-tolerant replication path

FRS does not rely on broadcast technology, and it can provide fault-tolerant distribution by way of multiple connection paths between members. If a replica member is unavailable, the data will take a different route. FRS prevents an identical file from being sent more than once to any replica member.

Replication scheduling

You can schedule replication to occur at specified times and durations as needed by your organization. For example, scheduling replication to occur during evening hours can reduce the cost of transmitting data over expensive WAN links. Replicating data during off-hours also frees up network bandwidth for other uses.

Replication integrity

Files are replicated only after they have been changed and closed. FRS relies on the update sequence number (USN) journal to log records of files that have changed on a replica member. As a result, FRS does not lose track of a changed file even if a replica member shuts down abruptly. After the replica member comes back online, FRS replicates new or updated files that originated from other replica members, as well as replicating locally created or updated files that occurred before the shutdown. This replication takes place according to the replication schedule.

Common FRS Scenarios

FRS is commonly used in the following scenarios:

SYSVOL Replication

Every domain controller has a shared folder in its local file system that is the file system component of Active Directory. This shared folder, named SYSVOL, contains files and folders that must be available and synchronized between domain controllers in a domain, including:

  • The NETLOGON shared folder, which includes system policies and user-based logon and logoff scripts for non-Windows Server 2003 and non-Windows 2000 network clients, such as clients running Windows 95, Windows 98, and Windows NT 4.0.

  • Windows Server 2003 and Windows 2000 system policies.

  • Group Policy settings (templates), including Group Policy settings for domain controllers running Windows Server 2003 or Windows 2000.

When you add, remove, or modify the contents in the SYSVOL shared folder, FRS replicates the changed contents to the SYSVOL shared folders on all other domain controllers in the domain. The following figure illustrates how SYSVOL shared folders are kept in sync on domain controllers in the corp.contoso.com domain.

SYSVOL Replication

SYSVOL Replication

Publishing Applications

FRS and DFS can be combined to distribute and publish applications. DFS allows administrators to group shared folders located on different servers by transparently connecting them to one or more hierarchical namespaces that behave like a single high-capacity hard disk. Users can navigate the namespace without having to know the physical server names or shared folders hosting the data. Administrators can also host data on multiple servers in multiple sites; users see a single copy of the data and DFS can refer users to the closest server to access the data.

When using DFS and FRS to publish applications, an administrator defines the topology used to distribute the data. The topology defines the path along which files are replicated; common topologies for distributing applications are hub-and-spoke, a multilevel tree, and redundant hub-and-spoke. New applications are typically deployed or updated on a single computer (usually the hub or root of the topology or another centrally located computer), and FRS then replicates the files to the spoke computers. The following figure illustrates a hub-and-spoke topology where applications are deployed on the hub and then replicated to the spokes.

Publishing Applications Using a Hub-and-Spoke FRS Topology

Publish Applications Using Hub-and-Spoke Topology

Publishing Data

DFS and FRS can also be used to publish data across an organization. Common examples of data include documents, diagrams, and operational procedures. This scenario often uses similar topologies (hub-and-spoke, a multilevel tree, or a redundant hub-and-spoke) as those used for publishing applications.

Another method of publishing data is known as reverse publication. In reverse publication, data flows from a number of different servers to a central server. Reverse publication is often used to gather log files and reports from individual computers and collect them in one central location. Reverse publication is also used in backup scenarios where data is collected from multiple servers and then backed up from the central server.

The following figure illustrates the reverse publication method.

Reverse Publication

Reverse Publication

Ensuring That Personal Folders Are Available

Organizations that store users’ personal folders on file servers can increase the availability of those folders by using DFS and FRS to store the folders on multiple servers. The following figure illustrates a DFS namespace, \\Corp.Contoso.Com\Users, hosted by two servers, ServerA and ServerB. DFS equally distributes the client load between the two servers, and FRS keeps the data synchronized on the two servers. If one of the servers fails, DFS refers clients to the remaining server. Even when one of the servers is unavailable, users can continue to access the \\Corp.Contoso.com\Users namespace.

How DFS and FRS Keep Data Available

How DFS and FRS Keep Data Available

FRS is closely related to the following two technologies.

Active Directory replication

Active Directory replication is the process by which the changes that are made to Active Directory objects on one domain controller are automatically synchronized with other domain controllers. This replication method does not use FRS and does not include SYSVOL replication. However, FRS replicates SYSVOL by using the connection object topology and schedule that the Knowledge Consistency Checker (KCC) creates for Active Directory replication. In addition, FRS has its own Active Directory objects that are replicated using Active Directory replication.

DFS

FRS can be used to keep data in DFS shared folders synchronized among replica members. However, DFS and FRS are two separate technologies, and DFS does not require FRS. You can use other replication methods, such as manual copying, the Windows Resource Kit tool Robocopy, or other replication tools to keep DFS shared folders synchronized. Conversely, if you want to use FRS to keep data in shared folders synchronized, you must use DFS.

FRS Dependencies

FRS has the following dependencies:

  • Active Directory replication. FRS requires that Active Directory replication is working properly so that FRS Active Directory objects reside on all domain controllers in the domain.

  • DFS. If you want to use FRS to keep data in folders synchronized on multiple servers, you must first set up a DFS namespace. (This dependency is not applicable to SYSVOL.)

  • DNS. FRS requires that DNS is properly designed and deployed so that FRS can correctly resolve DNS names of replica members. (DNS is also required for Active Directory replication.)

  • Kerberos authentication. FRS requires that Kerberos authentication is properly designed and deployed.

  • NTFS. To detect changes to files and folders, FRS relies on the USN journal on NTFS volumes. FRS is not supported on FAT file system volumes.

  • Remote procedure call (RPC). FRS requires Internet Protocol (IP) connectivity and the Remote Procedure Call (RPC) for communication between replication partners and communication with domain controllers.

The following resources contain additional information that is relevant to this section: