I debated on what part 2 of this blog series should be - hardware and software compatibility or data migration. I chose data migration purely based on the automation steps in the chain I listed out in the first blog 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. If you're inpatient like me and hate waiting sometimes 3-4 hours for user state to migrate per computer when the operating system plus applications takes under 45 minutes in many cases, then you might appreciate Hard-Link Migration like I do.

To be fair, you could use technologies and tactics like roaming profiles, folder redirection and disallow creation of local email 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 desktops you probably have multiple users with files in every possible location on their PCs and there are settings like Internet Explorer favorites, known wireless network connections, application settings 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 compatibility of older applications and not necessarily attempt to migrate them in-place from Windows XP to Windows 7, plus we can completely automate installation of managed applications at deploy time or capture them as part of the custom operating system image. I'll cover all of that in the next blog 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, and
• "C:\Users" in Windows Vista and newer versions of Windows

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

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 we want to retain on the new computer, create and enable user accounts and some of us might want to block things from getting migrated. You may not want Joe in the marketing department to store his 100GB music and video collection on your managed PC, 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 backup 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 helpdesk asking where his cached email 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 (ConfigMgr) 2007 SP2, it's already part of the end-to-end OS deployment process. You may have seen the migration demos from Windows XP to Windows 7 occur in as little as 18 minutes (yes, with several gigabytes of data being migrated, too), but if you haven't check them out:

• As part of MDT
• As part of Configuration Manager
  

Both of these demos are using the Hard-Link Migration feature for the Computer Refresh scenario (remember I defined this and other scenarios in the first blog). 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 whereas 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 200MB, so you don't need a lot of free disk space to use Hard-Link migration. Again think about how much faster it is to "move" a 1GB file versus copy it to another location on the same disk; that is why Hard-Link Migration is so much faster and it doesn't really matter if we move 5GB or 50GB in the migration; the times will be pretty similar. Those times depend 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) (download it here) and USMT installs simply via a file copy. Once you install Windows AIK, the USMT tools for 32 and 64 bit by default are located in the "C:\Program Files\Windows AIK\Tools\USMT" folder.

You can perform a simple Computer Refresh using Hard-Link Migration and move from Windows XP to Windows 7 using normal Windows 7 install media (retail DVDs) and coupling that with USMT. I outlined the process in a video and on TechNet in written form. This will quickly migrate files from the default-created Windows.old folder when you install Windows 7 onto a Windows XP computer. Remember, if you don't follow the default process and format the Windows partition during the install process, then Windows.old won't be there to migrate from, so just follow the default install to keep your data and create Windows.old.

So you might be asking another question at this point...

Computer Replacement is pretty common as well and the tools are also 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 ConfigMgr 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 ConfigMgr 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 newest User State Migration Tool adds a new algorithm to find more user files than with previous releases versions of USMT. The control file (migdocs.xml) uses shared and comprehensive file detection logic with Windows Easy Transfer, so if you have used USMT in the past and 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.

I actually didn't set out to write this as an advertisement for the User State Migration Tool, but the truth is that the charter of USMT is to manage migration of user data and support as many mainstream options as possible for large customers. USMT does a great job in migrating user files and settings. Now for the people looking for a user interface for USMT, I would recommend 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 blog, 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.

Thanks and stay tuned,

Jeremy Chapman

Windows 7 Deployment