Managing User Profiles

A slap-dash solution for transferring profiles in toto. Anyone with a more elegant method?

• By Bill Boswell
• March 16, 2004

I've tried copying the profiles using Explorer, but when the user logs on, instead of getting the copied profile, they get a default profile and I see a duplicate profile in Documents and Settings called Username.Domain. For example, if the copied profile is John, the new profile is John.DOMAIN.

I assume this is a permission problem, in that the user is not getting access to the profile folder to write or access the ntuser.dat file, but how do I get around it?
—John

John and Readers: I'm going to go through what I suggested to John and then I want your input.

First, some quick background. A user profile consists of a folder in Documents and Settings that contains the user's profile folders along with a Registry hive called Ntuser.dat. The profile is protected in a couple of ways:

• The profile folder has an Access Control List (ACL) that grants access only to the user, the System account, and members of the domain Administrators group.
• The registry hive inside Ntuser.dat has security permissions that allow access only by the user, the System, and the Administrators group.

The system maintains a pointer to the user profiles in HLKM | Software | Microsoft | Windows NT | CurrentVersion | ProfileList using the SID of the user as the name of the Registry key containing the profile information. Here's a quick example for a user named avguser:

Key Name: HKLM\SOFTWARE\Microsoft\Windows NT\
          CurrentVersion\ProfileList\S-1-5-21-
          3862616078-362906602-1993679999-1015
Value:    ProfileImagePath
Data:     %SystemDrive%\Documents and Settings\avguser

If a user logs on and the ProfileList key has no entry for the user's SID, the system creates a new profile for the user by copying the Default User profile, either from the local machine or from the NETLOGON share.

If the system needs to a create a new profile but a folder with the user's logon name already exists in Documents and Settings, the system creates a new folder and gives it an extension that matches the user's domain.

Okay. With all that in mind, I recommended that John do the following:

• Use xcopy /o to copy the profiles from the old server to the new one. This retains the ACLs of the files so that the user retains full control access to the profile. (Actually, you'd need to use xcopy /o /e /h to copy empty files and hidden files.)
• Use Regedit to dump the entries in the ProfileList key to a REG file.
• Edit the REG file to remove any profile entries, such as the Administrator profile, that would also exist at the new machine.
• Import the REG file into the Registry of the new machine.
• Verify that users log on and get their original profiles.

Although this works, frankly, it seems a bit inelegant to me. So here's what I'd like you to do. If you have a better way to do profile transfers and profile management in general, whether it be a cool script you developed or a favorite Microsoft tool or a third-party utility or whatever, send it to me. at [email protected]; put "Profile Transfers" on the subject line of your message. I'll print the best submissions in a future column and I'll acknowledge the name of anyone who sends an idea, whether or not it gets printed.

As for the example I've provided, hope this helps.