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 Problem
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.
The Solutions
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.