New DFSR Data Restoration Script

re: New DFSR Data Restoration Script

NedPyle [MSFT] — Thu, 14 Oct 2010 13:14:45 GMT

You need to run it with cscript.exe restoredfsr.vbs. Otherwise it will use wscript and prompt.

re: New DFSR Data Restoration Script

MicahRomo — Thu, 14 Oct 2010 01:19:30 GMT

Hi Ned,

Is there a way to suppress the OK prompts with the restoredfsr.vbs script?

I thought the /I switch took care of this but I still get a prompt.

Thank you,

re: New DFSR Data Restoration Script

NedPyle [MSFT] — Mon, 11 Oct 2010 13:29:33 GMT

It sounds like you have a typo in your edits. Please paste this part of your script in here:

'=======================================================================

' 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"

objXMLDoc.load("C:\your_replicated_folder\DfsrPrivate\yourManifest.xml")

' Change path to specify location of source files

' NOTE: this path DOES have a trailing backslash

' Example 1: "C:\data\DfsrPrivate\ConflictAndDeleted\"

' Example 2: "C:\data\DfsrPrivate\preexisting\"

SourceFolder = ("C:\your_replicated_folder\DfsrPrivate\preexisting\")

' Change path to specify output folder

' NOTE: this path DOES NOT have a trailing backslash

OutputFolder = ("c:\dfsr_repair_tree")

'========================================================================

Mine will look a little different than yours, I updated this text to be more explicit

re: New DFSR Data Restoration Script

danielbarnes — Mon, 11 Oct 2010 01:04:39 GMT

Hi,

great script, however i am running into some trouble.

I think it may be related to xcopy on windows 2008.

i have tried manually running one of the lines from the script output.

eg.

XCOPY "(source full path and filename)" "(destination full path and filename)" /Q /H /R /X /C /Y

and xcopy responds:

Does (destination full path and filename) specify a file name or directory name on the target (F = file, D = directory)? ?

so it appears xcopy isn't copying my files because it is unsure if they are files or folders...

Any suggestions?

changing to robocopy won't work coz it copys folders

and copy is too basic, it won't copy some of the needed information.

re: New DFSR Data Restoration Script

Keith Sumlar — Wed, 07 Apr 2010 20:13:12 GMT

It appears after looking at the properties of files in preexisting, the size was due to the preexisting being populated on different occurrences of the server doing an "initial sync" over the time the DFS has existed. That would explain why the script doesn't result in the same amount of data as the preexisting folder. What isn't clear is where the data that was moved in this most recent sync ended up. I suppose that is a question for whoever we talk to after creating a ticket.

Thanks for all of your help. It has been invaluable.

-Keith

re: New DFSR Data Restoration Script

NedPyle [MSFT] — Wed, 07 Apr 2010 19:41:08 GMT

I don't need the folders you see in the manifest but are explained (these have the 14 attribute you mentioned before)- I need some folders that do not restore at all. I need to see if they are mentioned anywhere in the path of the manifest.

If not in the manifest, not going to be restored. Simple as that.

I am out until next week. Please open a support case in the meantime to get a resolution here.

re: New DFSR Data Restoration Script

Keith Sumlar — Wed, 07 Apr 2010 19:04:45 GMT

here are some paths. sorry about overlooking your instruction

\\.\D:\DFS\FSHNShare\Personal\fayedong\My Data Sources

\\.\D:\DFS\FSHNShare\Personal\plawecki\My Data Sources

\\.\D:\DFS\FSHNShare\Personal\tcumming\My Data Sources

\\.\D:\DFS\FSHNShare\Personal\helferic\Email Archive2.pst

re: New DFSR Data Restoration Script

NedPyle [MSFT] — Wed, 07 Apr 2010 18:24:37 GMT

No, they don't have to be the same - look closely at the manifest. It typically refers to FOLDERS, not files. It also only refers to the base folders and files in the PE folder - the subfiles/folders are not referenced as they are implied within base folders.

It's much more likely that someone deleted the data. Please follow my previous directions - I am about to be gone until next week so you only have about 30 minutes for me to figure this out before I leave. Otherwise you must open a support case.

re: New DFSR Data Restoration Script

Keith Sumlar — Wed, 07 Apr 2010 18:15:53 GMT

I did a dir /b on the preexisting directory and piped the results to a file. There were 106603 lines in the resulting document indicating just that many items at the root of preexisting. I then counted the number of entries in the manifest and came up with 2089 items. I have a feeling these numbers should be the same but aren't. We aren't missing data before a certain date, more like data created after a certain date. It seems that there aren't any items created between Feb. 9th and March 30th that exist in the preexisting folder. So despite users being able to access their data via the DFS all the way up to when the initial sync happened on March 30th, the data created after Feb 9th was either not logged in the manifest and moved or simply lost by the DFS somehow. Is it possible that the data somehow was sent upstream to the staging folder of the upstream server then removed from the downstream server (as if somehow the intial rep changed directions for some amount of time)? Is there any way to peek into the staging files to figure out what files or parts of files are there?

re: New DFSR Data Restoration Script

NedPyle [MSFT] — Wed, 07 Apr 2010 17:19:19 GMT

The other explanation would be that someone has deleted a preexistingmanifest and it was created by the service later. If this is Win2008+ then the manifest could have been corrupted by a disk issue - if so, DFSR would have recreated it. That would only explain a gap where everything prior to X was not in the manifest.

I have no explanation for your manifest right now, never seen this before. If it was as easy to run into as your theory, I'd suspect we would have seen it at least a 100 times in 5 years. Anything's possible though.

Please send me the original path of a few folders that are now in PE that are not restoring with the new script, so I can compre them to your manifest file.