What's New in DFS Replication and DFS Namespaces in Windows Server

Applies To: Windows Server 2012 R2, Windows Server 2012

This topic describes the Distributed File System (DFS) Replication functionality that is new or changed in Windows Server 2012 R2 and the DFS Replication and DFS Namespaces functionality that was new or changed in Windows Server 2012.

DFS Replication is a role service in File and Storage Services. It enables you to efficiently replicate folders (including those referred to by a DFS namespace path) across multiple servers and sites. DFS Replication uses a compression algorithm known as remote differential compression (RDC). RDC detects changes to the data in a file, and it enables DFS Replication to replicate only the changed file blocks instead of the entire file. DFS Namespaces enables you to group shared folders that are located on different servers into one or more logically structured namespaces.
In this topic:

• What’s new in DFS Replication in Windows Server 2012 R2
  
• What’s new in DFS Namespaces and DFS Replication in Windows Server 2012
  

What’s new in DFS Replication in Windows Server 2012 R2

In Windows Server 2012 R2, DFS Replication offers enhanced support in the following areas.

Feature/functionality	New or updated?	Description
Windows PowerShell module for DFS Replication	New	Provides Windows PowerShell cmdlets for performing the majority of administrative tasks for DFS Replication, in addition to new functionality.
DFS Replication Windows Management Infrastructure provider	New	Provides the latest Windows Management Infrastructure (WMI)-based methods to manage DFS Replication.
Database cloning for initial sync	New	Provides support for bypassing initial replication when creating new replicated folders, replacing servers, or recovering from a disaster.
Database corruption recovery	New	Provides support for rebuilding corrupt databases without unexpected data loss caused by nonauthoritative initial sync.
Cross-file RDC disable	New	Provides the option to disable cross-file remote differential compression (RDC) between servers.
File staging tuning	New	Provides the option to configure variable file staging sizes on individual servers.
Preserved file restoration	New	Provides the capability to restore files from the ConflictAndDeleted and PreExisting folders.
Unexpected shutdown database recovery improvements	Updated	Enables automatic recovery after a loss of power or an unexpected stoppage of the DFS Replication service.
Membership disabling improvements	Updated	Stops DFS Replication private folder cleanup when disabling a server’s membership in a replicated folder.

See also Removed or deprecated functionality.

Windows PowerShell module for DFS Replication

The DFS Replication module provides Windows PowerShell cmdlets for performing the majority of administrative tasks for DFS Replication, in addition to the new functionality described in this topic.
What value does this change add?
Administrators can use the extensive Windows PowerShell cmdlets to perform common administrative tasks, and optionally automate them by using Windows PowerShell scripts. These tasks include operational actions such as creating, modifying, and removing replication settings. New functionality is also included with the cmdlets, such as the ability to clone DFS Replication databases and restore preserved files.
What works differently?
Instead of using DFS Management or DFS Replication command-line tools, administrators can perform all common tasks by using the Windows PowerShell cmdlets.
The Windows PowerShell cmdlets are available on computers that run Windows Server 2012 R2 or Windows 8.1 and that have the DFS Management Tools feature (part of the Remote Server Administration Tools) installed.

Tip
To use the Windows PowerShell module for DFS Replication from a computer that doesn’t have the module installed, use the Enter-PSSession or Invoke-Command cmdlets to establish a session with a computer that has the DFS Management Tools feature installed.

DFS Replication Windows Management Infrastructure provider

Windows Server 2012 R2 includes new Windows Management Infrastructure (sometimes referred to as WMI v2) provider functionality, which provides programmatic access to manage DFS Replication.
What value does this change add?
Management programs can use the latest Windows Management Infrastructure-based methods to manage DFS Replication.
What works differently?
Windows Management Infrastructure-based management access occurs over a firewall friendly Windows Remote Management (WinRM) transport protocol. The WMI v1 namespace is still available for backwards compatibility.
For more information about the new DFSR WMI classes, see What’s New.

Database cloning for initial sync

Windows Server 2012 R2 includes new database cloning functionality, which can accelerate initial replication when you create new replicated folders, replace servers, or recover from disaster.
What value does this change add?
You can now export a DFS Replication database from a volume on one server, and then preseed replicated files and import the database on multiple servers. The replicated folders begin replicating with a greatly reduced initial setup time (the setup time is usually reduced approximately 99%).
What works differently?
In Windows Server 2012 and earlier operating systems, initial sync replication required that a destination server populate its database over the network through a resource-expensive version-vectoring process with the source server. For larger datasets, this can take considerable time (days or weeks), even when you preseed data on the destination server.
Now the Export-DfsrClone cmdlet allows you to export the DFS Replication database and volume configuration .xml file settings for a given volume from the local computer to clone that database on another computer. Running the cmdlet triggers the export in the DFS Replication service and then waits for the service to complete the operation. During the export, DFS Replication stores file metadata in the database as part of the validation process. After you preseed the data and copy the exported database and .xml file to the destination server, you use Import-DfsrClone to import the database to a volume and validate the files in the file system. Any files that perfectly match don’t require expensive interserver metadata and file synchronization, which leads to dramatic performance improvements during the initial sync.
For more information, see Export a Clone of the DFS Replication Database.

Database corruption recovery

Windows Server 2012 R2 provides support for rebuilding corrupt databases without unexpected data loss caused by a nonauthoritative initial sync.
What value does this change add?
When DFS Replication detects database corruption, it rebuilds the database and then resumes replication normally, with no files arbitrarily losing conflicts. When replicating with a Read-only partner, DFS Replication resumes replication without waiting indefinitely for an administrator to manually set the primary flag.
What works differently?
Previously, a corrupt database would trigger DFS Replication to delete the database and start the nonauthoritative initial sync process again, as if replication was being set up for the first time. Any files on the recovering server would lose all conflicts automatically, even if they were the latest version of the file. Those conflicts would move into the ConflictAndDeleted or PreExisting folders, leading to perceived or real data loss.
In Windows Server 2012 R2, when DFS Replication detects database corruption, it rebuilds the database by using local file and update sequence number (USN) change journal information, and then marks each file with a Normal replicated state. DFS Replication then contacts its partner servers and merges the changes, which allows the last writer to save the most recent changes as if this was normal ongoing replication.

Cross-file RDC disable

Windows Server 2012 R2 provides the option to disable cross-file remote differential compression between servers.
What value does this change add?
You can now specifically choose to use the cross-file remote differential compression (RDC) capability, depending on your data and network topologies. For servers on LANs, turning off cross-file RDC may reduce server resource overhead and increase replication performance.
What works differently?
In Windows Server 2012, DFS Replication always enables cross-file RDC. Cross-file RDC uses up to five existing previously replicated files on a volume to seed a new replicating file. Applying cross-file RDC over low-bandwidth network connections with files that are similar results in large bandwidth savings and potentially large time savings. However, when you use cross-file RDC on high-bandwidth network connections, cross-file RDC might increase local processing time and negatively affect performance. In extremely large datasets (millions of files on a volume with a great deal of similarity), cross-file RDC might also negatively affect CPU and disk utilization.
In Windows Server 2012 R2, DFS Replication allows you to choose whether to use cross-file RDC on a per-connection basis between partners. Disabling cross-file RDC might increase performance at the cost of higher bandwidth usage.

File staging tuning

Windows Server 2012 R2 provides the option to configure variable file staging sizes on individual servers.
What value does this change add?
You can now choose a minimum file size for a file to stage if you have not configured RDC for a smaller size. For servers on LANs with larger files, increasing the minimum staging size for files can increase replication performance.
What works differently?
In Windows Server 2012 and earlier operating systems, DFS Replication uses a hard-coded 256 KB file size to determine staging requirements. If RDC is enabled and the RDC minimum size (by default, this is 64 KB) is larger than 256 KB, a file will be staged before it replicates. Usually this means that files smaller than 64 KB don’t get staged on servers running Windows Server 2012 and earlier operating systems. File staging adds replication time to allow for performing RDC operations and to lower the chance of files not replicating because they are in use by applications that created file locks on them.
DFS Replication now allows you to configure the staging minimum size from as little as 256 KB to as large as 512 TB. When you are not using RDC or staging, files are no longer compressed or copied to the staging folder, which can increase performance at the cost of much higher bandwidth usage.

Preserved file restoration

Windows Server 2012 R2 provides the ability to restore files from the ConflictAndDeleted and PreExisting folders.
What value does this change add?
This allows recovery of obfuscated user data from hidden DFS Replication private folders.
What works differently?
Windows Server 2012 and earlier operating systems don’t provide any tools to recover these files.
DFS Replication now enables you to inventory and retrieve the conflicted, deleted, and preexisting files by using the Get-DfsrPreservedFiles and Restore-DfsrPreservedFiles cmdlets. You can restore these files and folders to their previous location or to a new location. You can choose to move or copy the files, and you can keep all versions of a file or only the latest version.

Unexpected shutdown database recovery improvements

Windows Server 2012 R2 enables automatic recovery after a loss of power or an unexpected stoppage of the DFS Replication service.
What value does this change add?
When DFS Replication detects an unexpected database shutdown (for example, after a power outage or service termination), it automatically validates the database against the file system and then resumes replication normally, settling any file conflicts normally.
What works differently?
In Windows Server 2012 and Windows Server 2008 R2, an unexpected shutdown required you to re-enable replication manually by using a WMI method. You could disable this default behavior by using a per-computer registry value.
When DFS Replication detects an unexpected shutdown in Windows Server 2012 R2, it defaults to triggering the automatic recovery process. You must opt out of this behavior by using the registry value. In addition, if the only replicated folder on a volume is the built-in SYSVOL folder of a domain controller, it automatically triggers recovery regardless of the registry setting.

Membership disabling improvements

Windows Server 2012 R2 stops DFS Replication private folder cleanup when disabling a server’s membership in a replicated folder.
What value does this change add?
Files that had previously moved to the ConflictAndDeleted or PreExisting folders are no longer deleted when you disable a server’s replication group membership. Additionally, the message that is displayed by the management tools now states the processing that occurs after memberships are disabled. The message also explains that re-enabling a membership starts nonauthoritative synchronization.
What works differently?
In Windows Server 2012 and earlier operating systems, disabling a membership immediately deleted the DfsrPrivate folder for that membership, including the Staging, ConflictAndDeleted, and PreExisting folders. After these folders are deleted, you can’t easily recover data from them without reverting to a backup.
DFS Replication now leaves the DfsrPrivate folder untouched when you disable a membership. You can recover conflicted, deleted, and preexisting files from that location if the membership is not re-enabled. (Enabling the membership deletes the content of all private folders.)

Removed or deprecated functionality

The following features are included in Windows Server 2012 R2, but they are being phased out, and they likely will be removed from future versions of the Windows Server operating system.

Deprecated feature	Replacement
DFS Namespaces command-line tool, Dfscmd	DFS Namespaces module for Windows PowerShell
File Replication Service (FRS)	DFS Replication In Windows Server 2012 R2, it is no longer possible to use Windows PowerShell or Server Manager to create new domains with a Windows Server 2003 domain functional level. This means that new FRS deployments are blocked, and DFS Replication is always used for SYSVOL replication in new domains. To use FRS to replicate SYSVOL on domain controllers running Windows Server 2012 R2, the domain controllers must belong to an existing domain that uses the Windows Server 2003 domain functional level.

What’s new in DFS Namespaces and DFS Replication in Windows Server 2012

In Windows Server 2012, DFS Namespaces and DFS Replication offer enhanced support in the following areas.

Feature/functionality	Description
Windows PowerShell module for DFS Namespaces	Provides Windows PowerShell cmdlets for performing the majority of administration tasks for DFS Namespaces.
DFS Namespaces: Site awareness for DirectAccess clients	Provides remote client computers with optimal referrals to corporate resources when the computers connect by using DirectAccess to the corporate network.
DFS Namespaces: Windows Management Infrastructure provider	Provides the latest Windows Management Infrastructure-based management methods to manage DFS Namespaces.
DFS Replication: Support for Data Deduplication volumes	Provides support for replicated folders stored on volumes that use Data Deduplication.

See also Removed or deprecated functionality.

Windows PowerShell module for DFS Namespaces

Windows Server 2012 includes Windows PowerShell cmdlets for performing the majority of administration tasks for DFS Namespaces.
What value does this change add?
Administrators can use the extensive Windows PowerShell cmdlets to perform common administration tasks, and optionally automate them by using Windows PowerShell scripts.
What works differently?
Instead of using DFS Management or DFS command-line utilities, administrators can perform all common tasks by using the Windows PowerShell cmdlets.
The Windows PowerShell cmdlets are available on computers that run Windows Server 2012 or Windows 8 and that have the DFS Management Tools feature (part of the Remote Server Administration Tools) installed.
For more information, see DFS Namespace (DFSN) Cmdlets in Windows PowerShell and Introducing DFS Namespaces Windows PowerShell Cmdlets.

Tip
To use the Windows PowerShell module for DFS Namespaces from a computer that does not have the module installed, use the Enter-PSSession cmdlet to establish a session with a computer that has the DFS Management Tools feature installed.

DFS Namespaces: Site awareness for DirectAccess clients

Windows Server 2012 includes site awareness for DirectAccess functionality to provide optimal site-aware referrals to remote users who access a corporate network by using DirectAccess.
What value does this change add?
Remote users who connect to DFS namespaces over a DirectAccess connection receive referrals to the namespace servers and folder targets that are closest to their location. This reduces network latency when accessing files on the corporate network, making more efficient use of bandwidth.
What works differently?
When accessing a DFS namespace path by using DirectAccess in Windows 7 or Windows Server 2008 R2, remote computers that have IP addresses outside of the sites specified in Active Directory Domain Services receive a randomly ordered referral that could include servers in distant sites, even when servers in a nearby site are available.
When a remote computer accesses a DFS namespace path by using DirectAccess on computers running Windows 8 or Windows Server 2012, the computer provides a site name in the referral request to the namespace server running Windows Server 2012. The namespace server uses the site name to provide a referral to the closest site available.
For site awareness to work for clients that are using DirectAccess, the client computer must be running Windows 8 or Windows Server 2012 and the server must be running Windows Server 2012.

DFS Namespaces: Windows Management Infrastructure provider

Windows Server 2012 includes new Windows Management Infrastructure (the new version of WMI, sometimes known as MI or WMIv2) provider functionality, which provides programmatic access to manage DFS Namespaces.
What value does this change add?
Management programs can use the latest Windows Management Infrastructure-based methods to manage DFS Namespaces.
What works differently?
Windows Management Infrastructure-based management access occurs over a firewall-friendly Windows Remote Management (WinRM) transport protocol.

DFS Replication: Support for Data Deduplication volumes

Windows Server 2012 includes support for replicated folders stored on volumes on which Data Deduplication is enabled.
What value does this change add?
You can use the new Data Deduplication functionality to reduce storage requirements without impacting DFS Replication.
What works differently?
DFS Replication replicates files that include the new reparse point tag IO_REPARSE_TAG_DEDUP without impacting Data Deduplication or DFS Replication. Deduplicating or rehydrating a deduplicated file won’t trigger replication.

Removed or deprecated functionality

The following features are included in Windows Server 2012, but they are being phased out, and they likely will be removed from future versions of the Windows Server operating system.

Deprecated feature	Replacement
DFS Namespaces command-line tool, Dfscmd	DFS Namespaces module for Windows PowerShell
File Replication Service (FRS)	DFS Replication

DFSR Event 5012 (DFS Replication)

Summary

DFS Replication failed to communicate with a replication group member because the member didn’t have the same configuration information. DFS Replication will retry this operation, which might resolve after configuration changes replicate through Active Directory Domain Services (AD DS).

Causes

DFS Replication could not establish a connection with the member. This error can occur for the following reasons:

• An administrator recently made a configuration change or created a new replication group. If two replication group members obtain their configuration data from different domain controllers, they may have mismatched configuration data due to AD DS replication latencies.
• An administrator altered AD DS permissions.

---

Resolutions

• Wait for configuration changes to replicate with AD DS
• Test AD DS connectivity

Wait for configuration changes to replicate with AD DS

DFS Replication will retry this operation, which usually resolves automatically after configuration changes replicate through AD DS.
To poll immediately for configuration changes, open a command prompt window and then type the following command once for each member of the replication group, where is the domain the server is located in and is the server name:
Dfsrdiag PollAD /Member:\
If this problem persists, verify that AD DS replication is working and that the service is able to reach a domain controller. If the problem persists for 8 hours, the DFS Replication service will disable the connection and log DFS Replication Event 5016.

Test AD DS connectivity

To test DFS Replication’s ability to communicate with AD DS, open a command prompt window and then type the following command: Dfsrdiag pollad /verbose. The command should report Operation Succeeded. If not, there is a problem communicating with AD DS.

---

Verification

To confirm that the issue is resolved, look for DFS Replication Event 5004 in the Event Viewer.crusoe
To manually verify the replication topology, see Repair a Disconnected Topology (http://go.microsoft.com/fwlink/?LinkId=187103 )

How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)

Summary

Consider the following scenario:
You want to force the non-authoritative synchronization of SYSVOL on a domain controller. In the File Replication Service (FRS), this was controlled through the D2 and D4 data values for the Burflags registry values, but these values do not exist for the Distributed File System Replication (DFSR) service. You cannot use the DFS Management snap-in (Dfsmgmt.msc) or the Dfsradmin.exe command-line tool to achieve this. Unlike custom DFSR replicated folders, SYSVOL is intentionally protected from any editing through its management interfaces to prevent accidents.
How to perform a non-authoritative synchronization of DFSR-replicated SYSVOL (like "D2" for FRS)

1. In the ADSIEDIT.MSC tool modify the following distinguished name (DN) value and attribute on each of the domain controllers that you want to make non-authoritative:
   
   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
   msDFSR-Enabled=FALSE
   
2. Force Active Directory replication throughout the domain.
   
3. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
   
   DFSRDIAG POLLAD
   
4. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
   
5. On the same DN from Step 1, set:
   
   msDFSR-Enabled=TRUE
   
6. Force Active Directory replication throughout the domain.
   
7. Run the following command from an elevated command prompt on the same servers that you set as non-authoritative:
   
   DFSRDIAG POLLAD
   
8. You will see Event ID 4614 and 4604 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D2” of SYSVOL.

How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like "D4" for FRS)

1. In the ADSIEDIT.MSC tool, modify the following DN and two attributes on the domain controller you want to make authoritative (preferrably the PDC Emulator, which is usually the most up to date for SYSVOL contents):
   
   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
   msDFSR-Enabled=FALSEmsDFSR-options=1
   
2. Modify the following DN and single attribute on all other domain controllers in that domain:
   
   CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
   msDFSR-Enabled=FALSE
   
3. Force Active Directory replication throughout the domain and validate its success on all DCs.
   
4. Start the DFSR service set as authoritative:
   
5. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated.
   
6. On the same DN from Step 1, set:
   
   msDFSR-Enabled=TRUE
7. Force Active Directory replication throughout the domain and validate its success on all DCs.
   
8. Run the following command from an elevated command prompt on the same server that you set as authoritative:
   
   DFSRDIAG POLLAD
   
9. You will see Event ID 4602 in the DFSR event log indicating SYSVOL has been initialized. That domain controller has now done a “D4” of SYSVOL.
   
10. Start the DFSR service on the other non-authoritative DCs. You will see Event ID 4114 in the DFSR event log indicating SYSVOL is no longer being replicated on each of them.
    
11. Modify the following DN and single attribute on all other domain controllers in that domain:
    
    CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC=
    msDFSR-Enabled=TRUE
    
12. Run the following command from an elevated command prompt on all non-authoritative DCs (i.e. all but the formerly authoritative one):
    
    DFSRDIAG POLLAD

More Information

If setting the authoritative flag on one DC, you must non-authoritatively synchronizeall other DCs in the domain. Otherwise you will see conflicts on DCs, originating from any DCs where you did not set auth/non-auth and restarted the DFSR service.For example, if all logon scripts were accidentally deleted and a manual copy of them was placed back on the PDC Emulator role holder, making that server authoritative and all other servers non-authoritative would guarantee success and prevent conflicts.
If making any DC authoritative, the PDC Emulator as authoritative is preferable, since its SYSVOL contents are usually most up to date.
The use of the authoritative flag is only necessary if you need to force synchronization of all DCs. If only repairing one DC, simply make it non-authoritative and do not touch other servers.
This article is designed with a 2-DC environment in mind, for simplicity of description. If you had more than one affected DC, expand the steps to includeALL of those as well. It also assumes you have the ability to restore data that was deleted, overwritten, damaged, etc. previously if this is a disaster recovery scenario on all DCs in the domain.

DFS-R Walkthrough

DFS Replication allows for multi-master replication of files located on windows servers. Multi-master is a term we generally frequently in the AD world, but simply means that changes can happen on any server in the replication group, and those changes will replicate to its partners. One important note: DFS-Namespace and DFS-Replication technologies are mutual exclusive and does not require the other to be configured first, but at Dell we do generally see them used together.

Setup:

2 DC’s – DC01 (192.168.1.10) and DC02 (192.168.1.11) are domain controllers for the matrix.local domain and are in the Default-First-Site-Name

2 File Servers –

FS01.matrix.local

FS02.matrix.local

Once all the good times of setting IP Addresses, renaming, and joining the domain we are now ready to setup FS01.

The environment is not very complicated: 2 domain controllers and 2 file servers.  That said, I needed to generate some test data in order to be have some data to replicate which we’ll do next.  I embedded the actual script used to create this data.

Word of warning: some really basic code ahead:

Set objFSO = CreateObject(“Scripting.FileSystemObject”)
strStartPath = “C:\Data\CorpData”

strFileName = “Sample”
strExt = “.txt”

Set objFolder = objFSO.CreateFolder(strStartPath)
for i = 0 to 200
strNewFolder = strStartPath & “\Folder” & i
Set objFolder = objFSO.CreateFolder(strNewFolder)
for j = 0 to 200
strSubFolder = strNewFolder & “\Subfolder” & i & “-” & j
Set objFolder = objFSO.CreateFolder(strSubFolder)
for k = 0 to 200
Set objFile = objFSO.CreateTextFile(strSubFolder & “\” & strFileName & i & “-” & j & “-” & k & strExt)
next
next
Set objFile = objFSO.CreateTextFile(strNewFolder & “\” & strFileName & i & strExt)
next
msgbox “Done”

So that’s all fancy but what does it do?
Well first thing is that its vbscript; I am an old vb guy so when I want to whip out some quick code this is what I resort too. Sure you could do this in PowerShell, and given enough time I may eventually do that. Don’t beat me up too much on it.
Here are the steps of the script in plain English

1. Create a folder called c:\Data\CorpData
2. Then create 201 subfolders called Folder(#) in my case 0 to 200
3. Then in the sub folder create 201 more folders called SubFolder(#)
4. In each subfolder create 201 empty files named Sample-Folder#-Subfolder#-File#.txt
5. Rinse and repeat steps 2-4 for 200 times while creating a file under the original Folder(#)

I know that’s a lot of overkill but since the files are all 0kb and the folders are 0 kb it allows me to create a lot of files and folders really quickly (about 5 to 10 minutes) – this little script creates the following for files and folders:

Yes that says 8 million files in 40,602 folders with a 0kb size. While this is not likely what you will see in production, it will allow us to move on to the next step. If your are testing this as well and do not want that many then you could change all the 200’s to 20 in the above script and that would make a lot less files and folders, thus making the whole process quicker.

I went ahead and set the corpdata as a share called corpdata – because of all the files and folders this took a really long time – mental note to self “create the share first”.

For users to access at this point they would go to \\fs01.matrix.local\corpdata which looks like

Next we’ll install the DFS features.,

Step 1: Install the DFS Namespace, DFS Replication, and DFS Management tools

In Server Manager, Click Manage and select Add Roles and Features – This will bring up the Add Roles and Features Wizard

Note: As soon as you click one of the 2 roles a popup will open prompting to install the DFS Management Tools – Click Add Features

Step 2: Create the Namespace “Data”

While I am not going through all the steps that have been done to get the namespace up and running, for specific steps please see this blog posting here

In the above picture we have a domain based namespace called Matrix.local\Corp with a folder named Data. The Data folder has a target of \\fs01.matrix.local\CorpData

Data can be accessed either via directly from the server or namespace

Step 3: Prepare FS02

So time passes and the Matrix powers that be decide that the corporate data needs to be duplicated to FS02. Usually this is to allow either users faster access to the data when located at another site, data redundancy, or as a disaster recovery scenario. Windows 2012 R2 has many enhancements that allow for replication to be faster and much more efficient over previous versions.

While it would be easy to go through the Add Roles and Feature wizard again for FS02, where would the fun be in that? We will configure FS02 with PowerShell.

That command is “Install-WindowsFeature FS-DFS-Namespace, FS-DFS-Replication, RSAT-DFS-Mgmt-Con”

That was much quicker and easier to install than using Server Manager.

Step 4: Create the CorpData share on FS02

The path locally for FS02 will be C:\Data\CorpData

Run the command New-Item C:\Data –Type directory

Run the command New-Item C:\Data\CorpData –Type directory

Open windows explorer and validate the ntfs permissions for the above folders match the FS01 server

This is necessary to keep the permissions consistent – mismatched permissions is a common issue we see in Dell support when DFS replication is used. It is also easier/quicker to set permissions before there is actual data in the folder. Check both folders.

Go ahead and create the share using the same permissions as FS01

Browse to the folder to validate that the share is accessible – there won’t be any data – we will do that next

Step 5: PreSeed the Data

This is the step where we get our Robocopy on. If you need some background on Robocopy see this blog or Microsoft site http://technet.microsoft.com/en-us/library/dn495044.aspx. The command that we will use is:

robocopy “” “” /e /b /copyall /r:6 /w:5 /MT:64 /xd DfsrPrivate /tee /log: /v

Our specific command will be:

Robocopy \\fs01\corpdata C:\Data\CorpData /e /b /copyall /r:3 /w:1 /MT:64 /XD DfsrPrivate /tee /log:c:\robo.log /v
We will run that from FS02.

This will take a while to run – after all, there is 8 million files to copy.

Once complete, validate the copy status – in my test environment there will be no failures because nobody is really accessing the data and it is all text files. In the real world there may be failures, but there is no harm in running the Robocopy command several times.  After the initial copy subsequent runs will be quicker because only changed files or new files will be copied. Robocopy gives a pretty good report when the copy is done.

One step that you will want to do is to check the file hash, on 8 million files would be a really tough task to accomplish so I am going to spot check a file or 2 to validate the copy’s file hash matches the FS01 file. Using the Get-DfsrFileHash PowerShell command to get the hash from the source and destination server to visually validate.

As you can see the file hashes match from the source and destination. See this TechNet article for more options and switches.
http://technet.microsoft.com/en-us/library/dn495042.aspx

Step 6: Create the Replication Group

Now we are getting down to actually creating the replication group. Using the DFS Management Interface is easy enough but will not allow for cloning the Replication database because you have to add both members at the time of the creation of the replication group. The reason we want to clone is that with the 8.1 million files initial synchronization will take a really long time while the servers compare and exchange metadata and files. So we will create the replication group on FS01.

Create the Replication Group by running this command

Create the replicated folder by running this command

Add FS01 as a member of the replication group

Set the DFSR membership properties including the path of the folder to be replicated

Refresh the DFS Management console and the new replication group and replicated folder will be there

Now I am updating the config from AD by running the PowerShell command Update-DfsrConfigurationFromAD

Before we go to step 7, we need to wait for event 4112 in the DFS Replication log. That event will let us know that we are done and ready to export the DFS Replication database.

Step 7: Export a clone of the Database

First we will need a place to store the clone, so we will create a new folder

Running the following command will export the database:

When the export completes, a message similar to this will be displayed

Step 8: Copy the Clone to FS02

Running Robocopy with the command
Robocopy C:\Data\DFSRClone \\FS02\C$\Data\DFSRClone /B

Step 9: Import the Clone

On FS02 run the following command to import the clone from FS01

This will take a bit as the Export was 3.3 GB. Either wait for the command to complete, or check the DFS Replication event log for Event 2404 which indicates the import is completed.

Event ID 2416 in the same log will give you status update information while the import is going on, usually about 4 events a minute.

Step 10: Add FS02 to the Replication Group

In PowerShell on FS02 Run the following 3 commands

Add-DfsrMember –GroupName Corpdata –ComputerName FS02

Add-DfsrConnection –GroupName Corpdata –SourceComputerName FS01 –DestinationComputerName FS02

Set-DfsrMembership –GroupName Corpdata –FolderName CorpData –ContentPath C:\Data\CorpData –ComputerName FS02

Wait for event 4104 in the DFS Replication log to know when this has been completed

Step 11: Test Replication

Ok now that DFSR is setup let’s validate that everything is working as expected.

In DFS Management, Select the Replication group on the left pane and Select Create Diagnostic Report in the Action Pane.

On the Diagnostic Report Wizard Select Propagation Report

Click Next

On the next screen select the server and folder then click next

On the Next page Click Create

View the results then Close the wizard.

Give some time to pass, a couple minutes or so, then rerun Diagnostic Report Wizard – This time select the propagation report.

Go through the wizard and view the results. A health report is also a good way to monitor health of the replication group.

Additional tests to perform

Test 1: Open one of the text files and modify the contents, validate that change replicates to the other server.

Test 2: The final test would be to create a new folder and a new file in that folder, allow some time to pass then check the other server and validate the data has replicated.