Understanding DFSR conflict algorithms (and doing something about conflicts)

Understanding DFSR conflict algorithms (and doing something about conflicts)

  • Comments 5
  • Likes

Ned here again. I’m frequently asked to explain the DFSR conflict algorithm – i.e. what happens when files are created or modified on two servers before replication takes place. What we don’t document well is that there are actually three conflict algorithms and they all behave quite differently. I am breaking these out into scenarios for easier understanding.

(Note: updated 3/25/2011 with some newer behaviors)

Scenario 1: Brand new files in initial sync with different versions of the file on each server.

  • Two servers, A and B
  • Both have a folder called c:\rfdata
  • Folder contains a file called salespitch.pptx
  • On server A, salespitch.pptx is dated July 2009. On server B, salespitch.pptx is dated October 2009 and was modified by a user very recently.
  1. I setup a new Replication Group.
  2. I make c:\rfdata the Replicated Folder.
  3. I make Server A the Primary Server.

Result: salespitch.pptx from A (dated July 2009) will now exist on both servers. The October version will be conflicted on B and it will lose the conflict.

Explanation: When setting a server as Primary, it wins all conflicts no matter what. This is the so-called “Initial Sync conflict algorithm”.

Scenario 2: Existing files that have been replicated previously and are now being modified on two servers before replicating.

  • Two servers, A and B
  • Both are in an existing Replication Group (not performing initial sync) with a replicated folder pointing to c:\rfdata
  • Folder contains a file called salespitch.pptx
  • Replication is latent (in my test, I disconnected network cable from Server A)
  1. I modify the salespitch.pptx file on both servers. On Server A, I modified salespitch.pptx last.
  2. I plug the network cable back in to allow replication to resume.

Result: The file I modified last (i.e. the newest file with the latest UTC time stamp) replicates from A to B. B loses the conflict and his older copy will be conflicted.

Explanation: This is the classic “last writer wins conflict algorithm” that is usually described for DFSR.

Scenario 3: New files that were created on both servers before replicating, but initial sync is not happening

  • Two servers, A and B
  • Both are in a Replication Group with a replicated folder pointing to c:\rfdata
  • Replication is latent (in my test, I disconnected network cable from Server A)
  1. I copy an old file to both server A and B – so this file is “new” to DFSR on both servers.
  2. I modify one file on server B.
  3. I plug the network cable back in on A.

Result (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 without KB2450944 installed): The old file on A is replicated to B, and B loses the conflict.
Result (Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 with KB2450944 installed): The new file on B is replicated to A, and A loses the conflict.

Explanation: This was the only time an older file would win and this was the so-called “New to DFSR file conflict algorithm”. The reasoning was that when it came to two files being created, the oldest one was likely the most important as it has been in use the longest. But this turned out to be too confusing and likely to cause other issues, so it was changed to match the more consistent "last writer wins" behavior in a hotfix later.

That’s all well and good. But how do I get my conflicted files back when the “wrong” one wins?

You have a few options here:

  1. Use DPMData Protection Manager provides on-the-fly backups of files and near-line recovery. This way your odds are highest that the latest versions of the file have been backed up.
  2. Use Volume Shadow Copies – You can configure automatic backups of files on your DFSR servers. Then when users delete or conflict files, the data can be easily restored. With a little training, your users can even restore files themselves and not have to spend time with the help desk. Note also that if you are still running XP or (Dog forbid) Win2000, you need to install a client to let users restore their own files. See TechNet and Windows Help for configuring this on a per-OS basis and make sure you read through the best practices info. VSC does not replace regular backups!
  3. Use backups – Windows Server Backup, NT Backup (if still on Win2003 R2), or 3rd parties should be used to back up
    your data every day. This way no matter what, you can always get back to yesterday’s copy of a file.
  4. Use the restoredfsr.vbs script – Unsupported, as-is, and provided without warranty, this script may be your only hope if you have no created backups and shadow copies. Use it at your own risk. The script is hosted on Code Gallery (http://code.msdn.microsoft.com/restoredfsr). As always, the script requires you to edit a few variables before running – see the script for how-to documentation. You run it with:

    CSCRIPT.EXE restoredfsr.vbs

Hopefully this makes more sense now.

- Ned “the mediator” Pyle

  • Hi Ned "the oracle" Pyle =)

    if you still have in mind to use XCOPY for copying files and folders within your restoredfsr.vbs , please have a look at the "File Attribute Constants":

    msdn.microsoft.com/.../gg258117%28v=VS.85%29.aspx

    You will find out, that:

    1) all values in *Manifest.xml column "Attributes" are file attribute constants

    2) these value strings are ment as combinated hex values

    3) any senseful combination of these attribute values are possible and therefore should be handled by your script

    4) attribute combination "11" in your vbs is definitely wrong (it is a read-only folder, not a file)

    So, to get a decision for "FileOrFolder" you only have to calculate, if the Bit 6 [0x20] is set [1] in the attribute value, because this indicates a folder. If it is not set, the test will indicate a file.

    I hope this will help you to make your vbscript pretty perfect and I'd appreciate to see a new version :D

    I also hope, that sometimes a GUI would be available by Microsoft for restoring files/folders from the DFSRPrvate folder to its origin location ;)

  • Little correction to myself, because I've counted the wrong bit ^^

    'So, to get a decision for "FileOrFolder" you only have to calculate, if the Bit 5 [0x10] is set [1] in the attribute value, because only this bit indicates a folder. If it is not set, the test will indicate a file.'

  • Thanks for the comments. You're right, but the 11 line will never be hit, as there is no such thing as a read-only folder.

    As far as the rest: eh, of course. These points are all obviously well understood. The problem is not lack of understanding, it's that vbscript didn't have an easy way to handle this when I wrote the script in a few minutes years ago for a critsit. If you would like to write code that can interpret these values and provide it as a sample, I'll be happy to integrate it.

  • Hi Ned,

    I've found a nice site:

    msdn.microsoft.com/.../ebkhfaaz(v=VS.85).aspx

    2 blocks are interesting and could be used for handling all combination of file attributes:

    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    ' Constants returned by File.Attributes

    ''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

    Const FileAttrNormal   = 0

    Const FileAttrReadOnly = 1

    Const FileAttrHidden = 2

    Const FileAttrSystem = 4

    Const FileAttrVolume = 8

    Const FileAttrDirectory = 16

    Const FileAttrArchive = 32

    Const FileAttrAlias = 1024

    Const FileAttrCompressed = 2048

    Function ShowFileAttr(File) ' File can be a file or folder

      Dim S

      Dim Attr

      Attr = File.Attributes

      If Attr = 0 Then

         ShowFileAttr = "Normal"

         Exit Function

      End If

      If Attr And FileAttrDirectory Then S = S & "Directory "

      If Attr And FileAttrReadOnly Then S = S & "Read-Only "

      If Attr And FileAttrHidden Then S = S & "Hidden "

      If Attr And FileAttrSystem Then S = S & "System "

      If Attr And FileAttrVolume Then S = S & "Volume "

      If Attr And FileAttrArchive Then S = S & "Archive "

      If Attr And FileAttrAlias Then S = S & "Alias "

      If Attr And FileAttrCompressed Then S = S & "Compressed "

      ShowFileAttr = S

    End Function

    And just for information:

    I had a view on a PreExistingManifest imported into Excel and I've seen a lot of other combinations of file attributes not handled in your script...so, I hope, this snippets will help for going sure with the script :D

    ---

    And hey, I see all:

    "Now maybe someone can convince him to write a PowerShell alternative to restoredfsr.vbs."

    ( blogs.technet.com/.../get-dfsrbacklog-powershell-script-available.aspx )

    PowerShell...tztztz :P

  • That wasn't the route I took, but I appreciate the link. I rewrote the script last night and now it handles files versus folders in a foolproof manner. Thanks for bugging me to finally square it away for good.