Microsoft's official enterprise support blog for AD DS and more
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.
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.
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
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:
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":
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  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  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.
I've found a nice site:
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
Attr = File.Attributes
If Attr = 0 Then
ShowFileAttr = "Normal"
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
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."
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.