3.1.5.1 Both Short and Long DS Polling Interval Timers

  • Article

On expiration, FRS MUST do the following:

  1. Locate the computer object for the server it is running on and enumerate the FRS Subscriber objects.

  2. For a given subscriber, follow the fRSMemberReference attribute to the FRS Member object.

  3. Read the FRS replica set object (always directly above the FRS Member object) to determine if it is a SYSVOL or a DFS replica set.

  4. Enumerate the connection objects. This process is different for SYSVOL and DFS.

    For DFS replica sets, FRS MUST:

    • Find all the NTDS connection objects that represent an inbound connection to this member. (All NTDS connection objects that represent an inbound connection are directly under the NTFRS member object.)

    • Find all the NTDS connection objects that represent an outbound connection to this member. (All NTDS connection objects that represent an outbound connection have this member name in the fromServer attribute.) See section 2.3.1.6.

    • Form a list of FRS member objects that have an inbound or outbound connection with this member. This list MUST be a combined list for all the replica sets that this server is a member of.

    • Form a list of the computers corresponding to the members in the member list. All members have an frsComputerReference attribute pointing to the computer object.

    • Find the FQDN of each of the computers in the computer list. This is the name that FRS uses to bind to its upstream and downstream partners.

      For SYSVOL replica sets, FRS MUST:

    • Find all the NTDS Connection objects that represent an inbound connection to this member. The serverReference attribute on the FRS 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.)

    • Find all NTDS connection objects that represent an outbound connection to this member. (All NTDS connection objects that represent an outbound connection have this member name in the fromServer attribute.)

    • Form 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. FRS MUST:

      1. Form the list of NTDS settings objects.

      2. Find the NTFRS member objects that point to each of these NTDS settings objects. This list MUST be a combined list for all the replica sets that this server is a member of.

    • Find the FQDN of each of the computers in the computer list. This is the name that FRS uses to bind to its upstream and downstream partners.

Once FRS detects a configuration change and realizes that it became a new member in a given replica set, FRS MUST:

  1. Add the replica tree root folder into the IDTable.

  2. Generate a new GUID to uniquely identify the local replica set member. This GUID MUST be used in version vectors to identify the local replica set member.

  3. Initialize the replica set object with the values discovered from Active Directory.

  4. Initialize all the connections of the local replica set member.

  5. Initialize inbound log and inbound log to be empty.

  6. Put the new replica in Seeding state, which triggers the initial sync process. (If the member is configured as a primary member, this process does not apply.)

  7. Start monitoring the replica tree root in the local file system to detect changes that need to be replicated out to downstream partners.

Once FRS detects a configuration change and determines that it is no longer a member in a given replica set, the following MUST be performed by FRS:

  1. All the connections having one endpoint as the machine which is going to be removed are first set to Unjoined state, and then deleted.<41>

  2. Outbound log processing is shut down.

  3. Entries corresponding to this replica in the filter tables and parent file IDTable are deleted.

  4. Journal processing for the replica is stopped.

  5. Staging space is reclaimed.

  6. All the pre-install files and pre-install directories for the replica are deleted.

Following are some of the types of changes that trigger replication:

  • File or folder was created.

  • File or folder was deleted.

  • File or folder was renamed.

  • Main file data stream was overwritten.

  • Main file data stream was extended.

  • Main file data stream was truncated.

  • Basic information was changed. Changes related to the archive flag or the last access time do not cause files to be replicated.

  • Object ID was changed.

  • Alternate data stream name was changed.

  • Alternate data stream was overwritten.

  • Alternate data stream was extended.

  • Alternate data stream was truncated.

  • Extended file attribute was changed.

  • File permission, auditing, or ownership was changed.

  • File compression attribute changed.

  • File encryption changed. This type of change triggers replication only when the file is changed from encrypted to not encrypted. <42>

  • Reparse point deleted or reparse point changes related to SIS or HSM.

When a change is detected, FRS MUST replicate the entire file or folder in the staging file. 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.

FRS uses the following process to determine if a file has changed:

  1. FRS monitors the USN journal for changes. When FRS detects a closed record for a file (a handle being closed can trigger this), FRS gathers relevant information about the recently closed file, including the file's attributes and MD5 checksum, from the file IDTable.

  2. FRS computes an MD5 checksum for the recently closed file. The MD5 checksum is calculated based on the file's data, including its security descriptors. File attributes are not included in this calculation. If the MD5 checksum and attributes of the recently closed file are identical to the information about the file stored in the file IDTable, the file is suppressed and not replicated. If either the MD5 checksum or the attributes are different, FRS begins the change order process.

If a file is changing frequently, the changes are suppressed using the aging cache. Changes to a file are held in the aging cache for a period of time (three seconds by default) before FRS examines the file to determine if replication is necessary. This allows multiple changes to be collapsed into one change order and prevents excessive updates from getting sent to downstream partners.

When doing initial sync for the replica set member, FRS performs the following steps in order to complete a VVJoin with each of its upstream partners:

  1. FRS forms a list of connections to upstream partners in order of the connection priority stored in the AD connection object (see section 2.3.1.6).

  2. For every connection in a given priority class (see the following table), FRS sends a NEED_JOIN request to the upstream partner. For more details on connection joining, see section 3.3.4.6.

  3. A downstream partner can only perform a VVJoin with a single upstream partner at a time. Once an upstream partner responds to an FRS request, the connections to all other upstream partners are paused to prevent VVJoins from proceeding on those connections. On successful completion of the VVJoin on a connection, the connection state never goes back to initial sync. If the VVJoin failed (that is, if the partner goes offline), the connection is returned back to the list and the logic goes back to connection selection, and then performs a VVJoin again on the newly selected connection. For more details on how files and folders are replicated out to partners during initial sync, see section 3.3.4.4.1.

  4. The replica set leaves the Seeding state and becomes Online only after it has successfully completed a VVJoin with each of its upstream partners.

FRS performs initial VVJoin with one partner at a time. The sequence depends on the priority class of the upstream partner. Next class in the table below means the class with a larger priority value (plus 1). The priority classes and their meanings follow.

Priority class

Behavior

0

FRS MUST go to partners in the next class even if it has not successfully completed VVJoin with partners in the current class. The class has the lowest priority.

1-2

FRS MUST NOT go to partners in the next class until it has successfully completed VVJoin with every partner in the current class. 1 > 2 in priority. These classes have the highest priority.

3-4

FRS MUST NOT go to partners in the next class until it has successfully completed VVJoin with at least one partner in the current class. 3 > 4 in priority.

5-7

FRS MUST go to partners in the next class even if it has not successfully completed VVJoin with partners in the current class. 5 > 6 > 7 in priority.

Using the priority class assigned to a connection, a sorted list of upstream partners is formed using the following priority order (highest to lowest): 1, 2, 3, 4, 5, 6, 7, 0.

FRS walks through this list and performs a VVJoin with each partner. The behavior differs based on the priority class.

Along with the priority, the FRS_IGNORE_SCHEDULE value SHOULD be used to indicate if the schedule is to be ignored or followed for the initial VVJoin.

The Options attribute on the NTDS Connection object, used to set the VVJoin priority, indicate that FRS MUST force a sync in the opposite direction at the end of a sync, and indicate whether the schedule is to be ignored. The format of the Options attribute is as specified in section 2.3.1.6.

For the SYSVOL replica set, the FRS service MUST detect the domain functional level (as specified in [MS-ADTS] section 6.1.4.3) during Active Directory Polling. FRS might not be used as the SYSVOL replication engine for some domain functional levels. <43><44>