Best Practices for Using USMT 2.6

By Eric Voskuil

The Microsoft Windows User State Migration Tool (USMT) version 2.6, which is available at no cost, provides a capable solution to the problem of preserving user state during migrations. With this latest release, which includes support for unattended migration, multiple users per machine, and support for Microsoft Office 2003, USMT has become an enterprise-class user state migration product. This article describes the issues associated with user state migration and shows what USMT 2.6 can do to minimize the impact of migration on users.

User State vs. Computer State

Think of the desktop software environment as divided between user and computer components and data—all of which is collectively known as state.Computer state (such as the operating system, installed applications, and system configuration) represents the platform on which users work. User state is the result of users’ work (such as user documents, data, and preferences). The Microsoft Group Policy configuration management system models configuration tasks based on this division, and a clean split between user state and computer state facilitates many aspects of configuration management, including platform migration. For example, the separation of user state and computer state data enables multiple users to share a single computer (user profiles), and it allows users’ settings to follow them (roaming user profiles).

From an information technology (IT) management perspective, in an ideal world, user state wouldn’t be bound to a particular platform, and users wouldn’t be permitted to affect computer state. Ensuring that users don’t have permissions to affect anything but their own user state is critical to maintaining this isolation model. Getting everyone to work with a Limited User Account (LUA) is one way to move toward this vision, but sometimes it is not easy to accomplish. However, community support for this effort is growing. For example, see the nonadmin wiki site, a great resource for related information.

Computer state migration is often not part of a deployment plan; and I don’t recommend in-place operating system upgrades on enterprise business desktops. For an in-depth discussion of this topic, see Upgrade or Wipe-and-Load: Choosing the Best Scenario for Deploying Windows XP Professional. Instead, platform deployment typically consists of deploying a new base image and, when the platforms come up on the network, “binding” applications, updates, standard settings, and policy that were not considered fundamental or static enough to be part of the base image. Deployment is an ideal time to clean up environments that have degraded over time and make another attempt at hardening computer state against users. For more information about image configuration and deployment, see Imaging: Overview in the TechNet Desktop Deployment Center.

User State Migration or Roaming User Profiles?

Before engaging in a user state migration, you must ask a basic question: Is there a reason to migrate user state? If there is, will the benefit outweigh the cost of implementing a solution? The benefit is generally a reduced loss of productivity, because users can more quickly adjust to new environments if they can maintain their personal preferences. In some very restrictive environments, such as with mandatory user profiles, there may be no user state to migrate. In other, highly managed environments, roaming user profiles and folder redirection may have been used effectively—in which case, user state may already be preserved independent of computer state.

When you have similar source and target platforms, it is worth considering the possibility of using roaming user profiles as a means of implementing user state migration. Many organizations prefer not to use roaming user profiles, especially if their users don’t roam. Roaming user profiles introduce a significant amount of network traffic and delay during the user logon and logoff processes (some of which can be mitigated by using folder redirection). These issues may be acceptable for the limited timeframe of a migration. However, the most notable drawback of this approach is that you cannot map settings from one location to another, and you are limited as to which settings get migrated.

If you are migrating users from a Microsoft Windows 98 to a Windows XP operating system, don’t even consider using roaming user profiles. However, if you’re moving users from Microsoft Windows 2000 to Windows XP, the settings in user profiles are consistent and using roaming profiles will work. The primary advantages are speed and ease of implementation, because locating and mapping settings for applications not provided by default with USMT can be time-consuming and difficult. With roaming profiles, you also have flexibility in terms of deployment timing, because you are taking a state snapshot at every logoff. For more information about user profiles, see Microsoft TechNet user profile Frequently Asked Questions.

Choosing a User State Migration Technique

If you determine that users’ state must be migrated to the new platform, the first step is to determine the appropriate method of collecting user state apart from the platform so that the platform image can be replaced and then the user state restored. Generally, this decision comes down to a question of the number of platforms. The investment in automation pays greater dividends for each additional platform. Table 1 summarizes the various techniques available.

Table 1. Methods for Migrating User State Using USMT 2.6

For a more in-depth discussion of these options, see Choosing a Method for Collecting User State in the Windows Server 2003 Deployment Guide.

For user-driven or manual migration, you should use the Files and Settings Transfer Wizard, which is a Windows XP accessory. For manual and scripted migration by IT professionals as well as centralized automation, you should download and use USMT 2.6. The number of computers targeted simultaneously using the centralized automation method will be effectively limited by available storage capacity and bandwidth (see “Determining Storage Requirements” below).

USMT Customization Options

USMT 2.6 contains two executable command-line tools—scanstate.exe and loadstate.exe—and several .inf files (as well as compiled help and supporting DLLs). In addition to command-line switches, USMT 2.6 supports extensive customization through the .inf files. You can modify these files or create new files to add new rules to the migration for the purpose of supporting applications that USMT 2.6 does not support by default, remove rules that cover data you do not want to migrate, and modify target locations for migrated data.

Note: You should not modify the four default files without first creating backup copies.

The .inf files are text instructions that include rules telling USMT what actions to perform. For example, they describe the files or registry settings to copy from specified source locations to specified target locations. If properly crafted, the rules are flexible enough to support execution on various platforms. Rules support wildcards, environment variables, and special variables that allow targeting of well-known folders (for example, %CSIDL_DESKTOP%) on any system. Before putting any rules into production, be sure to test them thoroughly.

Note: The help file installed with USMT 2.6 includes a detailed reference for command-line options and rule syntax.

Determining Storage Requirements

Your most significant infrastructure issue surrounding user state migration will probably be the temporary storage requirement for USMT data files. The recommended technique for estimating storage requirements is to sample a few representative desktops, multiply the resulting average by the number of users you’re going to migrate, and allow for a minimum 20 percent buffer in the store. Scanstate.exe includes a command-line option (/p) for estimating space requirements. To improve performance, ensure that the migration store is on a dedicated server and that it has a high-speed network connection. By default, USMT compresses state data before transferring it across the network. Typical system settings for storage accounts are about 5 MB per user, although local e-mail and certain types of user document storage can vary widely. Two gigabytes is a reasonable initial estimate for a user’s data collection size.

Note: For more detailed information, see the USMT 2.6 help file topic "Determining where to store data during migration".

USMT and Security

Early in the process, ask the following questions regarding loss of security data:

• Do desktops use Encrypted File System (EFS)?

• Do you need to preserve access control lists (ACLs) on user data?

• Is it acceptable to lose cached password information, such as passwords for mapped drives?

Scanstate.exe does not migrate file system or registry ACLs, and it decrypts encrypted files for migration when you use the /efs:decryptcopy command-line option, in which case it must run in the user’s security context. Cached password information is also not migrated. In many cases, these items will not be an issue, but you should consider them during the planning stages. For more information about the limitations of USMT 2.6 with respect to migration of security data, see Identifying Security Concerns in the Windows Server 2003 Deployment Guide.

When managing user data, data security should be a primary concern. To that end, ask the following questions:

• Do you have sufficient permissions to access user data for collection and restoration?

• How will you protect temporary USMT data storage access by other users?

• Do you need to have an audit trail of any administrator access to user data?

The Centralized Automation topic of the Windows Server 2003 Deployment Guide describes how to set up data collection so that data is automatically sent to a file server under the user’s security context. This means that the directory for the data in the store would be restricted to the user, providing a solution to the problems above. This concept is the same as the concept of a home directory; in fact, you could technically use existing home directories, but a dedicated server during the migration is recommended for performance reasons. Note that in multi-user mode, you must run scanstate.exe using an account with permissions to all user profiles. In this case, the temporary USMT data will be accessible to this account and not be restricted to only the user who owns the data.

With respect to the dedicated server, ask the following questions:

• Does your security policy allow you to store unencrypted user data on a file server?

• Does your security policy allow you to transfer unencrypted user data across the network?

• Do you have to comply with government standards regarding secure data disposal?

You can use EFS on the store to encrypt the data, and you can use IP Security (IPSec) to protect data as it traverses the network. To securely erase the temporary data from the file server after migration, you can use the built-in cipher.exe utility with the /w command-line option. See Managing Data Encryption During Your Migration for solutions to other security issues involving EFS.

Concern with security issues will vary by organization but should not to be taken lightly. After you have answers to all the questions outlined in this column, you can formulate your plan for a secure and successful state migration using USMT 2.6. For help setting up your team and getting it started, check out the User State Migration Feature Team Guide.

For More Information

About the Author
Eric Voskuil is a co-founder of DesktopStandard Corporation, and has led the development of enterprise desktop-management products since 1997. He holds a B.S. in Computer Science from Rensselaer Polytechnic Institute, is an IBM trained software developer and Microsoft MVP (Windows Server-Admin Frameworks), and is a former US Navy F/A-18 pilot and TopGun graduate.

As CTO of DesktopStandard, Eric Voskuil and his team have produced some of the most innovative and forward-looking enterprise desktop-management products on the market. His overriding philosophy-namely, that management products exist solely to make management tasks easier-has guided development to produce easy-to-use, powerful, standards-driven, integrated products that leverage pervasive technologies. You can reach Eric at eric@desktopstandard.com; his full bio is available at https://www.desktopstandard.com/ExecutiveBios.aspx.

  Print This Page

  Rate This Page