Dfs домен режим windows server 2008

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.

Картинка с сайта: www.samuraj-cz.com

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.

Картинка с сайта: www.samuraj-cz.com

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

Картинка с сайта: www.samuraj-cz.com

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.

Картинка с сайта: www.samuraj-cz.com

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)

Картинка с сайта: www.samuraj-cz.com

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.

Картинка с сайта: www.samuraj-cz.com

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.

Картинка с сайта: www.samuraj-cz.com

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.

Картинка с сайта: www.samuraj-cz.com

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)

Картинка с сайта: www.samuraj-cz.com

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

Картинка с сайта: www.samuraj-cz.com

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

To improve the reliability and availability of file
shares in an enterprise network, Microsoft has developed the Distributed
File System (DFS). DFS improves file share availability by providing a
single, unified namespace to access shared folders hosted across one or
more servers. A user needs to only remember a single server or domain
name and share name to connect to a DFS shared folder.

DFS has many benefits and
features that can simplify data access and management from both the
administrator and end-user perspective. DFS provides three main
functions, as follows:

• Data redundancy—
  DFS can provide access to a single share that is hosted on multiple
  servers. This allows clients to get referred to or fail over to a
  different server if the primary server cannot be contacted.

• Automated data replication—
  DFS can be configured to utilize the Distributed File System
  Replication (DFSR) service, and can be configured to automatically
  synchronize folders between DFS servers to provide data redundancy or
  centralized storage of branch office data.

• Distributed data consolidation—
  DFS can be used to provide a single namespace that can contain several
  distinct or unique data sets, which can be hosted on separate servers.
  This enables administrators to provide access to existing file shares
  hosted on many different file servers, from the single namespace,
  without adding replication or redundant data sets.

DFS Namespaces

DFS can be used in a few
different ways, but it will usually require the creation of a DFS
namespace. A DFS namespace can be the name of a single server and share
folder or the DNS and NetBIOS name of an Active Directory domain and
share folder. The DFS namespace is also referred to as the namespace
root. The namespace allows connections to automatically be redirected to
different servers without user knowledge. Using Figure 1 as an example, when a client connects to the domain DFS namespace named \\Companyabc.com\Apps, the client will be redirected to \\Server10\Apps, and the client will be unaware of this redirection.

Figure 1. Domain DFS namespace.

Картинка с сайта: tutorial.wmlcloud.com

For
DFS to function properly with regard to client redirection and just
basic connectivity, a compatible DFS client is required. In a network
that supports different versions of Windows, Apple Mac, and UNIX
clients, DFS should be tested on all clients before it is released to
production. DFS-compatible clients are currently available for the
following Microsoft Windows operating systems:

• Windows 2000 Professional and Server.

• Windows XP Professional.

• Windows Server 2003 and Windows Server 2003 R2.

• Windows Vista Business, Ultimate, and Enterprise.

• Windows 7 Professional, Ultimate, and Enterprise.

• Windows Server 2008 and Windows Server 2008 R2.

• Windows
  NT Server and Workstation 4.0 with Service Pack 6a and the Active
  Directory Client Extension found on the Windows 2000 Server CD.

• Windows
  98 can support DFS domain namespaces with the installation of the
  Active Directory Client Extension found on the Windows 2000 Server CD.

Because DFS clients do not
connect to the actual server by name, administrators can move shared
folders to new servers and user logon scripts and mapped drive
designations never need to be changed. In fact, DFS data presented in a
single namespace can be hosted on multiple servers to provide redundancy
and distribution of large amounts of data.

Standalone DFS Namespace

A
standalone DFS namespace utilizes the name of the server hosting the
DFS namespace. Standalone DFS namespaces should be used when file system
access needs to be simplified and the amount of data exceeds the
capacity of a single server. Also, if no Active Directory domain exists,
a standalone DFS namespace is still supported. When a standalone DFS
namespace is created on a Windows Server 2008 R2 server that is a member
of an Active Directory domain, DFS replication can be configured.

Domain-Based DFS Namespace

A domain-based DFS namespace
utilizes the name of the Active Directory domain the DFS namespace
server is a member of. A domain-based DFS namespace is created upon
deployment of an Active Directory domain at the location of
\\domain\SYSVOL to replicate the domain group policies and logon script
folders. Domain-based DFS namespaces support replication using either
the File Replication Service or the new Distributed File System
Replication service.

Domain-Based DFS Namespace Windows 2008 Mode

When a new domain-based
DFS namespace is created on a Windows Server 2008 R2 system, an option
to enable Windows Server 2008 mode is presented. This option is
available on Windows Server 2008 and Windows Server 2008 R2 systems when
the namespace is hosted on either operating system, and the domain the
system is a member of must be running in Windows Server 2008 domain
functional level and at least Window Server 2003 forest functional
level. This means that the domain must have only Windows Server 2008
domain controllers and the entire forest must have only Windows 2003
and/or Windows 2008 domain controllers.

Windows Server 2008 mode
enables the namespace to contain more than 5,000 DFS folders and it also
enables access-based enumeration within the DFS namespace.
Historically, many organizations ran into issues when deploying DFS
because over time, the number of folders beneath a namespace grew too
large and they had to create multiple namespaces and segregate the data,
which in some cases defeated the purpose for deploying DFS. Windows
Server 2008 namespace mode surpasses this previous limitation and with
the added bonus of access-based enumeration, it allows for users to
locate the data that is relevant to them much easier.

It is important to note that
the same functionality enabled for a Windows 2008 mode domain-based
namespace exists on standalone DFS namespaces when the namespace server
is hosted on a Windows Server 2008 R2 server, so this functionality can
be leveraged immediately, even in organizations that are far from
meeting the requirements for Windows 2008 mode domain-based namespaces.

DFS Replication

When an Active
Directory domain exists, standalone and domain-based DFS namespaces
support the replication of DFS data stored on multiple servers. This can
be a valuable tool used to distribute company applications to each site
or to provide centralized storage of remote office data for redundancy,
centralized backup, and to support users who travel and work in
different offices.

With
the release of Windows Server 2003 R2 and further improved in Window
Server 2008 R2, a service to extend the functionality and optimize DFS
Replication has been created. This service is called the Distributed
File System Replication (DFSR) service, which utilizes the new Remote
Differential Compression (RDC) protocol. DFSR replaces the legacy File
Replication Service (FRS) that was previously used to replicate DFS
data. As long as all of the DFS servers defined in a DFS replication
group are running Windows Server 2003 R2 or later, the DFSR service will
be used to replicate the data. If any of the systems are running a
previous version operating system, DFS data will be replicated using the
File Replication Service. There is one exception to this rule: The
Domain System Volume (SYSVOL) will be replicated between domain
controllers using the File Replication Service, even if all the domain
controllers are running Windows Server 2008 R2, until the domain
functional level is raised to the Windows Server 2008 level and the
SYSVOL is migrated from FRS to DFSR.

DFS Replication and DFS
namespaces are independent of one another, but they can be used
together, as they are commonly deployed in this fashion. Replication of
folders can be set up between servers that do not host any DFS
namespaces or namespace folders but the DFS Replication service must be
installed on all systems participating in the replication. Windows
Server 2008 R2 increases DFS Replication security and performance
because all DFS Replication is compressed and encrypted. Note that the
data stream cannot be set to run unencrypted.

DFS Terminology

To properly understand DFS,
a number of technical terms are used when deploying, configuring, and
referencing DFS. Although the DFS namespace and DFS Replication have
already been described, the remaining terms should also be understood
before reading the remainder of this article or deploying a new DFS
infrastructure:

• DFS namespace— A unified namespace that presents a centralized view of shared folder data in an organization.

• DFS namespace server— A Windows server that hosts a DFS namespace.

• DFS namespace root—
  The top level of the DFS tree that defines the namespace for DFS and
  the functionality available. The namespace root is also the name of the
  DFS namespace. A domain-based root adds fault-tolerant capabilities to
  DFS by allowing several servers to host the same DFS namespace root.

  Note

  Depending on which Server
  version, service pack, and edition of Window Server 2003 or 2008 is used
  will determine how many namespaces are supported on a single server.
  Please refer to online Microsoft documentation to determine which
  edition is right for your organization’s implementation of DFS.

  
  

• DFS folder—
  A folder that will be presented under the root when a DFS client
  connects. When a root is created, folders can be created within the file
  system, but DFS folders allow the system to redirect clients to
  different systems other than the namespace server hosting the root.

• Folder target—
  A shared folder hosted on a Windows server. The DFS folder name and the
  share name do not need to be the same but for troubleshooting purposes
  it is highly recommended. Multiple folder targets can be assigned to a
  single DFS folder to provide fault tolerance. If a single folder target
  is unavailable, clients will be connected to another available target.
  When DFS folders are created with multiple folder targets, replication
  can also be configured using DFS replication groups to keep the data
  across the targets in sync. Folder targets can be a share name or a
  folder beneath a share. For example, \\server1\userdata or \\server1\userdata\Finance are both valid folder targets.

• DFS tree—
  The hierarchy of the namespace. For example, the DFS tree begins with
  the DFS root namespace and contains all the defined folders below the
  root.

• Referrals—
  A configuration setting of a DFS namespace and/or folder that defines
  how DFS clients will connect to the namespace server, a folder in the
  namespace, or a particular folder target server. Referral properties
  include limiting client connections to servers in the local Active
  Directory site and how often to check the availability of a DFS server.
  Disabling a target’s referral keeps it from being used by clients.
  Target referral can be disabled when maintenance will be performed on a
  server.

DFS Replication Terminology

DFS uses either the File
Replication Service or the Distributed File System Replication service
to automatically replicate data contained in DFS folder targets. To
understand the replication concepts, you must understand some key DFS
replication terminology. Here are some important terms:

• Replication— The process of copying data from a source server folder to a destination server folder.

• Replication connection—
  The directory object that defines and manages the replication between a
  sending and receiving replication member server. The replication
  connection defines the replication schedule, which service will
  replicate the data, the sending and receiving members, and any bandwidth
  restrictions for the connection. Each replication connection has only a
  single sending and receiving replication member.

• Replication member—
  A server that shares a common replication connection. The receiving
  replication server receives data from a sending member server specified
  in the replication connection. The sending replication partner sends
  data to the receiving member specified in the replication connections.

• Read-only replication folders—
  Windows Server 2008 R2 introduces support for read-only replicas. This
  can be useful for auditing, centralized backup, or managing data sets.
  Only the replication members that are not defined as the primary source
  can host read-only replication folders. Read-Only Domain Controllers
  host the SYSVOL as a read-only replication folder. When read-only
  replication folders exist, it is a best practice to ensure that replication is only one-way to the read-only replication folder.

• Replication group— All the servers, folders, and connections that define a replication set of data.

• Multimaster replication—
  This defines two-way replication between multiple servers in a
  replication group. With multimaster replication, data changed on any
  server in the group will be replicated to every other server in the
  group.

Аббревиатура DFS расшифровывается как Distributed File System (распределенная файловая система), данная служба реализовывает достаточно важные функции для крупных организаций, распределенных территориально и состоящих из нескольких сетей WAN или сайтов, предоставляя услуги простого хранения, репликации и поиска файлов по всей сети предприятия.

Первое преимущество службы DFS — предоставление единого сетевого пространства имен (Namespace), которое все пользователи сети могут использовать для доступа к общим файлам и папкам, в не зависимости от своего местонахождения.

Вторая важная функция DFS – возможность настройки службы репликации, которая осуществляет синхронизацию папок и файлов по всей организации, предоставляя пользователям доступ к последним и актуальным версиям файлов.

Давайте подробнее рассмотрим эти две функции DFS.

DFS NameSpace – каждое пространство имен (namespace) представляет собой сетевую папку с подпапками внутри нее. Главное преимущество использования такого пространства имен заключается в том, что пользователи могут обращаться к своим общим папкам и файлам через корень пространства имен, не задумываясь, на каком сервер в действительности они хранятся. Т.е. namespace это своеобразная логическая структура, упрощающая доступом к файлам.

DFS Replication – служба репликации DFS позволяет иметь множество синхронизованных копий одного и того же файла или папки. Репликация позволяет внутри каждой подсети или сайта организации иметь копию файлов, например, центрального офиса. Т.е. когда пользователи обращаются к некой общей папке, они попадают не на сам сервер центрального офиса, а на ближайшую реплику DFS, тем самым существенно уменьшая загрузку слабого меж-сайтового канала передачи. И в том случае, если пользователь вносит изменения в любой из файлов, изменения реплицируются по всему пространству DFS, в результате все пользователи сети получают доступ к актуальной и свежей копии файла.

В Windows Server 2008 служба Distributed File System получила ряд усовершенствований, и стала более стабильной, были решены многие проблемы, наблюдающиеся в ранних версиях службы DFS.

Для того, чтобы воспользоваться всеми преимуществами новой DFS на Windows Server 2008, необходимо соблюсти ряд требований: все сервера участники DFS должны быть не ниже Windows Server 2008, и уровень домена AD должен быть не ниже Windows 2008.

В DFS появились следующие изменения:

Access-based Enumeration – пользователям разрешено видеть только те файлы и папки, которые разрешено. По умолчанию данная функция отключена, чтобы включить ее, нужно набрать следующую команду: dfsutil property abde enable \‹namespace_root›

Улучшенные инструменты командной строки – в Windows Server 2008 DFS NameSpaces появилась новая версия утилиты dfsUtil, кроме того, для диагностики и поиска неисправностей в службах DFS можно воспользоваться командой dfsdiag.

Поиск внутри пространства имен DFS– в Windows Server 2008 появилась возможность поиска внутри всего пространство имен DFS по всем файлам и папкам.

Улучшения в службе репликации Replication:

Улучшение производительности– значительно улучшена репликация больших и маленьких файлов, синхронизация теперь выполняется быстрее, а нагрузка на сеть меньше.

Улучшена служба обработки неожиданных перезагрузок серверов – в ранних версиях DFS, при неожиданной перезагрузке сервера часто возникало повреждение базы NameSpace или нарушение процесса репликации. В результате запускался длительный процесс ребилда базы и репликации, вызывающий большую нагрузку на сервера и сеть. DFS в Windows Server 2008 выполняется лишь частичный ребилд базы данных в случаях перезагрузки сервера, в результате процесс восстановления выполняется заметно быстрее.

Принудительная репликация– администратор теперь может вручную запустить процесс немедленной репликации, игнорируя настроенное расписание.

Поддержка Read Only Domain Controllers (RODC) – любые изменения на контроллере домена RODC могут быть отменены службой репликации DFS Replication.

Репликация SYSVOL– в Windows Server 2008 репликация Active Directory посредством FRS (File Replication Service) заменена на репликацию DFS.

Отчеты– теперь можно создавать диагностические отчеты о работе DFS

Установка роли DFS на Windows Server 2008

Итак, мы познакомились с основными возможностями службы DFS NameSpaces в Windows Server 2008 DFS NameSpace, теперь познакомимся с процедурой установки роли DFS на сервер.

В данном примере используется контроллер домена Windows Server 2008, уровень домена (functional level) тоже 2008. Как узнать версию схемы Active Directory.

1. Откройте оснастку Server Manager.

2. Перейдите в раздел Roles и выберите Add Roles.

Картинка с сайта: winitpro.ru

3. Из списка ролей выберите File Services.

Картинка с сайта: winitpro.ru

4. Появится информационной окно (Introduction to File Services), перейдите далее, нажав Next.

Картинка с сайта: winitpro.ru

5. В списке ролей выберите Distributed File System , а также DFS Namespaces и DFS Replication; после чего нажмите Next.

Примечание:
Среди ролей вы увидите «Windows Server 2003 File Services»и «File Replication Service». Данные опции стоит использовать только в том случае, если необходимо синхронизировать сервер Windows 2008 с устаревшими службами FRS.

Картинка с сайта: winitpro.ru

6. На экране «Create a DFS Namespace», вы можете указать хотите ли вы создать пространство имен немедленно, или позднее.

В данном примере, я не буду создавать корень пространства имен. Поэтому, я выбрал «Create a namespace later using the DFS Management snap-in in Server Manager» и нажал Next.

Картинка с сайта: winitpro.ru

7. На следующем экране, нажав Install, мы запустим процесс установки службы DFS.

Картинка с сайта: winitpro.ru

8. После установки DFS, в консоли Server Manager появится новая роль File Services со следующим списком установленных компонентов:

Distributed File System

DFS Namespaces

DFS Replication

Картинка с сайта: winitpro.ru

Итак, мы установили DFS, далее мы должны создать корень пространства имен и настроить репликацию DFS. Обо все этом я буду писать в последующих статьях.