Heya folks, Ned here again. Today I’m sharing advice on migrating from Distributed File System Replication (DFSR) to Storage Replica. This includes deciding when SR is a good replacement, inventorying your DFSR and DFS Namespaces, backing up your existing configuration, validating your existing replication and converging it, migrating to SR, then updating your disaster recovery runbook.
Let’s get to re-replicating!
We introduced Storage Replica in Windows Server 2016. SR replicates volumes between servers, between clusters and within stretch clusters. We designed SR for disaster recovery – I prefer the term disaster prevention – scenarios where organizations need to protect critical data from floods, fires, superstorms, and war. It supports synchronous and asynchronous replication:
In the first release, SR supported bandwidth throttling, encryption, delegation, network constraint, and was available only on Datacenter edition. In Windows Server 2019 we offered an additional limited version for Standard edition servers and the ability to mount a destination volume for testing or backups. In Windows Server 2022 Azure Edition, we offered compression to improve performance for over congested or lower-throughput networks. In September 2021, we began previewing that greatly lowers synchronous replication latency and is the future of SR. For instance, using DISKSPD on our test hardware here, you can see the improvement in IO on the source device when writing a volume protected by SR with the new enhanced (“RAW”) log is far better than the legacy (“CLFS”) log:
IO size |
CLFS (in MiB/s) |
RAW (in MiB/s) |
4K |
35.25 |
56.53 |
8K |
68.16 |
112.16 |
2MB |
521.32 |
1450.57 |
Customers have deployed DFSR for 17 years. It shipped in Windows Server 2003 R2 and millions of organizations use it to replicate domain controller SYSVOL and file servers. DFSR scales to thousands of nodes across extremely poor networks for smaller datasets and has an excellent differential compression algorithm, but has significant limitations as a modern DR solution:
Storage Replica is an excellent alternative under the right circumstances:
Important: DFSR is still required for domain controller SYSVOL replication and you can't replace it with SR. It's ok, that replica is usually pretty small and self-managing. Usually.
That’s the “if”. Let’s get to the “how”.
Before migrating to Storage Replica, inventory your organization for their current DFS Replication and DFS Namespace topologies and your file server versions. You need this to build your project and future DR plan. Locating domain-based DFSN is easy but standalone DFSN requires knowing your namespace hosts.
Use DFSMGMT, PowerShell or DFSUTIL to inventory all your domain-based DFSN including roots, links (“folders”), and link targets (“folder targets”). If you end up adding new servers or using the switch to Storage Replica as an opportunity to replace servers, you can modify the DSFUTIL export’s XML files to become easy input files.
There’s a sample script from IT Pro BritV8 for listing all the domain-based DFSN folder targets in the domain out to the console:
Powershell – Get List Of All Folder Targets In Domain Namespace | BritV8
#Requires -modules DFSN
#Gets a list of all the folder targets in the Domain Namespace
#Example use
#$results Get-DfsnAllFolderTargets
#$results |select namespacepath,TargetPath,ReferralPriorityRank,ReferralPriorityClass,state |ogv
function Get-DfsnAllFolderTargets ()
{
#Get a list of all Namespaces in the Domain
Write-Progress -Activity "1/3 - Getting List of Domain NameSpaces"
$RootList = Get-DfsnRoot
#Get a list of all FolderPaths in the Namespaces
Write-Progress -Activity "2/3 - Getting List of Domain Folder Paths"
$FolderPaths = foreach ($item in $RootList)
{
Get-DfsnFolder -Path "$($item.path)\*"
}
#Get a list of all Folder Targets in the Folder Paths, in the Namespaces"
Write-Progress -Activity "2/3 - Getting List of Folder Targets"
$FolderTargets = foreach ($item in $FolderPaths)
{
Get-DfsnFolderTarget -Path $item.Path
}
return $FolderTargets
}
Get-DfsnAllFolderTargets
You can use Get-SmbShare -CimSession to dig deeper into the shared folders and their volume usage, or just look at the folders in File Explorer.
Reminder: Standalone DFSN doesn’t store any data in Active Directory, making inventory difficult. You’ll need to know which servers are hosting data in a standalone namespace and inventory them manually. Hopefully you’ve kept good records.
The DFSR PowerShell module is the best way to inventory your replication groups and associated replicated folders. To get all DFSR member machines and their storage configuration in the domain, just run:
Get-DFSRMembership
You can format table the output for this inventory using:
Get-DfsrMembership | FT groupname,computername,contentpath,dfsnpath
Notice how you can’t rely on DfsnPath – that value is only set when you used DFSMGMT to create replication of an DFS Namespace. You can create replication groups without DFSN or even a shared folder, so be sure to reconcile that in your plans.
DFSMGMT is the graphical alternative:
If you are running Windows Server 2012 R2 and older or Windows Server 2016/2019/2022 Standard edition, you’ll also need to inventory the machines you collected from DFSN and DFSR above – remember that Storage Replica only became available in WS2016 and is limited on Standard Edition WS2019+. This migration to SR may be an OS upgrade, hardware replacement, or data migration story.
The easiest way is to use the Active Directory PowerShell module to query AD, either based on your list of identified servers or all of them:
Get-ADComputer -Filter 'OperatingSystem -Like "Windows *Server*"' -Property * | Format-Table Name,OperatingSystem -Wrap -Auto
Look for machines running Standard Edition or older OSes, they may need upgrade or replacement before you can get to Storage Replica.
Before you migrate, ensure you backup your DFSR and domain-based DFSN configurations. A normal Active Directory System State backup contains all that info, and you’re getting those backups nightly, right?
Besides that, you can save the domain-based DNS targets into XML files using DFSUTIL inside PowerShell:
$formatString = ".\dfsn-{0:D2}.xml"
$i = 0
$root = get-dfsnroot | Get-DfsnRootTarget
foreach ($targetpath in $root)
{
$i = $i + 1
$fileName = $formatString -f $i
dfsutil.exe root export ($targetpath).targetpath $fileName verbose
}
These DFSR PowerShell commands will save the configuration for later review or recreation:
Get-DFSReplicationGroup > rgs.txt
Get-DFSReplicatedFolder > rfs.txt
Get-DFSRMember > members.txt
Get-DFSRMembership > memberships.txt
Get-DFSRConnection > conns.txt
Now you will determine who will be primary and evaluate your storage options.
You can use the Test-SRTopology tool to ensure you have met all of these requirements.
Having selected your first set of servers to migrate and having backed up all your DFSR and DFSN settings, you can now:
Now that the infrastructure is ready, you can deploy Storage Replica.
Now that you’re using your first new Storage Replica set and updated DFSN and file server settings, validate that it’s working to your requirements:
Having confirmed that your first migration to Storage Replica meets your requirements, migrate the remainder of your servers. Store all your inventory and configuration backups for at least 60 days to ensure you can roll back servers if necessary.
Write down your configuration and how to fail it over in the event of a disaster.
Azure File Sync is also a replacement for DFSR, especially since they are both file-based replication features, with the flexibility and file server-oriented workload that it provides. You can even use SR and AFS on the same server with the same replicated folders and volumes, where you want some data to tier to the cloud and some to directly replicate to other on-prem servers. Read more at Deploy Azure File Sync.
I want to give a huge shoutout to Gabriel Luiz, MVP, who encouraged the creation of this blog post and always does what’s right for his customers and the Windows Server IT community. Obrigado, Gabriel!
Until next time,
Ned Pyle
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.