Migrating User Files and Settings from Windows XP to Windows 7

  • Article

Applies To: Windows XP

I’ll start with data migration purely based on the automation steps in the chain I listed in the first section and because there aren't many things that excite me more in the Windows 7 deployment space than hard-link migration. Think about the speeds of large file moves versus file copies; that is essentially the speed advantage that hard-link migration can have. If you're inpatient like I am, and you hate waiting 3-4 hours per computer for the user state to migrate from one operating system to another (especially considering the operating system plus applications combined often takes under 45 minutes), then you might appreciate hard-link migration like I do.

To be fair, you could use technologies and tactics like roaming profiles and folder redirection, and you could disallow the creation of local e-mail stores, at which point many of the problems associated with user state migration might go away. But in this case, I'll cover the traditional case of user state as part of the user's computer.

If you manage desktop computers, you probably have multiple users with files in every possible location on their computers, and there are settings like Internet Explorer favorites, known wireless network connections, and application settings that you want back in the new operating system. We can handle all of these things except for migrating the applications themselves. In most cases, we'll want to test the compatibility of older applications, and not necessarily attempt to migrate them in-place from Windows XP to Windows 7. Plus, we can completely automate the installation of managed applications at deployment time or capture them as part of the custom operating system image. I'll cover all of this in the next section when I talk about application management.

Bringing this back to user files and settings, we know that user data is typically stored in a couple of places:

  • "C:\Documents and Settings" in Windows XP

  • "C:\Users" in Windows Vista and newer versions of Windows

Then the question that begs to be asked is...

“Can't we use a utility such as Robocopy to move the files from "C:\Documents and Settings" to a folder somewhere on the network that is named for the computer and then copy them back to the "C:\Users" folder after we're finished?”

Well, yes and no; it isn't usually that simple though. Unless you have draconian standards and policies about where your users can save data on their local drives, this won't suffice. We also have to look through settings in the registry that we want to retain on the new computer, create and enable user accounts, and some of us might want to block some files from getting migrated. For example, you may not want Joe in the marketing department to store his 100 GB music and video collection on your managed computer, so we may want to block certain file types in the migration process (hopefully we let Joe know about this in advance so he has time to back up his media collection). On the other hand, Joe may not know where his Microsoft Office Outlook® PST files are, and even if we catch that PST file with our Robocopy command, he'll probably call the Help Desk asking where his cached e-mail is after we've installed Windows 7.

The good news is that we have a tool for this, the User State Migration Tool (USMT). The even better news is that if you use the Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager 2007 SP2, it's already part of the end-to-end operating system deployment process. You may have seen the migration demos from Windows XP to Windows 7 occur in as few as 18 minutes (yes, with several gigabytes of data being migrated, too), but if you haven't, check them out:

Both of these demos use the Hard-Link Migration feature for the Computer Refresh scenario (I defined this and other scenarios in the first section). In the old days, USMT could support a Computer Refresh without moving the files off the computer, but it was basically a file copy and double-instancing of files locally. Now the files do not move on the disk when migrating from Windows XP—we simply reassign pointers to files to the appropriate locations in Windows 7. The index of hard links consumes around 200 MB, so you don't need a lot of free disk space to use Hard-Link Migration. Think about how much faster it is to "move" a 1 GB file versus copy it to another location on the same disk; that is why Hard-Link Migration is so much faster. It doesn't really matter if we move 5 GB or 50 GB in the migration; the times will be pretty similar. The amount of time depends on the number of files we move and not the size of the files.

The User State Migration Tool is now part of the Windows Automated Installation Kit (AIK). The USMT installs simply through a file copy. After you install the Windows AIK, by default, the USMT tools for 32-bit and 64-bit operating systems are located in the "C:\Program Files\Windows AIK\Tools\USMT" folder.

You can download the Windows AIK from the following Microsoft Web site: Windows Automated Installation Kit for Windows 7.

You can perform a simple Computer Refresh with hard-link migration by using normal Windows 7 installation media along with USMT files on a USB drive I outline this process in a couple of locations:

This process will quickly migrate files from the default-created Windows.old folder when you install Windows 7 onto a computer running Windows XP. If you don't follow the default process and format the Windows partition during the installation process, Windows.old won't be there to migrate from. So remember to follow the default installation process to keep your data and create Windows.old.

You might be asking another question at this point...

"What if I am performing a Computer Replacement and the data needs to move from my users' old computer that is running Windows XP to my new computer that is running Windows 7?"

Computer Replacement is pretty common, and the tools are built to handle this. Normally, the data is passed from the old computer to a network share and then from the network share to the new computer. Both Configuration Manager and MDT can be used to automate the entire computer replacement migration process using a network share. You can even encrypt the migration store on the network (as Configuration Manager does by default) to ensure data stores cannot be compromised.

Another useful addition to the migration tools for Computer Replacement is support for Volume Shadow Copy. That means that we can gather files even while they are in use. One thing to point out with Computer Replacement is that you can't get the speed benefits from Hard-Link Migration, because we are at the mercy of physics moving the data to an external network location or external hard drive.

What about the types and locations of files that get migrated? The User State Migration Tool adds a new algorithm to find more user files than previous releases versions of USMT. The control file (migdocs.xml) uses shared and comprehensive file detection logic with Windows Easy Transfer. So if you used USMT in the past, and you had to extensively modify the previous control files (for example miguser.xml) to add file coverage, the new migdocs.xml should be a welcome addition.

There are other methods to move files between operating systems, but USMT was developed specifically to manage the migration of user data and to support as many mainstream options as possible for customers with a large number of computers to manage. USMT does a great job migrating user files and settings. For people who are looking for a user interface for USMT, I would recommend that you use it in conjunction with the Microsoft Deployment Toolkit or with System Center Configuration Manager. If you have used USMT in the past without a lot of success, the current version of USMT offers several enhancements to increase speed, flexibility, and process reliability to make the migration portion of your operating system deployment easier and more predictable.

In the next section, I'll take on the topic of application management, including application compatibility and automating application installation, as well as touch on hardware inventory and compatibility.