3

We have a DFS environment. If we have a 100MB file for example that we put in the DFS share, it will appear very quickly on the destination server at another site even though with the bandwidth available there is no way it could have completely transferred. We believe this is causing our issue since when we then try to delete/rename the file on the source server it will keep reverting back.

John K
  • 31
  • 1

1 Answers1

0

There are features such as RDC and cross file RDC that allow to optimise the data that needs to be transferred over the wire to replicate these files. If you have near identical files that are already part of the replica set, then this is expected behaviour. See http://technet.microsoft.com/en-us/library/cc773238(WS.10).aspx#BKMK_029 for details.

IMHO this doesnt sound like an easy problem to solve over serverfault. I tend to prefer to steer people in the right direction when the problem seems complex. You will likely need to check if the initial sync has completed, get backlog details in each direction and then dump idrecord details for files to determine and check GVSN to see where they are changing.

There is a lot of information DFSR related on http://blogs.technet.com/askds and on http://blogs.technet.com/filecab that is specific to DFSR troubleshooting.

HTH

maweeras
  • 2,734
  • 2
  • 17
  • 23
  • We have two servers replicating via DFS at two separate sites. They are both running 2003 R2. The root issue is that when we put a file on a server, and immediately try to rename or delete it on the source, it will revert the original back. This seems to happen more so to larger files. I believed the issue was that since it was appearing on the destination while it was still replicating, it was becoming the master file because it kept updating. That way, even if we were to delete the source file or rename it since the destination is still updating it would replicate back the destination file. – John K Nov 14 '11 at 14:40