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.

  1. 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).
  2. 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.
  3. 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!).
  4. 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”

  5. 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).
  6. 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

  7. Restart, then login as the local admin (or as any local user with administrative privileges).
  8. 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).
  9. 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).
  10. 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.
  11. 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.
  12. 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.

  13. Log off, then log in as the domain user.

  14. 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.
  15. 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.
  16. 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.

17 thoughts on “Transparent Windows Workstation Domain Migration

  1. Hi Ville! Great tutorial, thx. I’m in the situation to migrate about 1500 workstations from a novell-netware-network to active directory. by now everything seems to be well working. the only thing that gives me some troubles is the profile migration. Atm i copy the profiles with the windows-built-in-tool where you can delelte or copy profiles. this sometimes takes quite a while but if it worked constantly it would be fine for me though. The problem is that sometimes profiles get crashed and lost. It seems that they are deleted after reboot but I think they are just inaccessible. Anyway, the procedure u described looks quite good.

    The only thing I would like to change is the thing in pt 15. If i got you right you change the users-profile back to the old name in order to keep programs that put some data inside the profile running. I’d rather have the new profile-name because the usernames completely changed and I don’t want to have the old usernames shown up in document and settings tree. Is there a way to retain the profile name? Or do I have to reinstall the concerning software?

    Good Times! Shaba…

  2. I also considered the built in profile transition tool for my SMB migration. The problem with it was that it wanted to *copy* the profiles, not rename. Some users had massive profile folders (mostly thanks to Desktop and My Documents contents) which by far exceeded the remaining free disk space on their system’s c: drive. For this reason duplicating the profile wasn’t an option. The process I described made it possible to transition the old profile to the new without copying it.

    Renaming the profile folder back to the original is a completely optional step. In some cases the users could have installed lots of 3rd party applications that store data in “\Documents and Settings\profilename\Application Data” and/or in “\Documents and Settings\profilename\Local Settings\Application Data”. If you keep the new profile name (which of course would be more logical from the standpoint of the changed user name) any such programs would be affected. In most cases you can adjust the data paths in the affected program’s options/preferences/settings (or instruct the users to do so) without having to reinstall the package. So whether reverting the profile folder name back to the original makes sense (or is worth it) depends on the circumstances, on the IT policy (if one exists), and on what kinds of programs the users have installed.

    In your case the migration process of course needs to be scripted, or else someone has to go through the profile migration manually 1500 times. :) I only had to migrate seven workstations so writing a script would’ve been more trouble than it was worth, and so I migrated the workstations manually (despite of just seven workstations to migrate the process still took me 10 hours, from six o’clock in the evening until 4 o’clock in the morning).

  3. I am trying to follow your procedures setting up a new server where I am using a new domain name. The old server crashed and the hive was not recoverable, so the network machines cannot access the previous domain. At step 10, when I try to change the security settings, it only shows the local computer name under SELECT LOCATION. It will not accept the new domain name even though the computer has joined the new domain. This also prevents step 12.f. Do you know why the new domain name does not show up in select locations?

  4. Yet in step 5 you were able to join the affected computers to the new domain..? I’m wondering if the network settings are correctly set on the affected system, particularly WINS configuration. Can you resolve anything else on the local network and/or on the Internet from those machines?

    If you were able to join to the domain originally, but the domain is subsequently not available, also make sure you haven’t configured netlogon batch file (on the server) with potentially incorrect settings that would propagate to workstations that log on to the domain.

  5. Thank you Ville for that great tutorial! It really saved my neck! It took a long time to set all user profiles, but we finally done it!

    But since I’ve done that trick to the profiles, I got event IDs #1508, 1502, 1515 & 1511 for 5 or 6 users (me included, and I don’t know if it is caused by that trick or by my new domain…). When users log in in the morning, Windows XP says that it can’t find the user’s profile (see Event IDs) and load a temporary profile. The user needs to reboot the computer in order to use his profile. It looks like something’s happening during the night or after a long period the user did not use his computer. Maybe NTUSER.DAT does not unload properly at logoff (even if I use UPHCleaner)? I’m not used to mess around with profiles…

    Thanks again!

  6. Just curious, are any of you guys admins in large corporate environments? There’s a Microsoft tool for this called the ADMT. You can migrate user accounts while preserving SID history and user profiles; this will save yourself a LOT of work and a lot of grief from the end user. This step-by-step would cause any self-respecting admin to put a gun to his head. RTFM, boys…

    My $.02…

  7. Steve: I installed ADMT at the time, but deemed writing a script for it to achieve the switch more trouble than it was worth since the LAN I was working on only had some seven, eight workstations. Granted, if I had known how to use ADMT beforehand, it would probably seemed a more worthwhile option. I also don’t remember whether ADMT would’ve migrated the existing profiles on the client PCs (which was the goal of this tutorial), or whether it would just have taken care of the AD migration on the server side. It would seem to me the latter was the case but I don’t remember (or, possibly, know) for sure.

  8. You’re my hero. You have saved me so much time and taken the anxiety out of upgrades and migrations.


  9. very good, maybe, can add a step to delete old user profile in registry entry: ProfileList.

  10. Pingback: Windows Server 2008 Reinstall and User Accounts

  11. Pingback: Desktop Profile preservation when migrating to a new Domain - Zytel KB

  12. Plse help with a VISTA problem. I tried to convert my old domain user profile to a local profile least expecting what happended next. The profile of course as you know became unknown. I did not create a restore point to revert to. I created a new user and accessed all of the documents and applications except for one application which is picking up a changed hostname. I sucessfully imported all of the Outlook .pst files.
    My main problem is I no longer have access to the domain and I should have preserved my Outlook for a few more weeks because I needed access to the phone book etc. How do I restore my old domain user profile so that I am able to login locally and have access to the Outlook .osd file etc – so I want to get back to the situation when I was a network user but working offline.

  13. Further to my earlier post – hope you feel like publishing me!!! So far I´m 3 machines in with 3 more XPs and a Win7 to do. The Win7 is looking messy but the XPs have been really smooth, even the desktop background has been migrated on each occasion on XP so far :-)
    Obviously you don´t mention at point 5 about the DNS requirement – I guess you consider that assumed knowledge. Personally I didn´t bother removing the credentials from the old domain marked with question marks at point 10 and 12f.
    I did however find some quirks where previous domain administrators had played with user profiles in the past. I noticed windows recreating the original user profile between point 9 and point 15.
    I also needed some assistance to work out which was the actual current user profile, these 2 helped
    And this: combined with the ProfileList registry key in point 16 did the trick.

  14. Afternoon –

    My 2008 AD server crashed. I had to start from scratch, so I reloaded the 2008 Server OS and created a new AD domain, DNS, DHCP, etc…. I have seven (7) existing Win 7 PCs that still need to be added to the new domain. They still are a part of the old domain. However, I did keep the domain names the same. In this case, I rather proceed with similar steps for reinstating Win 7 to the new domain. Has anyone simplified or created a step by step procedure for Win 7? If so and you’re willing to share, I’d appreciate it. Success stories would be great to hear, as well. Thanks to all of you for working hard on this…very helpful in many many ways!

  15. Hi,

    I just want to say thank you for one of the Internet’s best articles ever.

    I used the steps in this article some years ago when migrating a bunch of workstations to a new domain and from what I recall it worked almost flawlessly (the problems being the background image and some occasional weird thing I don’t even remember).

    Truly helpful!

Leave a Reply

Your email address will not be published. Required fields are marked *