When you have a few DFS servers, everything seems fairly manageable. Add a few more…Yeah… All good… Get an issue, oh joy! Look at all these servers I need to examine in minute detail!

So I’ll start with an MS Blog that deals with config mistakes

Common DFSR Mistakes and Oversights

Might be a few banged heads on the desk (your own!) when you read some of that!

And put together by my own fair hand, some troubleshooting from the DFSR Management tool and some useful DFSR Diag commands

DFSR Management Tool

Verify topology simply checks the servers are contactable, which is useful, but does not verify replication.

DFS Management includes the ability to run a propagation test and generate two types of diagnostic reports—a propagation report and a general health report:

Propagation test    Tests replication progress by creating a test file in a replicated folder.

Propagation report    Generates a report that tracks the replication progress for the test file created during a propagation test.

Health report    Generates a report that shows the health of replication and replication efficiency.

To create a diagnostic report for DFS replication

Click Start , point to Administrative Tools , and then click DFS Management .

In the console tree, under the Replication node, right-click the replication group that you want to create a diagnostic report for, and then click Create Diagnostic Report .

Follow the instructions in the Diagnostic Report Wizard.

Perform all 3 tests and save the resulting xml/html report file.

DFSRdiag

This is the command line tool for DFSR – useful commands are:

dfsrdiag ReplicationState /all – verbose output

pollad – checks in with Active Directory

List DFS replication groups:

dfsradmin rg list

List replicated folders in a replication group:

dfsradmin rf list /rgname:<REPL_GROUP>

List members of a replication group:

dfsradmin mem list /rgname:<REPL_GROUP>

List the local folders that correspond to replicated folders of a replication group:

dfsradmin membership list /rgname:<REPL_GROUP> /attr:RfName,MemName,LocalPath

Show backlog between 2 members of a replication group:

dfsrdiag backlog /rgname:<REPL_GROUP> /rfname:<REPL_FOLDER> /smem:<SRV_A> /rmem:<SRV_B> [/v]

dfsrdiag backlog /rgname:<REPL_GROUP> /rfname:<REPL_FOLDER> /smem:<SRV_B> /rmem:<SRV_A> [/v]

Using the ‘Replicate Now’ command within the GUI or command line, kicks off replication again but is more used for when you have a schedule and want to replicate out of that schedule, whereas we can use it to tell it to start replication again.

Within the DFSR GUI – choose the Replication group, choose the ‘Connections’ tab and right click the Sending Server (usually you have a specific server that’s authoritative, but you can choose the sending member to be whichever you believe is most up to date and Microsofts black magic algorithm will attempt to resolve any file conflicts) and choose ‘Replicate Now’

A huge problem in DFSR is when you have an issue with Conflicted, Deleted and pre-existing files. Thankfully if you do get a conflict and file loss, they become Deleted…And you can get them back. This is the MS blog on this, but a few years ago when I had to do this, it took a great deal of work. It’s not just about getting the files back – who’s going to know which one they were working on? Or which is the most up to date? You do end up needing end user involvement and for me personally, that was making the data recovered available for a certain amount of time with the users expressly informed that they needed to check it themselves and there was just no way of doing that for them.

Restoring Conflicted, Deleted and PreExisting files with Windows PowerShell