After my organization upgraded all its desktop machines to run Windows 2000, we soon discovered that replacing old PCs with new ones in a Win2K environment is very different from doing so in a Windows 95 environment. The profiles were killing us because they required the user to log on to the PC before we could restore their data.
We developed an automated solution to this problem. The solution is a mix of resource kit utilities and custom code that runs on Win2K Professional machines (we haven't tested the code on Win2K Server). Even if our solution doesn't exactly meet your needs, it might provide helpful information about the Win2K profile-generation process.
Our process moves most configurable settings—including desktop and startup customizations, drive and printer mappings, and Microsoft Internet Explorer (IE) settings—for each user profile on the old PC directly to the new PC. This direct PC-to-PC copy process (rather than a PC-to—network share—to-PC copy) has the advantage of reducing network traffic and conserving disk space on a file server.
The core problem in using traditional file-copying methods is that you can't manually create a user-profile folder in Win2K even when you know the name that Win2K will expect that folder to have. You've probably already tried to manually create a C:\documents and settings\jsmith folder on John Smith's new PC, only to find that when John logs on to the PC for the first time, Win2K creates a C:\documents and settings\jsmith.mydomain folder. Why won't Win2K use the folder you created?
I called the experts to find out. The Microsoft support representative I talked to struggled to understand why I would want to know such a thing. When I expressed my desire to copy user profiles between PCs, I was directed to the User State Migration Tool (USMT) in the Microsoft Windows 2000 Server Resource Kit and Microsoft Windows 2000 Professional Resource Kit. Based on what I've read about this tool, USMT had two shortcomings in our situation: It's meant to migrate a PC from Win9x to Win2K (rather than from Win2K to Win2K), and it migrates just one profile at a time.
Another Microsoft suggestion was to have each user log on to the PC, then move the user's data. We tried this tactic with a few users but found it unworkable. Some of the PCs in our building have 100 profiles. Also, users work three shifts. I wasn't keen on going in to work at 2:00 a.m. to have third-shift users log on to their new PCs for me.
Instead, I set out to discover what a script would need to do to make Win2K accept the folders the script created as valid user profile folders. After some trial and error, I found that two components are key. First, the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry subkey must contain the SID for each user whose profile you want to add and requires very specific security settings. Second, a C:\documents and settings subfolder (which typically has the user ID as its name) must exist so that the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry subkey can reference it. The user account must have full permissions to the profile subfolder and all its subfolders.
Some of the plain-vanilla tools we tried first wouldn't let us solve the key profile-configuration requirements, so we had to explore other tool options for our script. When we migrated to Win2K, we gave up KiXtart (a tool in the Win2K Server resource kit and Microsoft Windows NT Server 4.0 Resource Kit) in favor of VBScript and Windows Script Host (WSH). VBScript and Windows Management Instrumentation (WMI) can export and import a registry subkey, but we couldn't locate a WMI class that migrates the registry security settings. However, our old friend KiXtart's Savekey and Loadkey functions can save and restore a subkey, including its security settings. The disadvantage of Loadkey is that it doesn't prompt, confirm, validate, or even say "thank you" before it replaces an existing subkey with the one you specify, but we use the function despite this shortcoming. For more information about KiXtart, see Matthew Moran, "KiXtart User Logons," July 2002, InstantDoc ID 25276.
You can easily use the Xcopy command to copy the C:\documents and settings folder, but remember that all the subfolders must have full privileges granted to the users. Our script uses the Robocopy utility (in the Win2K Server resource kit and NT Server 4.0 resource kit) to perform an Xcopy-like copy that retains the security settings from the old PC.
Behaviors and Assumptions
Carefully review the following cautions before using the script. If you're unsure about your own practices and whether the script might negatively affect your systems, don't use the script.
- The script erases all existing local accounts on the new PC. If your new PCs have local accounts that you want to keep, don't use this script. The script overwrites the SIDs for the local accounts. We typically create new PCs from a ghost image, so they have no real existing local accounts when the script copies domain accounts to them from the old PCs.
- The script deletes the new PC's C:\documents and settings\administrator folder. The script deliberately deletes the folder because the script overwrites, then deletes the registry key for the local administrator account. Removing the folder causes Win2K to create both the registry key and the folder together the first time a local administrator logs on. My organization doesn't store anything in the local Administrator folder, so losing it is unimportant.
- The script assumes that the C$ administrative share is enabled. The script copies information from the Win2K default administrative share for all PCs.
- We've used the script to copy from Win2K to Win2K only. Be sure to test any other combination of Windows versions before using the script in production.
To run the script, you need the KiXtart and Robocopy resource kit utilities. You also need to download the following script files from the 26356.zip file at http://www.winscriptingsolutions.com, InstantDoc ID 26356:
- Savepc.bat, which Listing 1 shows, calls savepc.vbs.
- Savepc.vbs, which Listing 2 shows, writes the old PC's SID and other information to a three-line ASCII file, then calls savepc.kix.
- Savepc.kix, which Listing 3 shows, writes the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList registry subkey and its security settings to a file.
- Copypc.bat, which Listing 4 shows, copies the C:\documents and settings folder from the old PC, then calls copypc.kix and copypc.vbs. Copypc.kix must be called before copypc.vbs.
- Copypc.kix, which Listing 5 shows, overwrites the new PC's profile list with the old PC's list.
- Copypc.vbs, which Listing 6 shows, scans for and deletes SIDs that were specific to the old PC (which copypc.kix imported along with the domain profiles to the new PC). Copypc.vbs then deletes the C:\documents and settings\administrator folder.
Running the Script
Now, you're ready to give the script a try. This part is easy. Place all the KiXtart, Robocopy, Save, and Copy files in a network folder. Then, to copy the user profiles from an old PC to a new one, complete the following steps:
- Prepare a new PC for use and make it ready to log on to the domain. Be sure to give it a name different from the old PC because both PCs must be on the network when you're copying from the old to the new. (After you've completed the copy, you can remove the old PC from the network and rename the new PC, if you like.)
- Use any domain account that has administrator privileges to log on to the old PC.
- On the old PC, click Start, Run and type the path to the savepc.bat file (e.g., C:\copyprofiles\savepc.bat).
- When savepc.bat is finished (after 3 to 5 seconds), restart the old PC and leave it at the logon prompt (you'll be tempted to skip the restart and just log off, but doing so leaves some profile files open and therefore uncopyable, so be sure to restart).
- Log on to the new PC with Domain Administrator privileges; click Start, Run and type the path to the copypc.bat file and the name of the old PC (e.g., C:\copyprofiles\copypc.bat oldpc).
Wait while the script completes the copying. The time required will vary depending on the number and size of the profiles on the old PC. When the copying is finished, the script opens Windows Explorer on the new PC and sends keystrokes to delete the C:\documents and settings\administrator folder. (Although I have full permissions to the C:\documents and settings\administrator folder and wasn't logged on as the administrator, I couldn't make VBScript delete the folder. The Deletefolder method reported success, but the folder remained in place.)
Wait until the folder has been deleted before doing anything. You might want to keep the old PC around a while (i.e., don't redeploy or dispose of it right away) in case you run into problems later with the copied information.
After the copying is finished, you might not be able to turn off the new PC by clicking Start, Shut Down. Press Ctrl+Alt+Del and select Shut Down from the Win2K Security menu.
Like usmt.exe, the script copies printer mappings and application shortcuts but doesn't copy printer drivers or other applications. You must reinstall your applications on the new PC.
To improve this script, you could add code that restarts the old PC after savepc.bat runs. Likewise, you could add code that shuts down or restarts the new PC after the copying is finished. You could also use the free PsExec utility, which you can download from the Sysinternals Web site at http://www.sysinternals.com/ntw2k/freeware/psexec.shtml, to perform all the steps from the destination PC.
Although my script isn't pretty, it does a sound job of copying user profiles and their settings directly from one Win2K PC to another. When used within a structured migration process, this automation technique is a real time-saver.