Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

NedPyle [MSFT] — Sun, 27 Feb 2011 18:05:51 GMT

Ah. If you had not mentioned all the Novell red herrings the first time I could have skipped the support case bit. :)

Preseeding after having already created and started initial sync an RG is not something I can recommend, as the fencing of data behaves very differently and I'd need to test this carefully.

The other idea of recreating the RG at this point is good though. Using a USB drive is a good idea as well, as long as you mean a USB enclosured drive formatted with NTFS and not thumb drives formatted with FAT32.

If you are in a "do-over" phase here also, I really recommend using Win2008 R2 on both servers. The performance difference with DFSR will be immense.

And 30GB in three weeks is unnaturraly slow unless this network is quite constrained. That's only 60MB an hour or 128Kbps bandwidth. Ensure you are not artificially bottlenecked:

blogs.technet.com/.../common-dfsr-configuration-mistakes-and-oversights.aspx

blogs.technet.com/.../tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx.

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

EricMan — Sun, 27 Feb 2011 16:24:18 GMT

OK, what about this. Since I have already created the replication group using the new data on the Windows 2003R2 server at the branch office (about 160GB) and it has actually been synching for about 3 weeks now and I have about 30GB at corporate office. Obviously this will take about 2 more months to complete, to long. So what If I get a 'copy' of all the data from the branch office onto a USB drive, ship usb drive back to my corporate office, then at that point can I a) copy the data to the existing replication group or b) start fresh with a new replication group and copy the data. By the time I receive the USB drive the data will be a couple days old but it would seem that this should sync rather quickly. Will this process work? I would think this data has existing hashes and DFSr would understand and be able to match files/folders up properly. Seems this is a perfect "Pre-Seeding" scenario.

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

NedPyle [MSFT] — Fri, 25 Feb 2011 21:56:38 GMT

Not a "little more unique"... a TON more. :)

Please open a support case. We have no way here to look at or evaluate Novell file servers so we would need to try all this out in your environment directly. We'd need to find a tool that could copy the files without changing hashes from Novell to Windows. Which may not actually be possible considering they are two different files systems.

You are risking all your data (and your job) trying to do this yourself in the dark. Please don't skimp on a case.

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

EricMan — Fri, 25 Feb 2011 21:41:12 GMT

My situation is a little more unique. We have a remote site which replicates to our corporate office via old RSYNC and these are both Novell servers. Yes, we are still on Novell… We recently moved the remote site to a Windows 2003 R2 server and, like other Windows Server based remote sites, we will use DFSr to backup the data nightly. So my Pre-seeded data is from a Novell server. I want to just “copy” this data to the Corporate (Hub) server and then create a Replication group using this pre-seeded data. There is only two servers in the replication group, the Branch office and our Corporate office and the data flows from Branch  to Corporate for backups only. So can someone help me understand any additional steps I need to perform to get this replicating properly. The Pre-seeded data I have is about 160GB and is only a couple days old from the branch office, so I assume, if I can get DFSr to see this data correctly, it will not have to replicate all the data back over a slow WAN link. I’m also fearing that the actual “updated”(newer) file at the branch office will somehow disappear or move to some system folder, like ‘conflict and resolution’ folder if not done right.

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

NedPyle [MSFT] — Tue, 22 Feb 2011 18:06:17 GMT

Define a "large amount". :)

Tha sounds like overkill, especially since it's new data that no one has ever accessed before, so they won't mind it not being on both servers for awhile...

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

David K Welch — Tue, 22 Feb 2011 17:34:05 GMT

Great article Ned. What about a process where we need to add a large amount of data to an existing DFS Replication Group? Do we remove and re-create the replication group and pre-seed it?

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

NedPyle [MSFT] — Fri, 18 Feb 2011 23:02:14 GMT

Indeed it has! But you already knew that as a frequent AskDS subscriber...

blogs.technet.com/.../sp1-and-directory-services-what-s-new.aspx

;-P

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

Justin Bouska — Fri, 18 Feb 2011 22:58:47 GMT

FYI, the updated 2008R2 Robocopy has been included in 2008R2 SP1.

www.microsoft.com/.../details.aspx

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

NedPyle [MSFT] — Mon, 17 Jan 2011 19:22:50 GMT

Hi,

The delta of changes will replicate to the new server. The backup is mainly to cover the 99% of files that won't be changing and save you that replication.

re: Replacing DFSR Member Hardware or OS (Part 2: Pre-seeding)

MARKKUNZ — Mon, 17 Jan 2011 19:20:18 GMT

Your article is excellent, thank you. In our environment, a few files will change after backing up. I am confused. Can I still preseed? How will DFS-r handle the changes?

Thank you.