- Understanding Kubernetes Persistent Volumes - Mon, May 29 2023
- Pulseway 9.2: Remote monitoring with workflow automation - Thu, May 18 2023
- ENow Active Directory Monitoring & Reporting - Tue, May 16 2023
DFS Replication overview
Interestingly, Microsoft transitioned to DFS Replication with Active Directory Domain Services (AD DS) running Windows Server 2008 or later domain functional levels. Therefore, as a testament to the technology itself, Microsoft has entrusted DFSR with one of the most critical replication processes in the enterprise—that between AD DS domain controllers.
Please take note of the following aspects concerning DFS Replication:
- It uses a remote differential compression (RDC) algorithm that detects changes;
- It uses a form of changed block tracking that only copies the changed blocks of a file instead of the entire file, which is much more efficient;
- The replication topology includes the connections between all members;
- Folders replicated on each member can be stored in different locations on each member.
DFS also allows IT admins to group shared folders located on different servers into a logically structured DFS Namespace. Using a single path, you can present files located on multiple servers to end users.
Install DFS Replication
The process of installing DFS Replication is very straightforward and can be done on a Windows Server using either the Server Manager or PowerShell, as most server roles.
To use PowerShell to install DFS Replication and the DFSR RSAT management tools, use the following cmdlet:
Install-WindowsFeature "FS-DFS-Replication","RSAT-DFS-Mgmt-Con"
Installing DFSR using PowerShell
Once DFS Replication and the management tools are installed successfully, you can launch the DFS Management Console using the command:
dfsmgmt.msc
There, you right-click the Replication node and select New Replication Group.
Beginning the process of creating a new DFS replication group
This will launch the New Replication Group Wizard. In the wizard, the first screen allows you to select the Replication Group Type you want to configure. Here, I am selecting the Multipurpose replication group, which is generally suited for most scenarios.
Choose the replication group type for DFSR
On the Name and Domain screen, name the replication group, set a description (optional), and select the domain. The domain should auto-populate with the parent domain for the DFSR servers.
Name the DFS replication group
Add the DFS Replication Group Members servers by clicking the Add button and selecting the member servers you want to include in the replication group.
Add the DFS Replication group members
On the Topology Selection screen, select a topology of connections among members of the replication group. Here, I am choosing the Full mesh topology, which replicates on all other replication group members. As mentioned in the configuration wizard, this topology works well with replication groups with 10 or fewer members. You will most likely want to create a custom replication topology with large replication groups.
Configuring the DFS Replication topology selection
Next, on the Replication Group Schedule and Bandwidth, select the replication schedule and bandwidth to be used by default for new connections in the replication group. The default is to enable replication 24 hours a day with full bandwidth.
Configure the DFS Replication group schedule and bandwidth
On the Primary Member screen, select the server that contains the content you want to replicate to other members. This server serves as the authoritative member during the initial replication if the folders or files on the primary server exist on the other member servers.
Configure the DFS Replication Primary Member
Choose the folders on the primary member you want to replicate to other replication group members. Here, I chose a test folder created on the root of the C drive.
Configure the DFSR folders to replicate
Next, choose the local path for the other members. When you add a member, you can create the folder if it doesn't already exist on the replication member. You can also enable or disable the member.
Configure the local path of the folder to synchronize on the other members
Finally, review the settings and create the replication group.
DFS Replication configuration completes successfully
The wizard will display a note about the initial replication delay. DFS Replication will not start until the replication group members pick up the configuration from the replication group. Active Directory replication latency and polling intervals affect the time it takes to start the initial replication.
Message about initial replication and replication latency
After a short time, when monitoring the second replication group member, the folder is created, and the test files from the primary server replicate to the replication group member.
The second member of the replication group receives the files after the initial DFS Replication interval completes
Using the command line tools available, you can quickly get the status of the DFS Replication and backlog of items to be replicated.
Wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicationgroupname,replicatedfoldername,state Dfsrdiag backlog /rgname:<replication group> /rfname:<replicated folder name> /smem:<source server> /rmem:<receiving server>
Getting the state and replication status using the command line
Final notes
Distributed File System Replication provides a great way to replicate files between file servers using the built-in role found in Windows Server. In addition, it provides an efficient way to copy files using only changed block replication, which efficiently synchronizes files.
Subscribe to 4sysops newsletter!
DFSR builds on the replication logic already tried and proven within the Active Directory. When combined with the DFS Namespace, DFS Replication ensures that users can access files using the server, providing the most efficient network access on the same site.
Does DFSR or a related version of that service work with Azure Directory Services?
If so, what are the typical replication latencies like in the Azure environment – and how do they compare with a distributed AD environment?