DFS-R Replicating only one way. Replication on outbound stuck on arrival pending

Question

I have TWO Windows 2012 r2 servers with identical paths and drive names (not on purpose).

If I create a folder on server A the folder instantly replicates to server B. However If I create a folder on server B it does not replicate to server A.

I have run DFS Diagnostics and it does not find anything wrong. However when I run a propagation test from Server B to Server A I don't get a error. Just a Incomplete test alert.

I have a test that is 6 days old (file replication test). The Replication status for that test file is stuck on "Arrival pending".

Keep in mind deletions from Server A to B replicate fine. Anything that B to A does not work.

Everything is setup correctly as far as i know and there are no errors.

Data is at around 6TB that was preseeded before hand. The replication is between a File server cluster and a single server. The DFS relationship has been up for over 3 weeks.

Ideas?

Answer 1

There are many reasons why replication can fail. Unfortunately symptoms alone don't help here.

Can you please review the information at http://blogs.technet.com/b/askds/archive/2009/04/09/dfsr-debug-log-series-wrapup-and-downloadable-copies.aspx and then update the question with any specific debug log entries you see from both servers?

The blog is a little out of date given that you are using 2012 R2 but it will still help.

Please provide entries specific to this folder only.

Alternatively I suggest doing the following to re-initialise B using A.

1. Backup B. This is necessary if you have end users who committed changes on B but don't realise it hasn't replicated to A. The below steps will revert all data on B to versions as of A which might cause some "data loss" if B changes have not been backed up.

2. Disable B as a member for that replicated folder(RF) using the DFS console on B. This updates the configuration for the topology on a DC nearest to B (or rather one B is using now).

3. Do a "dfsrdiag pollad" on B to make it read the topology changes from AD

4. Run "wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state". Ensure the folder does NOT appear in the list. (edited: fixed wmic namespace).

5. Look for an event 4114 indicating that folder has stopped replicating

6. Optionally also look in the debug logs for any entries by ldbmanager::deleteidrecords which indicate database from been cleaned up.

7. Re-enable the B member using DFS console on B.

8. Do a "dfsrdiag pollad" on B to ensure it picks up the changes

9. If A and B are in different sites and you end up disabling/enabling B before A realises, then you need not do anything on A. Else you may have to also take into account Ad replication latency and wait for AD changes to converge to DC used by A. Then do a "dfsrdiag pollad" to ensure it picks up each topology change you do (i.e. the disable and then the enabling of the member).

10. Run "wmic /namespace:\root\microsoftdfs path dfsrreplicatedfolderinfo get replicatedfoldername,replicationgroupname,state". Ensure the folder eventually gets to state 4. More details of state are here http://blogs.technet.com/b/filecab/archive/2008/10/27/how-to-check-if-the-initial-replication-was-completed-successfully.aspx

If this still fails to fix, then debug log entries are required to give a more specific answer.

I'm afraid I wont be able to do a back and forth repeatedly answering questions based troubleshooting. I suggest raising a case with Microsoft support if you need further help. Else others on the site may have the time to help you.

Answer 2

Did you happen to create these volumes by cloning virtual disks or entire VMs without sysprepping? This sounds like the drive serial number or volume serial number are not unique between the two servers, which will cause DFS-R to fail.