Configure Distributed File System Replication in Windows Server 2012 R2
In this Ask the Admin, I’ll show you how to replicate folders between two servers using Distributed File System Replication (DFSR).
Install DFS Replication
Before DFS replication can be configured, the DFS replication service needs to be installed on participating file servers. In my lab, contososrv1 already exists, and I want to replicate two shared folders (accounts and production) to contososrv2.
Log in to contososrv2 with a domain administrator account, open a PowerShell prompt and run the command below to install DFSR on both servers using the Install-WindowsFeature cmdlet:
Remember that the DFS replication and namespace features are mutually exclusive, and while contososrv1 is a namespace server in my lab, contososrv2 doesn't necessarily need to be a namespace server to host DFS folder targets, shared folders or take part in replication. In a real-world environment, contososrv2 might well be configured as a namespace server for redundancy. For more information on DFS namespaces, see Create a Distributed File System Namespace in Windows Server 2012 R2 on the Petri IT Knowledgebase. The accounts and production folders I want to replicate from contososrv1 need to be created on contososrv2, so let's do that using the mkdir cmdlet:
Add Folder Targets to a DFS NamespaceIf you don’t have a DFS namespace configured or don't want to add the folders we created above as folder targets to a namespace, you can skip this section. It's not required for replication to work. On contososrv2, let's share the accounts and production folders using the New-SMBShare cmdlet so they can be added as folder targets to a DFS namespace:
Once the folders are shared, I'll add them as folder targets to my existing DFS namespace using the New-DfsnFolderTarget cmdlet:
The results of the New-DfsnFolderTarget cmdlet will be displayed in the console. You can get this information again at any time by replacing New-DfsnFolderTarget with Get-DfsnFolderTarget in the above code.
Set Up a Replication GroupFirst we need to create a replication group (RG01) and add the two servers. The New-DfsReplicatedFolder cmdlet creates logical folder objects (accounts and production) that represent the physical folders to be replicated, the actual paths of which will be configured later.
Set Connections and MembershipIn this example, I'm going to set up bidirectional replication between the two file servers in the group. The Add-DfsrConnection cmdlet creates a logical partnership between the source (outbound or upstream) and destination (inbound or downstream) computers. Partnerships are always bidirectional unless the –CreateOneWay parameter is specified. For more information on the available replication topology options, see Planning a DFS Architecture, Part 2 on the Petri IT Knowledgebase.
Finally, I'll enable replication for the folders on both servers using the Set-DfsrMembership cmdlet, setting the –PrimaryMember parameter to $true for contososrv1. One server must be designated as the primary member for each group and is used during initial replication as the master copy, i.e. the content on other replica servers in the group will look like the primary server. Once initial replication is complete, changes can be made on any of the replication group member servers, and the primary member flag loses its significance.
And the same commands for the production folder on both servers with the exception that I've added the –Force parameter, so I don't have to confirm each operation:
Update the Local DFSR Configuration InformationThe commands above change the DSFR objects in AD, so let's run the Update-DfsrConfigurationFromAD cmdlet to force an update of the cached DFSR configuration information on each file server, kick starting the initial replication process:
It's worth noting at this point that if the accounts and production folders are published in a DFS namespace, which is not a requirement for replication to work, that the Publication Status for the folders on the Replicated Folders tab in the DFS Management GUI tool is not updated when replication is configured using PowerShell. Nevertheless, files should start replicating between contososrv1 and contososrv2.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.