In-Depth

How To Migrate to Windows 7 Using the Microsoft USMT

Migrating user settings and data over to Windows 7 is much easier when you have the User State Migration Tool on your side.

When moving to a new OS, some organizations may only migrate certain components, like ODBC connections, third-party fonts and the Outlook profile. Other organizations migrate more, including scanning the local drives for known data types and applications settings. There's always something worth migrating.

Migrating user state, data and settings is a critical part of any Windows 7 deployment project. The Microsoft User State Migration Tool (USMT) 4.0 is a free set of tools you can use to migrate user state, data and settings as part of your Windows 7 deployment project. These tools are enabled by default in the Microsoft recommended deployment solutions (Microsoft Deployment Toolkit, or MDT, 2010 and System Center Configuration Manager, or SCCM, 2007), and for a good reason. If you don't take care of local data or settings, and that data is lost because you reimaged a user's machine, recovering that data will be expensive and difficult.

What Is the USMT 4.0?
The USMT 4.0 is the enterprise version of the Windows Easy Transfer utility available for Windows 7. It consists of a few command-line utilities:

  • ScanState.exe—the backup tool
  • LoadState.exe—the restore tool
  • USMTUtils.exe—the utility normally used to clean out the data store used by the USMT

Refresh and replace are the two deployment scenarios where the USMT 4.0 plays a big role. A refresh involves re-imaging the existing machine while keeping a local backup. A replace is just that—replacing a machine. In that scenario, you store the backup on a network share or sometimes on an external drive.

The latest version of the USMT 4.0 includes several new features:

  • Hard-Link Migration Store. This lets you store data locally without having to copy it to another folder. This reduces backup and restore time. It takes advantage of NTFS hard links for the migration, and actually never moves the data from the physical sectors on the disk.
  • Running ScanState Offline. This lets you do backups from within the Windows Preinstallation Environment (WinPE). This is currently only available via the User-Driven Installation (UDI) components in SCCM 2007 and MDT 2010 Zero Touch, but will be available in upcoming versions of MDT (MDT 2012).
  • Volume Shadow Copy Support. When enabled, ScanState can use volume shadow copy service to snapshot files.
  • New Advanced Encryption Standard (AES) Encryption Options. You can now control the level of encryption in the USMT data store.
  • Configurable File Errors. These let you control what files and folders you can safely ignore with the /c command-line option (continue on error).
  • New Helper Functions. New helper objects allow for deeper control on what files and data are migrated.
  • Improved Space Estimation. The switch for estimating backup size (/p) is much more accurate in this release.
  • List of Files Being Migrated. A new switch (/listfiles) generates a text file listing all files included in the migration.
  • Local Group Migration. You can use a new section (<ProfileControl>) to configure the local group membership of users during the migration.

USMT System Requirements
The USMT 4.0 supports the following source and destination OSes:

  • Source OSes
    • Windows XP
    • Windows Vista
    • Windows 7
  • Destination OSes
    • Windows Vista
    • Windows 7

As far as crossing processor platforms, the USMT 4.0 will support 32-bit to 64-bit migration, but not 64-bit to 32-bit.

What Does USMT Migrate?
In the USMT, XML templates control the data being migrated from the machine. The default templates migrate the following:

  • Accessibility settings
  • Address book
  • Command-prompt settings
  • Desktop wallpaper (not migrated when using offline backup)
  • Encrypting File System (EFS) files
  • Favorites
  • Folder options
  • Fonts
  • Group membership
  • Internet Explorer settings (not migrated when using offline backup)
  • Microsoft ODBC settings
  • Mouse and keyboard settings
  • Network drive mapping
  • Network printer mapping (not migrated when using offline backup)
  • Offline files (not migrated when using offline backup)
  • Phone and modem options (not migrated when using offline backup)
  • Remote Access Service (RAS) connection and phone book (.pbk) files
  • Regional settings (not migrated when using offline backup)
  • Remote Access
  • Taskbar settings (not migrated when using offline backup)
  • Windows Mail (Microsoft Outlook Express Mail, or .dbx, files are migrated from Windows XP)
  • Windows Media Player (not migrated when using offline backup)
  • Windows Rights Management

In addition to this list, the USMT also migrates settings for some 30 applications and many known file types. Please check the USMT documentation (USMT.CHM) for a detailed list.

Office 2010 Support
The original version of the USMT 4.0 doesn't support Office 2010. There was an update released in February 2011 that adds support for Office 2010. If you're using SCCM 2007 OS deployment (OSD) with MDT 2010 Zero Touch, you need to update the ZTIUserState.wsf with the new version numbers. You'll find detailed information here.

When using MDT 2010 and SCCM 2007, these will generate the necessary command lines for ScanState and LoadState. These drive the fully automated process in the background, but you'll most likely want to customize what data is being backed up by the USMT.

In the USMT 4.0, data and settings are defined as either data within a user profile or data outside a user profile. With command-line switches, you can define what profiles are being backed up. By default, the USMT will migrate every profile on the machine. The USMT will only migrate local profiles (local accounts as well as domain users). You can't point the USMT to a server share used for roaming profiles.

You can use the following switches to the ScanState command to limit the number of profiles you'll be backing up. These switches will configure the USMT to only back up profiles logged on to within the past 60 days:

/ue:*\* /uel:60

Another way to limit the data being backed up is to configure the XML templates. The USMT comes with several default templates. You can also create your own templates. Here's a sample that will migrate all text files in the C:\Demo1 folder, and the entire C:\Demo2 folder:

<pre><?xml version="1.0" encoding="UTF-8"?>
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/filemig">
<component type="Application" context="System">
<displayName>File Migration Test</displayName>
<role role="Data">
<rules context="System">
<include>
<objectSet>
<pattern type="File">C:\Demo1\* [*.txt]</pattern>
<pattern type="File">C:\Demo2\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>
</migration></pre>

When using MDT 2010 Lite Touch, you need to store your custom template in the deployment share\USMT folder. Then update the rules (customsettings.ini) with the following settings:

USMTMigFiles001=MigApp.xml

USMTMigFiles002=MigUser.xml

USMTMigFiles003=YourTemplate.xml

When using SCCM 2007 OSD and MDT 2010 Zero Touch, you need to store your custom template in the USMT Package folder. Then update the settings package with the following settings:

Properties=OSDMigrateConfigFiles,OSDMigrateMode
OSDMigrateMode=Advanced
OSDMigrateConfigFiles=Miguser.xml,Migapp.xml,YourTemplate.xml

Testing the USMT
When working with the USMT, you can take the following approach when testing templates you've created:

  • Run a backup, either manually or via a task sequence, from a live machine in your environment. A backup is non-destructive and you can run it multiple times.
  • Deploy your corporate image to a virtual machine (VM).
  • Take a snapshot of the VM.
  • On the VM, restore the backup manually and see if you got the configuration right.
  • If you didn't, modify the template, run a new backup, restore the VM snapshot and try the restore again.

By using a VM for your testing, you can quickly test multiple templates in a matter of a few hours. That's much faster than doing a full image deployment every single time. Once you have verified that it works manually, you can test a full image deployment.

 

 

About the Author

Johan Arwidmark is a consultant, author and all-around geek specializing in enterprise-grade Windows deployment solutions. He speaks at several conferences each year, including the Microsoft Management Summit and TechEd, and has been recognized as a Microsoft Most Valuable Professional in Setup & Deployment.

Featured

comments powered by Disqus

Subscribe on YouTube