Microsoft Solution Accelerator for Business Desktop Deployment

On This Page

	Using This Guide
	Introduction
	USMT Process Overview
	Planning a User State Migration Project
	Developing USMT Configuration Files
	Stabilizing USMT Configuration

Using This Guide

This guide is intended to be used as a part of the Microsoft Solution Accelerator for Business Desktop Deployment. The focus of this document is to guide a specialist team through the User State Migration tasks and checkpoints. The User State Migration is part of the larger desktop deployment project and must be managed as such. This means that the decisions made during the User State Migration must align with the overall project goals and that the deliverables be well integrated into the total desktop deployment project.

Setting Up the Team

The specialist team responsible for ensuring the success of the User State Migration is the User State Migration Feature Team. A feature team is a cross-organizational team responsible for solving a defined problem. Within the Business Desktop Deployment (BDD) project, the User State Migration team is one of several feature teams that work with a lead team on the project.

Feature teams are an important component of the Microsoft® Solutions Framework (MSF) Team Model. The ability to split a large and complex project into smaller sets of related tasks allows work to be performed on many tasks in parallel, with the application of specialized expertise where needed. A great advantage of this approach is an enhanced ability to manage large projects with many simultaneous tasks.

However, for the approach to work it is vitally important that the teams synchronize their efforts and maintain active communications between each other and the project management team. This is particularly important in complex projects, where there is a danger that a feature team may focus on its portion of the project to the exclusion of the role they play in the overall project.

Communication

The team’s ability to communicate and cooperate both internally with each other and externally with other feature or function teams and project stakeholders is key to successful project implementation.

Within the team, each role is considered equally important and decisions are made jointly.

Across teams, and between individual feature teams and the project management team (defined as the lead team in this document), the process is more formalized, with well-defined pathways of communication. This formality does not prevent informal communication between the teams, which is encouraged, but it does ensure that important communications are well documented, occur at the appropriate level, and are directed to the appropriate team members.

An important consideration for feature teams is communicating with the project stakeholders, which typically includes various entities within the customer organization. To avoid confusion, incomplete or conflicting messages, or misunderstood expectations, it is important that all communications with stakeholders be routed through the project management team. This process ensures that management is always aware of the state of the customer relationship, and it helps enhance customer satisfaction in the deployment process.

Additional Guidance on the MSF Team Model

For additional guidance on the MSF Team Model, see the MSF Team Model white paper at http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

Top of page

Introduction

One of the most tedious and time-consuming tasks during a deployment of a Microsoft® Windows® operating system is that of identifying users’ data files on their current desktops, saving them, and restoring them back to the new workstation image.

In addition to users’ data files, it is often desirable to save users’ preferences (settings) as well. These preferences include items such as screen saver settings, Web browser favorites, and other similar features.

The combination of users’ data files and their preferences are referred to as the user state.

The Business Desktop Deployment (BDD) solution uses the User State Migration Tool (USMT) to save and restore the user state during the deployment process. This guide describes the development process for customizing the behavior of the USMT during workstation deployments.

Background

The work described in this guide typically starts in the Planning Phase of Microsoft Solutions Framework (MSF), when the project team decides what applications to deploy. It continues through the Developing and Stabilizing phases where the configuration files are coded, tested, and piloted until they are approved for release to the Deploying Phase.

The primary consumer of this guide is the MSF Development Role Cluster because most of this guide focuses on the development work needed to create USMT configuration files.

The USMT process uses the information obtained from the application inventory process and the general working knowledge of the information technology (IT) operations staff to derive the data and preference information to be collected.

Once defined, these configuration files are then given to the Test Role Cluster for testing, validation, and acceptance.

Prerequisites

This solution requires a copy of the USMT program. The solution uses the 2.5 release of USMT, which is included in the deployment server section of this solution download. It is also available for download from the Microsoft Web site at http://www.microsoft.com and on the Windows Server 2003 CD-ROM.

Assumptions

Those who use this system should be familiar with the concepts of migrating user state and how those concepts fit into the overall workstation deployment process.

It is also assumed that this development work will be done in a non-production lab environment. Since the USMT does not require complex infrastructure, in many cases the USMT developers share space and resources in the lab with the developers who are creating the workstation images. See the imaging solution guide for details on the lab requirements.

It is assumed that the USMT developers have the following:

Education and References

Microsoft TechNet and the Microsoft Web site (http://www.microsoft.com) offer white papers and other articles that can provide additional information and background on the USMT.

Detailed information on the configuration of the USMT is described in the UsmtInfCommands.doc file in the USMT folder, which is contained in the BDD Deployment Server Scripts package.

Top of page

USMT Process Overview

Figure 1 offers an overview of the USMT process. Note that the graphic includes an Envisioning Phase, which is the part of a project during which initial thinking and planning about a project occur. That phase ends with the scope of the project defined.

This guide does not include information about the project Envisioning Phase because this preliminary planning will have already taken place. This guide begins with the Planning Phase.

Figure 1: Overview of user state migration process
See full-sized image.

USMT Execution

A distinction should be made between the execution of the USMT during the workstation deployment and the development of the configuration files that are used during the workstation deployment.

During the deployment process, a technician runs a deployment wizard on the user’s desktop to be migrated. This wizard collects information about the user, the user’s computer, and the user’s applications. The wizard then runs the USMT (Scanstate.exe) to copy the user’s data files and preference settings from the workstation onto a network server. The deployment process installs a new Windows XP image on the hardware and then calls the USMT (Loadstate.exe) to copy the user’s data files and settings from the server onto the new workstation image.

Refer to the BDD deployment process documentation for a detailed description of the deployment process.

This guide does not detail the execution phase of the USMT previously described. It does address why and how to alter the configuration files that direct USMT’s behavior during the execution.

Figure 2 illustrates the high-level tasks that occur during the development of the USMT configuration files.

Figure 2: Overview of tasks for creating configuration files
See full-sized image.

User state migration development begins with identifying and prioritizing the applications in use throughout your organization. Because the application inventory is conducted by the application compatibility team in the BDD solution, the USMT team does not have to conduct its own inventory. Instead, the team can use the results of the inventory that the application compatibility team conducts.

Working with the application compatibility team, the supplemental application team, the user experience team, and the release management team, the USMT team prioritizes the applications that require application data and/or settings migration.

Because it is unlikely that the USMT developers will have in-depth knowledge of the applications to be addressed, it is important to identify someone in the organization who is a subject matter expert (SME) for each application. The SME assists the USMT team in identifying the data files and settings that are to be migrated as well as any other constraints the application may have, such as hard-coded locations.

Note: The supplemental application team that is responsible for packaging each application for a hands-free installation also needs access to the application SMEs. This ensures that the packaging team packages applications in a way that is consistent with the proper use of the application within the company.

After the USMT team establishes priorities, it works with the application SMEs to research and migrate the individual applications to determine the specific documents and settings that are to be migrated. This work is conducted in the lab.

Next, the USMT team builds the configuration files for the User State Migration Tool to migrate the data and settings.

Once the configuration files have been verified, they can be given to the testing team for validation and in turn provided to the release management team for inclusion in the deployment servers.

After the deployment servers have been upgraded and the rest of the project team is ready, the USMT files can be tested as part of the pilot deployment project.

Top of page

Planning a User State Migration Project

This section describes the team roles, establishment of the lab environment, and selection and prioritization of applications during the Planning Phase. It also identifies an application SME and the application files and settings. Figure 3 depicts the planning tasks accomplished during this phase.

Figure 3: USM Planning Phase activities
See full-sized image.

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 1 lists those roles and defines the focus areas for each of the different role clusters.

For more information about MSF team role clusters, see http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

Team Roles and Responsibilities During the Planning Phase of the Initiative

Establishing the Lab

During the planning stage, the lab environment, where all of the development work is conducted, is established. The USMT team does not necessarily need a separate lab. Typically they can use the lab infrastructure established by the imaging team, the application compatibility team, and the supplemental application team.

However, the USMT team must have the USMT 2.5 software and the base set of configuration scripts provided in the BDD solution. You can get these files from the BDD_Development_Server.zip file in the BDD_Solution_Accelerator.exe file. For more information on the solution packaging, refer to the “Getting Started” guide.

Selecting and Prioritizing Applications

Once the USMT team obtains a copy of the application inventory from the application compatibility team, they review the application inventory.

The USMT team typically addresses only those applications that will be redeployed during the deployment project. There is little use in migrating an application’s data and settings if the user will no longer have the application that uses these files.

Often a committee is established with representatives from the user experience, IT operations, application compatibility, supplemental application, USMT, and product management teams to review the application lists and decide which application will move forward and be redeployed during the deployment process and which applications will be retired. These decisions affect all of the teams on the committee but have particular significance to the supplemental application team and the USMT team.

When this review exercise is completed both the supplemental application team and the USMT team should have the same list of applications to address.

Prioritizing this application list helps the USMT team focus its attention on the applications in an orderly process. Often the applications are prioritized based on a combination of how pervasive an application is in the environment and the complexity of an application. The most pervasive and/or complex applications are listed first followed by the less pervasive and simpler applications.

Identifying an Application SME

Once the USMT team has a prioritized list of applications, it can start to address each application in priority order.

The USMT developers will not be experts on all of the applications in the enterprise. It is important for both the supplemental application team and the USMT team that a SME be identified for each application. This SME may not be an expert on the application but is the person identified as having the most overall experience with the application. The SME provides insight into how the organization installs, configures, and uses each application.

Identifying Application Files and Settings

The investigation and identification of each application starts in the Planning Phase and continues on through the Developing Phase of the deployment project.

Working together, the USMT developers and the application SMEs review each application and identify specifically what files or file types to migrate, what settings or preferences to migrate and where to store them, and where to place the files during the restore process on the new workstation.

The SME should assist with several key issues:

Note: If possible, store all user data under the user’s profile, either in %profile%\My Documents or %profile%\Application Data. The application SMEs should provide input into the feasibility of any data file relocation requirements.

Because there are expectations and dependencies across teams with respect to where data and settings are located, the USMT team, application SME, and supplemental application team should work closely with each other.

It is easy to dismiss saving and retrieving user preferences, but experience shows that users spend significant amounts of time restoring items such as wallpaper, screen savers, and other UI customizable features. In addition, most users do not remember how these settings were applied, and this increases the loss of productivity. So although theses items are not critical to migration success, migration of theses items often increases user productivity and overall satisfaction of the migration process.

Milestone: Deployment Plan Complete

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy guide for the Microsoft Solution Accelerator for Business Desktop Deployment.

Deliverables

Top of page

Developing USMT Configuration Files

This section discusses the team roles, USMT components, configuration considerations, and updates and known issues with the USMT. Figure 4 illustrates the tasks completed during the Developing Phase.

Figure 4: USM Developing Phase activities
See full-sized image.

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Developing Phase of the initiative. The following table lists those roles and defines the focus areas for each of the role clusters.

For more information about MSF team role clusters, see http://www.microsoft.com/technet/solutionaccelerators/msf/default.mspx.

Table 2 Team Roles and Responsibilities During the Developing Phase of the Initiative

USMT Components

This section describes the three components of USMT: Scanstate, Loadstate, and the configuration files.

Scanstate

Scanstate is the command-line tool that is used to copy the user settings from the current logged-on user. It also copies files the user has permission to access. Scanstate is controlled by a set of configuration files (.inf text files) that define what rules and actions Scanstate is to perform. The destination of Scanstate is controlled through command-line switches detailed in the USMTINFCommands.doc file located in the USMT application directory. During the execution process, USMT creates the Migration.inf file in the USMT destination directory that Loadstate uses to load the USMT data to the pre-defined locations.

Scanstate uses the following components:

Loadstate

Loadstate is the command-line application that restores the data to the user’s profile. Loadstate runs in the context of a local administrator and preconfigures the users’ profiles before they log on for the first time.

Note: Network connectivity to a domain controller for that user’s domain is required by the Loadstate to determine the SID of the destination profile.

Loadstate uses the following components:

USMT Configuration Considerations

Although the USMT is extremely flexible, and many special application considerations can be customized, a majority of applications can be categorized by using the following options:

Technical Considerations

Technical considerations for planning with the USMT include the following:

USMT Take All vs. Take Known Scenarios

When performing a migration with the USMT you can use one of two models: Take All or Take Known. These refer to the user’s registry (HKEY_CURRENT_USER). The recommended solution is to use the Take Known model.

The Take All model gets all of HKEY_CURRENT_USER. It:

The Take Known model takes only what is in the .inf files. It:

scanstate.exe \\server\share /i sysfiles.inf /i Migapp.inf /I Migsys.inf
/i miguser.inf /i UserData.inf /l \\server\share\scanlog.txt /v 7 /x /s /f /o /q

Updates and Known Issues

Updating the USMT Configuration Files

For comprehensive information on specific configuration files, see “User State Migration Tool—INF Commands.” This file (USMTINFCommands.doc) is in the USMT folder on the deployment server.

Known Issues with USMT

The following section identifies some known issues identified with using USMT.

Issue: Loadstate requires access to the destination user’s domain controller.

Fix: To associate the user profile SID with the profile that Loadstate creates, access to the domain controller is required. Organizations may want to complete migrations in an isolated network environment that does not have access to the production domain controllers.

There are two methods to work around this requirement.

Issue: Configuring USMT not to migrate cookies.

Fix: Cookie migration is controlled by the Migism.inf file and is modified by adding a semicolon as shown below:

[Virtual Computer Modules]
SCRIPT=script.dll
ACCESSIBILITY=sysmod.dll
COOKIES=sysmod.dll
PRINTERS=sysmod.dll
RAS=sysmod.dll
OSFILES=sysmod.dll
NETDRIVES=sysmod.dll
;LNKMIG=sysmod.dll

Issue: Loadstate restores cookies, printers on first user logon.

This issue is documented in Knowledge Base article 319854.

Loadstate populates: HKCU\Software\Microsoft\Windows\CurrentVersion\Run key with the USMT2RUN value pointing to the location of Loadstate.exe.

Fix: Use the UNC path, rather than a mapped drive, to run Loadstate. Otherwise users may run into problems later. Users must be connected to the network the first time they log on to the computer.

Optionally, you can copy the entire USMT directory (the USMT programs and INF files directory, not the user data store) to the temporary location on the user’s hard drive and update the USMT2RUN value to point to the local version of Loadstate.

Issue: CSIDL/USMT variables may not resolve on older operating systems.

Fix: The following are examples and workarounds:

Issue: Rerooting folders with variables to not append source directory.

You can use environment variables to move the contents and subfolders of C:\Data to the user’s My Documents folder without rerooting (appending) the Data folder. The USMT uses variables to decide whether the directory information should be appended to the target file, if an environment variable exists for a specific directory.

To create an environment variable on the source and destination computers (the target location cannot be …username\My Documents\Data):

SET CDATA=C:\Data

SET CDATA=C:\Documents and Settings\username\My Documents
Use a rule such as:
[Data Folder.Instructions]
CopyFiles=CopyDataFiles

[CopyDataFiles]
dir=%CDATA%\*

Milestone: Control Files Developed

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy guide for the Microsoft Solution Accelerator for Business Desktop Deployment.

Deliverables

Top of page

Stabilizing USMT Configuration

During the Stabilization Phase, the USMT team works with the release management team to identify and correct bugs in the USMT configuration files. Figure 5 illustrates the Stabilizing Phase activities.

Figure 5: USM Stabilizing Phase activities
See full-sized image.

Testing the USMT

After the USMT configuration scripts have been updated, they must be tested before being included in the deployment server.

The USMT developers should work in conjunction with the application SMEs to test the collection and restoration of the application data files and settings.

To test each application, workstations in the lab must be configured with the original application. Images of production workstations are often useful as the source computers for these tests because they accurately reflect the production configurations. In addition, destination computers with the new Windows XP image will be needed as the target or destination of the USMT data.

You can run the USMT process manually on the source and destination computers in order to speed the testing process. You can do the application tests individually or you can group them in a logical sequence, such as all tax department applications.

Once these manual tests are successful, you can transition the USMT configuration files to the release management team for inclusion in the pilot testing. During the pilot, end-to-end USMT testing will be done as part of the automated deployment process.

Updating the Deployment Server

In order for the deployment process to use the modified configuration files, these updated files must be copied to the deployment servers.

The updated configuration files must be copied into the USMT folder on each of the deployment servers. Once completed, the USMT will use these updated files the next time the USMT is executed.

Milestone: Deployment Readiness Review

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy guide for the Microsoft Solution Accelerator for Business Desktop Deployment.

Deliverables

Top of page

11 of 16