Microsoft's official enterprise support blog for AD DS and more
Hi, Ned here. Just a quick heads up - there is a new DFSR data recovery script posted below. This allows you to restore data from the ConflictAndDeleted or PreExisting folders within DFSR, primarily during disaster recovery. As always, we prefer you use your backup system to do this, as the script is 'at your own risk' and unsupported.
The latest script is now hosted on Code Gallery: http://code.msdn.microsoft.com/restoredfsr
Well that gallery is kaput. Now hosted from here.
This old script is really gross, I recommend instead using our new Windows PowerShell cmdlet Restore-DfsrPreservedFiles instead. You can restore from 8.1 client if you install RSAT, or from a WS2012 R2 server. Can either run locally or just map a drive to \\dfsrserver\h$ or whatever the root drive is, then restore.
Take a look at http://blogs.technet.com/b/filecab/archive/2013/08/23/dfs-replication-in-windows-server-2012-r2-restoring-conflicted-deleted-and-preexisting-files-with-windows-powershell.aspx for steps on using this cmdlet.
Remember, this script must be run from a CMD prompt using cscript. Don't just double-click it.
The script also requires to edit three paths (your source files, a new destination path, and the XML manifest you are calling) . If you fail to edit those the script will exit with an error:
'=======================================================================' Section must be operator-edited to provide valid paths'=======================================================================
' Change path to specify location of XML Manifest' Example 1: "C:\Data\DfsrPrivate\ConflictAndDeletedManifest.xml"' Example 2: "C:\Data\DfsrPrivate\preexistingManifest.xml"
' Change path to specify location of source files
' Example 1: "C:\data\DfsrPrivate\ConflictAndDeleted"' Example 2: "C:\data\DfsrPrivate\preexisting"
SourceFolder = ("C:\your_replicated_folder\DfsrPrivate\ConflictAndDeleted")
' Change path to specify output folder
OutputFolder = ("c:\your_dfsr_repair_tree")
- Ned Pyle
Ah good - so does the C&D folder actually contain some of the files referenced in the XML file?
Yes it does. And I tried another folder. At first it didn't look like it restored. Then I checked that pre-existing folder and lo and behold, the missing database files were there. I could be on to something here.
All the other folders seem to be doing OK. My life and job have been saved! Thank you!!!!!
Excellent. Have a great day.
Hello, everyone Below you have a compilation of some very interesting blog posts from AskDS and Extreme
We’ve been at this for over a year (since August 2007), with more than 100 posts (127 to be exact), so
Do you know of any issues with your script restoring data from server 2008 dfsr data?
I've used your script successfully in the past on 2003 r2 networks. I'm now on a native 2008 network and am needing to restore one of the replicated folders.
Using the script, the folder hierarchy is restored, but no files are restored. The files are indeed in the ConflictAndDeleted folder I am using as the source, and the Manifest appears to have all the files listed in there.
I receive no errors - but files clearly are not copied back to the restore folder.
No issues that I am aware of specific to 2008, but there are definitely some scenarios where the script won't work. :-/
Use the email contact form on the website to send me a mail and when I reply, you can can send me your XML file. I'll take a look.
I have a 2-node DFS set up using 2k3 R2. I had the node in sync and they were perfectly happy for quite some time. I recently moved our equipment to a new server room and subsequently noticed the DFS was no longer replicating (one node was actually expecting initial rep). I set the primary flag on one of the nodes and it caused the data in the other node to be moved to preexisting. I ran the recovery script but it appears some data that is missing wasn't recovered by the script. Is there some point in replication where a file could be removed from the DFS and not yet have been written to preexisting?
When you moved your equipment was the only change the physical move? DFSR wasn't disabled, reconfigured, changed, etc in any software way?
That version of the script is pretty old and ratty, and has some bugs that can miss data with esoteric attributes. I attached a better one to the article above.
Thanks for the prompt reply!
When the equipment was moved the public IPs of the servers were changed and everything was shutdown. Once everything was in it's new location everything was started together and seemed to work fine. A week later, I checked the DFSR logs in preparation for adding a 2k8 node to the DFS to transition off of 2k3. The logs indicated communications issues between the two existing servers and that the node that everyone gets referred to first is waiting for initial replication. I then ran dfsradmin to check the status of the isprimary flag which was no for both nodes (as it should have been). In an attempt to get replication going I mistakenly set the other node to primary. The next morning I was faced with as mess as many files were moved to preexisting and since it was the node everyone was getting referred to, I got reports of data missing. I then stopped the dfsr service and ran your script to recover as much of the moved data as I could. After the script finished it seemed as if there were still several files still missing. I am wondering how could anything be missing from both the preexisting folder and the dfs. Unfortunately backups were being run from the node that wasn't first in the referral list so the missing data was never backed up (due to the interruption in replication). I searched the preexisting manifest for some of the known files and didn't find anything. The actual preexisting folder is so large it takes forever to perform any kind of operation on it (searching or otherwise). Is there any way data could have not been copied to preexisting before being removed from the dfs? Are the files tied up in the mysterious staging folder?
Nothing could be missing unless it happened outside of DFSR's knowledge - preexisting is pretty simple and unsophisticated. It has no quota, no deletion mechanism, no ties to staging. Any files that do not exist on the upstream but do exist on the downstream server during initial sync get moved into PE, that's it.
If you know of several files that are missing, and you know their path info, you can examine the DFSR debug logs to see more about what happened.
Hmm, it appears that the dfsr logs have maxed out and only extend back to the 1st. We are making a second pass through the preexisting folder using the new script. Is it possible for files to be in preexisting but not in the manifest? We have certainly confirmed that there are several files missing from several different folders and don't know how the files are on neither server nor in the preexisting folder.
I just want to give you many thanks on the help you have provided.
Remember that the manifest may only contain *folder names* for some paths, so not all files will be referenced in the manifest. Usually the only time that they do not reconcile is if someone manually deleted files in PE, but still referenced in xml.
I see. Well, it appears the new script resulted in a folder that is only about 500GB compared to the 2TB of the preexisting folder. Is there something we can do about all the files/folders the script seems to be skipping? Are there perms that I need to modify the script to add cases for or can the script be modified to strip out the perms to files\folders it can't retain the perms for?