Ready for some fiddling?
You probably don't give much thought to the amount of time you spend working on profiles. However, when you add up all the minutes you've ever spent modifying this application setting and that desktop tweak—and realize that nearly all those settings reside in a profile—you'll see that you've probably spent months turning your user profiles into solipsistic works of art.
A moment of great frustration is when you have to start over. Suppose your desktop has gone out of business, or perhaps you simply need to upgrade to a faster system. How can you either restore your settings from a backup or transfer them from your old computer to the new one? Essentially, you have three options—two easy yet limited approaches and one flexible one-size-fits-all approach. Unfortunately, the flexible way is undocumented and involves some fiddling. Let's start with the basics.
Two Limited Approaches
Roaming profiles let you store your profile in a directory on a file share, then link that directory to your domain account. Whenever you use your domain account to log on to a workstation, your workstation goes to the file share and loads the profile. The benefit of this process is that your desktop and other settings follow you. If your workstation spontaneously combusts, you need only log on to another workstation to access your familiar desktop settings. (For more information about using roaming profiles, see Ed Roth, "Using Intellimirror to Manage User Data and Settings," page 74.)
Unfortunately, many people don't use roaming profiles because every logon triggers a large set of file downloads. Because most people log on at roughly the same time every morning, the file server that holds the office's roaming profiles tends to get overloaded. Also, the large size of most roaming profiles strains the network further. My roaming profile is 36MB—a size that I'm told is anorexic compared with some of my clients' roaming profiles. In theory, roaming profiles are terrific, but they're not practical for many networks. Thus, many of us use local profiles.
Windows XP users who need to move profiles from one system to another have a great tool in the OS's Files and Settings Transfer Wizard (aka Fastwiz). If memory serves, Fastwiz first appeared in the Microsoft Windows 2000 Server Resource Kit, and it didn't work well. I'm delighted that the tool now works well in its newer XP incarnation. Fastwiz lets you copy your application settings, Microsoft Internet Explorer (IE) Favorites and cookies, Microsoft Outlook Express mail, desktop settings, and data files from any XP, Win2K, Windows NT 4.0, Windows Me, or Windows 9x system to an XP system. In my experience, Fastwiz does a great job of grabbing just about everything you would miss from your old system (except, of course, your applications; you'll need to reinstall those) and dropping it into a new system. However, Fastwiz is beneficial only if no one else uses your old system or your new system.
So, the question remains, "How do I move a local profile from one system to another or restore a local profile?" You can take virtually any profile from any machine and account and transplant it to any other machine and account—as long as you don't mind adjusting file permissions and registry settings.
What Makes Profiles Tick?
When you log on to a system, the system goes to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry subkey, which Figure 1, page 73, shows, and finds subkeys with numeric names that you'll probably recognize as SIDs. If your logon account's SID matches the name of one of these subkeys, your workstation looks in that subkey for the ProfileImagePath value entry. The ProfileImagePath entry appears as something like \%systemdrive%\documents and settings\username, where username is your username. Your workstation grabs the files in the directory named in ProfileImagePath and uses them as your profile.
Suppose a user named Jake uses either a local or domain account to log on to a workstation. (If he uses a domain account, assume he doesn't have a roaming profile.) His workstation logs him on, discovering in the process that his SID is S-1-5-21-3675345140-426764551-501881172-1012. The workstation looks in the registry for the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-21-3675345140-426764551-501881172-1012 subkey. If that subkey exists, the workstation looks in ProfileImagePath. (If the subkey doesn't exist, the workstation assumes that Jake needs a new profile—but that's another story.) ProfileImagePath contains a value such as \%systemdrive%\documents and settings\jake. The workstation then goes to that directory to find Jake's registry settings (in a file called ntuser.dat), Jake's desktop, and so on.
Suppose Jake needs to move from one Win2K Professional workstation to another, and he wants to move his local profile. You might think that you need to perform only the following steps:
- Copy Jake's old profile from C:\documents and settings\jake on the old machine to C:\documents and settings\jake on the new machine.
- Create an HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList subkey whose name matches Jake's SID.
- Place a ProfileImagePath subkey, of type REG_SZ, in that subkey and fill it with C:\documents and settings\jake or \%systemdrive%\documents and settings\jake.
That process would almost work—but not quite. You would run into several problems. First, all the registry subkeys in ntuser.dat contain permissions that refer to the old machine's Jake. If Jake has been using a domain account to log on to the old machine and will continue to use that domain account on the new machine, you don't have a problem because his SID hasn't changed. However, if Jake has been using a local account on the old machine and will use a new local account on the new machine, you'll need to change the registry permissions to give the new SID full access to the subkeys in ntuser.dat.
Second, the files and folders in Jake's newly copied profile will similarly contain permissions that refer to Jake's SID on the old machine. Again, if Jake has been using a domain account, you don't have a problem. But if Jake uses a new local account to log on to the new machine, you'll need to change the file and directory permissions in his profile directory.
Finally, ProfileImagePath isn't the only registry subkey under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList; a bunch of other subkeys—none of which are well documented—need your attention. Unfortunately, I can't offer much advice about how to create appropriate subkeys or what to put in them. But you need to create and populate these subkeys, so go ahead and let the OS do it. The easy way to completely establish Jake's ProfileList subkey and its attendant entries is to create Jake's new account, then have him log on and immediately log off.
The One-Size-Fits-All Approach
Let's try a step-by-step example. Suppose Jake once used a local account to log on to a machine named Old, and he'll now use a different local account to log on to a machine named New. Here's how to move his profile from Old to New.
- Copy Jake's old profile folder from Old to New. The %USERPROFILE% environment variable identifies the location of Jake's profile. (You must log on as Jake for this method to work.) Alternatively, look in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\SID\ProfileImagePath subkey, where SID is Jake's SID. If you need to determine which SID is Jake's, use GetSID, which you can download from http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.asp. GetSID's syntax is a bit odd:
- After you find Jake's profile, copy it to the location in which New keeps profiles—probably Documents and Settings, so his copied profile now sits in C:\documents and settings\jake.
- Create Jake's new local account on New. Log on as Jake, then log off. Log back on to the system as a local administrator, and use GetSID to find Jake's new SID.
- Open Jake's folder in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Double-click the ProfileImagePath subkey and replace its contents with \%systemdrive%\documents and settings\jake. Close your registry editor.
- To fix the file and directory permissions, right-click the Jake directory and choose Properties. On the Security tab, add a permission for Jake in the typical way: Click the Add button, then choose the local Jake account. Back on the Security tab, give Jake full control by clicking the box under Allow next to Full Control. Close the dialog boxes.
- Start up regedt32 (in Win2K or NT) or regedit (in Windows Server 2003 or XP). Navigate to the HKEY_USERS hive. In regedt32, click Registry, Load Hive; in regedit, click File, Load Hive. In the Load Hive dialog box, navigate to C:\documents and settings\jake. Inside that folder, select ntuser.dat and click OK. A second Load Hive dialog box asks you to fill in a Key Name text field. Enter Jake and click OK.
- On your registry editor's main screen, open the HKEY_USERS hive. In regedt32, click the Jake folder and choose Security, Permissions; in regedit, right-click the Jake folder and choose Permissions. Click Add and add a new permission entry for Jake. Click OK to return to the Permissions for dialog box. Give Jake full control over his registry subkeys by clicking the box under Allow next to Full Control, then click OK to return to the registry editor's main screen.
- Now that you're finished with the modifications, you need to write the changes back to the file. To do so, click the HKEY_USERS\Jake folder. In regedt32, click Registry, Unload Hive; in regedit, select File, Unload Hive. Choose Yes to confirm the action. Exit your registry editor.
where accountname is the account's name and accountsource is the name of the machine that contains the account. Having the account name and machine name appear twice isn't a typo—both names must appear twice. In Jake's case, you would type
Now you have the SID and therefore the correct registry subkey.
Try logging on as Jake. You might get an error message stating that the system is unable to access an .inf file, but you'll receive this error message only once. In my experience, the preceding process moves desktop settings, preferences, IE Favorites and cookies, Outlook Express settings and mail, and so on.
The solution isn't perfect—for example, it might not transfer all your Outlook Express passwords. However, it's a fairly complete way to move a profile or load one from a backup.