Migrate Profiles on Small Business Server Networks
OK, OK! Based on recent meetings with IT professionals and e-mail received from readers, folks are asking heaps of questions about migrating user profiles from an existing Small Business Server (SBS) 2000 network (or any domain-based network for that matter). While you can always manually transfer settings for a user to a new network, such an approach is tedious and not truly acceptable in the real world.
But first things first. Why bother to migrate user profiles at all? In small companies, it sometimes seems more trouble than it’s worth. The fact of the matter is that small companies operate much like larger ones and are surprisingly sophisticated users of technology infrastructure. Don’t believe that? Then just step back, tour a small business of sufficient size (30 users) and look at how they’re using their infrastructure. Whereas in the “old days,” the concern for user profile migration in a small business focused on making sure the business owner saw his grandchildren as desktop wallpaper in a post-conversion state, today it’s much deeper than that.
Rather than keeping the “big guy” happy with his JPG photo as desktop wallpaper (that’s the grandchildren part), you’ll find yourself migrating the proper security identifiers (SIDs) and access control list (ACL) settings to keep line-of-business applications such as Microsoft’s CRM 1.2 healthy and the business owner wealthy!
Specific to SBS 2003, it would be nice if it were possible to use the SBS Network Configuration Wizard to handle migration from an existing domain-based network. And it even looks like it should be possible to make the necessary profile migration election on the screen titled “Assign users to this computer and migrate their profiles.” (See Figure 1.) Unfortunately, that screen is for migrating profiles from peer-to-peer networks or stand-alone computers, not domain-based workstations. The consequence is that you can’t migrate a user profile from an older network to SBS 2003 using the native SBS tools.
The good news, though, is that it is straightforward to migrate user profiles from domain-based workstations, and there are at least three ways to migrate a profile from an SBS 2000 or existing domain over to SBS 2003.
The Easy Way
This method was a lesson I learned in the heat of battle during a network conversion for a client in the real estate and finance business in January 2004. For this procedure, I assume you are using a Windows XP Professional workstation. While the XP Pro workstation is still attached to the legacy SBS 2000 network (again, this could be any older network such as Windows 2000 Server), copy the network profile down to the local hard disk. Assuming you are logged on to said SBS 2000 network and are sitting at the workstation, complete the following procedure:
- Click Start>Control Panel>System>Advanced> User Profiles>Settings.
- Highlight the network profile for the user. For example, EricW.
- Select Copy To and direct the profile to copy to the local hard disk. For example, C:Temp. Click OK>OK.
- From the Control Panel, launch AdministrativeTools> Computer Management.
- Select System Tools>Local Users and Groups.
- Select Users.
- Right-click in the right-pane and select New User to add a user named “Foo.”
- Double-click the user object and select the Profile tab to view the properties for Foo.
- In the Profile path field, point to the exact profile you copied to C:Temp in Step 3. Click OK.
- Close all open applications, shut down the Windows XP Pro machine and move it physically to the new SBS 2003 network. Reboot and re-launch the SBS Network Configuration Wizard.
- Back on the screen to Assign users to this computer and migrate their profiles, in the lower section, under the user name (for example, EricW), click Current User Settings and select Foo. (This is the profile that will be listed.) Complete the steps for joining the workstation to the SBS 2003 domain. The profile will be migrated!
User Profile Registry Way
This method, while slightly more complex, has worked without fail. You can retain the complete profile customizations for a PC that was logged into one domain and now must be logged into a new one. The method works for both Windows 2000 and XP. It has also worked for upgrading SBS 2000 to SBS 2003, where it is happening on the same server, meaning that you have to reformat the SBS 2000 server and load “freshie,” as you would say, with SBS 2003. Here’s how it works:
- Once the SBS 2003 server is set up and the computers are set up on the server side, log into the client computer and run the http:\<sbs2003 server name>connectcomputer URL. When that step is completed, log in as the user. Then, immediately log off and log on as the domain administrator.
- Be sure the domain user account is in the Local Administrator’s group. Then open Registry Editor (run REGEDIT at the command line) and navigate to HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsNTCurrentVersionProfileList. You will see a listing for each Security Identifier (SID). Within each SID key, you will see an, entry for ProfileImagePath with a path to the user’s profile in the form of %SystemDrive%Documents and SettingsUserName.
- The trick is to find the new key that was set up at logon to the SBS 2003 server and edit the path to refer back to the original profile path. So, for example, if you are migrating and changing domains, you want to have a path like %SystemDrive% Documents and SettingsUser Name.OldDomain. You then have a new SID key with a path like %SystemDrive%Documents and SettingsUser Name.NewDomain. You can edit this key and replace NewDomain with OldDomain to point to the old profile.
4. In the case of a server migration within the same domain, you have a path to the effect of %SystemDrive%Documents and SettingsUser Name.Domain and %SystemDrive%Documents and SettingsUserName.Domain.000. In this instance, you delete the .000 to point back to the original profile.
However, just editing the registry path is not enough. User settings in the registry are stored in the user.dat file for each specific user. Only the original user has permissions to that file. You must give the new user permissions to the old user.dat. If you don’t do this, the default user profile will be used instead of the old one. To set appropriate permissions, you must do the following:
- Launch REGEDIT from the command line to launch the Registry Editor. From the Registry Editor, go to File, Load Hive.
- Navigate to the user.dat file of the old user. It’s located in that person’s folder under documents and settings. You need to make sure hidden files are visible (in Windows Explorer, select Folder Options, View, View hidden files and folders).
- Once you have loaded the user.dat file as a hive, go to Edit, Permissions in Windows XP (or go straight to the Permissions menu in Windows 2000).
- Give the new user full permissions to the registry key you have created. Once you are done, highlight the registry key and click File, Unload hive.
- That’s all there is to it. The new user now has full access to the user.dat file.
The MCSE Way
Then there are the grizzled certified professionals among us, typically MCSEs, who pointedly highlight using the Active Directory Migration Tool (ADMT). This tool not only permits you to migrate from a legacy domain to the 2003 time frame, but it also permits you to restructure your domain as well. (This second part might be of greater interest to some readers than a simple migration.) The bottom line is that this tool has SID and ACL setting preservation when you migrate users and gr