Zytel KB

I usually will use a document called “Successful preseravtion of User Profiles on Windows 2000 and XP Workstations when switching Active Directory Domains” by Matt Bradford, but I cant seem to find it anywhere. Alas, my Googlefu has failed me. It its stead I have found two documents that may prove useful in the future

One: http://www.raygibson.net/kb/profile_migration/

How to Migrate User Profiles in Windows XP Quickly and Easily!

One of the hardest things as an administrator has been that of a server installation. A user has a well established profile with desktop settings that they do not want to lose. What do you do? Well, in the past you would have clicked on user profiles in the advanced system properties and clicked on “Copy Profile” with moderate success. Did you know that it skips the “Local Settings” folder? So much for that user’s PST file! Or, god forbid, you see “Account Unknown” in there, when you know that you need that account? Perhaps the picture to the right is all too familiar… Well, when you’re done reading you’ll realize that hope is not lost and you might kick yourself in the butt for not thinking of this earlier (I definitely did!) There are three key steps which I will explain momentarily. They are: Give the new SID full permissions on the target profile directory. Give the new SID full permissions on the target registry hive. Change the ProfilePath of the new SID to the target profile directory. What the hell does all that mean? Let me explain for the purposes of this document. This tutorial is not for anyone unfamiliar with the Windows Registry and general file permissions. If you don’t understand all of the below, you really should hire a professional to do it for you.

How Profile Creation works in Windows XP/2000

Every user account in a Windows environment has something called a SID, or Security Identifier. There are only two parts of this number that we care about, the 28 (or so) number string in the middle, and the last set of three or four numbers, called the Relative ID (RID).

An example of a Windows SID is S-1-5-21-746137067-1425521274-725345543-1003. Don’t let that scare you. The computer/domain identifier in this string is 746137067-1425521274-725345543, and the RID is 1003.

The domain/local string is generated when you install windows or promote a domain controller. The RID corresponds to a user account. A RID of 500 is the built-in Administrator account, and anything above 1000 is a normal user account.

Practicalities

This process can be adapted to many situations. Here are a few that I can think of:

• Converting a local (workgroup) account to a domain account.
• Converting a domain account to a local account.
• Converting a domain account to a different domain.
• Recovering a profile after an account has been deleted and recreated. (my favorite)

Our Scenario

For this tutorial, I am going to walk through converting a local account to a domain account, as it’s one of the most common things I run across.

Here’s our problem: I’ve just sold a new customer a Windows 2003 Server to replace their aging Windows 2000 Professional Workgroup Server. They have more than 10 computers now, and are getting licensing errors when connecting to their shared drives. Each user has an expansive Desktop and My Documents, and they have their desktop icons arranged in a way that they just can’t part with.

When you join the computer to the domain and reboot, they need to be able to log back in and pick up where they left off as if nothing ever happened. Sound difficult? Impossible?

The old way would be to join the computer to the domain, log in as their new network user account, log out, log in as administrator, go to system properties, click advanced, click user profiles, select theirs in the list, click copy profile, select the location of their new user profile (user.DOMAIN), add them (or Everyone) to the “allowed to use” list, click “go” and pray. Wait three hours because of their iTunes collection, reboot and hope for the best. GOD FORBID one of their files has too many characters in the file name, you’ll have to start all over again. For shame.

Herein, the better way.

Preparation

First thing is first, join the computer to the new domain and create the user’s new account in Active Directory. Log into their workstation as their new user and let it generate its new profile. Log out.

This does a couple of things for us. First, you’ve established the new account in the domain so the user can log in. Secondly, you’ve established the domain account as active on that workstation, and it has generated a new profile corresponding to that user’s new SID.

Step One: Profile Directory Permissions

Find the user’s original profile. Look in “C:\Documents and Settings”. If the user was James, it’s probably called james. In that case, the new profile folder would be called james.domain. Right click the old profile folder, go to properties, and click the security tab. You should see “Administrators” “SYSTEM” and the old user account in the list. If the old user account is deleted, you’ll see the SID, similar to the picture to the right. Click the “Add” button, and add the user’s new account to the list. Click the box to allow “Full Control”. Click Advanced, then check the box for “Replace permission entries on all child objects with entries shown here that apply to child objects”. Click Apply, then OK and OK. Don’t click anything else. Seriously. You can (and should) remove the old user/SID from the list when you add the new one in. That is only semi important, but it will prevent confusion later.

Step Two: User Registry Hive Permissions

The most important step to get right is this one. Open the registry editor. You need to be able to edit permissions, so in XP run regedit.exe and in 2000 run regedt32.exe. If you’re on windows 2000 you’ll have to figure out this step for yourself, as I’m only going to illustrate the XP method. Expand the HKEY_LOCAL_MACHINE key but leave it selected. Click on the file menu, then click “Load Hive”. Navigate to the old (target, the one we want to use) profile directory. Double click the NTUSER.DAT file. If you don’t see it, type it in. It’s hidden, but it will work. The registry editor will ask you to give it a name… I use something like “asdf” or “chickenfucker” — be creative. Right click our new creation, and go to Permissions. You’re going to follow suit with exactly what you did earlier. Click Add, type in the new domain user name, give it full control, click advanced, and check the box for “replace” all the child permissions. Apply, OK, OK, and remove the old user. VERY IMPORTANT: When you’re done, select the hive again, click file, and then “Unload Hive”. Don’t forget to do this, really.

And finally, The Last Step (can you tell I’ve activated windows by phone?)

Step Three: ProfileList Key

This part is so easy and it makes so much sense. Remember those SIDs I was talking about? Navigate your registry editor to the following key: HKEY_LOCAL_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList Look at the list beneath ProfileList. Does it look familiar? Notice my list of SIDs, and you can easily divide them into two groups. One set were the local accounts, and one set are the new domain accounts. This part is tricky, but if you screw it up you can probably recover from it. You’ll want to look through each of the items in the list, but you’re looking for two inparticular; our old user account and our new user account. Keep in mind that we’re pairing the new user account with the old profile, and we’re ditching the old user account and the new profile. Get it? Look at the subkey called ProfileImagePath in each of the SID keys. You’ll find one matching the old profile directory and one matching the new profile directory. In our scenario, the 28ish digit number in the SID should be different for each account. Look in ProfileImagePath for username, and for username.domain. The one without the .domain is the old profile SID. Ignore it or delete it! (Microsoft recommends backing up your registry. Don’t say I didn’t warn you!) The one with the .domain attached is the NEW account, that we’re about to point to the OLD folder. Don’t delete it. Instead, modify the ProfileImagePath subkey and remove the .domain. So, %SystemDrive%\Documents and Settings\james.domain will become %SystemDrive%\Documents and Settings\james. See what we did there? Now you can log in as that user and you’ll see the old desktop with all the icons in the right spots. You didn’t even have to reboot! (you might want to though, I’ve had an issue with the new account’s “new” hive not unloading correctly, so it had the old path with the new registry until a reboot. Don’t let that happen to you)

Holy Hell Batman, have I just done something in 5 minutes (with practice) better than what I used to do in one to three hours?

Yes, why, yes you did.

Wrapping Up

If all went as planned, your new SID will be using the old SID’s information. If you decide to do this in real life, pay attention to the SID and RID numbers. Try to understand what they mean. In reality, it’s a lot simpler than you would think: We gave the new user permission to control the old user’s stuff, and we told windows that their profile was in a different spot. How hard should that be? Yet, I could not find a single web page documenting the process. This really beats the File Settings and Transfer wizard.

You can use this technique to recover “Account Unknown” Profiles as well. Just think about it.

Technique TWO

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.