User State Migration Tool 3.0
You can use Microsoft® Windows® User State Migration Tool (USMT) 3.0 to migrate user files and settings during large deployments of Microsoft Windows XP and Microsoft Windows Vista™ operating systems. USMT captures desktop, and application settings, as well as user accounts and users' files, and then migrates them to a new Windows installation. Using USMT can help you improve and simplify your migration process. You can use USMT for both side-by-side and wipe-and-load migrations. If you are only upgrading your operating system, USMT is not needed.
In this guide
z Quick Start Checklist z Getting Started with USMT 3.0 z Planning Your Migration z Automating Your Migration z USMT Components z Using USMT 3.0 z Troubleshooting z XML ReferenceQuick links
z For syntax and command-line options, see USMT Components.
z For information about what has changed in this version of USMT, see What is New in USMT 3.0. z For answers to common questions, see Frequently Asked Questions.
z For information about the .xml files, see .xml Files.
z For instructions on how to change the default migration behavior, see Using USMT 3.0.
z For more information about the XML elements, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519). © 2006 Microsoft Corporation. All rights reserved.
Quick Start Checklist
This topic outlines the general process that you should follow to migrate files and settings. You should complete the following steps:
Plan for the migration
1. Determine what to migrate. This includes what users, applications settings, operating system settings, files, folders, and registry keys to include. 2. Determine where to store data. Depending on the size of your store, you can store the data remotely, locally, or directly on the destination computer. 3. Modify the migration .xml files and create custom .xml files if needed. If you want to modify the migration behavior (for example, migrate the My Documents
folder but do not migrate My Documents\My Music folder), then you should modify the rules in the appropriate migration .xml files and/or create any custom .xml files.
{If the destination computer is running Windows XP, you can modify MigUser.xml, MigApp.xml, and MigSys.xml.
{If the destination computer is running Windows Vista, you can modify MigUser.xml and MigApp.xml. To exclude certain operating system settings from the migration, you will need to create and modify a Config.xml file because MigSys.xml is not applicable in this scenario.
You can use MigXML.xsd to help you write and validate the .xml files. For more information about modifying these files, see Using USMT 3.0 and XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519).
4. Create a Config.xml file if you want to exclude any components from the migration. To create this file, specify the /genconfig option along with the other .xml files. For example, this command creates a Config.xml file using MigUser.xml and MigApp.xml:
scanstate /genconfig:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scanstate.log
5. Review the migration state of the components listed in the Config.xml, and specify "migrate=no" for any that you do not want to migrate.
Collect files and settings from the source computer
1. Back up the source computer.
2. Close all applications. If some applications are running during ScanState or LoadState, USMT may not migrate some data. For example, if Outlook is open, USMT may not migrate .pst files.
Plan for the migration
Collect files and settings from the source computer
Prepare the destination computer and then restore the files and settings
Note
3. Run ScanState on the source computer to collect files and settings using the ScanState command-line options. You should specify all of the (possibly modified) .xml files that you want ScanState to use. For example:
{This command creates a store for a destination computer running Windows Vista.
scanstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scan.log
{This command creates a store for a destination computer running Windows XP.
scanstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /i:migsys.xml /targetxp /v:13 /l:scan.log
Prepare the destination computer and then restore the files and settings
1. Install the operating system on the destination computer.2. Install all applications that were on the source computer. Though it is not always essential, it is good practice to install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved. Specifically, if the following applications are installed on the source computer, they must be installed on the destination computer before running LoadState: Lotus SmartSuite, RealPlayer Basic, and Quicken 2004 Home and Business.
3. Close all applications. If some applications are running during ScanState or LoadState, USMT may not migrate some data. For example, if Outlook is open, USMT may not migrate .pst files.
4. Run LoadState on the destination computer using the LoadState command-line options. Specify the same set of .xml files that you specified on the ScanState command line. However, you do not have to specify Config.xml unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, simply modify the Config.xml and specify the updated file with LoadState. Then, LoadState will only migrate the files and settings that you want to migrate. For more information about the how LoadState processes and migrates the data, see USMT Internal Workflow.
For example, this command migrates the files and settings to a destination computer running Windows Vista:
loadstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:load.log
This command migrates the files and settings to a destination computer running Windows Vista:
loadstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /i:migsys.xml /v:13 /l:load.log
5. Log off after you run LoadState. Some settings (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs on.
Getting Started with USMT 3.0
This section covers:z Introduction z Requirements
z What is New in USMT 3.0 z What Does USMT 3.0 Migrate? z Frequently Asked Questions z Example Scenarios z Additional Resources
Introduction
You can use Microsoft® Windows® User State Migration Tool (USMT) 3.0 to migrate user accounts during large deployments of Microsoft Windows XP and Microsoft Windows Vista™ operating systems. USMT captures user accounts, including desktop and application settings as well as a user's files, and then migrates them to a new Windows installation. Using USMT can help you improve and simplify your migration process. You can use USMT for both side-by-side and wipe-and-load migrations. If you are only upgrading your operating system, USMT is not needed.
USMT is intended for administrators who are performing automated deployments. If you are only migrating the user states of a few computers, you can use the Files and Settings Transfer Wizard for computers running Windows XP, or Windows Easy Transfer for computers running Windows Vista. USMT enables you to do the following:
z Configure your migration for your situation, using the migration rule (.xml) files to control exactly which user accounts, files and settings are migrated and how they are migrated. For more information about how to modify these files, see Using USMT 3.0.
encounters a file that is in use that it did not migrate.
Notes
z If the source computer is running Windows Vista, you need to run in "Administrator" mode. To run in "Administrator" mode, right-click
Command Prompt, and click Run As Administrator.
z If the source computer is running Windows XP, you need to run ScanState from an account with administrative credentials. z For more information about the how ScanState processes and stores the data, see USMT Internal Workflow.
Note
The application version that is installed on the destination computer should be the same version as the one present on the source computer. USMT does not support migrating an older version of an application to a newer version — except with Microsoft Office, which USMT can migrate from an older version to a newer version.
Note
USMT will fail if it cannot migrate a file or setting unless you specify /c. When you specify /c, USMT will ignore the errors, and log an error each time it encounters a file that is in use that it did not migrate.
Note
If the destination computer is running Windows Vista, you need to run in "Administrator" mode. To run in "Administrator" mode, right-click Command
z Automate your migration using the two USMT command-line tools, which control collecting and restoring the user files and settings. For more information, see USMT Components and Automating Your Migration.
In this topic
z Overviewz Benefits and assumptions
Overview
USMT includes two command-line tools named ScanState and LoadState, a set of modifiable .xml files (MigApp.xml, MigSys.xml, and MigUser.xml), and various internal files. In addition, you can create custom .xml files if needed, and you can create a Config.xml to specify what to exclude from the migration.
First you run ScanState on the source computer, specifying your desired .xml files that control what gets migrated to the store. ScanState compresses the files and settings and stores them as an image file (Usmt3.mig) in the location that you specify. Then, you run LoadState on the destination computer, specifying your desired .xml files that control what gets migrated from the store, and where the data is migrated to on the destination computer. LoadState migrates the files and settings from the store to the destination computer. Depending on what you want to migrate, you can specify any number of .xml files on the command lines using the /i option. In most cases, you should specify the same set of .xml files on both command lines. The .xml rules enable you to:
z Choose what to copy and what not to copy
z Arbitrate conflicts between the source computer and destination computer z Modify where the data is migrated to on the destination computer z Emulate missing settings
z Remove settings from the destination computer
Benefits and assumptions
Requirements
In this topic
z Supported operating systems z Software requirements z Hard disk requirements
Supported operating systems
USMT does not have any explicit RAM or CPU speed requirements for either the source or destination computers. If your computer complies with the system requirements of the operating system, then it will also be able to run USMT. You will also need a large enough intermediate store to hold all of the migrated data and you will need the same amount of hard disk space on the destination computer for the files and settings.
The following are the supported operating systems for USMT 3.0.
Benefits Assumptions
USMT 3.0 benefits businesses that are deploying Windows operating systems in the following ways:
z Reduces the cost associated with inefficient migration techniques and processes.
z Eliminates the time it takes to manually copy and transfer files and settings.
z Reduces end-user downtime while they recustomize their desktop and find missing files.
z Reduces help-desk calls from users who are recustomizing their desktop.
z Reduces the time needed for the user to become familiar with the new operating system.
z Increases employee satisfaction with their migration experience.
It is assumed that IT professionals using USMT understand the following: z The navigation and hierarchy of the Windows registry.
z The files or file types that applications use.
z How to extract application and setting information manually from internal development groups and non-Microsoft software vendors.
z The basics of XML.
Operating Systems ScanState (source computer) LoadState (destination computer)
Microsoft Windows 2000 Professional with Service Pack 4 X
Microsoft Windows XP Home with Service Pack 2 X X
Microsoft Windows XP Professional with Service Pack 2 X X Microsoft Windows XP Professional x64 Edition with Service Pack 2 X X
32-bit versions of Microsoft Windows Vista* X X
64-bit versions of Windows Vista* X X
Notes
Software requirements
z Close all applications before running ScanState or LoadState. If some applications are running during ScanState or LoadState, USMT may not migrate some
data. For example, if Outlook is open, USMT may not migrate .pst files.
z Must run in Administrator mode in Windows Vista. When running ScanState and LoadState on Windows Vista, you need to run the tools in “Administrator”
mode from an account with administrative credentials to ensure that all specified users are migrated. This is because User Access Control (UAC) is turned on in Windows Vista. To run in this mode, click Start, click All Programs, click Accessories, right-click Command Prompt, click Run as administrator, and then specify your LoadState or ScanState command. If you do not run USMT in “Administrator” mode, only the user profile that is logged on will be included in the migration.
z Must run ScanState on Windows XP from an account with administrative credentials. If you do not, then some operating system settings will not migrate.
For example, wallpaper settings, screen saver selections, modem options, media player settings, and RAS connection phone book (.pbk) files and settings. z Install applications before running LoadState . Though it is not always essential, it is good practice to install all applications on the destination computer
before restoring the user state. This ensures that migrated settings are preserved. Specifically, if the following applications are installed on the source computer, they must be installed on the destination computer prior to running LoadState: Lotus SmartSuite, RealPlayer Basic, and Quicken 2004 Home and Business.
Hard disk requirements
To determine your hard disk requirements, ensure that there is enough available space in the store location and on the destination computer.
z Store - Ensure that there is enough available space for the user state. You should base your calculations on the volume of e-mail, personal documents, and system
settings for each user. The best way to estimate these is to survey several average desktops to estimate the size the store that you will need. You can create a space-estimate file (Usmtsize.txt) using the /p option to help determine whether there will be enough available disk space.
z Destination computer - The destination computer will need enough available space for the following:
{Operating system {Applications
{Size of the uncompressed store
{Twice the size of the largest file that will be migrated.
You will need the last two items listed because when you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer. The files are decompressed (and decrypted if necessary) during this process. Then, LoadState transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file.
What is New in USMT 3.0
In this topic
z Overall changes from USMT 2.6 z ScanState changes
{New command-line options {Changed command-line options z LoadState changes
{New command-line options {Changed command-line options
Overall changes from USMT 2.6
z The migration behavior is now controlled by .xml files instead of .inf files. Because of this change, there are also the following changes:
{You can use the same MigUser.xml and MigApp.xml files to migrate to computers running Windows XP and computers running Windows Vista. This means that the migration will require fewer resources for organizations that are migrating to both operating systems. (MigSys.xml is not applicable when the destination computer is Windows Vista.)
{Unlike previous versions of USMT, the .xml files are not copied to the store. Because LoadState needs the .xml files to control the migration, you will need to specify the same set of .xml files on the ScanState and LoadState command lines.
{You can select what to migrate and what to exclude by creating a Config.xml file using the /genconfig option. z Must run from administrator account.
{When running ScanState and LoadState on Windows Vista, you need to run the tools in “Administrator” mode from an account with administrative credentials. To run in this mode, click the start button, click All Programs, click Accessories, right-click Command Prompt, click Run as administrator, and then specify your LoadState or ScanState command.
{In addition, you must run ScanState on Windows XP from an account with administrative credentials, or some operating system settings will not migrate. z USMT 3.0 migrates EFS files and certificates to computers running Windows Vista.EFS files and certificatesare migrated automatically to computers
z USMT does not support any of the Windows server operating systems or any of starter editions for Windows XP or Windows Vista.
Note
USMT will fail if it cannot migrate a file or setting unless you specify /c. When you specify /c, USMT will ignore the errors, and log an error each time it encounters a file that is in use that did not migrate.
running Windows Vista when you specify the /efs:copyraw option on the ScanState command line.
z You can encrypt the store. You can encrypt the store with the /encrypt option using an encryption key (password). You can specify the key using either a file or in plain text.
z USMT 3.0 is faster and more robust than previous versions. For example, USMT 3.0 can migrate more user accounts than USMT 2.6.
z By default, all users are migrated. You can use /ui, /ue and /uel to change this behavior.
z For the most part, the .xml files migrate the same settings that the .inf files migrated in version 2.6. However, there are a few changes. For more
information, see What Does USMT 3.0 Migrate?. z USMT 3.0 migrates access control lists (ACL's).
z The following features that were present in USMT 2.6 will not be available in USMT 3.0:
{Some of the older applications that were supported by USMT 2.6 are not supported with USMT 3.0. For more information, see applications settings. {You can only specify which users to include and exclude using the command line. You cannot specify users in the migration .xml files or in Config.xml. {USMT 3.0 does not migrate files and settings from computers running Windows 95, Windows 98, Windows Millennium Edition, or Windows NT
Workstation 4.0.
{USMT 3.0 does not migrate files and settings to computers running Windows 2000 and older operating systems.
{When the destination computer is Windows XP, USMT 3.0 will not migrate users’ cookies, network drives and printers. Also, for Outlook Express and RAS settings, USMT 3.0 will only migrate the mail (.dbx) files and phone book (.pbk) files.
ScanState changes
ScanState has new command-line options, and command-line options that have changed.
New command-line options
The following are new command-line options for ScanState.
Command-line options that have changed
The following command-line options have been changed for ScanState in USMT 3.0.
LoadState changes
In this version of USMT, there are new LoadState command-line options and options that have changed.
New command-line options
The following are new command-line options for LoadState.
Option Explanation
/config Specifies the Config.xml file that ScanState should use to create the store. /encrypt Encrypts the store with the specified key.
/genconfig Generates a Config.xml file, but does not create a store.
/targetXP Optimizes ScanState when the destination computer is running Windows XP. /uel
(User exclude based on last login)
Migrates only the users that had logged onto the source computer within the specified time period. /ue
(User exclude)
Excludes the specified user(s). /nocompress Disables compression of data.
Option in USMT
2.6 Explanation for USMT 3.0
/all This option is now the default.
/user This option has been replaced by the /ui option. /ui This option now specifies to include the specified users. /compress[+/-] This option has been replaced by the /nocompress.
Storepath Specifying Storepath is now optional when using the /genconfig option to create a config.xml file.
/efs:copyraw When migrating to a computer running Windows Vista, EFS certificates migrate automatically when you specify this option. For more information, see How To Migrate EFS Files and Certificates.
/v The accepted values for VerbosityLevel have changed in this version. /test
/x /u /f /s
These options are no longer supported.
Option Explanation
Command-line options that have changed
The following command-line options have changed in LoadState in USMT 3.0. For more detailed information about these options, see LoadState Syntax.
What Does USMT 3.0 Migrate?
In this topic
z User data
z Operating system components z Supported applications z What USMT does not migrate
User data
z Folders from each user profile. When you specify MigUser.xml, USMT migrates everything in a user’s profiles including the following:
My Documents, My Video, My Music, My Pictures, Desktop files, Start Menu, Quick launch settings, and Favorites.
z Folders from the "All users" and Public profile. When you specify MigUser.xml, USMT also migrates the following which are from the "All users" profile (in
Windows XP) or the Public profile (in Windows Vista):
Shared Documents, Shared Video, Shared Music, Shared Desktop files, Shared Pictures, Shared Start Menu, and Shared Favorites.
z File types. When you specify MigUser.xml, USMT migrates the following file types. ScanState searches the fixed drives and collects the files with any of these
extensions. The asterisk (*) stands for any single letter. For example, .xla, .xlb, .xls, and so on.
.qdf, .qsd, .qel, .qph, .doc, .dot, .rtf, .mcw, .wps, .scd, .wri, .wpd, .xl*, .csv, .iqy, .dqy, .oqy, .rqy, .wk*, .wq1, .slk, .dif, .ppt*, .pps*, .pot*, .sh3, .ch3, .pre, .ppa, .txt, .pst, .one*, .mpp, .vsd, .vl*, .or6, .accdb, .mdb, .pub
z Access control lists. USMT 3.0 migrates access control lists (ACLs) for files and folders from computers running both Windows XP and Windows Vista. For
example, if you migrate a file named File1.txt that was read-only for User1 and “full control” for User2, these settings will still apply after the migration on the destination computer.
Operating system components
USMT 3.0 migrates the following operating system components./decrypt Decrypts the store with the specified key. /nocompress Specifies that the store is not compressed. /ui
(User include)
Migrates the specified user(s). /ue
(User exclude)
Excludes the specified user(s). /uel
(User exclude based on last login)
Migrates only the users that had logged onto the source computer within the specified time period..
Option in USMT 2.6 Explanation for USMT 3.0
/compress[+/-] This option has been replaced by the /nocompress option.
/mu This option has been modified so that OldUserName is never optional.
/md This option has been modified so that OldDomain is never optional, and you can now specify this option more than once on the command line. /all This option is now the default.
/user This option has been replaced with the /ui, /uel, and /ue options. /v The accepted values for VerbosityLevel have changed in this version. /test /x /u /f /s /ix /rollback /efs:recover
These options are no longer supported.
Note
Some settings like fonts, wallpaper, and screensaver settings are not applied by LoadState until after the destination computer has been restarted. For this reason, you should log off after you run LoadState.
When the destination computer is running Windows XP, the following components are migrated when you specify MigSys.xml.
When the destination computer is running Windows Vista, the following components are migrated by default using the manifests.
Supported applications
Though it is not always essential, it is good practice to install all applications on the destination computer before restoring the user state. This ensures that migrated settings are preserved. Specifically, if the following applications are installed on the source computer, they must be installed on the destination computer prior to running LoadState: Lotus SmartSuite, RealPlayer Basic, and Quicken 2004 Home and Business.
When you specify MigApp.xml, USMT 3.0 migrates the settings for the following applications: z Accessibility settings
z Classic desktop z Command prompt settings z Dial-up connections z Favorites z Folder options z Fonts z Taskbar settings
z Microsoft Internet Explorer settings (all versions through version 6.0) z Microsoft Open Database Connectivity settings
z Microsoft Outlook Express mail (.dbx) files z Mouse and keyboard settings
z Multimedia settings z Phone and modem options
z RAS connection phone book(.pbk) files z Regional options
z Remote Access z Screen saver selection z Wallpaper settings zAccessibility settings zCommand prompt zCustom wallpaper zFAX settings zDial-up connections zFolder options
zMouse and keyboard settings zMedia player settings
zMicrosoft Internet Explorer settings (all versions through version 7.0) zMicrosoft Outlook Express mail (.dbx) files
zNetwork printers
zRAS connection phone book(.pbk) files and settings zRegional options zRemote Access zScheduled jobs zScreensaver zSound Settings zTaskbar settings Important
This list may not be complete. There may be additional components that are migrated.
Note
The versions of these applications must match on the source and destination computers. This is because USMT does not support migrating the settings of an older version of an application to a newer version — except with Microsoft Office which USMT can migrate from an older version to a newer version.
Note
USMT only migrates settings that have been used and/or modified by the user. If there is an application setting that was not touched by the user on the source computer, the setting may not migrate.
Product Version
Adobe Acrobat Reader 4.0, 6.0, 7.x Adobe PhotoShop CS 8, 9 AOL Instant Messenger 5.9
Apple iTunes 6.0
Apple QuickTime Player 7 Corel Paint Shop Professional 9.0 CuteFTP Professional 6.0, 7.0
Eudora 5,6,7
ICQ Pro 2003b
IBM Lotus Notes 6.x, 7.0 IBM Lotus SmartSuite
z Lotus 1-2-3 z Organizer z WordPro
9, 9.8
MusicMatch JukeBox Basic 7.x, 8.x, 10.x Microsoft Windows Media Player 7-9, 11 Microsoft Office z Microsoft Access z Microsoft Excel z Microsoft FrontPage* z Microsoft Outlook 2000, XP, 2003, 2007* Note
What USMT does not migrate
USMT 3.0 does not migrate the following items. For a list of the components that are migrated, see What Does USMT 3.0 Migrate?. z Mapped network drives.
z Local printers.
z Network printers, when the destination computer is running Windows XP.
z Microsoft Project settings, when migrating from Office 2003 to 2007 Microsoft Office system. z Taskbar settings, when migrating from a computer running Windows XP to Windows Vista.
z Customized icons for shortcuts (may not migrate). For example, if user right-clicks a shortcut, clicks Properties, and changes the icon for the shortcut, then the customized icon may not migrate to the destination computer.
z Permissions for shared folders. After migration, you will have to manually re-share any folders that they were shared on the source computer.
z Files and settings between operating systems with different languages. That is, the operating system of the source computer must match the language of the operating system on the destination computer.
z Settings from older versions of an application. The versions of each application must match on the source and destination computers. This is because USMT does not support migrating the settings of an older version of an application to a newer version — except with Microsoft Office, which USMT can migrate from an older version to a newer version.
z Hardware-related settings, drivers, passwords, application binary files, synchronization files, .dll files, or other executable files.
z Some firewall settings in Windows XP. Review the following limitations when using USMT to migrate your firewall settings to a computer running Windows XP.
{Only the Internet Connection Firewall check box and setting is migrated. USMT supports Windows Management Instrumentation (WMI)–based settings and the Windows XP Service Pack 2 registry setting.
{The Internet Connection Sharing setting is not migrated because it can make the network less secure if it is migrated to the destination computer. {The firewall advanced configuration settings are not migrated due to security risks.
{The network connections user interface will not completely refresh until you log off or press F5.
{Bridge settings are not migrated (for example, bridging a virtual private network to a second network adapter). You should also note the following:
z The data located on external universal serial bus (USB) hard disks will be included in the migration even when you specify /localonly. However, this issue will not occur with USB flash drives (that is, the data on USB flash drives will not be included when you specify /localonly).
If you are having a problem that is not listed here, see Common Issues for resolutions to commonly encountered problems.
Frequently Asked Questions
General
z How much space is needed on the destination computer?
z Can I store the files and settings directly on the destination computer or do I need a server? z Can I migrate data between operating systems with different languages?
z Microsoft PowerPoint z Microsoft Publisher z Microsoft Word
Microsoft FrontPage is not available in Office 2007.
MSN Messenger 6.1, 7.0, 7.5 Microsoft OneNote 2003, 2007 Microsoft Project 2003, 2007 Microsoft Visio 2003, 2007 Microsoft Windows Live Messenger 8.0 Microsoft Windows Moviemaker 2.1 Microsoft Works 7.0, 8.0
Mozilla Firefox 1.8
Odigo Messenger 4.0
Quicken 2001-2006 Home and Business
RealPlayer Basic 6.x, 10 SpyBot - Search & Destroy 1.4
WinAmp 5
WinZip 8.0, 9.0, 10.0
WordPerfect Office 11, 12, X3
WS_FTP Pro 8, 9, 10
z Can I change the location of the temporary directory on the destination computer? z How do I uninstall USMT?
Files and settings
z How can I exclude a folder or a certain type of file from the migration?
z What happens to files that were located on a drive that does not exist on the destination computer?
.xml files
z Where can I get XML examples?
z Can I use existing custom .inf files that were written for USMT 2.6x? z How can I validate the .xml files?
z Why do I have to include the .xml files on both the ScanState and LoadState command lines? z Which files can I modify and specify on the command line?
z What happens if I do not specify the .xml files on the command line?
Conflicts and precedence
z What happens when there are conflicting XML rules or conflicting objects on the destination computer?
General
How much space is needed on the destination computer?
The destination computer will need enough available space for the following: z Operating system
z Applications
z Size of the uncompressed store*
z Twice the size of the largest file that will be migrated*
Can I store the files and settings directly on the destination computer or do I need a server?
No, you do not need to save the files to a server. If you are moving the user state to a new computer, you can create the store on a shared folder, on media that you can remove (such as a Universal Serial Bus (USB) drive), or you can store it directly on the destination computer. For example, create and share C:\store on the destination computer. Then run ScanState on the source computer and save the files and settings to \\DestinationComputerName\store. Then, run LoadState on the destination computer and specify C:\store as the store location.
Can I migrate data between operating systems with different languages?
No. USMT does not support migrating data between operating systems with different languages. That is, the operating system of the source computer must match the language of the operating system on the destination computer.
Can I change the location of the temporary directory on the destination computer?
When you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer before saving it to the final location. USMT does not allow you to change this temporary location.
How do I uninstall USMT?
For instructions on how to script an uninstall of USMT, see the Release Notes (http://go.microsoft.com/fwlink/?LinkId=73868).
Files and settings
How can I exclude a folder or a certain type of file from the migration?
You can use the <unconditionalExclude> elements to globally exclude data from the migration — for example, to exclude all .mp3 files on the computer or to exclude all files from C:\UserData. This element excludes objects regardless of any other <include> rules that are in the .xml files. For an example, see
"<unconditionalExclude>" in the How To Exclude Files and Settings topic. For the syntax of this element, see the XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519).
What happens to files that were located on a drive that does not exist on the destination computer?
USMT will migrate the files to the %SystemDrive%, while maintaining the correct folder hierarchy. For example, if E:\data\File.pst was on the source computer, but the destination computer does not have an E:\ drive, the file will be migrated to C:\data\File.pst where C is the system drive.
.xml files
NoteYou will need the last two items listed (*) because when you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer. The files are decompressed (and decrypted if necessary) during this process. Then LoadState transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file.
Note
If there are <locationModify> rules in the .xml files that specify to migrate the files from a drive that does not exist on the destination computer (but that did exist on the source computer) to a drive that does exist on the destination computer, the files will be migrated correctly.
Where can I get XML examples?
See the following topics:
z How To Exclude Files and Settings z How To Reroute Files and Settings z How To Include Files and Settings
z XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496) z Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510).
Can I use existing custom .inf files that were written for USMT 2.6x?
No, you cannot use .inf files with USMT 3.0. In order to use USMT 3.0, you will need to re-author the migration behavior into the new .xml file format.
How can I validate the .xml files?
You can use the USMT XML Schema (MigXML.xsd) to write and validate migration .xml files.
Why do I have to include the .xml files on both the ScanState and LoadState command lines?
Unlike previous versions of USMT, the .xml files are not copied to the store. Because ScanState and LoadState need the .xml files to control the migration, you will need to specify the same set of .xml files on the ScanState and LoadState command lines. However, you do not have to specify Config.xml unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, simply modify the Config.xml and specify the updated file with LoadState. Then, LoadState will only migrate the files and settings that you want to migrate.
If you leave out an .xml file from LoadState, then all data that was migrated with the missing .xml files (that is in the store) will be migrated. However, the migration rules that were specified on the ScanState command line will not apply. For example, if you leave out MigApp.xml, and it had a rerouting rule like
MigsysHelperFunction.RelativeMove(“c:\data”, “%CSIDL_PERSONAL%”), USMT will not reroute the files, and they will be migrated to C:\data.
Which files can I modify and specify on the command line?
z If the destination computer is running Windows XP, you should specify MigUser.xml, MigApp.xml, and MigSys.xml on both command lines. You can modify each of these files if you want to change how the data is migrated. If you want to exclude any components from the migration, you can also create and modify Config.xml.
z If the destination computer is running Windows Vista, you should specify MigUser.xml and MigApp.xml on both command lines. You can modify each of these files. You should not specify MigSys.xml because MigSys.xml is only applicable when the destination computer is running Windows XP. When the destination computer is running Windows Vista, the migration of operating system settings is controlled by the manifests which you cannot modify. If you want to exclude certain operating system settings (or any other components), you should create and modify Config.xml.
What happens if I do not specify the .xml files on the command line?
z ScanState. If you specify /targetxp then only user accounts are stored and migrated. If you do not specify /targetxp, then all user accounts and default operating
system components are migrated.
z LoadState. If you do not specify any files on the LoadState command line, then all data that is in the store will be migrated. However, any migration rules that
were specified in .xml files on the ScanState command line will not apply. For example, if you leave out MigApp.xml, and it had a rerouting rule like MigsysHelperFunction.RelativeMove(“c:\data”, “%CSIDL_PERSONAL%”), USMT will not reroute the files, and they will be migrated to C:\data.
Conflicts and precedence
What happens when there are conflicting XML rules or conflicting objects on the destination computer?
See Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) for more information.
Example Scenarios
Wipe-and-load migration
The following diagram shows a wipe-and-load migration. First, the administrator migrates the user state from a source computer to an intermediate store. After installing the operating system, the administrator migrates the user state back to the source computer.
system on each computer will be reinstalled.
1. An administrator runs the ScanState command-line tool on each computer. ScanState saves each user state to a server.
2. On each computer, an administrator installs the company's standard operating environment, which includes Windows Vista, Microsoft Office, and other company applications.
3. An administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back to the source computer.
Side-by-side migration
The following diagram shows a side-by-side migration. First, the administrator migrates the user state from the source computer to an intermediate store. After installing the operating system on the destination computer, the administrator migrates the user state from the store to the destination computer.
Scenario one
A company receives 50 new laptops for their managers, and needs to reallocate the 50 older laptops to new employees. 1. An administrator runs ScanState on each of the old laptops, and saves each user state to a server.
2. On the new laptops, an administrator installs the company's standard operating environment which includes Windows Vista, Office, and other company applications.
3. An administrator runs LoadState on the new laptops to migrate the user states to the appropriate computer.
4. On the old computers, an administrator installs the company's standard operating environment which includes Windows Vista, Office, and other company applications. The old computers are now ready for the new employees to use.
Scenario two
A company is allocating 20 new computers to users in the accounting department. The users all have one computer with their files and settings—the source computer. 1. On each source computer, an administrator runs ScanState using Microsoft Systems Management Server (SMS), a non-Microsoft management technology, a
logon script, or a batch file. ScanState collects the user state from each source computer and then saves it to a server.
2. On each new computer, an administrator installs the company's standard operating environment which includes Windows Vista, Office, and other company applications.
3. On each of the new computers, an administrator runs LoadState using SMS, a non-Microsoft management technology, a logon script, or a batch file. LoadState migrates the user states from the intermediate store to a new computer.
Additional Resources
Automating deployment
z For more information about automating your USMT deployment (including best practices, migration sample scripts, and information about application compatibility, imaging, and remote deployments) see Desktop Deployment (http://go.microsoft.com/fwlink/?LinkId=56488).
z For more information about planning for user state migration in Windows XP, see User State Migration: Overview (http://go.microsoft.com/fwlink/? LinkId=56489).
z For information about the migration tasks and checkpoints in a desktop deployment, see User State Migration Feature Team Guide (http://go.microsoft.com/fwlink/?LinkId=74511).
z For more information about deploying Windows Vista, see Deploying Windows Vista (http://go.microsoft.com/fwlink/?LinkID=63891). z To download the SMS 2003 Operating System Deployment Feature Pack, see http://go.microsoft.com/fwlink/?LinkID=71256.
XML
For more information about XML, see
z XML Developer Center (http://go.microsoft.com/fwlink/?LinkID=74455). z XML Fundamentals (http://go.microsoft.com/fwlink/?LinkId=63993).
Miscellaneous
z You can view this USMT documentation online at http://go.microsoft.com/fwlink/?LinkID=56578. z For the USMT newsgroup, see http://go.microsoft.com/fwlink/?LinkId=64934.
z To provide feedback on this documentation, e-mail [email protected].
Planning Your Migration
This section covers:z Determine What to Migrate z Determine Where to Store Data z Test Your Migration z Best Practices
For more information about automating your deployment (including best practices, migration sample scripts, and information about application compatibility, imaging, and remote deployments) see Desktop Deployment at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=56488).
For more information about planning for user state migration, see User State Migration: Overview at the Microsoft Web site (http://go.microsoft.com/fwlink/? LinkId=56489).
Determine What to Migrate
By default, USMT migrates the items listed in What Does USMT 3.0 Migrate? (depending on which migration .xml files you specify). These default settings are often sufficient for a basic migration. However, when considering what settings to migrate, you should consider what settings you would like the user to be able to configure and what settings you would like to standardize. Many organizations use their migration as an opportunity to create and begin enforcing a better managed environment. Some of the settings that users can configure prior to the migration (on unmanaged computers) can be locked on the new, managed computer. For example, a standard wallpaper, Internet Explorer security settings, and the desktop configuration are some of the items you can choose to standardize.
To reduce complexity and increase standardization, your organization should consider creating a standard operating environment. A standard operating environment is a combination of hardware and software that you distribute to all users. This means selecting a base line for all computers — including standard hardware drivers, core operating system features, core productivity applications (especially if they are under volume licensing), and core utilities. This environment should also include a standard set of security features as outlined in the organization’s corporate policy. Using a standard operating environment can vastly simplify the migration and reduce overall deployment challenges.
In this section: z Identify Users
z Identify Applications Settings z Identify Operating System Settings z Identify File Types, Files, and Folders
Identify Users
This topic contains information that you should know while you plan how to migrate users. By default all users are migrated. For instructions on how to migrate users, see How To Migrate User Accounts.
z Migrating local accounts z Migrating domain accounts z Command-line options
Migrating local accounts
Before migrating local accounts, note the following:z You must specify /lac. If you are migrating local accounts (as opposed to domain accounts) and if the local account does not exist on the destination computer, you must specify /lac on the LoadState command line. If /lac is not specified, any local user accounts will not be migrated.
z Consider specifying /lae. This option enables the account that was created with /lac. You can create a disabled local account by only specifying /lac, but then a local administrator will need to enable the account on the destination computer.
z You should be careful when specifying a password for local accounts. If you decide to create the local account with a blank password, anyone could log on to
that account on the destination computer. If you decide to create the local account with a password, the password is available to anyone with access to the USMT command line.
Note
You can only specify which users to include using the command line. You cannot specify users in the .xml files.
Note
Migrating domain accounts
Before migrating domain user accounts, note the following:z The destination computer does not need to be connected to the domain for domain user profiles to be created.
z If USMT cannot determine a domain for a user, USMT will apply the settings to a local account. For example, if the computer is not part of a domain, if a
server is down, or if there is a network communication error, then USMT will migrate the settings to a local account, which will appear as "Account Unknown" in User Profiles. Then, when the computer is connected to the network, the computer will connect to the naming server and get the account names and credentials back.
Command-line options
USMT provides several options that you can use to migrate multiple users on a single computer. You can use the following command-line options to specify which users to migrate.
z Specifying users. You can specify which users to migrate with the /all, /ui, /uel, and /ue on both ScanState and LoadState command lines. z Moving users to new domains. You can move user accounts using the /md option on the LoadState command line.
z Migrating local accounts. You can create and enable local accounts using /lac and /lae on the LoadState command line. z Renaming user accounts. You can rename user accounts using the /mu option.
Identify Applications Settings
When planning for your migration, you should identify which applications and settings that you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see How To Create a Custom .xml File.
Applications
You should create and prioritize a list of applications that you want to migrate. It may be helpful to establish a committee to review the application lists and decide which applications will be redeployed and which applications will be retired. Often the applications are prioritized based on a combination of how widely the application is used and how complex the application is.
After you have created your list, you should identify an application owner to be in charge of each application. This is necessary because the developers will not be experts on all of the applications in your organization. The application owner might not be an expert on the application, but will be the person who has the most experience with the application. The application owner will provide insight into how the organization installs, configures, and uses the application.
Application settings
You will need to determine and locate the application settings that you want to migrate. You can acquire a lot of the information that you need for this step when you are testing the new applications for compatibility with the new operating system (for example, application inventory, and installation locations). Instead of duplicating your efforts, you can use your application tracking database to hold the info that you will need to determine what user application settings to migrate.
You should review the list of applications that you have decided to migrate and work with the application owner to list the possible settings. For each setting, you should determine whether it needs to be migrated or if you want to apply standard settings. Then determine where the setting is located (for example, in the registry or in an .ini file). Next you should consider the following questions to determine what needs to be done in order to migrate the setting successfully.
z Is the destination version of the application newer than the source version? z Is it appropriate to migrate these setting to the new version (will it work)? z Do the settings need to be moved or altered?
z Can the first run process fool the application into thinking it has run already? Does this work or break the application?
After answering the previous questions, you will then need to create a custom .xml file to migrate settings. You should work with the application owner to develop test cases and also to determine the file types that need to be migrated for the application.
Locating Where Settings Are Stored
If you do not know the storage mechanism or location of a given setting, it can be difficult to create rules to migrate the setting. Settings can be stored in the registry, .ini files, or a text or binary file. To determine the location of a setting, start by checking the vendor’s documentation or Web site.
If the location of a setting is not documented, you can use tools like Regmon and Filemon from the Sysinternals Web site (http://go.microsoft.com/fwlink/?
linkid=36109) or a non-Microsoft application-packaging tool to find it. Regmon monitor registry activity and Filemon monitors file system activity. To determine where a setting is stored, start Regmon and Filemon monitoring and then change the setting. Once you’ve done this, look for registry and file system writes that occurred when you changed the setting and note where those writes are located.
Using an application packaging tool, you can typically take a snapshot, make a setting change, and then take another snapshot to see what has changed. We recommend doing this on a computer that only has Windows installed and the relevant application. For example, antivirus software can result in many file system and registry reads and writes, which will make it difficult to find the setting you are looking for. Also, you should keep an unprotected computer like this isolated from the network.
Note
When the destination computer is running Windows XP, you can use Moveuser.exe to move the local account back to the correct domain account after domain connectivity is restored. You can download Moveuser.exe by using the tools at Windows Server 2003 Resource Kit Tools (http://go.microsoft.com/fwlink/? linkid=20334).
Note
Identify Operating System Settings
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. USMT enables you to migrate select settings and keep the default values for all others. The operating system settings include the following:
z Appearance. This includes items such as wallpaper, colors, sounds, and the location of the taskbar.
z Action. This includes items such as the key repeat rate, whether double-clicking a folder opens it in a new window or the same window, and whether you need to
double-click or single-click an item to open it.
z Internet. These are the settings that let you connect to the Internet and control how your browser operates. This includes items such as your home page URL,
favorites, bookmarks, cookies, security settings, dial-up connections, and proxy settings.
z Mail. This includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
To help you decide what settings to migrate, you should consider any previous migration experiences as well as the results of any surveys and tests that you have conducted. You should also consider the number of help desk calls related to operating system settings that you have had in the past, and are able to handle in the future. Also decide how much of the new operating system functionality you want to take advantage of.
You will want to migrate the settings that users need to work, those that make the work environment comfortable, and those that will reduce help desk calls after the migration. Although it is easy to dismiss migrating user preferences, you should consider that users can spend a significant amount of time restoring items such as wallpaper, screen savers, and other customizable user-interface features. Most users do not remember how these settings were applied. Although these items are not critical to migration success, migrating these items increases user productivity and overall satisfaction of the migration process.
Identify File Types, Files, and Folders
When planning for your migration, you should identify the file types, files, folders, and settings that you want to migrate. First you should determine and locate the standard file locations on each computer, such as My Documents, C:\Data, and company-specified locations, such as \EngineeringDrafts. Next, you should determine and locate the nonstandard locations. For nonstandard locations, consider the following:
z File types. Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your
organization. Applications normally use specific file name extensions. For example, Microsoft Word primarily uses .doc file name extension. However, it also uses other file types, such as templates (.dot files), on a less frequent basis.
z Excluded locations. Consider the locations on the computer that should be excluded from the migration (for example, %windir% and Program Files).
z New locations. Decide where files should be migrated to on the destination computer (for example, My Documents, a designated folder, or the original location).
Once you have verified which files and file types the end users work with regularly, you will need to locate them. Files may be saved to single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer.
1. Click Start and then click My Computer. 2. On the Tools menu, click Folder Options.
3. On the File Types tab, the registered files types are displayed in the Registered file types dialog box.
1. Open Control Panel, click Control Panel Home on the left hand side, and click Programs. 2. Click Default Programs, and click Associate a file type or protocol with a program. 3. On this screen, the registered file types are displayed.
For more information about how to change the file types, files, and folders that are migrated when you specify MigUser.xml, see Using Using USMT 3.0.
Determine Where to Store Data
Consider these questions when deciding where to store data during migration:z How much space do I need for the store?
z How much space do I need on the destination computer? z Should I store the data remotely or locally?
How much space do I need for the store?
You first need to determine how much space you will need to store the migrated data. You should base your calculations on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate these is to survey several average desktops to estimate the size the store that you will need.
The amount of space that is required in the store will vary depending on the local storage strategies each organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets will be smaller. If e-mail is stored locally, as in offline storage files, data sets will be larger. Mobile users especially will typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in your organization.
Notes
z For more information about how to change the operating system settings that are migrated, see Using USMT 3.0. z For information about the operating system settings that USMT migrates, see What Does USMT 3.0 Migrate?.
To find the registered file types on a computer running Windows XP
To find the registered file types on a computer running Windows Vista
When trying to determine how much disk space you will need, consider the following issues:
z E-mail: If users deal with a large volume of e-mail or keep e-mail on their local computers instead of on a mail server, the e-mail can take up as much disk space
as all other user files combined. Prior to migrating user data, make sure that users who store e-mail locally synchronize their inboxes with their mail server. z User documents: Frequently, all of a user's documents fit into 50 megabytes (MB) of space, depending on the types of files they work with. This estimate
assumes typical office work such as word processing documents and spreadsheets. This estimate can fluctuate substantially based on the types of documents that your organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs much more space than a law firm that primarily uses word processing documents. You do not need to migrate the documents that users store on file servers through mechanisms like Folder Redirection, as long as they will have access to these locations after the migration.
z User system settings: 5 MB is usually adequate to save the registry settings. This requirement can fluctuate based on the number of applications that have been
installed, but it is rare for the user-specific portion of the registry to exceed 5 MB.
The following table provides storage space estimates for each user's profile and e-mail. The estimates do not account for any files that are migrated from the source computer. These estimates are based on the above factors and a hypothetical office situation. You should check these estimates against your own environment as intermediate stores can greatly vary depending on the type and size of the collected files. You should allow a minimum buffer of 20 percent additional space on the intermediate store.
How much space do I need on the destination computer?
The destination computer will need enough available space for the following:z Operating system z Applications
z Size of the uncompressed store*
z Twice the size of the largest file that will be migrated*
Should I store the data remotely or locally?
If you have enough space and you are migrating the user state back to the same computer, then storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on removable device such as a Universal Serial Bus (USB) drive. Also, depending on the imaging technology that you are using, you might be able to store the data on the partition that is being re-imaged (if the data will be protected from deletion during the process). To increase performance, you should store the data on high-speed drives that use a high-speed network connection. It is also good practice to ensure that the migration is the only task the server is performing.
If there is not enough local disk space, or if you are moving the user state to a new computer, then you must store the data remotely. For example, you can store it in on a shared folder, on media that you can remove (such as a USB drive), or you can store it directly on the destination computer. For example, create and share C:\store on the destination computer. Then run ScanState on the source computer and save the files and settings to \\DestinationComputerName\store. Then, run LoadState on the destination computer and specify C:\store as the store location. By doing this, you do not need to save the files to a server.
Test Your Migration
You should always test your migration plan in a controlled laboratory setting before deploying it to your entire organization. In your test environment, you will need at least one computer for each type of operating system that you want to migrate from. For example, if you are migrating data from computers running Windows 2000 and Windows XP, you need to test at least one computer running each of these operating systems.
After you have migrated a few typical user states to the intermediate store, you should note the space required and adjust your initial calculations accordingly. You might also need to adjust the registry setting and file location information in your migration rule files. You should test the migration again after making any changes. After you have thoroughly tested the entire migration process on a single computer, you should conduct a pilot migration with a small group of users. You should verify that all data and settings have migrated as expected. A pilot migration also gives you an opportunity to test your space estimates for the intermediate store.
Once you have determined that the pilot migration is successfully migrating the files and settings, you are ready to add USMT to the server that is running Microsoft Systems Management Server (SMS) 2003 or a non-Microsoft management technology. If you are using SMS, it is assumed that the SMS 2003 Operating System Deployment (OSD) Feature Pack has been installed on the server running SMS. For more information, see the Microsoft Web site.
Best Practices
Security best practices
You can create a space-estimate file (Usmtsize.txt) using the /p option to estimate the size of the store.
User Type Intermediate Store Estimate
Desktop user storing e-mail on server 50 MB to 75 MB (plus any collected files) Desktop user with local e-mail storage 150 MB to 200 MB (plus any collected files) Laptop user 150 MB to 300+ MB (plus any collected files)
Note
You will need the last two items listed because when you run LoadState on the destination computer, LoadState migrates each file (one by one) from the store to a temporary location on the destination computer. The files are decompressed (and decrypted if necessary) during this process. Then LoadState transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file.
Note
If possible, you should have users to store their data within their %UserProfile%\My Documents and %UserProfile%\Application Data folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.
Note
For testing purposes, you can choose to create an uncompressed store using the /nocompress option. When compression is disabled, ScanState saves the files and settings to a hidden folder named "File" at StorePath\USMT3. You can use the uncompressed store to view what USMT has stored, troubleshoot a problem or you can run an antivirus utility against the files.
As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, consider the following issues.
z Encrypting File System (EFS). You should take extreme caution when migrating encrypted files to computers running Windows XP. This is because the end
user does not need to be logged on or even present to capture the user state. By default, USMT fails if an encrypted file is found. In order for USMT to successfully migrate EFS certificates, the end user is needed both before and after the migration. For more information about EFS best practices, see article 223316 in the Microsoft Knowledge Base. For specific instructions, see How To Migrate EFS Files and Certificates.
z Encrypt the store. You should consider using /encrypt (on the ScanState command line) and /decrypt (on the LoadState command line). However, you should use extreme caution with this option because anyone that has access to the ScanState command line script will also have access to the encryption key. z Virus scan. We recommend that you scan both the source and destination computers for viruses prior to running USMT. In addition, you should scan the
destination computer image. Running an antivirus utility prior to migration will ensure that all data is virus-free.
z Maintain security of the file server and the deployment server. We recommend that you manage the security of the file and deployment servers. It is important
to make sure that the file server where you save the store is secure. You will also need to secure the deployment server to ensure that the user data that is in the log files is not exposed. You should not transmit data over an Internet connection unless you have a secure connection (such as a virtual private network) because most of the data that you are migrating will be unencrypted.
z Password migration. To ensure the privacy of the end users, USMT does not migrate passwords (including those for applications such as Microsoft Outlook
Express, Microsoft Internet Explorer, as well as Remote Access Service (RAS) connections and mapped network drives). It is important to make sure that the end users know their passwords. In order to ensure that all passwords are known, you should ask end users to change and record their passwords before the migration. z Local account creation. Before you migrate local accounts, see Migrating local and domain accounts.
z Administrator security. In some organizations, it is critical to keep the user state secure from the administrator who is performing the migration. If the
administrator's access to user states is a security concern for you, you can use the following precautions:
{Have the end user perform the migration using USMT, a scripted-manual method, or the PC Migration Assistant. Under the scripted-manual method, the user must be able to restore the user state by logging on as the administrator.
{When securing the state in the temporary store, make sure that while the root folder might allow full user access, the individual user folders only allow access for IT staff and the owner of the folder.
{Use Internet Protocol security (IPSec) or other network security protocols to secure data as it travels over the network. {Use a software deployment tool that uses restricted rights.
{The deployment engineer should not have physical access to the end-user computer. All troubleshooting and control should be performed through secure interfaces.
General best practices
z Install applications before LoadState. Though it is not always essential, it is good practice to install all applications on the destination computer before restoring
the user state. This ensures that migrated settings are preserved. Specifically, if the following applications are installed on the source computer, they must be installed on the destination computer prior to running LoadState: Lotus SmartSuite, RealPlayer Basic, and Quicken 2004 Home and Business.
z Close all applications before running ScanState or LoadState. If some applications are running during ScanState or LoadState, USMT may not migrate some
data. For example, if Outlook is open, USMT may not migrate .pst files. USMT will fail if it cannot migrate a file or setting unless you specify /c. When you specify /c, USMT will ignore the errors, and log an error each time it encounters a file that is in use that did not migrate.
z Log off after you run LoadState. Some settings (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs in.
For this reason, you should log off after you run LoadState.
z Managed environment. To create a managed environment, you may want to move all of the end user’s documents into My Documents (%
CSIDL_PERSONAL%). We recommend that you migrate files into the smallest possible number of folders on the destination computer. This will help you to clean up files on the destination computer if LoadState fails to complete.
z Chkdsk.exe. We recommend that you run Chkdsk.exe before running ScanState and LoadState. Chkdsk creates a status report for a hard disk drive and it also
lists and corrects common errors. For more information about this tool, see Chkdisk at the Microsoft Web site.
z Migrate in groups. If you decide to perform the migration while users are using the network, it is best to migrate user accounts in groups. In order to minimize
the impact on network performance, you should determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. This also allows you to make any necessary modifications to your plan between groups.
Automating Your Migration
z For more information about automating your USMT deployment (including best practices, migration sample scripts, and information about application compatibility, imaging, and remote deployments) see Desktop Deployment (http://go.microsoft.com/fwlink/?LinkId=56488).
z For more information about planning for user state migration in Windows XP, see User State Migration: Overview (http://go.microsoft.com/fwlink/? LinkId=56489).
z For information about the migration tasks and checkpoints in a desktop deployment, see User State Migration Feature Team Guide (http://go.microsoft.com/fwlink/?LinkId=74511).
z For more information about deploying Windows Vista, see Deploying Windows Vista (http://go.microsoft.com/fwlink/?LinkID=63891). z To download the SMS 2003 Operating System Deployment Feature Pack, see http://go.microsoft.com/fwlink/?LinkID=71256.
USMT Components
You use ScanState to collect the files and settings from the source computer. You use LoadState to restore the user state onto the destination computer. This section describes the components and files that ScanState and LoadState use. For ScanState and LoadState to use an .xml file, you will need to specify it on both command
Important
