3

I am currently migrating from a Windows Server 2003 R2 Standard to a Windows Server 2008 file server.

I want to do a "soft" migration by using dfs replication.

Now I am wondering what is the best solution to do this

a) one replication group per share

b) a single replication group that replicates all shares

Jürgen Steinblock
  • 316
  • 1
  • 4
  • 16

2 Answers2

4

A couple clarifying questions:

  • How much data are you migrating (# of files and total size)?
  • Do you plan on keeping the replication active following your migration, or is it a one-time transfer?

Assuming you really do want to use DFS migration, I would use a single replication group. This reduces the complexity, chance for problems, and the amount of size required for staging files.

That being said, if this is a one-time transfer and if these servers are on the same LAN, I would run this command from your new Windows 2008 server instead of using DFS for this:

robocopy "\\oldserver\share\" "D:\newservershare" /MIR /NDL /NFL /MT:2

This will start a multi-threaded mirror of your old share to your new share, and it will be much more efficient than DFSR on the LAN. Run it once to get the majority of your data, and then whenever your scheduled migration is, run it again to get any changes (that's what the /MIR is for).

This way your second run of robocopy will be very fast, and you can cut over.

Also, if you're not already using a DFS namespace for these shares, I highly recommend you start now with this migration. It will make any future ones a breeze, as you can simply change the folder target with no change on your user's part.

Update #1:

In light of your first comment, I would still recommend pre-seeding for DFS with the following excellent blog post written by Ned Pyle with the DS Team at Microsoft: http://blogs.technet.com/b/askds/archive/2010/09/07/replacing-dfsr-member-hardware-or-os-part-2-pre-seeding.aspx

Follow the Robocopy instructions, as this will make the initial replication MUCH faster.

I would still recommend using a single replication group for simplicity, unless your shares containing the 1TB of data are not grouped under a parent folder that can be replicated in whole.

Jeff Miles
  • 2,065
  • 2
  • 19
  • 27
  • I agree. Robocopy seems like the most efficient and expedient way to do this for a one-off migration. – joeqwerty Sep 20 '11 at 14:03
  • Yepp, robocopy is great. But I want to migrate 1TB of data from different drives to one big share on the new server. After migration is done, I want to keep the old server as an "cold standby server" with disabled dfs shares but enabled replication so I only have to reenable the shares if the main server has a problem. – Jürgen Steinblock Sep 20 '11 at 14:15
  • Updated answer with additional information. If you are using cold-standby, don't disable the share, rather disable the folder target referral within DFS. – Jeff Miles Sep 20 '11 at 14:32
  • By the way, for migration (and not backup) with robocopy you should include the `/SEC` and `/SECFIX` switches otherwise you loose your file/folder permissione: http://blogs.technet.com/b/filecab/archive/2008/07/31/robocopy-mir-switch-mirroring-file-permissions.aspx – Jürgen Steinblock Sep 20 '11 at 14:37
  • That link is out of date, and the proper robocopy command is listed in my link in Update#1 of my answer. /SEC and /SECFIX aren't necessary anymore. – Jeff Miles Sep 20 '11 at 14:41
  • Thats a great blog post. thx a lot. – Jürgen Steinblock Sep 20 '11 at 14:51
2

If you're just doing this for a migration, I don't see a reason not to just use one large replication group. It's not the most flexible solution, but it's fine for a one-shot migration and it's simpler.

MDMarra
  • 100,734
  • 32
  • 197
  • 329