Migrating to Windows Vista Through the User State Migration Tool

By Nelson Ruest and Danielle Ruest

Abstract

Each time a new version of an operating system becomes available, organizations begin a process that eventually leads to a massive deployment of the new technology. One of the key factors that can help make this deployment a success is user-setting migration—specifically, the capture of all custom settings on existing systems and the restoration of those settings to newly deployed systems. With Microsoft Windows Vista, this activity is facilitated by a revamped Microsoft Windows User State Migration Tool (USMT), which should help ensure that migrations are smooth and error free. This paper describes how migrations work in both corporate and personal situations and how to make these migrations a success.

On This Page

Overview of Migration Challenges
Different Migration Strategies
Enhancements in Windows Vista for Migration
Migration Scenario
Summary

Overview of Migration Challenges

Each time a new version of an operating system becomes available, organizations that want to take advantage of the new feature set begin a process that eventually leads to a massive deployment of the new technology. One of the key factors that can make this deployment a success is user-setting migration—specifically, the capture of all custom settings on existing systems and their restoration to newly deployed systems. For the purpose of this paper, migrations focus on this data capture and restoration process, whereas deployments focus on the replacement of an operating system. With Microsoft Windows Vista, migrations are facilitated by a revamped Microsoft Windows User State Migration Tool (USMT), which should help ensure that they are smooth and error free. This paper describes how migrations work in both corporate and personal situations and how to make these migrations a success.

Two tools are provided for settings migration, depending on the migration scenario:

• PC-to-PC migrations use the PC Migration Assistant, a graphical interface to the migration process. This tool supports personal migrations—migrations either performed in noncorporate environments or corporate migrations performed by individual users.
• Remote migrations or migrations that are automated using USMT version 3.0, a command-line interface that provides a scriptable migration process, present a standard, reusable process for corporate migrations.

Both tools are described here, although this paper focuses primarily on USMT because by default this tool includes more comprehensive capabilities than the graphical tool.

In organizations large and small, deployment success typically relies on reduced complexity and reduced diversity. Successful operating system deployments typically depend on tested processes that are repeatable with a high degree of accuracy. This is one reason why diversity must be reduced as much as possible—the more diversity there is in a deployment process, the more likely that process is to fail.

To reduce complexity and increase standardization, organizations should select a combination of hardware and software to distribute to all users. This means putting in place a standard operating environment (SOE) that can serve as the baseline for all system installations. The SOE should include standard hardware drivers, core operating system features, core productivity applications-especially if they are under volume licensing, and core utilities. It should also include a standard set of security features as outlined in the organization’s corporate policy. Using such an SOE can vastly reduce deployment challenges.

In migration planning, both organizations and individuals should first identify what to migrate, including personal user settings, applications and application settings, personal data files, and folders. Identifying the applications to be migrated is especially important because there is no point in capturing data about applications that are to be phased out. One of the most important concepts in settings and data migrations is that the information restored to the target must consist of only the information that is required. Even if the source capture is more comprehensive than the restore for backup purposes, restoring data or settings for applications that won’t be installed on the target system is redundant and can introduce instability in newly deployed machines.

The complexity of the settings-transfer process can be compounded when multiple users share a system. In such a case, the source machine contains multiple user profiles, each of which must be protected. This is another opportunity for validation. Profiles can be obsolete because users no longer access this machine or are no longer with the organization. Similarly, in personal migration scenarios, migration should address only the profile or profiles that will be reused on new systems.

Different Migration Strategies

Both personal and organizational migrations may involve several different types of deployments. These can include the basic system upgrade (or in-place installation) of the new operating system; the side-by-side computer replacement, which involves moving data from one computer to another; and the clean (or wipe-and-load) installation, which reuses the same system but erases the hard disk to perform a new installation. Of the three scenarios, the in-place upgrade is by far the easiest to manage because it performs a nondestructive update of the system. In any case, creating a backup of the system before performing any type of migration, even the upgrade, is a best practice that everyone should follow.

In a Microsoft Windows XP or Microsoft Windows 2000 system, settings and personal data are stored within the user profile (see Figure 1). This profile includes a folder structure that is designed to contain all the data users require for proper operation of the applications and tools they use-that is, if the applications and tools were designed for these operating systems. Legacy applications are often problematic in migration situations because they do not store either settings or data in default locations. In this case, it is necessary to identify where these settings and data are located on the system before migration can occur. Similarly, certain organizations use two or more folders for user data storage on a system. One is protected and the others are not. In a migration, all user folders need to be moved for a more successful migration.

Figure 1. The structure of a

user profile in Windows XP.

In corporate environments, especially those that use Microsoft Active Directory directory service, it is possible to simplify the migration process through the use of strategies that centralize the storage of user profiles. Two strategies support this objective. The first is to use roaming profiles. In this case, profiles are stored in a central location and are made available to users whenever they log on to a computer. In a system migration, there is no need to scan user settings from workstations, as they are already stored on a server. But, in a migration from an older version of Windows to Windows Vista, this method might not work because the profile structure in Windows Vista is different than that of the source operating system.

Another method of protecting user data is through folder redirection. Folder redirection uses a Group Policy extension to automatically redirect user data and settings to a central location. This allows organizations to protect user data and back it up regularly. Folder redirection supports the redirection of four key folders in the user profile:

• Application Data stores all application-specific settings.
• Desktop includes everything that is stored on the desktop.
• Start Menu includes all of a user's personal shortcuts.
• My Documents stores all user data. My Documents can also include My Pictures, which stores all user images.

Although folder redirection provides protection for most of a user’s data and provides support for migrations, migration tools are still required to capture 100 percent of a user’s data during migration. Folder redirection does not cover such items as Favorites and Templates (see Figure 1). By default, USMT supports the migration of all the elements listed in the first column in Table 1.

Table 1. Default Files and Settings USMT Version 3 Migrates

USMT Migrates

USMT Does Not Migrate

Microsoft Internet Explorer settings

Hardware-related settings

Drivers

Microsoft Outlook Express store

Passwords

Dial-up connections

Applications

Desktop

Synchronization files, .dll files, or other executable files Encrypting File System (EFS) certificates, although in some scenarios EFS certificates can be migrated if the target is Windows Vista

Phone and modem options

Accessibility options

Classic desktop

Command prompt settings

Favorites

Fonts

Folder options

Taskbar settings

Mouse and keyboard settings

Quick Launch settings

Screen saver selection

Sounds settings

Regional options

My Documents folder

My Pictures folder

My Videos

My Music

My Received Files

In addition, USMT can be customized to include supplementary elements because it uses files in the XML format as inputs to the migration process. In short, for a successful migration, a migration technology, such as USMT or the Migration Assistant, should be used.

Migration Scenarios

The three migration scenarios mentioned earlier are: upgrade, side-by-side, and wipe-and-load installation. Of the three, the first is the simplest because even if it involves an initial information capture for backup purposes, it often does not require the restoration of settings. The Windows Vista upgrade process will automatically roll back the upgrade and restore the user’s original desktop in the case of failure at any point before the first log on. Of course, few organizations today opt for the in-place upgrade because they prefer to use a process that replaces all the system contents. This complete replacement guarantees that once the PC is deployed, it is in a known state and does not include any leftover components from previous operating systems or previous use.

In fact, organizations often take advantage of new operating system deployment projects to perform PC cascades or rotations to move systems from one user to the other. This cascade begins with the acquisition of a new batch of systems to use as the central pool for deployment. These new systems include improved capabilities over existing systems and therefore are delivered to the organizations’ most demanding users. In turn, the PCs recovered from the first delivery become re-imaged and are delivered to a second community of users whose systems are recovered and cascaded down to other users, and so on. This rotational method requires the existence of a staging laboratory for system preparation. Because older systems are being rotated through this staging area, organizations often take advantage of this opportunity to properly clean all cases and system components, giving the receiving user the impression that the system is as new as possible. This scenario usually relies on side-by-side migration (see Figure 2) and is most commonly used by organizations that have existing obsolescence programs for PCs.

Figure 2. The side-by-side migration scenario.

This migration type typically uses a three-step process:

1. The original or source system is scanned and files and settings are copied in compressed format to an intermediate store.
2. In the second step, the new target system receives the SOE image as well as the required supplemental applications.
3. Finally, the user settings are restored to the target system.

Other organizations might already have PCs in place that can support the new operating system and prefer to limit user disruption by doing remote installations. In this case, they will perform wipe-and-load installation deployments (see Figure 3). These deployments are usually less costly because there is no need to transport all systems from one location to another.

Figure 3. The wipe-and-load installation migration scenario.

This migration type typically uses a slightly different three-step process:

1. The system is scanned and files and settings are copied in compressed format to an intermediate store.
2. In the second step, the hard disk is optionally reformatted and the SOE image and the required supplemental applications are installed.
3. Finally, the user settings are restored to the system.

Once again, Figure 3 lists the two USMT commands, although the Migration Assistant can also be used. Obviously, the Migration Assistant would be used only in interactive setups. Organizations that want to automate this process and apply it to massive numbers of PCs would script the USMT process.

Migration Process

Whichever migration type is used will require planning and forethought. Figure 4 illustrates the planning process for any migration. It begins with a comprehensive inventory of the contents of the source PC. Here, the key is to identify which applications exist on the system, and more specifically, which are actually in use by the users of this system. Unless organizations use a complete software-management system and strategy, it is very common to find applications that are no longer used on source systems. Perform this cleanup before beginning the migration, or invalid data could be migrated. For those applications that are to be included in the migration, it is important to validate with subject matter experts (SMEs) the components—settings and data—that must be migrated for each application. Once this is done, prepare a comprehensive script to ensure that all data is captured. USMT captures several application data types by default, but organizations might have custom applications that are not included in the default types. Use the USMT tools to modify and update the existing migration scripts or create custom scripts. Test custom scripts by actually performing a migration, capturing source data, storing it in an intermediate location such as a central file share, and restoring the data to a different system. Once again, validate the restore results with the SMEs. Refine the process as needed before releasing the script to the production deployment team.

Figure 4. The migration process.

By default, ScanState compresses all data during its upload to the interim store. This decreases both the time for the upload and the bandwidth required. Then, when data is transferred to target systems, LoadState downloads the entire compressed store and decompresses it on the target computer. It is possible to tell ScanState not to compress data during upload, but this should be used for troubleshooting only. It is highly recommended to use compressed stores during the actual migration.

Enhancements in Windows Vista for Migration

Microsoft has made migration tools available for several generations of Windows. For example, the previous version of USMT, version 2.6, supported migration from Windows XP or Windows 2000 to either 64-bit or 32-bit versions of Windows Server 2003 and Windows XP. The new release for Windows Vista, USMT version 3.0, has significant changes and improved capabilities. Here are some examples:

• ScanState and LoadState, two commands that are driven by some key scripts that are now in XML format.
• USMT provides the capability to move profiles that contain files encrypted with the EFS.
• Source operating systems include only Windows Vista, Windows XP, and Windows 2000. Older versions of Windows are not supported.
• Destination operating systems include Windows Vista and Windows XP only.
• If the destination is Windows XP, cookies, network drives, and printer settings will not be migrated.
• If Microsoft Outlook Express or Remote Access Settings is present, only the mail files for Outlook Express and the phone book files for Remote Access Settings are migrated if the target is Windows XP. If the target is Windows Vista, all pertinent settings are migrated as described in the migration manifests of the respective components.

In addition, each of the two commands includes several new features. For more information, see What’s new in USMT version 3.0 in the Getting Started with User State Migration Tool 3.0 guide at https://go.microsoft.com/fwlink/?LinkId=56486.

USMT 3.0 also loads operating-system settings. When the target system is Windows Vista, USMT will use the Component Manifests for Windows Vista to migrate operating-system settings. Windows Vista creates a manifest file for each component that is loaded with the operating system. This means that no matter which settings are captured with ScanState, LoadState will load only those settings that have a corresponding manifest file on the target computer. For Windows XP targets, USMT relies on a special script, MigSys.xml, because this version of Windows does not include manifests.

Default XML Files for USMT

USMT includes several default XML files to support migration. These files can be customized to meet organizational requirements. One key difference between USMT version 3.0 and previous versions is that when files are specified with the ScanState tool, they must also be specified with the LoadState tool. Different files are required depending on whether the migration target is Windows Vista or Windows XP.

• If the target is Windows Vista, use the MigApp.xml and the MigUser.xml files. In addition, it is possible to create or generate a Config.xml file.
• If the target is Windows XP, one more file, the MigSys.xml file, is required.

Each XML file has a specific purpose.

• MigApp.xml is used to control which application settings are migrated. The applications listed in this file can be included or excluded from the migration.
• MigUser.xml is used to identify which user folders, files, file types, and desktop settings are migrated. It does not control which users are migrated.
• MigSys.xml is typically only used for Windows XP targets and will contain information that controls operating system and browser settings to migrate. For Windows Vista migrations, USMT relies on the Repositories for Windows XP and Windows 2000 to identify data to migrate.
• Config.xml is a custom file that is created through a special ScanState switch, /genconfig. Ideally, this option is used to generate a custom configuration file that meets organizational requirements. To best use this option, first identify all the applications to be migrated. Then, load one system with each application. Run ScanState /genconfig on this system to capture the list of user, operating system, and application settings to migrate from any computer in the organization. This file is specifically required for control of migrated operating system components when either the source or the target is Windows Vista. If Config.xml is not included, USMT migrates all default components in Windows Vista.

Using the XML format standardizes the way administrators interact with the two USMT commands and facilitates customization. For more information, see How to change default behavior in the Getting Started with User State Migration Tool 3.0 guide.

Migration Scenario

When moving to Windows Vista, both organizations and users should have an improved migration experience because of the modifications to the Migration Assistant and USMT. Relying on XML files for USMT can provide a standard approach to migration customization. Now is a good time to test these migrations as much as possible to be prepared for the official Windows Vista release. Testing should include as complete a migration process as possible.

Create the Migration Script

USMT script creation can be as easy as generating a Config.xml file in support of the migration. After this file is created, it can be edited to determine what to include and what to exclude from the migration. The basic format for inclusion or exclusion is as simple as specifying yes or no in the XML file. Each component has a migrate = section; assigning a yes or no to this section tells USMT whether to include it.

Take the time to examine the content of each migration file in order to prepare a more complete migration. Because of their pure text format, XML files can be edited in a text editor such as Notepad.

Use Windows Vista Deployment Technologies

In addition to its improved migration tools, Windows Vista includes new capabilities for system imaging, remote system installation, and enhanced software deployment. The Windows Imaging format in particular provides enhanced deployment capabilities because it uses file-based disk imaging technology. Once captured, imaging files can be mounted as system volumes where they can be edited more easily, thereby providing simple maintenance and avoiding multiple re-imaging scenarios. WIM enables a single image to be deployed to different types of computer hardware with different language requirements and fully supports the SOE concept.

Perform Remote Migrations with USMT

Integrate Windows Vista’s improved deployment tools into deployment tests to provide end-to-end testing of this powerful new set of technologies. Specifically, integrate USMT scripts into the deployment test and learn which scripts work best in which situation. Organizations running Windows XP or Windows 2000 should take the time to create test environments that will allow their technical staff to become completely familiar with the technologies they will be using when Windows Vista is released. Organizations that are currently using Microsoft Systems Management Server (SMS) will be able to fully leverage the new USMT and integrate it with SMS’ Operating System Feature Pack to perform remote end-to-end deployments.

Summary

Migrations have often been a pain point for organizations as well as for individuals. Improvements in both the PC Migration Assistant and USMT will greatly facilitate these migrations in the future, but there is no substitute for trial and error. Organizations, especially, should consider investing in learning opportunities for these new tools and begin to build migration scenarios that will best meet their needs. These scenarios will greatly smooth the migration process and help prepare for the official Windows Vista deployment.

Danielle Ruest and Nelson Ruest
Danielle Ruest and Nelson Ruest (MCSE, MCT, MVP Windows Server) are IT professionals specializing in systems administration, migration, and design. They are authors of multiple books, notably two books published by McGraw-Hill, "Windows Server 2003: Best Practices for Enterprise Deployments", ISBN 0-07-222343-X, and "Windows Server 2003 Pocket Administrator", ISBN 0-07-222977-2, as well as "Preparing for .NET Enterprise Technologies", published by Addison-Wesley, ISBN 0-201-73487-7. They both work for Resolutions Enterprises Ltd. (https://www.reso-net.com/).