Migrating to Windows Vista Through the User State Migration ToolBy 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 ChallengesEach 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:
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 StrategiesBoth 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.
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:
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.
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 ScenariosThe 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.
This migration type typically uses a three-step process:
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.
This migration type typically uses a slightly different three-step process:
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 ProcessWhichever 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.
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 MigrationMicrosoft 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:
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 USMTUSMT 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.
Each XML file has a specific purpose.
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 ScenarioWhen 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 ScriptUSMT 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 TechnologiesIn 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 USMTIntegrate 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.
SummaryMigrations 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
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
.gif "https://msdn.microsoft.com/en-us/aa905115.3squares(en-us,MSDN.10).gif")
.gif "Overview of Migration Challenges"){kind=icon}
Overview of Migration Challenges.gif "Top of page"){kind=icon}
Top of page.gif "The structure of a user profile in Windows XP")
.gif "The side-by-side migration scenario")
.gif "The wipe-and-load installation migration scenario")
.gif "The migration process.")