Howto: Migrate file shares, permissions, and user profiles paths in a Windows 2003 domain


I’m in the process of migrating from serv1, a Windows 2003 Domain Controller (DC) to serv2, a new Windows 2003 DC.  Serv1 has approximately 185 student accounts and 5 staff accounts.  Each user has their own shared folder on the server which is defined in Active Directory Users and Computers (ADU&C) user account profile path.  There are a handfull of other shares that need to be migrated as well. 

I decided on the following requirements and stipulations for my migration solution in this particular scenario:

1)  Make an effort to use only freeware or shareware tools whenever possible.

2)  The user home directories (defined by the user profile path) needed to be copied to the new server, but the data inside their home directories was not to be retained on the new server.

3)  I was not going to reshare each folder once it was migrated, so I needed some other method of redefinng the shares on serv2.  I needed the share permissions migrated as well

4)  Existing NTFS  permissions for user home directories needed to applied on serv2.

5)  The user profile path had to be updated in ACU&C from \\serv1\users\%username% to \\serv2\users\%username%

6)  The drive letter location of all the user’s home directories was being changed from c:\users\%username% (on serv1) to e:\users\%username% (on serv2).

I took the time to come up with this methodology since I have to do this type of server migration all the time.  This should also work for migrating from Windows 2000 to Windows 2003.  Here’s my solution:

I initially planned on using the Microsoft File Server Migration Toolkit to migrate from serv1 to serv2, but I found it to be very clunky and not very configurable.  It kind of seemed like it was a migration tool for dummies without any advanced options that would confuse Joe Admin.  I played around with it for about an hour before detrmining it was not the solution for me.

The next path I wandered down was to use Robocopy (with the optional GUI) to copy my \\serv1\users directory to \\serv2\users.  Robocopy is a part of the Windows 2003 Resource Kit Tools, and Robocopy GUI is available from the Technet Magazine November 2006 Utility Spotlight.

Robocopy has a ton of options available, which is why the GUI comes in handy.  I originally planned to copy the \\serv1\users data to \\serv2\users using the syntax found in KB323275, but it never behaved quite as expected.

I tried to execute Robocopy in the following manner (type on all one line), expecting the directory tree structure to copy one folder down (LEV:1) from \\serv1\users, but it only copied the files located in \\serv1\users, but no directories. 

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:1 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

So I changed /LEV:1 to /LEV:2, and it copied the directory structure \\serv1\users\%username%, plus the data in the %username% folder, which was not what I wanted (again, type as one line)

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Robocopy frustrated the hell out of me, so I moved on to try xxcopy.exe, which is very similar to Robocopy.  I briefly perused the author’s web site and saw “freeware version”, so I started working with it.  Not until I received error messages about copying between remote shares did I notice the freeware version of xxcopy.exe was for personal property use only – since I don’t own this network, I was not allowed to use the free version per their licensing agreement – so I needed a new direction once again.

I finally resorted to using the good ole Windows xcopy.exe (see KB 289483 and KB 323007 for usage and options) to copy my directory structure from within the source users directory to the destination users directory:

xcopy *.* /T y:\users

This worked too well – it copied all subdirectories, which is definitely not what we wanted.

I was frustrated with my lack of progress, so I went back to my second robocopy, which copied the correct directory structure, but also copied the files within the directories.

robocopy.exe \\serv1\users \\serv2\users /COPYALL /LEV:2 /ZB /V /FP /W:5 /R:5 /LOG:copy.log

Next I used del.exe from within the \\serv2\users in order to delete all the files (but not folders) within the \\serv2\users\%username% structure:

del.exe *.* /f /s /q

This worked great, but did not remove hidden files.  In order to remove the hidden files, I had to do the following:

del.exe *.* /f /s /q /ah

Now I finally had the correct directory structure on \\serv2\users.  I could move on to copying the share permissions, since Robocopy.exe had copied the folder permissions for me when I used the  /copyall option.

Microsoft’s official method of migrating shares from one server to another is documented in KB125996, which requires a export of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManServer\Shares from \\serv1, and the importing of that resultant .reg file into \\serv2.

That process works great as long as the same drive letters are used on both servers.  In my case, c:\users was the source on \\serv1, which e:\users would be the share location on the destination \\serv2.  If you look at the exported .reg file, it’s not in a human readable format, its a bunch of hex numbers.  I hoped I could do a find and replace using a hex editor to change c:\users to e:\users in my exported .reg file, but that was another huge waste of time.

Finally I came across jv16 Powertools 2007, which I installed on \\serv2.  I imported the .reg file from \\serv1 into \\serv2, then ran the Registry Find and Replace utility, and replaced all instances of c:\users\ with e:\users\.  I rebooted \\serv2, and my 190 (or so) shared folders magically appeared!  Finally, I was making progress!

(As a side note, I recommend supporting the developer of this utility, and will be purchasing the $59 commercial license.  Personal licenses are $29.95.  I will gladly pay the $59 rather than have to recreate each share on \\serv2 by hand.)

Finally, I needed to change each of the user’s profile paths in Active Directory Users and Computers from  \\serv1\users\%username% to \\serv2\users\%username%.  I had no desire to edit each account by hand, so I searched for a solution and came up with ADModify.net, which I was faintly familiar with as an Exchange tool.

ADModify is very intuitive to use.  You’ll need to select the domain and source DC, then make sure the “show only users” check box is selected and “show containers only” in de-selected.  Click the green arrow box and expand your domain, and the list of OUs are displayed.  Expand the OU your users reside in and highlight the users whose profile path you’d like to modify.  The only slight roadblock I came acrosss using this utility was that I had to select my users once again from the right most pane before I could press next.

Once you press next, the familiar ADU&C interface appears.  I went to the Profiles tab, and selected the Profile Path check box, then entered \\serv2\users\%username% as the path to the profile.  I pressed the Go button, and all of my user’s profile paths were changed!  My migration was finally complete.

[update 11-09-2007]

KB 310316 describes a registry modification that can be made to modify how Windows Explorer handles permissions when objects are copied or moved to another NTFS volume. When you copy or move an object to another volume, the object inherits the permissions of its new folder. If you want to modify this behavior to preserve the original permissions, follow the instructions to modify the registry.

KB 174273 describes how to use scopy.exe to copy NTFS files or directory structures while maintaining NTFS permissions and restoring Share Level permissions. This method includes copying between partitions, hard drives, or computers.  It also briefly mentions using PermCopy.exe, a command-line utility that copies share-level permissions (access control lists [ACLs]) from one share to another.

If you’re using scopy to copy local group permissions to other domains, read KB 168470 regarding potential access problems with the trusting domain.

If you use some other solution to copy your data to it’s new location but still want to copy NTFS file system access control lists (ACLs), check out KB 323275 for how to do this with Robocopy.

Follow

Get every new post delivered to your Inbox.

Join 32 other followers