Migrating Users and Workstations from A Windows Workgroup Network to a Domain Security Model

If you ever have to move an old Windows Workgroup-style network (even with Windows Server running, if you don't have the computers join the domain, you are running Windows Workgroup type networking and user management), it can be pretty painful.

If you can front end your server setup with scripts, GPO's, and profiles, it can be easier, but you are still faced with migrating the user's profile off the workstation.

Here are the steps you need to follow to implement a workgroup to domain/active directory model...

The basic concept here is that we just want to move the users from their old user profile (workgroup based) to the domain model. In my example, I'll use user as the user and domain as the domain.

With that in mind, you'd probably find that old settings are in:
c:\documents and settings\user\*

and new settings might be in:
c:\documents and settings\user.domain\*

You can't rely on that, though. Sometimes users get renamed, but their settings stay under the old name. Also, XP usually creates the new user as user.domain if the user name is the same, but it isn't always. Double check everything by looking at the dates and times of access and other hints to make sure you are working with the right directories.

Here are the basic steps (all warnings apply about registry changes, backups, doing damage, etc.... this is what I did, your mileage may vary)

1. Log on as administrator on the workstation
2. Join domain and reboot as prompted to
3. Log on as each user for that computer and clean up things so the migration is much faster:
1. Purge the IE cache
2. Clean up %TEMP% (delete and create a new one, usually)
3. Clean up TEMP
4. Note any mapped drives
5. Note any shared printer
6. Log off
4. Create settings for the domain user by doing this:
1. Log on as domain user
2. Log off
5. Copy everything to the new user:
1. Log on as Domain admin
2. Show all files by opening My Computer, Tools, Folder Options, View, and checking "Show hidden files and folders" and unchecking "Hide extensions" and "Hide protected operating system files". Close My Computer.
3. Copy the local user's documents and settings and subdirectory entries to the new domain user's settings (copy c:\doc...\user\* to c:\doc...\user.domain\)
4. Rename the old user's directory to user.old (where user is the user's actual ID). This prevents a problem with Outlook and an error message about not having rights to access the user's old OST file, if there is one.
5. Fix permissions in the new user directories, if you need to (special cases)
6. Run Regedit
7. Load hive for domain user by clicking on the USERS hive and clicking File/Load Hive... and selecting the user's new NTUSER.DAT
8. Fix permissions on that hive by adding the domain user, domain admin's group, and removing the old user from the permissions. Make sure the new entries have full permissions. Click on the Advanced button and set all children to have these permissions (this will eliminate some problems later on with SSL and encryption that can happen because the registry hive doesn't have enough rights; IE displays an error about the "page cannot be displayed" when going to SSL pages).
9. Unload hive
10. Log out
6. Finish up...
7. Log on as domain user
8. Test everything
9. When you open Outlook, you may get an error about not being able to find your OST or PST (the registry still points to the old location). Point to the new user.domain location when prompted and the system will either create a new file or reuse the one you put there.
10. Use lusrmgr.msc to disable the local user (user must use the domain, now)
11. Since (windows) network printers go with the user, you may have to re-share and re-connect to windows network shared printers. Do this on a per user basis.
12. Follow up: delete local user in lusrmgr.msc, eventually
13. Follow up: delete local user profile, eventually