Use DFS Replication in Windows Server 2008 to Migrate Data?

If you are just migrating the server and will be shutting down the old one I would use robocopy. You will be able to keep all of your permissions using robocopy to.


http://technet.microsoft.com/en-us/library/cc733145(WS.10).aspx

Another decent tool is richcopy   http://blog.joeware.net/2009/04/08/1632/

I also really like secure copy and have used that in the past...but it is not free.

Thanks

mike

My goal is to make it seamless to the end users, so that I don't have to modify logon scripts...

I agree with the previous post. DFS isn't a good utility for migration of data. In past experiences, it's difficult to get a full replication, takes a vast amount of time and lacks the tools to verify that all the data has been moved. It's good for keeping things in sync, as a fault tolerance solution, but not good for migrations.

RoboCopy is just one of the solutions you can use, however, I suspect that you want to be able to keep data in sync for the migration period which is why you were looking in to using DFS. I've used a product called "Allway Sync"  http://www.allwaysync.com/ for a few migrations now. It will facilitate the bulk data move, while the systems are live & through the use of either a 1-way or 2-way sync, will allow you to keep both systems synchronized, till all your users have been moved to the new file server. It's a cheap ($20) piece of software which is very flexible in how it can be configured & allows for full logging, so you can be sure you haven't lost anything in the process. It can be run either from the source or target server, or a workstation. The only snag at times, can be permissions (if Allway Sync can't access it, then it can't copy it), but again, the logs will identify any permissions issues, so they can be fixed.

Are you using DFS now?

If not you will need to change your login script unless you name the new server the same as the old when you make the switch.

You could just modify the login script and keep the same drive mapping on the end users computer and just change the server anme where the sahre is located.

You're gonna have to change drive mappings, logon scripts, etc anyway.  When you create the DFS namespace users will access it using the form \\yourdomainname\theDfsNme - so at the very least you'll need to change that.

Once that's done, however, you can re-arrange the DFS onto different servers etc without ever needing to modify the scripts again.

not using DFS now -- I want to implement DFS so that I can call the namespaces the same as my current 2003 server...  

so \\2003\file

after DFS is turned on will send the request for \\2003\file to the DFS server, which will then direct it to the appropriate server where the file resides.

Using DFS will require you modify login scripts. The UNC would need to change from \\[servername]\[share], to \\[domainname]\[dfsroot]\[share]

If you use any of the products mentioned above to copy the data over (ensuring you also get the permissions copied too), then you can shut down the old server, bring up the new one & modify DNS so that the old server name points to the new server.

Obviously at some point you'd want to either rename the new server to the same name as the old one, or modify your login scripts (since leaving the alias in DNS for long term would be messy and possibly confusing down the road, but it would take the pressure off the migration.

tgerbert -- thanks -- this is my first experience with DFS... so what would you recommend?

1. Install DFS on what, the new 2008 file server?
2. Create namespaces \\domain\folder etc... and point them to the targets
3. Change logon scripts to match the new naming structure
4. Now -- the trick is, how do I get the data over from 2003 to the 2008 server seamlessly...?  what I was thinking is start a copy which will take maybe 2-3 days, and at the very end syncronize changes that occured since the copy finished?  Replication would be great, but again, my current server is 2003 SP2 not R2, and I am hesitant to update it because it's been crashing when windows patches are installed (it's 8 years old).

The best way to do this would be to install DFS, create a new root i.e \\domain\root name. In this root have 2 targets one that points to the 2003 server i.e \\oldserver\fileshare. Make referrals on this one active. The add another target \\newserver\fileshare (the 2008 box) make referrals on this one inactive. Then configure replication and allow it to complete.

Once the process has finished, switch OFF referrals on the 2003 box, and ON on the 2008 box. Seamless to the users. As long as they are using the DFS root in advance.

To do the initial data migration and then final sync, here's how you use robocopy. Use DFS for the new paths as woolnoir and others describe.

"robocopy source destination /sec /mir /create" for the first pass which creates the directory stucture to minimize directory fragmentation

"robocopy source destination /sec /mir /r:1 /w:1" to copy over all the files. Run it as ofen as you need to. It will only copy the changes.

Why use robo copy ? Dfs will do the initial sync just fine ? Or are you just suggesting an alternative?

awesome tips everyone -- I won't be able to use DFS replication after all because it requires 1) my AD schema to be sysprepped for R2 and 2) replication partners need to be 2003 R2 at the minimum -- my current file server is 2003 SP2 -- if I were to extend my schema, is there a way I could still use DFS replication even though the files live on a non-R2 server without DFS?  

i meant adprepped not sysprepped - sysprep would suck on a dc lol

Since you aren't on Windows 2003 R2, you don't have DFS-R, you have FRS for replication, which would really suck, and isn't supported under 2008 for replicating files.

Robocopy really is the answer.

You should be able to run adprep whenever you want, but I would do it and add the Windows 2008 as a DC before you start.

Thanks Kevin, that's what I was thinking but one more question before I close -- why add Win 2008 as a DC before starting robocopy?  Shouldn't I treat the AD schema upgrade to 2008 AD as a totally separate project?  

You can't create domain DFS paths on the new server until it's a domain controller. I also think that it's just better to make the server a domain controller, and then make all of the configuration changes you need. The act of promoting/demoting a domain controller changes local security settings on the server and if you setup things after it's a domain controller, the act of promotion can't break anything.

Kevin,

Please excuse my ignorance, but I'm having trouble following...  I already installed DFS on Server 2008 R2 and created namespaces that published fine to my existing 2003 active directory, and I intend to use this server as DFS namespace server and the new file server.  Do you mean that I can't create DFS paths on the new server unless it's a member of the domain?  

Actually, this doesn't appear to be true at least with windows 2008 server r2... I was able to create a domain root DFS namespace and am able to reference it via \\domain\rootfolder -- even though DFS was installed on a non-domain controller, but a domain member server.

Thanks for leading me on to the right track