When you set up DFS replication, you choose a shared folder whose contents you want to replicate. For the SYSVOL shared folder on domain controllers, replication is established automatically during the domain controller promotion process. The set of data to be replicated to all servers is known as the replica tree, and the servers to receive this replica tree are known as replica members. The group of replica members that participates in the replication of a given replica tree is known as a replica set. Replica members are connected in a topology, which is a framework of connections between servers and defines the replication path. There are a number of common topologies, such as full mesh, ring, and hub and spoke.

The following figure illustrates these terms.

Basic FRS Components (Ring Topology)

It is also helpful to understand the terminology used to describe the relationship between two members. This terminology is illustrated in the following figure.

Replication Partner Terminology

As illustrated in the figure, any two replica members with a direct connection between them are known as direct replication partners. In the figure, ServerA and ServerB are direct replication partners, as are ServerB and ServerC. Although changes that originate on ServerA are eventually replicated to ServerC, these two servers do not have a direct connection to each other, so they are known as transitive replication partners.

When a changed file or folder is received on a server, either because the change originated there or because the server received the file or folder from another partner, that server becomes the upstream partner, also known as inbound partner, for any direct replication partner that has not yet received the change. For example, in the figure titled “Replication Partner Terminology,” a change originates on ServerA, and ServerA is considered the upstream or inbound partner for ServerB. ServerB is considered the downstream (also known as outbound) partner for ServerA.

The following terms are used to describe the components and processes of FRS.

Active Directory object

A distinct set of named attributes that represents a network resource. FRS uses Active Directory objects to represent servers that participate in replica sets and the topology that FRS uses to replicate data.

Authoritative restore (also called D4)

The process whereby one replica member is made the authoritative member, and all the data in its replica tree is replicated to all other replica members. This procedure should be used only in extreme circumstances under the supervision of your support provider or Microsoft Product Support Services. This process is informally referred to as a “D4” in reference to the registry setting used to invoke this process.

Burflags

Short for “backup restore flags,” an FRS-related registry entry used to change the behavior of the FRS service at startup. The values for this registry entry are D2 (for nonauthoritative restores) and D4 (for authoritative restores).

Change order

A message that contains information about a file or folder that has changed on a replica member. The change order is sent to the member’s outbound partners. If the outbound partners accept the change, the partners request the associated staging file. After installing the changed file in their individual replica trees, the partners propagate the change order to their outbound partners.

Directed change order

A change order that is directed to a single outbound partner and primarily produced when the partner is doing a vvjoin, such as during initial synchronization or a nonauthoritative restore (D2).

File event time

The time at which a change to a file or folder is made. This might not be the same as the file create or last-write time. For example, restoring a file from a backup tape preserves the file create and last-write times, but the file event time is the time when the actual file restoration was performed.

File GUID

An identifying property of a file or folder in a replica tree. FRS creates and manages file globally unique identifiers (GUIDs), which, along with the replication version number and event time, are stored in the file ID table in the FRS database. Each file and folder stores its file GUID as part of its NTFS attributes; therefore, corresponding files and folders across all replica set members have the same file GUID.

File ID table

A table in the FRS database that contains an entry with version and identity information for each file and folder in the replica tree.

File version number

A property of a file and folder in a replica tree that is incremented each time the file or folder is updated. The file version number is used to resolve concurrent updates originating from more than one member of the replica set. The version number is only incremented by the member that originated the file update. Other members that propagate the update do not change the version number.

Filter

A setting that excludes subfolders (and their contents) or files from replication.

FRS debug logs

Text files in the \systemroot\Debug folder that store FRS transaction and event detail.

Inbound connection

For a given replica member, a component of the NTFRS Member object in Active Directory that identifies inbound partners. An inbound connection exists for each inbound partner.

Inbound log

A table in the FRS database that stores pending change orders to be processed. As entries are processed, acknowledgments are sent to the inbound partners.

Knowledge Consistency Checker (KCC)

A built-in process that runs on all domain controllers and generates replication topology for the Active Directory forest. The KCC creates separate replication topologies depending on whether replication is occurring within a site (intrasite) or between sites (intersite). The KCC also dynamically adjusts the topology to accommodate new domain controllers, domain controllers moved to and from sites, changing costs and schedules, and domain controllers that are temporarily unavailable.

Link target

In a DFS namespace, the mapping destination of a link, typically a shared folder on a server. FRS can be used to keep link targets (shared folders) synchronized on different servers.

Local change order

A change order that is created because of a change to a file or folder on the local server. The local server becomes the originator of the change order and constructs a staging file.

MD5 checksum

A cryptographically secure one-way hashing algorithm that is used by FRS to verify that a file on each replica member is identical.

Morphed folder

A folder that FRS creates when resolving a name conflict between two or more identically named directories that originate on different replica members. 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.

Nonauthoritative restore (also called D2)

The process whereby a given replica member is reinitialized by obtaining a replica tree from another replica member. This process is often used to resynchronize a replica member’s replica tree with one of its inbound partners, such as after a server failure. This process is informally referred to as a “D2” in reference to the registry setting used to invoke this process.

Originator GUID

A globally unique identifier (GUID) that is associated with each replica member. All change orders produced by a given replica member carry the replica member’s originator GUID, which is saved in the file ID table.

Outbound connection

For a given replica member, a component of the NTFRS Member object in Active Directory that identifies outbound partners. An outbound connection exists for each outbound partner.

Outbound log

A table in the FRS database that stores pending change orders to be sent to outbound partners. The changes can originate locally or come from an inbound partner. These change orders are eventually sent to all outbound replica partners.

Parent GUID

The globally unique identifier (GUID) of the parent folder that contains a particular file or folder in the replica tree.

Preinstall folder

A hidden subfolder under the root of the replica tree. When a newly created file or folder is replicated to a downstream partner, the file or folder is first created in the preinstall folder on the downstream partner. After the file or folder is completely replicated, it is renamed to its target location in the replica tree. This process is used so that partially constructed files are not visible in the replica tree.

Reanimation change order

A change order that FRS uses to reconcile a recently received change order against a previously deleted file or folder.

Remote change order

A change order received from an inbound (or upstream) partner that originated elsewhere in the replica set.

Retry change order

A change order that is in some state of completion but was blocked for some reason and must be retried later.

Schedule

The frequency at which data replicates.

Staging folder

A folder that acts as a queue for changed files and folders to be replicated to downstream partners.

Staging file

A file that FRS constructs in the staging folder as a result of a file or folder change. FRS constructs staging files by using backup application programming interfaces (APIs) and then replicates the staging files to downstream partners. Downstream partners use restore APIs to reconstruct the staging files in the preinstall folder before renaming the files into the replica tree. Staging files are compressed to reduce the network bandwidth used during replication.

SYSVOL

On a domain controller, a shared folder that stores a copy of the domain’s public files, including system policies and Group Policy settings, that are replicated to all other domain controllers in the domain by FRS.

Update sequence number (USN)

A monotonically increasing sequence number for each volume. The USN is incremented every time a modification is made to a file on the volume.

USN journal

On NTFS volumes, a persistent log that tracks all changes on the volume, including file creations, deletions, and changes. The USN journal has a configurable maximum size and is persistent across reboots and system crashes. FRS uses the USN journal to monitor changes made in the replica tree.

USN journal wrap

An error that occurs when large numbers of files change so quickly that the USN journal must discard the oldest changes (before FRS has a chance to detect the changes) to stay within the specified size limit. To recover from a journal wrap, you must perform a nonauthoritative restore on the server to synchronize its files with the files on the other replica members.

Version vector

A vector of volume sequence numbers (VSNs), with one entry per replica set member. All change orders carry the originator GUID of the originating member and the associated VSN. As each replica member receives the update, it tracks the VSN in a vector slot that is assigned to the originating member. This vector describes whether the replica tree is current with each member. The version vector is then used to filter updates from inbound partners that might have already been applied. The version vector is also delivered to the inbound partner when the two members join. When a new connection is created, the version vector is used to scan the file ID table for more recent updates that are not seen by the new outbound partner.

Version vector join (vvjoin)

The process in which a downstream partner joins with an upstream partner for the first time.

Replica tree on DFS replica members

SYSVOL folder domain controllers

Staging folder

Preinstall folder

FRS Jet database

FRS debug logs

Pre-existing data folder

Connection record table

Version vector table

File ID table

Inbound change order table (inbound log)

Outbound change order table (outbound log)

Local change order

Remote change order

Retry change order

Directed change order

Reanimation change order

The following figure illustrates the hierarchy of FRS-related Active Directory containers and objects for DFS replica sets. The figure also illustrates how several of these objects are linked together using reference attributes. For example, in the NTFRS Member object, there is an attribute called frsComputerReference that refers to the computer object for the server.

FRS Containers and Objects in Active Directory for DFS Replica Sets

The following sections briefly describe the Active Directory objects, containers, and their attributes for DFS replica sets. The class name of each object is shown in parentheses.

NTFRS Settings object

NTFRS Replica Set object

NTFRS Member object

NTDS Connection object

Computer object

NTFRS Subscriptions container

NTFRS Subscriber object

NTFRS Settings object

NTFRS Replica Set object

NTFRS Member object

NTDS Connection object

Computer object

NTFRS Subscriptions container

NTFRS Subscriber object

How changes to topology, schedule, filters, and settings are detected

How new and existing partners communicate

How replica sets are created and how members are added and removed

How changed files and folders are tracked and replicated

The Active Directory polling process is as follows. Note that if any of these steps fails, replication does not occur. Failure is typically caused by network connectivity issues or missing, damaged, or duplicate Active Directory objects.

1. FRS locates the computer object for the server it is running on and enumerates the NTFRS Subscriber objects.
   
   
2. For a given subscriber, FRS follows the fRSMemberReference attribute to the NTFRS Member object
   
   
3. Next, FRS reads the NTFRS Replica Set object (always directly above the NTFRS Member object) to determine whether it is SYSVOL or DFS replica set.
   
   

After FRS determines the replica type (SYSVOL or DFS), FRS enumerates the connection objects. This process is different for SYSVOL and DFS.

1. FRS finds all the NTDS Connection objects that represent an inbound (or upstream) connection to this member. (All NTDS Connection objects that represent an inbound connection are directly under the NTFRS Member object.)
   
   
2. FRS finds all the NTDS Connection objects that represent an outbound (or downstream) connection to this member. (All NTDS Connection objects that represent an outbound connection have this member’s name in the fromServer attribute.)
   
   
3. FRS forms a list of NTFRS Member objects that have an inbound or outbound connection with this member. This list is a combined list for all the replica sets that this server is a member of.
   
   
4. FRS forms a list of the computers corresponding to the members in the member list. All members have an frsComputerReference attribute pointing to the computer object.
   
   
5. FRS finds the DNS name of each of the computers in the computer list. This is the name that FRS uses to bind to its inbound and outbound partners.
   
   

1. FRS finds all the NTDS Connection objects that represent an inbound connection to this member. The serverReference attribute on the NTFRS Member object points to the NTDS Settings object. (All the NTDS Connection objects that represent an inbound connection are directly under the NTDS Settings object.)
   
   
2. FRS finds all NTDS Connection objects that represent an outbound connection to this member. (All NTDS Connection objects that represent an outbound connection have this member’s name in the fromServer attribute.)
   
   
3. FRS forms a list of member objects that have an inbound connection or outbound connection with this member. Forming the list of members is a two-step process for SYSVOL replica sets. First, FRS forms the list of NTDS Settings objects, and then FRS finds the NTFRS Member objects that point to each of these NTDS Settings objects. This list is a combined list for all the replica sets that this server is a member of.
   
   
4. FRS forms a list of the computers corresponding to the members in the member list. All members have an frsComputerReference attribute pointing to the computer object.
   
   
5. FRS finds the DNS name of each of the computers in the computer list. This is the name that FRS uses to bind to its inbound and outbound partners.
   
   

FRS polls Active Directory and the registry at the same interval. Some settings stored in Active Directory are also stored in the registry, but the Active Directory settings override the registry settings. Though some registry changes are detected and applied during polling, other changes are not applied until the FRS service is stopped and restarted. For more information about registry entries that require the service to be restarted, see Registry Reference in Tools and Settings Collection.

Each time a replica member is started or the FRS service is started, FRS polls the registry and the computer object in Active Directory in eight short intervals. If no changes in Active Directory are detected, FRS polls in long intervals until it detects configuration or subscriber list changes in Active Directory. The lengths of the short and long intervals are as follows:

• For domain controllers, the default short and long polling intervals are five minutes each. (Domain controllers always use the short interval, regardless of the long interval setting.)
  
  
• For member servers, the default short polling interval is five minutes and the long polling interval is 60 minutes.
  
  

Note

• These polling intervals are specified in the DS Polling Long Interval in Minutes and DS Polling Short Interval in Minutes registry values. To view the current interval and the length of the long and short polling interval, use the Ntfrsutl.execommand with the poll parameter.
  
  

If there have been no FRS configuration changes in Active Directory after the completion of eight short polling intervals, FRS automatically begins polling according to the long polling interval. If one of the following events occurs, the polling cycle is reset:

• A replica member is added or removed.
  
  
• A connection is added or removed.
  
  
• A schedule is changed.
  
  
• A file or folder filter is changed.
  
  

Unlike changes in Active Directory, registry changes do not affect the polling cycle.

In scenarios A, B, C, and D, FRS attempts to perform an optimized vvjoin instead of a full vvjoin. An optimized vvjoin occurs when the upstream partner’s outbound log contains all the changes that the downstream partner is missing.

Optimized vvjoins are desirable in scenarios where a downstream partner (ServerB in the previous figure) needs to vvjoin and has almost all files in the replica tree already. For example, assume the connection between ServerA and ServerB is new, but ServerB was offline for two days and only missed changes from a prior upstream partner, say ServerC, for those two days. In this case, the new upstream partner (ServerA) retains the change orders in the outbound log for seven days and sends its outbound log to the downstream partner (ServerB) instead of enumerating its entire database. ServerA also sends its existing staging files, so ServerA needs to regenerate staging files only for staging files that were purged if the staging folder reached 90 percent of its limit or that were purged during the staging folder cleanup process. The staging folder cleanup process is described in “How the Outbound Log Cleanup Process Works” later in this section.

If the upstream partner’s outbound log does not contain all the changes that the downstream partner is missing, a full vvjoin occurs. A full vvjoin requires the upstream partner to enumerate its entire database before determining whether to send changed files and folders to the downstream partner. As a result, the full vvjoin process is not as efficient as an optimized vvjoin, but a full vvjoin does not necessarily mean that the upstream partner sends the entire replica across the network to the downstream partner. The following sections describe the scenarios in which full vvjoins are performed and whether all or part of the data is replicated.

When a new replica member is prestaged and added to the replica set

When a new replica member is not prestaged and the replica set is more than seven days old

An existing replica member was offline for more than seven days

For initial master:

For the remaining replica members:

The following procedure describes how FRS responds when you prestage a DFS replica set.

1. Replication is enabled between two members, Server1 and Server2. The initial master, Server1, does not have any data in its replica tree when replication is enabled.
   
   
2. After you copy files into the replica tree (using \\Server1\Apps as an example replica root), FRS generates staging files and sends change orders to the downstream partner (Server2). FRS also generates an MD5 (a hash algorithm) checksum during the staging file generation and saves the result in the file ID table on Server1 and in the change order sent to Server2.
   
   
3. When Server2 processes this change order, it saves the MD5 checksum in the file ID table on Server2. This process is the only way an MD5 checksum is saved in the file ID table and the presence of the MD5 is necessary to avoid overhead when new members are added later.
   
   When step 3 is finished, the replicated files exist on both Server1 and Server2, and both file ID tables have MD5 checksums for each file and folder in the replica tree. (You can verify this by using the Ntfrsutil.exe command with the idtable parameter. Search for “MD5CheckSum” in the output.)
   
   
4. Windows Backup or another backup program is used to back up the contents of the replica tree from either Server1 or Server2. The backup is then restored to another server, for example, Server3.
   
   
5. If fewer than seven days have passed since the replica set containing Server1 and Server2 was created, the outbound log must be cleared so that a full vvjoin is triggered when the next member joins. (Setting the Outlog Change History In Minutes registry entry to 0 clears the outbound log.)
   
   
6. When Server3 is added to the replica set using the Distributed File System snap-in, FRS on Server3 moves all files from the restored target folder (\\Server3\Apps) to the pre-existing data folder, and then initiates a full vvjoin from each computer that Server3 has inbound NTDS Connection objects. Note that the vvjoin process is serialized, meaning that the downstream partner performs a vvjoin with one upstream member at a time. Subsequent vvjoins are much faster because the downstream partner will typically have a complete (or nearly complete) replica tree after the first vvjoin completes.
   
   The key requirement in this step is that Server3 has inbound connections from an upstream partner, Server1 or Server2 in this case, whose file ID table contains MD5 checksums for files contained in the replica set of interest.
   
   
7. FRS on Server1 enumerates all the files and folders in its file ID table and sends directed (that is, single target) change orders to Server3. Because the file ID table has an MD5 checksum, it is included in the change order. As Server3 processes these change orders, this server takes the file GUID for the file or folder from the change order and attempts to locate the corresponding file in the pre-existing data folder. If the server locates the file, it re-computes the MD5 checksum on the content of that file, compares the result to the MD5 checksum it received in the change order and, if they match, uses the pre-existing file instead of attempting to obtain the file from Server1. If Server3 does not find the file, or if the MD5 checksum or attributes do not match, the server obtains the file from Server1. Any change to the file content, such as to the access control lists or data streams, can cause an MD5 mismatch and the file is obtained from Server1 or other upstream partner.
   
   When all replication activity has settled out, the file ID tables on all three servers have an identical MD5 checksum and identical file content in the replicated folder.
   
   

The process for prestaging SYSVOL is part of the overall process of using backup media to create additional domain controllers. FRS follows the same method of determining whether the restored files are identical to those on the upstream partner as it does for DFS replica members. Specifically, the following requirements must be met for SYSVOL prestaging to be successful:

• FRS must have constructed MD5 checksum data for the files in the SYSVOL tree. MD5 checksum data is constructed after one of the following events occurs:
  
  
  • Every file in SYSVOL is modified after there are two or more domain controllers in the domain.
    
    
  • All data is moved to a non-replicated folder outside of SYSVOL and then moved back into SYSVOL after there are two or more domain controllers in the domain.
    
    
• The system state backup must contain all files in SYSVOL. If any files in the system state backup are out of date, those files are replicated across the network to the new member.
  
  
• The outbound log on the upstream partner must be cleared if SYSVOL is less than seven days old. As described in “How the Vvjoin Process Works” earlier in this section, if the replica set is less than seven days old, FRS attempts an optimized vvjoin, which does not look for prestaged content and will cause the entire replica tree to be replicated across the network to the new member. To work around this, you can clear the outbound log on all upstream partners, or you can clear the outbound log on one upstream partner and then do one of the following steps to make sure that the new member vvjoins with this partner:
  
  
  • Create a single inbound connection to the member with the cleared outbound log.
    
    
  • Set up connection schedules such that the parent with the cleared outbound log is the only schedule that is open.
    
    
  • Stop the FRS service on all other upstream partners.
    
    

Note

• When prestaging SYSVOL, do not clear the outbound log on bridgehead servers. Bridgehead servers typically have many outbound connections, and clearing the outbound log can cause full vvjoins to occur for every connection that has pending outbound change orders. If this occurs, the bridgehead server can experience a significant decrease in FRS performance and significantly increased CPU, memory, and bandwidth usage. To avoid this situation, we recommend that you prestage from an upstream replica member that has few outbound connections.
  
  

Dcpromo (via Ntfrsapi.dll) performs the following steps during a domain controller demotion:

1. Dcpromo prepares for demotion by:
   
   
   1. Stopping FRS.
      
      
   2. Cleaning out old demotion state in the registry (if any).
      
      
   3. Restarting FRS.
      
      
   4. Binding to Active Directory using a different domain controller in the domain. The binding occurs because the demotion will invalidate the local domain controller and thus Active Directory replication would not take place after the system restarts. (If this is the last domain controller in the domain then this step is not performed.)
      
      
2. Dcpromo starts the demotion by:
   
   
   1. Setting the SYSVOL Replica Set Command registry entry to Delete.
      
      
   2. Instructing FRS to tombstone the SYSVOL replica set.
      
      
3. Dcpromo commits the demotion by:
   
   
   1. Stopping the FRS service and setting the service to manual.
      
      
   2. Setting the Sysvol Ready registry entry to 0.
      
      
   3. Deleting the NTFRS Subscription object and NTFRS Replica Set object for SYSVOL.
      
      

The following process occurs when you use the Distributed File System snap-in to remove a replica member from a replica set.

1. If the topology is hub and spoke and the hub member is removed, the topology type is changed to custom.
   
   
2. The NTFRS Subscriber object and its container are deleted.
   
   
3. The connections are adjusted based on current topology preference. For example, if the topology is a ring topology, a ring topology is reformed using the remaining members.
   
   
4. The connections from the removed member to other members are deleted.
   
   
5. The NTFRS Member object is deleted.
   
   

Step 1: NTFS creates a change journal entry

Step 2: FRS monitors the USN journal

Step 3: Aging cache is used

Step 4: FRS creates entries in the inbound log and file ID table

Step 5: FRS creates the staging file in the staging folder

Step 6: FRS creates the entry in the outbound log

Step 7: FRS sends a change notification

Step 8: FRS records and acknowledges the change notification

Step 9: FRS replicates the staging file

Step 10: FRS constructs the staging file and moves it into the replica tree

Staging folder size

Staging folder compression

How the staging folder stays below its maximum size limit

Staging folder cleanup

The SYSVOL schedule is an attribute associated with each NTFRS Replica Set object and with each NTDS Connection object. FRS replicates SYSVOL using the same intrasite connection objects and schedule built by the KCC for Active Directory replication. FRS uses two replication protocols for SYSVOL:

• SYSVOL connection within a site. The connection is always considered to be on; any schedule is ignored and changed files are replicated immediately.
  
  
• SYSVOL connection between sites. SYSVOL replication is initiated between two intersite members at the start of the 15-minute interval, assuming the schedule is open. The connection is treated as a trigger schedule. The upstream partner ignores its schedule and responds to any request by the downstream partner. When the schedule closes, the upstream partner unjoins the connection only after the current contents of the outbound log, at the time of join, have been sent and acknowledged.
  
  

The SYSVOL replication schedule can be configured so that replication takes place four, two, one, or zero times per hour.

• When set to four times per hour, replication starts at 0:00, 0:15, 0:30, and 0:45. This schedule is essentially continuous replication.
  
  
• When set to two times per hour, replication occurs at 15-minute intervals starting at 0:15 and 0:45.
  
  
• When set to one time per hour, replication starts at 0:00 and ends at 0:15 assuming that all changes have been replicated.
  
  

It is possible to change the SYSVOL schedule, but this should be done only after careful consideration of the implications and alternatives. Also, note that schedules exist on both site links and NTDS Connection objects. If you change the schedule on an NTDS Connection objects, the connection then becomes a manual connection that cannot be managed by KCC.

For DFS replica sets, FRS uses the NTDS Connection objects, topology, and schedule built by the Distributed File System snap-in. The snap-in sets the schedule as follows:

• When you view the properties of a link and set the schedule in the Linkname Properties dialog box, the snap-in applies the schedule to all NTDS Connection objects for this replica set. The snap-in does not apply the schedule to the NTFRS Replica Set object.
  
  
• If you view individual connections in the Customize Topology dialog box and modify the schedule on a connection, the snap-in applies that schedule to the NTDS Connection object for the connection.
  
  
• If you add a new member to an existing replica set, the new member’s NTDS Connection objects get the default “always on” schedule.
  
  
• If you use the snap-in to set schedules on individual connections, and then you view the schedule from the Linkname Properties dialog box, the snap-in displays the schedule for the last enumerated NTDS Connection object. If you click OK in this dialog box, the schedule shown is applied to all NTDS Connection objects. To avoid this, click Cancel to close the dialog box.
  
  

When replication is set to available, replication occurs continuously. Unlike SYSVOL schedules, DFS replica set schedules are on/off schedules. As long as the schedule is open, the connection stays in the joined state and change orders are sent out as they are processed by the upstream partner. Any queued change orders in the upstream partner’s outbound log are sent first. When the schedule closes, FRS unjoins the connection.

Replication schedules are stored in Coordinated Universal Time (UTC). However, when you view the schedule, the schedule is shown in the local time of the server. Daylight savings time causes the schedule to shift by an hour for any server that is located in an affected time zone.