How DFS-N and DFS-R differ

When company files span servers or branches, users should not need new share paths whenever a server moves. DFS Namespaces provide a stable access path; DFS Replication can separately copy the files between servers. This guide builds the access path and then two-branch replication, checking the result before admitting users. Deletions and overwrites replicate too, so independent backups remain necessary.

Prepare AD, storage and shares

Use AD DS-joined Windows Server 2022/2025 with DFSN and DFSR modules. Store replicated content on NTFS. DFS-R does not support ReFS.

Allow data, staging and conflict/deleted space on both file servers. Staging size depends on large files and change volume rather than one universal allocation.

Replace corp.example.com, FS01, FS02, D: and CORP\FileUsers with actual values. Prepare NTFS paths, shares, role-installation rights and AD delegation.

Domain namespaces and PrimaryMember

This example uses a domain-based namespace. Assess standalone-namespace availability separately. PrimaryMember selects the initial-sync source rather than a permanent replication leader.

Referrals and replication paths

A client asks DFS-N for an SMB target and then accesses the files at that target. DFS-R works separately to replicate closed-file changes between servers. Multi-master replication does not provide a shared cross-site lock; this design does not suit a live database or files requiring cross-site locking.

Example: a shared path for two branches

Company/Data has FS01 and FS02 targets. FS01 supplies the initial data. FS02 remains offline for referrals during initial sync, and users must not write directly to its share.

Share, NTFS and firewall permissions

Share and NTFS permissions must both permit the intended access. End users need no namespace-root writes. Scope SMB and required RPC to members and approved subnets, aligning dynamic RPC with network policy. Review signing and access auditing.

Create the namespace and replication group

First prepare the role and data path on both file servers. Before running the commands, verify that D: is a suitable NTFS volume and replace CORP\FileUsers with the actual user group. Prepare both members so the namespace configuration refers to paths that already exist.

POWERSHELL
Install-WindowsFeature FS-DFS-Namespace,FS-DFS-Replication -IncludeManagementTools
New-Item -ItemType Directory -Path 'D:\DFSRoots\Company','D:\Data' -Force | Out-Null
New-SmbShare -Name Company -Path 'D:\DFSRoots\Company' -ReadAccess 'CORP\FileUsers'
New-SmbShare -Name Data -Path 'D:\Data' -ChangeAccess 'CORP\FileUsers'
Get-WindowsFeature FS-DFS-Namespace,FS-DFS-Replication

Design and apply NTFS permissions with the data owner; share permissions alone do not grant NTFS access. Then run the following commands from a management host with the DFSN and DFSR modules and the required delegated permissions.

POWERSHELL
Import-Module DFSN
Import-Module DFSR
New-DfsnRoot -Path '\\corp.example.com\Company' -TargetPath '\\FS01\Company' -Type DomainV2
New-DfsnRootTarget -Path '\\corp.example.com\Company' -TargetPath '\\FS02\Company'
New-DfsnFolder -Path '\\corp.example.com\Company\Data' -TargetPath '\\FS01\Data'
New-DfsnFolderTarget -Path '\\corp.example.com\Company\Data' -TargetPath '\\FS02\Data' -State Offline
New-DfsReplicationGroup -GroupName 'Company-Data'
New-DfsReplicatedFolder -GroupName 'Company-Data' -FolderName 'Data'
Add-DfsrMember -GroupName 'Company-Data' -ComputerName 'FS01','FS02'
Add-DfsrConnection -GroupName 'Company-Data' -SourceComputerName 'FS01' -DestinationComputerName 'FS02'
Set-DfsrMembership -GroupName 'Company-Data' -FolderName 'Data' -ComputerName 'FS01' -ContentPath 'D:\Data' -PrimaryMember $true -Force
Set-DfsrMembership -GroupName 'Company-Data' -FolderName 'Data' -ComputerName 'FS02' -ContentPath 'D:\Data' -Force

Add-DfsrConnection creates the reverse connection by default. Inspect Get-DfsrConnection. Do not repeat creation on existing deployments. AD propagation/initial sync takes time. PrimaryMember selects the initial source only. FS02 starts Offline so clients receive no referrals before acceptance. Also restrict direct user access to its share during initial sync. Accept only after a closed canary file reaches FS02 with the same hash and both backlogs reach zero. Run the following commands to bring that target Online only after these checks pass.

POWERSHELL
Set-DfsnFolderTarget -Path '\\corp.example.com\Company\Data' -TargetPath '\\FS02\Data' -State Online
Get-DfsnFolderTarget -Path '\\corp.example.com\Company\Data'

Backlog and staging pressure

Backlog describes changes that have not reached the other member. Read it in both directions alongside disk space and DFS Replication events. A short queue after a change is expected; sustained growth means replication cannot keep up with the change rate or communication is impaired.

Accept initial sync before user access

Close a test file on FS01 and verify the matching hash on FS02. Both backlogs must drain during the controlled test. Only then bring the FS02 target online.

A closed canary file and both-direction backlog

Use a delegated administrator with write access to both test shares. Run the first two lines once after configuring the group, then wait for initial sync and run the comparison block repeatedly. No output parity is assumed. The file name is unique and data is a disposable canary. Keep FS02 referrals Offline and direct user writes restricted until acceptance.

POWERSHELL
$CanaryName = 'dfsr-canary-' + [guid]::NewGuid().ToString('N') + '.txt'
Set-Content -LiteralPath (Join-Path '\\FS01\Data' $CanaryName) -Value 'DFS replication acceptance' -Encoding UTF8 -ErrorAction Stop
# Keep CanaryName in this session; run below after initial sync.
$SourceHash = (Get-FileHash -LiteralPath (Join-Path '\\FS01\Data' $CanaryName) -Algorithm SHA256 -ErrorAction Stop).Hash
$TargetHash = (Get-FileHash -LiteralPath (Join-Path '\\FS02\Data' $CanaryName) -Algorithm SHA256 -ErrorAction Stop).Hash
$SourceHash -eq $TargetHash
Get-DfsrBacklog -GroupName 'Company-Data' -FolderName 'Data' -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -Verbose
Get-DfsrBacklog -GroupName 'Company-Data' -FolderName 'Data' -SourceComputerName 'FS02' -DestinationComputerName 'FS01' -Verbose

Acceptance has three conditions: the hash comparison returns True, the test file is no longer pending, and backlog drains in both directions. A missing target file or a different hash fails the test; keep FS02 offline. Verbose output provides the total backlog beyond the limited file listing. Read events for synchronization completion, staging pressure and communication failures. This checks one closed file; ACLs, the full dataset and independent recovery need separate checks.

Stale files with a healthy namespace

When the path opens but content is stale, separate SMB reachability from DFS-R health. Inspect connections and backlog from a module-equipped host, then read events on the affected member.

POWERSHELL
Get-DfsrConnection -GroupName 'Company-Data'
Get-DfsrBacklog -GroupName 'Company-Data' -FolderName 'Data' -SourceComputerName 'FS01' -DestinationComputerName 'FS02' -Verbose
Get-DfsrBacklog -GroupName 'Company-Data' -FolderName 'Data' -SourceComputerName 'FS02' -DestinationComputerName 'FS01' -Verbose
Get-WinEvent -LogName 'DFS Replication' -MaxEvents 30
Test-NetConnection FS02 -Port 445

Get-DfsrBacklog returns a limited file list. Check verbose output for the full count. Open files, insufficient staging and content freshness need different corrections. Do not delete the DFS-R database as a generic repair.

Restore without unintended overwrite propagation

In the two-branch scenario, recovery must avoid spreading an unwanted version to both sites. Keep independent VSS-aware file backups and an AD/namespace protection plan. Restore a file to a separate path first, compare ACLs and hashes, and then return the selected file with replication controlled. Rebuild a failed member using the documented non-authoritative procedure; the actual backup determines RPO.

Best Practices

  • Version-control configuration and review changes.
  • Use least privilege and explicit allow-lists.
  • Automate repeatable checks and monitor the expected state.
  • Test upgrades and restores before production rollout.

Conclusion

A reliable implementation of Configure DFS Namespaces and Replication on Windows Server is more than a successful first run. Keep the configuration documented, observable, recoverable, and aligned with the team's change-management process.

Frequently Asked Questions

Is DFS-R a backup replacement?

No. Deletes/overwrites can replicate. Independent backups remain necessary.

Is PrimaryMember a permanent leader?

No. It selects the initial-sync source. Normal replication is multi-master.

Official Sources

Share

Meet AJInfrastructure & DevOps
Loading…