Description of DFS and migration to Windows Server 2008 mode

Note: This article was originally created a very long time ago, but in March 2021, I significantly expanded it. As the main addition, I included various options for monitoring replication and troubleshooting errors. Allegedly, Microsoft has not been developing DFSR for a long time, as it has a newer technology called Storage Replica, which is quite different.

Distributed File System

The Distributed File System (DFS) is a useful service that provides several functions. The principle is to simplify access to shared directories and also to provide load balancing and high availability.

• DFS Namespaces
• DFS Replication

DFS provides consolidation of various network storage under a single address. We can also have multiple servers hosting the same data, and DFS then handles load balancing and high availability. Another feature is replication, which ensures synchronization of data on multiple servers and possibly multiple locations. With replications, we can specify the bandwidth to be used at different times of the day. DFS became part of Windows Server as early as the 2000 version. Client-side support for DFS is also required, which has been part of MS OS since Windows NT 4.0.

DFS Namespaces

DFS consists of two parts: DFS Namespaces (DFSN) and DFS Replication (DFSR). The commonly used version is the domain-based namespace (the other option is the standalone namespace), where the configuration is stored in Active Directory, and access to the shared folders is done using \\domain.name\dfsroot\folder. We will further discuss the domain-based DFS on Windows Server 2008 R2 and newer. The DFS Management snap-in or the command-line tool dfsutil or the PowerShell DFSN module are used for management.

The configuration of DFS is stored in Active Directory, and we also need one or more (for high availability, certainly) Namespace Servers, which maintain information about the structure (shares). The information about the Site is automatically used, and the client connects to the server accordingly. The last part is the actual file servers (Targets) where the data is stored.

The structure is such that we create a Namespace (Root, identified by a name = dfsroot), which appears to clients as a standard shared folder, and inside we create folders (Folders) and can connect them to target servers as Folder Targets.

DFS data is stored in several places:

• in Active Directory - namespace configuration (namespace servers, folder targets, configuration)
  • DFS Namespaces - CN=Dfs-Configuration,CN=System,DC=domain,DC=local
  • DFS Replication - CN=DFSR-GlobalSettings,CN=System,DC=domain,DC=local
• in the registry on the Namespace server (namespace membership) - HKEY_LOCAL_MACHINE\Software\Microsoft\Dfs\Roots\domainV2
• on the disk on the Namespace server (manages shares) in the default path C:\DFSRoots

DFS Replication

DFS Replication is a Windows Server role that allows replication of folders between multiple servers and sites, with a multiple-master type. We can use it for replicating DFS Namespaces and AD DS SYSVOL folders in the domain. DFSR replaced the older FRS (File Replication Service). DFS Replication uses a compression algorithm called Remote Differential Compression (RDC), which allows detecting changes in data and replicating only the changed file blocks.

We create Replication Groups (RG), to which we add one or more Replicated Folders (RF) and Member servers. In other words, an RG is a set of servers (members) that participate in the replication of one or more folders. Between the members, we create Connections, where we specify the sending and receiving member of the replication and the replication schedule (time and bandwidth). The connections between all members create the Replication Topology. For the replicated folders, we can set a filter on the files and subfolders to be replicated.

DFSR has one major disadvantage: it does not support file locking. So it's possible for two users to edit the same file on different servers. The conflict algorithm uses the Last Writer Wins rule, so whoever saves the changes later will overwrite the previous ones. It also does not support replication of locally locked files, i.e., if someone is editing a file, its changes are not replicated during that time. Understanding (the Lack of) Distributed File Locking in DFSR

For replications, the Staging Folder and its size are important, which serves as a queue for the changes to be replicated. It is configured for each Replicated Folder member. How to determine the minimum staging area DFSR needs for a replicated folder

Migrating DFS to the New Mode

Along with Windows Server 2008, DFS was expanded and modified. I assumed that these new features would automatically start being used when DFS is on a new server, but unfortunately, that's not the case. The namespace needs to be migrated to the new mode, and it's quite an inconvenient process. The biggest problems are with the replications.

To be able to use the 2008 mode, the following conditions must be met:

• the domain functional level must be at least Windows Server 2008
• all namespace servers must be running at least Windows Server 2008

We can find the current DFS type by right-clicking on the Namespace and selecting Properties, then on the General tab we see the Type item, which can be:

• Domain (Windows 2000 Server mode) – this is how the original version was named afterwards
• Domain (Windows Server 2008 mode) – the new version

Unfortunately, it's not possible to change just a setting to achieve the new mode (like, for example, with the domain functional level). But an export, deletion, recreation (in the new mode), and import must be performed. The procedure for migrating to the 2008 mode is described in the MS article Migrate a Domain-based Namespace to Windows Server 2008 Mode. For import and export, we must use the command-line tool dfsutil. Other operations can be performed in the graphical DFS Management.

• from the command prompt (with sufficient privileges), we perform the export of the namespace to a file
  Dfsutil root export \\domain.local\namespace file.xml
• we must remember or write down the Namespace Servers and the name of our own Namespace (dfsroot)
• in DFS Management, we delete the Namespace, we get a prompt asking if we want to delete the replications, which we probably don't want to do, more on that later
• using the wizard, we recreate the Namespace, we enter the first Namespace Server and the name (dfsroot), the Enable Windows Server 2008 mode option must be checked
• we perform the import using the command
  Dfsutil root import merge file.xml \\domain.local\namespace
• we add another Namespace Server

Migrating DFS and Replication

Note: I'm assuming we're already using DFSR and not FRS.

When we check the state of DFS after the migration, we'll find an unpleasant thing. We could have noticed it already during the export, if we had opened the exported XML file, as it doesn't contain any information about the replications. When we look at a directory in the Namespace, the Replication tab is empty (Not configured). Similarly, in the Replication Group, on the Replicated Folders tab, it says Not Published.

When we check the replications, we find that they are working fine. The fact is that DFSN and DFSR can operate (and do operate) independently of each other. If we click on the Replicate Folder Wizard in the Namespace, we get an error that the replication group already exists.

Clearly, the only missing information is that this namespace belongs to this replication group. I searched the internet and found that in the Replication Group in Active Directory, there is an attribute that lists the path to the namespace. We can manually enter it there, for example, using the Active Directory Users and Computers with Advanced Features enabled (or ADSI Edit).

• navigate through the domain, System, DFSR-GlobalSettings, our replication group, Content
• there we see the object for our group, choose Properties and the Attribute Editor tab
• we find the attribute msDFSR-DfsPath, to which we can set the path (\\domain\dfsroot\folder)

When we now look again in the DFS Management (and possibly do a Refresh), we can correctly see the replications in the namespace and the Published to namespace state in the Replication Group.

It would seem that everything is fine now. But if we choose Delete on a Folder Target in a Namespace, only one confirmation dialog appears, and the target is deleted. The replication, however, remains unaffected and continues to run between all members. If we want to remove the server from the Replication Group as well, we need to do it in the replications.

But if we normally create a namespace with replication, when deleting a single Folder Target, another dialog appears asking if we want to delete the replication group member as well. Clearly, there is some missing link, but I couldn't find what it is. Everything seems to be functional, we just have to perform some separate adjustments for DFSR and DFSN members. But when adding a new Folder Target, the option to create the replications is offered (and correctly performed), or when deleting an entire Folder, the option to delete the replication group is also correctly offered.

I also thought about what happens if I have replicated data on two servers, delete the replication group, and recreate it. In practice, it looks (based on the logs) that a full replication somehow starts (on a folder of a few tens of gigabytes, it took several hours). So this is not a suitable solution.

DFS Replication

When Changes in Replications Take Effect and How to Trigger Them

DFS replication doesn't start immediately. The members must first download the new configuration from Active Directory. First, replication between the individual domain controllers (DCs) must occur, and then the individual DFSR servers must download the configuration from AD. If we make some changes to the replications, we may need the changes to take effect immediately so that we can proceed to the next step (for example, when removing a replication server, before deleting the folder on it).

We can trigger AD replication using the Active Directory Sites and Services (on NTDS Settings for individual servers in sites) or the repadmin command (called sequentially for all DCs).

repadmin /syncall <dc-name> /e /d /A /P /q

One MS article suggests finding out the DCs and running the synchronization only from one of them.

WMIC /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig get LastChangeSource
repadmin /syncall /d /e /P <dc-name> <Naming Context>

example:
repadmin /syncall /d /e /P dc.company.local DC=company,DC=local

To download the configuration for individual members, we can use the dfsrdiag command. It needs to be run sequentially for all servers that are replicating data (replication group members, i.e., those hosting the data). If we're on the server directly, we don't need to specify it.

dfsrdiag PollAD /Member:<server-name>
dfsrdiag PollAD

Similarly, we can use the PowerShell cmdlet.

Update-DfsrConfigurationFromAD -ComputerName "SERVER1","SERVER2" -Verbos

When talking about replications, we can also perform the Migration of SYSVOL replications from FRS to DFSR.

One-Way Replication

For various practical situations, it may seem advantageous to create a replication in only one direction. The configuration allows us to create a one-way connection (Connection), or to delete or disable the other one. But Microsoft states that this is an unsupported and not recommended solution.

In Windows Server 2008 R2, the Read-only Replicated Folders feature was added, which we can use. Chaining of member servers containing R/O replicated folders is not supported. Only a server with an R/W replicated folder can replicate.

We can switch the member server to R/O mode using the DFS Management, right-clicking on the member and selecting Make read-only.

More information:

• Using One-Way Connections in DFS Replication
• Read-only replicated folders on Windows Server 2008 R2
• Configuring a read-only replicated folder on Windows Server 2008 R2
• Recovering from Unsupported One-Way Replication in DFSR Windows Server 2003 R2 and Windows Server 2008 (it does not address the possibility of using Read-only replicated folders, if we switch to R/O, it seems that Initial Synchronization and Initial Replication will automatically start)

How to Monitor and Control DFS Replications

I think there is a lack of a tool that would show in a comprehensive and clear way what is currently happening or where there is a problem. For management and monitoring, we can use the DFS Management, command-line tools DfsrAdmin and Dfsrdiag, the PowerShell DFSR module, or call WMI.

To check the status, we can have a Health Report generated using the DFS Management - Create Diagnostic Report. By default, DFSR debug logging is also enabled in the %windir%\debug folder. It's a good idea to check the event logs. Command-line tools offer similar options to PowerShell cmdlets.

A simple test script could be one that creates or modifies a file on one member server and checks whether it was created/modified on the others within a certain time.

Events in the Event Log

Events about DFS replications are written to a separate log DFS Replication (exception are operations with the DFSR database, such as repair or defragmentation, which are written to the Application log), which we can open in the standard Event Viewer. Here we can find a lot of important information and error states, and it's a good idea to regularly check the log. Some events and the resulting current state cannot be learned in any other way than by finding the appropriate record in the log.

A few events when looking for the start and end (initial) replication.

• Event ID 4104 on the member server
  The DFS Replication service successfully finished initial replication on the replicated folder at local path <…>.
• Event ID 4002 on the member server
  The DFS Replication service successfully initialized the replicated folder at local path <…>.
• Event ID 4102 on the member server
  The DFS Replication service initialized the replicated folder at local path <…> and is waiting to perform initial replication. The replicated folder will remain in this state until it has received replicated data, directly or indirectly, from the designated primary member.
• Event ID 4112 on the primary server
  The DFS Replication service initialized the replicated folder at local path <…>. This member is the designated primary member for this replicated folder.
• Event ID 2002
  The DFS Replication service successfully initialized replication on volume <…>.

Some detected errors and their possible recovery

• Event ID 5002
  The DFS Replication service encountered an error communicating with partner <…> for replication group <…>.
• Event ID 4412
  The DFS Replication service detected that a file was changed on multiple servers. A conflict resolution algorithm was used to determine the winning file. The losing file was moved to the Conflict and Deleted folder.
• Event ID 4304
  The DFS Replication service has been repeatedly prevented from replicating a file due to consistent sharing violations encountered on the file. The service failed to stage a file for replication due to a sharing violation.
• Event ID 4308
  The DFS Replication service has successfully recovered from sharing violations encountered on a file.
• Event ID 4202
  The DFS Replication service has detected that the staging space in use for the replicated folder at local path <…> is above the high watermark. The service will attempt to delete the oldest staging files. Performance may be affected.
• Event ID 4204
  The DFS Replication service has successfully deleted old staging files for the replicated folder at local path <…>. The staging space is now below the high watermark.
• Event ID 4208
  The DFS Replication service detected that the staging space usage is above the staging quota for the replicated folder at local path <…>. The service might fail to replicate some large files and the replicated folder might get out of sync. The service will attempt to clean up staging space automatically.
• Event ID 4210
  The DFS Replication service cleaned up the oldest staging files for the replicated folder at local path <…>, and the staging space is now below the configured staging quota.
• Event ID 4502
  The DFS Replication service encountered errors replicating one or more files because adequate free space was not available on volume <…>. This volume contains the replicated folder, the staging folder, or both. Please make sure that enough free space is available on this volume for replication to proceed. The service will retry replication periodically.
• Event ID 4504
  The DFS Replication service did not encounter replication failures caused by insufficient free space on volume <…> in the past 30 minutes.
• Event ID 2212
  The DFS Replication service has detected an unexpected shutdown on volume <…>. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. The service has automatically initiated a recovery process. The service will rebuild the database if it determines it cannot reliably recover. No user action is required.
• Event ID 2214
  The DFS Replication service successfully recovered from an unexpected shutdown on volume <…>. This can occur if the service terminated abnormally (due to a power loss, for example) or an error occurred on the volume. No user action is required.
• Event ID 2218
  The DFS Replication service is in the second step of replication database consistency checks after an unexpected shutdown. The database will be rebuilt if it cannot be recovered. No user action is required.

Checking Backlogs Using PowerShell

Backlog refers to the file updates waiting to be replicated between two partners. It's often mentioned that it's important to monitor whether the files are being processed. We can use the cmdlet Get-DfsrBacklog or the command `dfsrdiag backlog`.

Examples of usage:

Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -Verbose |
 Select-Object FileName,FullPathName,CreateTime

Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -Verbose |
 Select-Object * -First 1
 
PS C:\> Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName SERVER2 -FolderName "Privat" -Verbose |
 Select-Object FileName,FullPathName,CreateTime,UpdateTime 

VERBOSE: The replicated folder has a backlog of files. Replicated folder: "Privat". Count: 140

FileName                FullPathName                       CreateTime              UpdateTime  
--------                ------------                       ----------              ----------
Documents_20191011      D:\DFS\Privat\Documents_20191011   10/11/2019 3:27:47 PM   3/1/2021 11:56:16 AM

Apparently, if there is a large number of changes, we may get the following error:

Get-DfsrBacklog : Could not retrieve the backlog information. Replication group: "*" Replicated folder: "*" Source computer:
 SERVER1 Destination computer: SERVER2 Confirm that you are running in an elevated Windows PowerShell session and are a
 member of the local  Administrators group on the destination computer. The destination computer must also be accessible
 over the network, and have the DFSR service running. This cmdlet does not support WMI calls for the following or earlier
 operating systems: Windows Server 2012. Details:  The WS-Management service cannot process the request.The computed
 response packet size (5047149) exceeds the maximum envelope size that is allowed (512000).
At line:1 char:1
+ Get-DfsrBacklog -SourceComputerName SERVER1 -DestinationComputerName  ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo          : ProtocolError: (okdata2:String) [Get-DfsrBacklog], DfsrException
 + FullyQualifiedErrorId : Get-DfsrBacklog.CimException,Microsoft.DistributedFileSystemReplication.Commands.GetDfsrBacklogCom

The important information is that the packet size exceeded the set maximum value. According to a number of online resources, we can increase the value on the target server, either using the `winrm` command or the PowerShell cmdlet `Set-WSManInstance`. Example of finding the current value and setting it.

PS C:\> get-item -path WSMan:\localhost\MaxEnvelopeSizekb
 
 WSManConfig: Microsoft.WSMan.Management\WSMan::localhost

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   MaxEnvelopeSizekb                              500

PS C:\> Set-WSManInstance -ValueSet @{MaxEnvelopeSizekb = "10240"} -ResourceURI winrm/config

Checking Replication Status

The state of the replications (e.g., whether an initial synchronization is in progress or an error has occurred) is very important, and we can view it on the member server using **WMI** (either with the `wmic` command or by calling from PowerShell). This is different from what `Get-DfsrState` shows. Apparently, no cmdlet displays this state, because `Get-DfsReplicatedFolder` and `Get-DfsReplicationGroup` look at the logical object that is not tied to the server and return the `Normal` state even when there is a replication error on a specific server.

wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo get replicationgroupname,replicatedfoldername,state

Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo |
 Select-Object ReplicatedFolderName,ReplicationGroupName,state

The state value (State) can be

• 0 - Uninitialized
• 1 - Initialized
• 2 - Initial Sync
• 3 - Auto Recovery
• 4 - Normal
• 5 - In Error

DFS Replication State for a Member from the File Perspective

Using the cmdlet Get-DfsrState or the command `dfsrdiag ReplicationState`, we can find the overall replication state within the replication group partners. It displays information about incoming and outgoing file replications (e.g., currently replicating or in the queue). This is a different view of the Backlog. Dfsrdiag.exe ReplicationState: What's DFSR up to?

PS C:\> Get-DfsrState -ComputerName SERVER1 | FT FileName,UpdateState,Inbound,SourceComputerName -AutoSize

FileName                 UpdateState Inbound SourceComputerName
--------                 ----------- ------- ------------------
dokument.pdf                 Waiting    True SERVER2 

PS C:\> dfsrdiag ReplicationState /member:SERVER1 /all
Summary

  Active inbound connections: 0
  Updates received: 0
  
  Active outbound connections: 0
  Updates sent out: 0

Operation Succeeded

Stuck Backlog Files in the Waiting State

The event logs mentioned above, Backlogs, DfsrState, and replication status are the main things we should check. During the check, I discovered the problem below.

When checking the Backlogs from the primary server to the Read Only Member, I came across several files that remain here and their UpdateTime is long in the past. Physically, the files are only on the primary server and are not replicated.

Example of one file:

PS C:\> Get-DfsrBacklog -SourceComputerName server1 -DestinationComputerName server2 -FolderName "Privat" -Verbose |
 select FileName,CreateTime,UpdateTime

FileName                        CreateTime             UpdateTime            
--------                        ----------             ----------            
OneNoteBackup_2018-10-15.zip    10/15/2018 9:00:00 AM  10/15/2018 9:00:07 AM

In the `Get-DfsrState` output, the files are visible in the waiting state (the files are displayed twice here).

PS C:\> Get-DfsrState -ComputerName server2 | FT  FileName,UpdateState,Inbound,SourceComputerName -AutoSize

FileName                        UpdateState Inbound SourceComputerName
--------                        ----------- ------- ------------------
OneNoteBackup_2018-10-15.zip        Waiting    True SERVER1           

The replication state for the given replicated folder (RF) shows an error.

PS C:\> Get-WmiObject -Namespace "root\MicrosoftDFS" -Class DfsrReplicatedFolderInfo |
 Select-Object ReplicatedFolderName,state

ReplicatedFolderName state
-------------------- -----
Privat                   5

I tried to move the files out of the replicated folders. This emptied the Backlog and the replication status showed as Normal (4).

In the event log (Event Log), I found repeated Event ID 4502 and 4504. Finally, I found that the problem is not with disk space. But these folders have a set quota (Storage Quota). Although it's the same on the source and target server, for some reason, the files no longer fit in the target. After removing the quota and uploading the files back, they replicated correctly.

After some previous attempts, the replication state was displayed as error (5). It was resolved by restarting the DFS Replication service.

Additional DFSR Checks and Settings

Setting the Primary Member

I'm not sure if it has any significance. We can set one of the group members as primary. When creating a new Replicated Group / Folder in the wizard, we choose which member is primary (its content is authoritative during initial replication). Nevertheless, when I list them, no member is set as primary.

To view the information, we can use the `dfsradmin` command or the cmdlet Get-DfsrMembership.

PS C:\> Dfsradmin Membership List /RGname:company.local\dfs\projects /attr:MemName,RFName,IsPrimary
MemName     RfName    IsPrimary
SERVER1     Projects  No
SERVER2     Projects  No

PS C:\> Get-DfsrMembership -GroupName "company.local\dfs\Projects" | FT ComputerName, FolderName, PrimaryMember

ComputerName FolderName PrimaryMember
------------ ---------- -------------
SERVER1      Projects           False
SERVER2      Projects           False

Get-DfsrMembership | FT ComputerName, GroupName, FolderName, PrimaryMember

Setting it can be done for a single replicated folder or for all of them.

Set-DfsrMembership -GroupName company.local\dfs\Projects -FolderName Projects -ComputerName SERVER1 -PrimaryMember $true

Get-DfsReplicatedFolder | Set-DfsrMembership -ComputerName SERVER1 -PrimaryMember $true -Force

dfsradmin Membership Set /RGName:<RG name> /RFName:<RF name> /MemName:<primary member> /IsPrimary:True

WMI - Windows Management Instrumentation

We can obtain various information using **WMI**, where there is also the option to execute special actions. DFSR WMI Classes

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig 
wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo
wmic /namespace:\\root\microsoftdfs path dfsrMachineConfig
wmic /namespace:\\root\microsoftdfs path DfsrReplicationGroupConfig

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUID-NUMBER" call ResumeReplication
wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo where "replicatedfoldername='<RFname>'" call cleanupconflictdirectory

Comparing Files Between Two Servers

We can get the file hashes (the same ones the DFSR service calculates) on one server and on the other, and then compare them.

Get-DfsrFileHash e:\* | Out-File d:\Srv01.txt
Get-DfsrFileHash e:\* | Out-File d:\Srv02.txt
Compare-Object -ReferenceObject (Get-Content d:\Srv01.txt) -DifferenceObject (Get-Content d:\Srv02.txt) -IncludeEqual 

Checking Connection Parameters Between Members

Get-DfsrConnection | FT GroupName,SourceComputerName,DestinationComputerName,Enabled,RdcEnabled,CrossFileRdcEnabled,State -AutoSize 

Displaying Information in PowerShell

Examples of displaying various information. It depends on which values we are interested in.

Get-DfsReplicationGroup | FT GroupName,State,Identifier
Get-DfsReplicatedFolder | FT GroupName,FolderName,Identifier,State,DfsnPath
Get-DfsrMember | FT GroupName,ComputerName,State
Get-DfsrMembership | FT ComputerName,GroupName,FolderName,PrimaryMember,ContentPath,ReadOnly,Enabled,State
Get-DfsrServiceConfiguration

Displaying Files Moved to the ConflictAndDeleted and PreExisting System Folders

Example of a simple script that goes through the subfolders of the specified path. If there is a `DfsrPrivate` folder and an XML file `ConflictAndDeletedManifest.xml` in it, it prints the information from it. We can simply replace it with the `PreExistingManifest.xml` file. For a different Replicated Folder organization, it needs to be adjusted (for example, we can search for the given XML files on the entire disk, but that would take significantly longer).

$SourceFolder = "d:\dfs"
$Path = "\DfsrPrivate\ConflictAndDeletedManifest.xml"
Get-ChildItem $SourceFolder -Directory | Where-Object { Test-Path ($_.FullName + $Path) -PathType Leaf } | 
 ForEach-Object { Get-DfsrPreservedFiles -Path ($_.FullName + $Path) | FT Path,PreservedReason,FileSize,PreservedTime -AutoSize }

Unexpected (Dirty) Shutdown

When the DFSR service does not terminate correctly, it is referred to as an Unexpected Shutdown.

Increasing the Service Termination Time on Restart

If the Event ID 2212 appears in the event log (Event Log) after a server restart, it may mean that the server was turned off too quickly, without the DFSR service being properly terminated. This can cause problems. The official solution is to increase the service termination time You receive DFSR event ID 2212 after you restart the DFSR service in Windows Server 2008. We change (or create) the value in the registry:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\WaitToKillServiceTimeout = 6000

Stopping Replications During AutoRecovery

If there was an Unexpected shutdown and the Event ID 2212 was logged, Microsoft states that from a certain OS version, the behavior is such that replication is stopped and AutoRecovery does not occur. The Event ID 2213 should be logged. Description DFSR event ID 2213 in Windows Server 2008 R2, Understanding DFSR Dirty (Unexpected) Shutdown Recovery.

To find out if this behavior is enabled (value TRUE or 1), we can use WMI or the registry.

wmic /namespace:\\root\microsoftdfs path dfsrMachineConfig get StopReplicationOnAutoRecovery
StopReplicationOnAutoRecovery
FALSE

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\StopReplicationOnAutoRecovery

I verified this on Windows Server 2012 R2 and Windows Server 2016, and it's disabled everywhere. Maybe Microsoft has changed this behavior again.

Restoring Replications

If the replications stopped, I couldn't find anywhere how to verify that they are stopped (everywhere it only mentions looking for event 2213). So we have to use the command to resume. The Volume Guid is displayed, for example, in events 2212 and 2213.

wmic /namespace:\\root\microsoftdfs path dfsrVolumeConfig where volumeGuid="GUID-NUMBER" call ResumeReplication

If the Event ID 2213 is not logged, the recovery should automatically occur, and the replications should proceed. Microsoft only states that during the database recovery, replications may be slowed down. When it's complete (it can take many hours), the Event ID 2214 is logged.

Temporary Issue - No Instance(s) Available

I encountered a situation where some repairs were being made on the server. After starting up, it seemed to me that the replications were not running. Two pieces of information suggested this. The replication status returned that no instance existed.

PS C:\> wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo get replicationgroupname,replicatedfoldername,state
No Instance(s) Available.

Similarly, the `Get-DfsrBacklog` command called for the target server returned an error.

Get-DfsrBacklog : No replicated folders were found on the member. Member name: server3 Replicated folder: "*" Replication group: "*"

In the log, I found the Event ID 2212, after a few hours the Event ID 2218 was logged, and shortly after, the Event ID 2002. Then the replication status already displayed the list of folders.

DFSR Replication System Folders

The DfsrPrivate Folder and Its Subfolders

In each Replicated Folder on each member server, a hidden `DfsrPrivate` folder is located at its root. More precisely, it's a Directory Junction to the `\System Volume Information\DFSR\Private\` folder on the same disk. XML files with a list of items for the given subfolder may be present directly in the folder.

Under `DfsrPrivate`, the following folders may be found:

• `ConflictAndDeleted` - if a file is (conflictingly) changed on multiple servers, the non-chosen version is stored in this folder, the server configuration of a specific RF in RG sets the quota for the size of this folder (Advanced tab)
• `Deleted` - used only if the 'Move deleted files to Conflict and Deleted folder' option is not checked, when deleted, the file is temporarily moved here, the DFSR database is updated, and then it is deleted
• `Installing` - temporary storage for the assembled file with changes transferred from replication partners
• `PreExisting` - if there were any data during the initial synchronization that did not match the source, it is moved here
• `Staging` - serves as a queue for changes to be replicated, the server configuration of a specific RF in RG sets the quota for the size of this folder (Staging tab)

I couldn't find any official description of this area from Microsoft. According to certain information, replication takes place if Remote Differential Compression (RDC) is enabled. The sending server creates a compressed representation of the file in the Staging folder. This file, or only a part of it, is sent to the recipient, where it is also stored in the Staging folder. The file is decompressed and assembled in the Installing folder. Then the target file in the Replicated Folder is updated. If a conflict is detected in the updated file, the original (overwritten) one is moved to the ConflictAndDeleted folder.

The `PreExisting` folder may contain a lot of data in certain situations. If we find that we don't need it, we can perhaps delete it. Discussions often state that it's more effective to use the `robocopy` command than to use a graphical tool. We create an empty folder and then delete the contents of the target folder.

robocopy d:\empty d:\DFS\Administrative\DfsrPrivate\PreExisting /MIR

Similarly, we may want to delete the contents of the `ConflictAndDeleted` folder or it may happen that it exceeds its set size. For that, Microsoft has an official procedure The ConflictAndDeleted folder size may exceed its configured limitation, Manually Clearing the ConflictAndDeleted Folder in DFSR.

wmic /namespace:\\root\microsoftdfs path dfsrReplicatedFolderInfo where "replicatedfoldername='<ReplicatedFolderName>'" call cleanupconflictdirectory

The DFSR Config and Database Folders

Above, we mentioned the `DfsrPrivate` folder. In the path `\System Volume Information\DFSR\`, there are two more important folders.

• `Config` - contains configuration information in XML downloaded from AD DS, corresponding to the currently set Replication Group and Replicated Folder
• `Database_*` - this is where the Jet database used by the DFSR service is located, it stores information about file versions and other metadata per Replicated Folder

DFS and Access-Based Enumeration

One of the new features of DFS in Windows Server 2008 mode is Access-Based Enumeration for DFS. Access-Based Enumeration is a nice feature that can be installed on Windows Server 2003 and is part of Windows Server 2008 for shared folders (shares). It ensures that users don't see folders they don't have permission to. For classic shared folders, it's simply enabled on the given share, and then the folder-level Security permissions are used, and users see them accordingly.

For DFS, Access-Based Enumeration should ensure hiding of folders (Folders) at the DFS level. The idea is good, but it seems to me that it's done quite inconveniently. The problem is that in DFS we create a Namespace structure using Folders, which is stored on Namespace servers. When we display the DFSroot, this structure is displayed, and at this point, the permissions set on the folders on the Namespace server (not on the file server) in `C:\DFSRoots` are used, which are by default inherited from the disk and have read permission for Domain Users. When we open a folder that has a Folder Target, the redirection is performed, and now the security permissions set on the actual folder on the file server are evaluated.

If we enable Access-Based Enumeration on the DFS Namespace, nothing usually happens, because the rights from the structure on the Namespace server are evaluated for display. To make everything start working, we need to go through the individual Folders and manually set the permissions. The permissions we set here are only used for display, not for access control (so even if we make a folder invisible in this way, if the user knows the path and has permissions there, they can still open it). We set the permissions as follows:

• right-click on the Folder, choose Properties
• switch to the Advanced tab and set the switch to Set explicit view permissions on the DFS folder
• click the Configure view permissions button
• here we set the permissions for the group or individuals who should be able to see the folder

DFSUTIL on the Client

The command-line tool `dfsutil` can be used not only for configuring the namespace or server, but also for operations on the client. On Windows 7, we can install the command from the `RSAT` (Remote Server Administration Tools) feature under the Distributed File System Tools section.

Displaying information in the client cache (namespace, server names, active server):

dfsutil /pktinfo

Clearing the local cache (links to Folder Targets servers):

dfsutil /pktflush

Displays information about domains and controllers:

dfsutil /spcinfo

Forces the client to update domain information:

dfsutil /spcflush