DFS Improvements in Windows 2008 R2

Windows 2008 R2 will feature some major DFS improvements, following is an explanation of them:

1. Support for Windows Failover Clusters

In Windows Server 2008 R2, Windows Failover clusters can be configured to be part of a replication group. Windows Failover clustering technology enables administrators to configure services and applications to be highly available.

Busy hub servers located in the datacenter that replicate with many branch office servers are perfect candidates for clustered DFS Replication. These servers are critical to the replication infrastructure and administrators expect high availability from these servers. A failure (hardware/software) on such crucial servers has the potential to bring all replication activity to a standstill.

2. Read-only Replicated Folders

Often, customers use the DFS Replication service to publish data from a central server out to many branch office servers. A typical characteristic of this data is that it is created/modified at one location (typically the hub/datacenter server) and changes aren’t expected to occur on any of the other member servers. Usually, administrators configure strict ACLs for the replicated data to ensure that changes aren’t made by end-users in branch offices.

Configuring and maintaining strict ACLs to block accidental modifications or recovering data that has been accidentally deleted entail high administrative overheads. A new feature in Windows Server 2008 R2 called ‘Read-only replicated folders’, offers an easy to manage solution to this problem.

In essence, on a read-only replica:

• Local modifications are blocked by the DFS Replication service. Changes to files/folders including creation, deletion, modification of attributes/permissions etc. are not possible. Semantically, the read-only replicated folder mimics a read-only share.
• Changes from members hosting read-write copies are replicated in. The DFS Replication service replicates in changes from other replication partners that host read-write enabled copies of the replicated folder. This ensures that the data remains up to date on the read-only replica.

3. SYSVOL on Read-only Domain Controllers

Windows Server 2008 introduced support in the DFS Replication service for Read-only Domain Controllers (RODC).

Building on this implementation, in Windows Server 2008 R2 the concept of read-only replicated folders has been extended to the SYSVOL replicated folder. This means that on read-only domain controllers running Windows Server 2008 R2 and using the DFS Replication service to synchronize the SYSVOL share, the SYSVOL share is configured as a read-only replicated folder. Therefore, there is a change in the end-user experience for the SYSVOL share exposed by a Windows Server 2008 R2 domain controller.

On Windows Server 2008 based RODC: Changes can be made to the contents of the SYSVOL share on RODCs. However, the DFS Replication service monitors these changes and then asynchronously overwrites these changes with updates from a writable domain controller. Therefore, any changes made on a Windows Server 2008 RODC will be visible for a short duration, until they are reverted by the DFS Replication service.

On Windows Server 2008 R2 based RODC: Changes cannot be made to the contents of the SYSVOL share on RODCs. Any attempts to make such modifications will encounter an ACCESS DENIED error. Therefore, the SYSVOL share on such RODCs looks like a read-only share.

4. Diagnostics Improvements

Windows Server 2008 R2 also features a set of powerful enhancements to the diagnostics capabilities of the DFS Replication service. These are in the form of new command line options to the dfsrdiag.exe command line diagnostics tool.

Dfsrdiag.exe ReplState : This command line switch provides an insight into the current working state of the DFS Replication service. This command initiates a snapshot of the internal state of the service and thereby gathers a list of the updates that are currently being processed (downloaded from or served out to replication partners) by the service.

Using this command line switch, an administrator can retrieve a snapshot of the status of replication activity across all connections on a given DFS Replication member server.

Dfsrdiag.exe IdRecord: The DFS Replication service maintains a record for each file and folder in the replicated folder in its database. These are known as ID records. This command line switch can be used to display the ID record information maintained by the DFS Replication service corresponding to a particular file/folder in its database. The ID record also contains information such as version vectors of the file/folder, timestamps etc.

Using this command line switch, an administrator can dump the ID record corresponding to a file/folder on each individual replication member server. In order to check whether a particular update has replicated to the member servers in the replication group, the version information in the ID records on these members can be compared.

Dfsrdiag.exe FileHash: This command line switch computes and displays the file hash generated by the DFS Replication service for a particular file. The file hash can be used to compare two files and determine whether they are similar.

For instance, while pre-seeding the contents of a newly added replicated folder, it is often required to verify whether the file being pre-seeded is identical (attributes, timestamps, ACLs etc.) to that on the authoritative copy being used as the source for pre-seeding. By comparing the file hash generated by this command line option for two files, it is possible to verify if the files are identical. If the data being pre-seeded is identical to that contained on the source server, the DFS Replication service will complete initial sync much faster. This is because it does not need to download the file data and merely downloads metadata.