DR 2.0: Migrating from DFSR to Storage Replica

[Ned Pyle]

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!

What is Storage Replica?

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:

• Synchronous replication mirrors data over short range, low latency networks with zero data loss during a disaster
• Asynchronous replication mirrors data over long range, high latency networks with minimal data loss during a disaster
  
  

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

When to replace DFSR with Storage Replica

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:

• It doesn't replicate in-use files.
• It doesn't replicate synchronously.
• Its asynchronous replication latency can be many minutes, hours, or even days.
• Its maximum size limits are low by modern standards
• Its initial replication is much slower than just copying data manually, requiring additional steps like preseeding and database cloning for larger datasets
• It relies on a database that can require lengthy consistency checks after interruption.
• It's often configured for multi-writer replication, which allows changes to flow in many directions to many servers, leading to (perceived) data loss from user updates and latency.
• It does not scale well on clusters.
• It’s not supported with the modern ReFS file system.
• While still supported, we no longer actively develop or improve DFSR.
  
  

Storage Replica is an excellent alternative under the right circumstances:

• You need zero or minimal data loss during a disaster.
• You have good throughput – lower latency, higher bandwidth - networks between locations.
• You only need two copies of the data and don’t need users or applications writing to multiple copies at once.

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”.

1. Inventorying your environment

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.

Inventory domain-based DFSN

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.

dfsmgmt.msc

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

powershell output

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.

powershell output

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.

Inventory DFSR

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

powershell output

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:

dfsmgmt.msc

Inventory OS Versions

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

powershell output

Look for machines running Standard Edition or older OSes, they may need upgrade or replacement before you can get to Storage Replica.

2. Backup DFSN and DFSR

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

}

dfsutil output

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

3. Pick your Primaries, examine volume & log storage

Now you will determine who will be primary and evaluate your storage options.

1. Unlike DFSR, Storage Replica doesn’t have “multi-master” replication, there is always just one source and one destination. You need to pick which of your DFSR servers that you want to become primary – where all writes occur – and then existing or new servers to make secondary, where you will replicate data for safety. Your other DFSR servers get repurposed or discarded. You can replicate from a single server to many servers with SR, but only with many volumes on the source, each replicating to a different destination.
2. You will also need to ensure there is SR log space set aside. Storage Replica doesn’t use a database like DFSR, it uses several types of logs in a separate partition. Both the source and destination server will need at least one volume and by default, it must be at least 9GB (this is adjustable). You can use the Windows Server disk management tools like DISKMGMT.MSC, the PowerShell Storage Module to create this new volume by shrinking an existing one or you can add additional storage. 
3. Finally, because SR perfectly mirrors the source volume to the destination server, ensure that the new SR destination has the same amount of disk space and exactly the same-sized volumes.

You can use the Test-SRTopology tool to ensure you have met all of these requirements.

test-srtopology html output

4. Remove DFSR, adjust DFSN, add SMB

Having selected your first set of servers to migrate and having backed up all your DFSR and DFSN settings, you can now:

1. Remove all of the DFSR settings using DFSMGMT.MSC or Remove-DfsReplicationGroup from your first group of servers
2. Disable any DFSN folder targets that point to servers that will not be the source for Storage Replica.
3. If you plan to replicate to new servers, you will also need to create and configure your shared folders and shares on the destination volume (without any data) using Windows Admin Center, New-SmbShare, or NET SHARE, using the inventory you gathered in step 1. Once SR starts running, that volume will dismount and you will not be able to create the SMB shares anymore. They will reappear if you ever disable replication, mount the replicated volume with Mount-SRDestination, or switch replication direction – the SMB server service won’t forget them when the drive dismounts temporarily.

5. Deploy Storage Replica

Now that the infrastructure is ready, you can deploy Storage Replica.

1. Use Windows Admin Center for a graphical management experience or familiarize yourself with the Storage Replica Powershell.
2. Follow the steps in Server-to-server storage replication to configure your first replica partnership either as synchronous or asynchronous.

Windows Admin Center

6. Evaluate health

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:

1. Ensure user and application IO performance is acceptable by copying files, opening files remotely, etc.
2. Temporarily mount the destination volume with Mount-SRDestination and ensure access to an SMB share works.
3. Schedule a change control window and perform a disaster recovery test, switching replication direction to the secondary site and then back again to the primary site.

7. Repeat migration for all remaining servers

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.

8. Write down your DR plan

Write down your configuration and how to fail it over in the event of a disaster.

1. Ensure you keep up with the inventory of these protected servers so that your team can execute your plan across the fleet.
2. Write it so that anyone can follow it! When a disaster strikes, you may not be there, and your plan should be understandable and complete enough that your most junior new hire can execute it without supervision.
3. You should test your runbook document at least once a year - using that most junior person.
   
   

Final notes

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