Share via

7 Appendix B: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

  • Windows Server 2003 R2 operating system

  • Windows Vista operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 operating system 

  • Windows Server 2025 operating system

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 2.1: The default behavior of a Windows-based server is to use dynamic endpoints. Static ports can be specified on a connection using the attribute DNSHostName, as specified in section 2.3.10.

<2> Section 2.1.2:  The default behavior of a Windows-based server is to use dynamic endpoints. Static ports can be specified on a connection using the attribute DNSHostName specified in section 2.3.10.

<3> Section 2.2.1.1.1: Windows Server 2003 R2 identifies its DFS-R protocol version as 0x00050000. Windows Server 2008 and Windows Server 2008 R2 both identify their DFS-R protocol version as 0x00050002. Windows Server 2012 identifies its DFS-R protocol version as 0x00050003. Windows Server 2012 R2 operating system and later identify their DFS-R protocol version as 0x00050004.

<4> Section 2.2.1.4.1: Windows Server 2003 R2 servers do not perform this check.

<5> Section 2.2.1.4.11: The parameter onDiskFileSize is computed from the size of a cached version of the marshaled, compressed file.

<6> Section 2.2.1.4.11: The parameter fileSizeEstimate is computed based on the allocated byte ranges for the main data stream of a file.

<7> Section 2.2.1.4.11: The way that Windows computes rdcSignatureLevels is specified in [MS-RDC].

<8> Section 2.3.1: If not present or not equal to "1.0.0.0", Windows replaces it with "1.0.0.0".

<9> Section 2.3.3: In version 0x00050002, 0x00050003, and 0x00050004 of the Distributed File System: Replication (DFS-R) Protocol, it contains a comma-separated list of 0 or more strings that specify which files are not compressed. Each string can be a file name or can be a file name with the initial portion replaced by the wild card character "*". There is no escape character; therefore, it is not possible to specify a file name with a comma.

<10> Section 2.3.3: Windows Server 2008 R2 operating system and later are the only versions of DFS-R that support read-only replicated folders.

<11> Section 2.3.3: This flag is set to 1 on Windows Server 2008 read-only domain controllers that are using DFSR for SYSVOL replication. In addition, on Windows Server 2008 R2 operating system and later this flag is set to 1 to configure a replicated folder as read-only.

<12> Section 2.3.3: Windows Server 2003 R2 does not have the msDFSR-DefaultCompressionExclusionFilter attribute. The list of default excluded compression extensions is hard-coded: .wma, .wmv, .zip, .jpg, .mpg, .mpeg, .m1v, .mp2, .mp3, .mpa, .cab, .wav, .snd, .au, .asf, .wm, .avi, .z, .gz, .tgz, and .frx.

<13> Section 2.3.5: Windows uses this security descriptor as a template for setting the security descriptor on the DFS-R WMI provider.

<14> Section 2.3.7: If no value is set for this attribute, Windows uses a value of "*.tmp,*.bak,~*".

<15> Section 2.3.9: Windows configuration tools allow an arbitrary string to be stored here; otherwise, ignore this field.

<16> Section 2.3.11: Windows configuration tools allow an arbitrary string to be stored here; otherwise, ignore this field.

<17> Section 2.3.11: Windows approximates its bandwidth usage and attempts to limit it based on the setting in the schedule. If the setting in the schedule is 0xF, Windows does not attempt to limit its bandwidth usage. Windows attempts to limit its bandwidth usage for the connection for all values from 0x1 to 0xE, according to the following table.

 Value

 Limit in kilobytes per second

 1

 16

 2

 64

 3

 128

 4

 256

 5

 512

 6

 1,024

 7

 2,048

 8

 4,096

 9

 8,192

 10

 16,384

 11

 32,768

 12

 65,536

 13

 131,072

 14

 262,144

<18> Section 3.1.6: Sharing violations DFS-R in Windows Server 2003 R2 operating system and later accesses files based on NT file system (NTFS) semantics. This implies respecting NTFS sharing semantics, which means that if other applications have files open denying shared read access, DFS-R cannot read these files from disk. Similarly, if applications have files open that deny shared delete access, DFS-R cannot update these files (by renaming the old version of these files to a temporary name and renaming a new version of the file). DFS-R in Windows Server 2003 R2 relies on internal timers (that use an exponential backoff scheme with a maximal time-out of 5 minutes) to re-attempt the file system operations that it requires.

<19> Section 3.2.1: Windows injects configuration changes into DFS-R over Active Directory in Windows Server 2003 R2 operating system and later.

<20> Section 3.2.2: Windows-based servers maintain a 30-minute time-out for inactivity on an open context handle before closing it.

<21> Section 3.2.4.1: Gaps in the opnum numbering sequence apply to Windows as follows.

Opnum

Description

14

Just returns ERROR_NOT_IMPLEMENTED. It is never used.

<22> Section 3.2.4.1.2: DFS-R client implementations on enterprise SKUs of Windows Server 2003 R2                                            operating system and later set the TRANSPORT_SUPPORTS_RDC_SIMILARITY bit in the downstreamFlags parameter to 1 when calling EstablishConnection.

<23> Section 3.2.4.1.4: Windows Server 2003 R2, Windows Server 2008, and Windows Server 2008 R2 operating system do not generate version vector tombstone updates.

<24> Section 3.2.4.1.4: Windows-based servers generate a version vector tombstone update for all replicated folders every time the service starts up and every 15 days thereafter.

<25> Section 3.2.4.1.4: For each GUID (m1), Windows-based servers generate a version vector tombstone update when the last refresh within a set of updates, whose GVSN shares the same GUID (m1), took place more than 60 days ago.

<26> Section 3.2.4.1.7: Windows Server 2003 R2 operating system and later implementations of DFS-R never return more than 1365 = 64 KB / size of(FRS_ID_GVSN) records, even if the client specifies a larger value in the maxRecords parameter.

<27> Section 3.2.4.1.7: Windows Server 2003 R2 and Windows Server 2008 do not verify this condition.

<28> Section 3.2.4.1.9: The default behavior of a Windows-based server is to complete the request successfully and set the sizeRead parameter to zero on return.

<29> Section 3.2.4.1.14: DFS-R with version 0x00050002 or later uses an implementation-defined failure value when performing operations on the database, such as the deletion of a directory tree, an NTFS journal wrap recovery, an NTFS journal loss recovery, or a dirty shutdown recovery, which prevents the file from being replicated until the operation is completed.

<30> Section 3.2.4.1.14: DFS-R in Windows Server 2003 R2 operating system and later always uses the following values.

 HorizonSize, level 11024
 Hash Window Size, level 148
 HorizonSize, level 2+ 128
 Hash Window Size, level 2+2

<31> Section 3.2.4.1.14: By default, Windows-based servers set the value to 16 which can be modified by the registry key [HKLM\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Settings\UpdateWorkerThreadCount].

<32> Section 3.2.4.1.14.1: The only type of reparse point that is replicated as a reparse point by Windows implementations of DFS-R is IO_REPARSE_TAG_SYMLINK. Reparse point types IO_REPARSE_TAG_SIS and IO_REPARSE_TAG_HSM are replicated as normal files rather than as reparse points. No other reparse point types (IO_REPARSE_TAG_MOUNT_POINT, IO_REPARSE_TAG_DFS, and so on) are replicated, neither as reparse points nor normal files.

<33> Section 3.2.4.1.14.1: Windows implementations of DFS-R do not marshal or send a file's Object ID Backup Stream.

<34> Section 3.3.1.3: In Windows, Slow Sync is initiated by the client once a week.

<35> Section 3.3.1.5: DFS-R uses the following algorithm to compute RDC recursion depth.

 h := 18 / horizonSize0 
 depth := 0 
 minSizeLevel := 65536 
 WHILE (depth < 8) AND (size > minSizeLevel) 
     size := size * h + 24 
     h := 18 / (2 * horizonSize1) 
     minSizeLevel := 32768 
     depth := depth + 1 
 ENDWHILE 
 

The various constants used are the following.

  •  18 is the size, in bytes, of an RDC signature (16-byte hash and 2-byte length).

  •  65,536 is the minimum size, in bytes, of a file that will be considered for RDC transfer.

  •  32,768 is the minimum size, in bytes, of a signature file that allows increasing the recursion level.

  •  24 is the size, in bytes, of the RDC signature file header.

  •  horizonSize0 is 1,024. Used for calculating RDC signatures of the file data.

  •  horizonSize1 is 256. Used for calculating all recursive levels of RDC signatures.

<36> Section 3.3.2: Connection schedules. Clients establish and terminate connections based on configured schedules. The only observed effect on the server is that clients could periodically reconnect to it. Connection schedules can be configured externally to Windows with a 15-minute granularity.

<37> Section 3.3.4.6.2: On the following servers without the QFE 353495, an update with a lower value of createTime supersedes updates with higher values.

  • Windows Server 2003 R2

  • Windows Server 2008

  • Windows Server 2008 R2

Servers with two different behaviors cannot be mixed.

<38> Section 3.3.4.6.2: Cycle conflicts are resolved on Windows implementations of DFS-R.

<39> Section 3.3.4.6.2: On the following servers without the QFE 353495, directory name conflicts are handled in the same way as file name conflicts.

  • Windows Server 2003 R2

  • Windows Server 2008

  • Windows Server 2008 R2

<40> Section 3.3.4.6.2: For each GUID (m1), Windows implementations of DFS-R generate a version vector tombstone update (with present set to 0) when the last refresh within a set of updates, whose GVSN shares the same GUID (m1), took place more than 60 days ago. Version vector tombstones are subsumed if the machine originating the GUID (m1) on the version vector tombstone receives the version vector tombstone.

<41> Section 3.3.4.6.2: Windows-based servers generate a version vector tombstone update, with present set to 1, for all replicated folders every time the service starts up and every 15 days thereafter. This interval can be modified using the Registry Key GcDbSendAliveIntervalInSeconds under \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Parameters\Settings\.

The following servers do not generate this update:

  • Windows Server 2003 R2

  • Windows Server 2008

  • Windows Server 2008 R2

<42> Section 3.3.4.16: Windows Server 2003 R2 operating system and later implementations of DFS-R will retry the records request up to a maximum of 128 retries before aborting the ongoing slow sync.

<43> Section 3.3.4.16.2: In Windows, the resolution is to reanimate missing records. That is, updates whose UIDs are not in the client's store are downloaded from the server.

<44> Section 3.3.4.18: DFS-R clients with version 0x00050002 use REQUEST_SUBORDINATE_SYNC to retrieve the server’s version chain vector in response to changes on the client's file system. The server’s version chain vector is used to synchronize the clients back to a state where they are a mirror image of the server, thus deleting possibly new files on the clients, as opposed to replicating these out. This behavior is also known as read-only replicated folders.