Transparent Windows Workstation Domain Migration

Couple of days ago I was faced with a task to move a small office environment into a new Windows domain. Basically an old LAN server was replaced with a new one, and at the same time the domain was renamed and restructured in a more logical way.

Switching the workstations (all running Windows XP Pro) to the new domain proved to be a bit of a challenge, especially since I wanted to preserve the users’ existing profiles. Lots of web searching ensued, and eventually I found a few resources such as this, this, and this. Especially the first of the three sites (Recovering a Windows Profile by Drew McLellan + reader comments, especially that by Carl Farrington) gave a very good starting point. Below is a cohesive step-by-step list, composed from the aforementioned resources with some new ideas and clarifications added.

The instructions below assume that you have a new Domain Controller ready, and also that you are somewhat familiar with the associated menus (i.e. not everything is spelled out). These instructions were written for Windows XP (Pro), but should work with other Windows flavors with minor modifications.

Before you begin, save (or make a note of) each workstation’s desktop background image (if you care). For some reason it was not automatically reinstated after the new domain was joined (in fact, as far as I could tell it was the only bit of a configuration that was lost in the process).
Make sure you have the local administrator password for all of the workstations (any local account with admin privileges that is not going to be joined to the domain is ok). If you don’t have admin password but the account that you have a password for has admin privileges, you can go to Settings > Control Panel > User Accounts and reset the password. If you’re at loss – no access to an account with admin privileges – refer to Petri IT knowledgebase article about the subject.
Make sure the user profile you’re going to migrate is a LOCAL PROFILE (in Settings > Control Panel > User Accounts). If it is not, make it local (roaming profiles stand to lose data during the migration process and these instructions do not apply to them!).
Write down the name of the user’s profile folder; it’s usually “c:\Documents and Settings\username” or “c:\Documents and Settings\username.OLDDOMAIN”
Join the new domain (you know, Settings > Control Panel > System > Computer Name > Change > Member of.. Domain [enter domain name] > enter domain administrator username/password if requested > reboot).
Log in as the user (with the password set in the Domain Controller). This creates the new profile folder at “c:\Documents and Settings\username.NEWDOMAIN”
Restart, then login as the local admin (or as any local user with administrative privileges).
Move the newly created user profile folder someplace else (doesn’t matter where… the folder can also be deleted, but I’d keep it until the process is complete, just in case ). In other words, move the new profile folder at “c:\Documents and Settings\username.NEWDOMAIN”, for example, to “c:\temp\username.NEWDOMAIN“, or just delete it (if you’re brave).
Rename the old profile folder to the new name, i.e. usually from “c:\Documents and Settings\username” or “c:\Documents and Settings\username.OLDDOMAIN” to “c:\Documents and Settings\username.NEWDOMAIN”. In an event that the original user profile folder is locked and can’t be renamed, use the free Unlocker tool to identify the locking process, and to unlock it (you can run unlocker on the entire profile folder and it’ll recurse through all files).
Add the new domain user to the profile folder’s filesystem permissions, and give full control for that user. Highlight the folder that you just renamed, right click on it > select Properties > Security. You should see the old profile (now displayed as string of number and letters), marked with a question mark. Click on it to select it, and select Remove to remove the old profile. Then click Add, and enter the new domain username (as NEWDOMAIN\username) as an authorized user for the folder and for all the content in it. Click OK. With the newly added user highlighted check Full Control “Allow” checkbox, then click Advanced > check “Replace permission entries on all child objects..” > click OK, then “Yes”. Depending on amount of content it could take a few moments for the system to parse through all the files and folders in the profile folder as the permissions are being updated.
Add the new domain user as a local user (and give the user administrative privileges for their computer if desired). Go to Settings > Control Panel > User Accounts > Add > Browse > enter the domain username as NEWDOMAIN\username, and click Check Names. Depending on the setup (and the account you’re logged in as), you may be prompted for the domain administrator’s user/pass. The name is validated (it becomes underlined if it’s ok), then click on OK, then Next. Unless your policy somehow restricts it, you should add the domain admin as a local admin user at this point with this same procedure.
Adjust registry. If you added the domain admin as an local administrative user, you may log off and log back in as the domain admin. Otherwise proceed as the local administrator (the difference is you may need to enter domain admin username/password when you add or validate user names).
a. Make sure all files are visible (i.e. open My Computer > Tools > Folder Options > View > select “Show hidden files and folders”, and uncheck “Hide extensions for known file types” and uncheck “Hide protected operating system files”).
b. As a precaution make a backup copy of the user’s NTUSER.DAT file. Go to the user’s profile folder (c:\Documents and Settings\username.NEWPROFILE) and copy the NTUSER.DAT to NTUSER.DAT.BAK. You can, of course, skip this step, but better be safe than sorry .

c. Run registry editor (Start > Run > regedit)

d. Highlight HKEY_USERS, then select File > Load hive

e. select NTUSER.DAT that resides in the user’s profile folder (i.e. “c:\Documents and Settings\username.NEWDOMAIN\NTUSER.DAT”), click Open, and give it any easily identifiable name (doesn’t matter what – this is just a temporary name).

f. expand HKEY_USERS and highlight the subkey (the name you gave it in the previous step). Right click, and select Permissions. There should be a SID (user ID) with a question mark indicating “unknown”. Delete it. Then click Add, and enter the domain user’s name as in NEWDOMAIN\username. Click on Check Names (if you’re logged in as the domain admin the name will be validated immediately, otherwise you’ll be asked for the domain admin username/password first). If the name is ok, it’ll be underlined, then click OK.

g. highlight the domain user you just added, then check Full Control under “allow”, then click Advanced, check “Replace permission entries on all child objects…” and click OK. If “not all child objects could be updated” (or such) error is displayed, ignore it. Click OK.

h. with the same subkey (that you created few steps earlier) still highlighted, select File > Unload Hive, then select “Yes”, and close the registry editor.
Log off, then log in as the domain user.
Go to “c:\Documents and Settings” and highlight the user’s own profile folder (again, usually “c:\Documents and Settings\username.NEWDOMAIN“). Right click > Properties > Security > Advanced > Owner. Select the user from the list and check “Replace owner on subcontainers and objects” and click on OK. Again, this could take a few moments to complete. Then click on OK to close the user profile properties.
Restart, then log in as a user with local administrative privileges (but not as the user we’re migrating, even if you assigned admin privileges to them). Go to “c:\Documents and Settings” and rename the user’s profile folder back to what it was originally called (i.e. the name you wrote down in step 4). This step might result in a confusing profile folder name if the old domain was part of the profile folder’s name (i.e. username.OLDDOMAIN), however, if the user has installed lots of 3rd party software that have saved data in the user’s profile (such as in user’s My Documents, or Application Data folders), all of those programs’ setting will need to be adjusted to reflect the changed profile folder name unless the profile folder is renamed to what it was before the migration.
Start Registry Editor (Start > Run > Regedit), and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Once there, go through the profile subkeys (S-1-5-, etc.) and look for the profile whose “ProfileImagePath” is set to that of the user. It should have a value such as “%SystemDrive%\Documents and Settings\username.NEWDOMAIN“. Double-click on the ProfileImagePath and set the value to reflect the original profile folder name as renamed in step 15 (e.g. “%SystemDrive%\Documents and Settings\username“, or “%SystemDrive%\Documents and Settings\username.OLDDOMAIN“). Then close the Registry Editor.

You’re done! You might want to finally log in as the user to make sure everything is working as they should. Finally, since the user’s old password was set by the new domain, and since you’ve logged in as that user few times, you might want to reset the user’s password in the domain controller with “User must change password at next logon” requirement.

Disclaimer: While this worked for me, various system settings may affect the described steps. If you destroy someone’s profile with 700Gb of irreplaceable data in the process, it’s not my fault , so be careful, and preferably take a full backup before you begin. While this process allows profile migration without having to duplicate it, it’s a good idea to make a backup copy of the profile (if the disk space allows it) before you migrate it; you can then delete it once the migration has been completed successfully.

I welcome any comments, corrections, or other feedback.