Export (0) Print
Expand All

7 Appendix B: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include released service packs:

  • Windows Server 2003 R2 operating system

  • Windows Server 2008 operating system

  • Windows Vista operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 FRS_COMMUNICATION_PROTOCOL_VERSION_W2K3R2. Windows Server 2008 and Windows Server 2008 R2 both identify their DFS-R protocol version as FRS_COMMUNICATION_PROTOCOL_VERSION_LONGHORN_SERVER. Windows Server 2012 identifies its DFS-R protocol version as FRS_COMMUNICATION_PROTOCOL_WIN8_SERVER. Windows Server 2012 R2 identifies its DFS-R protocol version as FRS_COMMUNICATION_PROTOCOL_WINBLUE_SERVER.

<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 should not be 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, Windows Server 2012, and Windows Server 2012 R2 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 which are using DFSR for SYSVOL replication. In addition, on Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2, 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2.

<20> Section 3.2.2: Windows 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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 do not generate version vector tombstone updates.

<24> Section 3.2.4.1.4: Windows 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 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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 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 RDCsignature (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 RDCsignature file header.

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

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

<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 may 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 Windows 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 Windows 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 vectortombstone 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 vectortombstones are subsumed if the machine originating the GUID (m1) on the version vectortombstone receives the version vectortombstone.

<41> Section 3.3.4.6.2: Windows servers generate a version vectortombstone 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 Windows 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, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 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'sversion chain vector in response to changes on the client'sfile system. The server'sversion 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.

 
Show:
© 2014 Microsoft