Developing

Article
03/05/2008

Published: June 30, 2006 | Updated: November 30, 2006

This section discusses the team roles, USMT components, and configuration considerations for the USMT. Figure 4 shows tasks completed during the Developing Phase.

Figure 4. User state migration Developing Phase activities

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Developing Phase of the initiative. Table 3 lists those roles and defines the focus areas for each role cluster. For more information about MSF Role Clusters, see Microsoft Solutions Framework at https://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 3. Roles and Responsibilities During the Developing Phase

Role	Focus
Product Management	Business requirements analysis Communications plan Conceptual design
Program Management	Budget Conceptual and logical design Functional specification Project plan and project schedule
Development	Creating and testing the USMT control files
User Experience	Localization and accessibility requirements Schedules Training plans Usage scenarios and use cases User documentation User requirements
Test	Test plan and schedule Testing requirements definition
Release Management	Application and hardware inventory Design evaluation Network discovery Operations requirements Pilot and deployment plan and schedule Working with IT Operations and the Security feature team

USMT Components

This section describes the major components of USMT:

Scanstate. The tool used to collect system state from the source system
Loadstate. The tool used to deposit user state on the destination system
.xml control files. Files that control the USMT migration process
Component manifests. Files that maintain lists of Windows Vista system configuration settings and data
Downlevel manifests. Manifest files that list and locate settings and data for previous versions of the Windows operating system (Windows XP and Windows 2000)

Figure 5 shows the USMT components, their relationships to each other, and at what point in the migration process they are used.

Figure 5. USMT components

Scanstate

During the execution process, Scanstate.exe creates the USMT3.mig file in the default store directory (or any directory defined by command-line settings). Scanstate uses the following components:

Scanstate.exe. This executable file runs on the source computer to capture user settings and files. A user can run Scanstate.exe to capture the settings stored in the registry and the files to which the user has permission. Alternatively, users can run Scanstate.exe in the Local System or Local Administrator security context, which permits unattended operation and capture of multiple user profiles. BDD 2007 scripts call Scanstate.exe during the deployment process.
MigSys.xml. When migrating from a source computer running Windows XP, this file controls which operating system and browser settings to migrate. Users can customize this file for specific needs.
MigApp.xml. This file controls which application settings are migrated from the source computer. Users can customize this file for specific needs.
MigUser.xml. This file controls which user folders, files, and file types to migrate from the source computer. Users can customize this file for specific needs.

Note BDD 2007 uses generic versions of the common three control files above. If User State Migration feature team members must customize these files, they can configure CustomSettings.ini (located in the Control folder) to specify the custom versions.

Config.xml. Create this file by using the /genconfig option in the Scanstate Command Prompt window. This file contains all settings defined by Component Manifests in Windows Vista or by Downlevel Manifests (these terms are described in the upcoming “Component Manifests” section) included with USMT 3.0. Specify this file in the Scanstate Command Prompt window. BDD 2007 does not currently use config.xml, but team members can call the file manually by specifying it in CustomSettings.ini. For detailed instructions on preparing a config.xml file, see “Appendix A:* *Creating and Customizing Config.xml.”
Custom.xml. Team members can create a custom control file to define custom rules for unique migration needs. For example, this file can contain information for migrating a custom business application. Team members can define multiple custom control files. Modify CustomSettings.ini to call custom.xml control files. For details on creating a custom.xml file, see “Appendix B: Creating a Custom.xml File.”

Note For additional information on Scanstate syntax, refer to the USMT Help file (USMT.chm) located in the USMT installation directory.

Loadstate

Loadstate is the command-line application that restores data to one or more user profiles. Loadstate runs in the context of an account with administrative privileges and loads the users’ profiles before they log on for the first time.

Note Loadstate requires network connectivity to a domain controller for a user’s domain to determine the security identifier (SID) of the destination profile.

Loadstate uses the following components:

MigSys.xml. When migrating to a Windows XP destination computer, this file controls which operating system and browser settings to migrate. Team members can customize this file for specific needs.
MigApp.xml. This file controls which application settings are migrated to the destination computer. Team members can customize this file for specific needs.
MigUser.xml. This control file controls which user folders, files, and file types to migrate to the destination computer. Team members can customize this file for specific needs.

Note BDD 2007 uses generic versions of the common three control files above. If team members must customize these files, they should configure CustomSettings.ini (located in the Control folder) to specify the custom versions.

Custom.xml. Team members can create a custom control file to define custom rules for unique migration needs. For example, this file can contain information for migrating a custom business application. Team members can define multiple custom control files. Modify CustomSettings.ini to call custom.xml control files. For details on creating a custom.xml file, see “Appendix A: Creating and Customizing Config.xml.”
Config.xml. Team members should not specify config.xml during Loadstate unless they are migrating only a subset of the settings and data from the Scanstate file. Specify this file on the LoadStateArgs item in CustomSettings.ini. For detailed instructions on preparing a config.xml file, see “Appendix A: Creating and Customizing Config.xml.”

Note For information on Loadstate syntax, refer to the USMT Help file (USMT.chm) located in the USMT installation directory.

Component Manifests

Component manifests are files that list settings and data important to components of Windows Vista. Scanstate reads this information during execution, creating a dynamic list of Windows Vista components, settings, and data to migrate.

Scanstate with the /genconfig option constructs a config.xml file from information obtained in component manifests that User State Migration feature team members can use to customize which data they will collect. A collection run without a custom config.xml collects all data that the component manifests, which cannot be modified, specify. Loadstate.exe does not use component manifests when the destination system is running Windows XP.

Downlevel Manifests

USMT includes a collection of manifests designed to act as component manifests when used to migrate user state from earlier versions of the Windows operating system. When migrating settings and data to a Windows Vista system from Windows XP or Windows 2000, these downlevel manifests determine which data to collect. Loadstate.exe does not use downlevel manifests when the destination system is running Windows Vista.

Technical Considerations

Technical considerations for planning with the USMT include:

The USMT supports migration from local user accounts and from computers that are members of workgroups. Use the /mu and /md options to migrate workgroup computers and local user accounts.
The USMT migrates user state information only for computers on a Microsoft network. However, by modifying the destination user name and domain, the USMT can support migration from Novell networks to Windows networks. Use the /mu and /md options to migrate computers on Novell networks.
The USMT migrates file permissions. A domain controller must be available, and the local Administrator account (or its equivalent) must be used at the destination computer to facilitate setting appropriate access control entries.
The USMT does not migrate passwords stored on the computer for applications such as the Microsoft Outlook® Express messaging client, Windows Internet Explorer®, and mapped network drives.
The USMT does not migrate drivers—except for print drivers, which the USMT attempts to migrate if driver support is available on the Windows installation CD. The User State Migration feature team can specify drivers in the distribution library. See the Computer Imaging System Feature Team Guide for more information.
The USMT can migrate application settings but not the applications themselves. The User State Migration feature team must reinstall applications on the target computers.

Note See the USMT release notes for more information about applications that must be installed before loading user state information.

The USMT supports the migration of multi-user computers. When a single computer has multiple profiles, each with unique user data, the User State Migration feature team must no longer execute the USMT for each user to capture all user states. The USMT can capture all user states during a one-time Scanstate execution—including both domain and local users. For more information about how to migrate computer systems with many users, see “Migrate Data on Computers with Multiple Users” in the USMT product documentation.
The User State Migration feature team can migrate Encrypting File Service (EFS) certificates to Windows Vista automatically by using the /efs:copyraw option. The User State Migration feature team must migrate EFS certificates to Windows XP systems manually. See “Appendix D: Importing and Exporting EFS Certificates” or the USMT product documentation in the USMT.chm file located in the USMT installation directory for usage details.
The USMT includes options to prevent migration of old profiles and to migrate specific profiles using command-line options.

Updating USMT Control Files from Previous Versions

Control files in previous versions of the USMT were .inf files, which USMT 3.0 does not support. However, the User State Migration feature team can use some information from previous custom.inf files. The USMT contains an XML reference in the XmlReference.htm file located in the USMT installation directory. Team members can translate settings from the original .inf files to XML by using this command reference. The team can also learn file structure by exploring the default .xml files and config.xml. For details on creating custom.xml control files based on .inf files, see “Appendix C: Converting Control Files from Previous Versions of the USMT.”

Milestone: Control Files Developed

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

At this milestone, shown in Table 4, the User State Migration feature team has prepared the files necessary for using the USMT and has created test cases.

Table 4. Deliverables

Deliverable ID	Description
USMT Control Files	The USMT files are complete.
USMT Test Cases	Test cases permit testing and stabilization.