User State Migration Tool

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 Quick Start Checklist Getting Started with USMT 3.0 Planning Your Migration Automating Your Migration USMT Components Using USMT 3.0 Troubleshooting XML Reference

Quick links For syntax and command-line options, see USMT Components. For information about what has changed in this version of USMT, see What is New in USMT 3.0. For answers to common questions, see Frequently Asked Questions. For information about the .xml files, see .xml Files. For instructions on how to change the default migration behavior, see Using USMT 3.0. 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 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

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:

Introduction Requirements What is New in USMT 3.0 What Does USMT 3.0 Migrate? Frequently Asked Questions Example Scenarios 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:

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 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. If the source computer is running Windows XP, you need to run ScanState from an account with administrative credentials. 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 Prompt, and click Run As Administrator.

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 Overview 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:

Choose what to copy and what not to copy Arbitrate conflicts between the source computer and destination computer Modify where the data is migrated to on the destination computer Emulate missing settings Remove settings from the destination computer

Benefits and assumptions

Requirements

In this topic Supported operating systems Software requirements 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:

Reduces the cost associated with inefficient migration techniques and processes. Eliminates the time it takes to manually copy and transfer files and settings. Reduces end-user downtime while they recustomize their desktop and find missing files. Reduces help-desk calls from users who are recustomizing their desktop. Reduces the time needed for the user to become familiar with the new operating system. Increases employee satisfaction with their migration experience.

It is assumed that IT professionals using USMT understand the following:

The navigation and hierarchy of the Windows registry. The files or file types that applications use. How to extract application and setting information manually from internal development groups and non-Microsoft software vendors. 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

You can migrate a 32-bit operating system to a 64-bit operating system. However, you cannot do the reverse.

Software requirements 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.

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. 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. 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.

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. 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 Overall changes from USMT 2.6 ScanState changes

New command-line options Changed command-line options

LoadState changes

New command-line options Changed command-line options

Overall changes from USMT 2.6 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.

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.

USMT 3.0 migrates EFS files and certificates to computers running Windows Vista. EFS files and certificates are migrated automatically to computers

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. 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. 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. By default, all users are migrated. You can use /ui, /ue and /uel to change this behavior. 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?. USMT 3.0 migrates access control lists (ACL's). 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 /config Specifies the Config.xml file that LoadState should use.

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 User data Operating system components Supported applications What USMT does not migrate

User data 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. 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. 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 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:

Accessibility settings Classic desktop Command prompt settings Dial-up connections Favorites Folder options Fonts Taskbar settings Microsoft Internet Explorer settings (all versions through version 6.0) Microsoft Open Database Connectivity settings Microsoft Outlook Express mail (.dbx) files Mouse and keyboard settings Multimedia settings Phone and modem options RAS connection phone book(.pbk) files Regional options Remote Access Screen saver selection Wallpaper settings

Accessibility settings Command prompt Custom wallpaper FAX settings Dial-up connections Folder options Mouse and keyboard settings Media player settings Microsoft Internet Explorer settings (all versions through version 7.0) Microsoft Outlook Express mail (.dbx) files Network printers RAS connection phone book(.pbk) files and settings Regional options Remote Access Scheduled jobs Screensaver Sound Settings Taskbar 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

Lotus 1-2-3 Organizer WordPro

9, 9.8

MusicMatch JukeBox Basic 7.x, 8.x, 10.x Microsoft Windows Media Player 7-9, 11

Microsoft Office

Microsoft Access Microsoft Excel Microsoft FrontPage* 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?.

Mapped network drives. Local printers. Network printers, when the destination computer is running Windows XP. Microsoft Project settings, when migrating from Office 2003 to 2007 Microsoft Office system. Taskbar settings, when migrating from a computer running Windows XP to Windows Vista. 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. Permissions for shared folders. After migration, you will have to manually re-share any folders that they were shared on the source computer. 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. 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. Hardware-related settings, drivers, passwords, application binary files, synchronization files, .dll files, or other executable files. 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:

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

How much space is needed on the destination computer? Can I store the files and settings directly on the destination computer or do I need a server? Can I migrate data between operating systems with different languages?

Microsoft PowerPoint Microsoft Publisher 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 Yahoo Messenger 5.x,6.x, 7.x

Can I change the location of the temporary directory on the destination computer? How do I uninstall USMT?

Files and settings

How can I exclude a folder or a certain type of file from the migration? What happens to files that were located on a drive that does not exist on the destination computer?

.xml files

Where can I get XML examples? Can I use existing custom .inf files that were written for USMT 2.6x? How can I validate the .xml files? Why do I have to include the .xml files on both the ScanState and LoadState command lines? Which files can I modify and specify on the command line? What happens if I do not specify the .xml files on the command line?

Conflicts and precedence

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:

Operating system Applications Size of the uncompressed store* 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

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 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:

How To Exclude Files and Settings How To Reroute Files and Settings How To Include Files and Settings XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496) 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?

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. 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?

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. 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.

For example, a company has just received funds to upgrade all of its computers to Windows Vista. Each employee will keep the same computer, but the operating

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 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). For more information about planning for user state migration in Windows XP, see User State Migration: Overview (http://go.microsoft.com/fwlink/?LinkId=56489). 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). For more information about deploying Windows Vista, see Deploying Windows Vista (http://go.microsoft.com/fwlink/?LinkID=63891). 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

XML Developer Center (http://go.microsoft.com/fwlink/?LinkID=74455). XML Fundamentals (http://go.microsoft.com/fwlink/?LinkId=63993). For more information about the USMT .xml elements, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519).

Miscellaneous You can view this USMT documentation online at http://go.microsoft.com/fwlink/?LinkID=56578. For the USMT newsgroup, see http://go.microsoft.com/fwlink/?LinkId=64934. To provide feedback on this documentation, e-mail [email protected].

Planning Your Migration This section covers:

Determine What to Migrate Determine Where to Store Data Test Your Migration 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:

Identify Users Identify Applications Settings Identify Operating System Settings 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.

Migrating local accounts Migrating domain accounts Command-line options

Migrating local accounts Before migrating local accounts, note the following:

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. 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. 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 If there are multiple users on a computer and you specify a password with /lac, all migrated users will have the same password

Migrating domain accounts Before migrating domain user accounts, note the following:

The destination computer does not need to be connected to the domain for domain user profiles to be created. 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.

Specifying users. You can specify which users to migrate with the /all, /ui, /uel, and /ue on both ScanState and LoadState command lines. Moving users to new domains. You can move user accounts using the /md option on the LoadState command line. Migrating local accounts. You can create and enable local accounts using /lac and /lae on the LoadState command line. 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.

Is the destination version of the application newer than the source version? Is it appropriate to migrate these setting to the new version (will it work)? Do the settings need to be moved or altered? 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 By default, if a user name is not specified in any of the command-line options, the user will be migrated.

Identify Operating System SettingsWhen 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:

Appearance. This includes items such as wallpaper, colors, sounds, and the location of the taskbar. 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. 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. 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:

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. Excluded locations. Consider the locations on the computer that should be excluded from the migration (for example, %windir% and Program Files). 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:

How much space do I need for the store? How much space do I need on the destination computer? 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 For more information about how to change the operating system settings that are migrated, see Using USMT 3.0. 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

Note

When trying to determine how much disk space you will need, consider the following issues:

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. 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. 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:

Operating system Applications Size of the uncompressed store* 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.

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.

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. 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. 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. 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. Local account creation. Before you migrate local accounts, see Migrating local and domain accounts. 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 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. 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. 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. 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. 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. 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 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). For more information about planning for user state migration in Windows XP, see User State Migration: Overview (http://go.microsoft.com/fwlink/?LinkId=56489). 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). For more information about deploying Windows Vista, see Deploying Windows Vista (http://go.microsoft.com/fwlink/?LinkID=63891). 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 If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.

lines.

ScanState Syntax LoadState Syntax USMT Internal Workflow .xml Files

USMT Components

ScanState Syntax

In this topic Before you begin Syntax Storage options Migration rule options Monitoring options User options

/ue, and /ui examples

Encrypted file (EFS) options Command-line option incompatibility

Before you begin Before you run ScanState, note the following:

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. You must run ScanState on Windows XP from an account with administrative credentials, or some operating system settings may not migrate — for example, wallpaper settings, screen saver selections, modem options, media player settings, and Remote Access Service (RAS) connection phone book(.pbk) files and settings. For this reason, we recommend that you run ScanState (and LoadState) from within an account with administrative credentials. Unless otherwise specified, you can only specify each option once on the command line. The Command-line option incompatibility diagram shows which options you can use together.

Component Explanation

ScanState.exe ScanState scans the source computer, collects the files and settings and creates a store. ScanState does not modify the source computer. By default, ScanState compresses the files and stores them as an image file (USMT3.MIG).

LoadState.exe

LoadState migrates the files and settings from the store to 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. Next, LoadState transfers the file to the correct location, deletes the temporary copy, and begins migrating the next file.

Compression improves performance by reducing network bandwidth usage as well as the required space in the store. However, for testing purposes, you can choose to turn off compression with /nocompress.

Migration .xml files MigSys.xml, MigApp.xml, MigUser.xml, and any Custom .xml files that you create.

Config.xml

If you want to exclude components from the migration, you can create and modify this file using the /genconfig option on the ScanState command line. This optional file has a different format than the migration .xml files because it does not contain any migration rules. Config.xml contains a list of the components that can be migrated and allows you to specify migrate = "no" for those you wish to exclude from the migration.

Component Manifests for Windows Vista

When the source or destination computer is running Windows Vista, these files control which operating system and browser settings are migrated and how. These files are located on computers running Windows Vista and you cannot modify these files. If you want to exclude certain operating system settings when the source computer is running Windows Vista, you will need to create and modify a Config.xml file.

Note These files are not used when the destination computer is running Windows XP. For Windows XP, MigSys.xml contains information that controls which operating system and browser settings to migrate.

Downlevel Manifests

When the source computer is running Windows 2000 or Windows XP, these manifests control which operating system and browser settings are migrated and how. For example, when the destination computer is running Windows Vista, ScanState collects the data using the Downlevel Manifests, and then LoadState migrates the data using the corresponding Component Manifest for Windows Vista . The Downlevel Manifests are not used during LoadState.

This set of files is located in the USMT\dlmanifests folder. You cannot modify these files. If you want to exclude certain operating system settings when the destination computer is running Windows Vista, you will need to create and modify a Config.xml file.

Note These files are not used when the destination computer is running Windows XP. For Windows XP, MigSys.xml contains information that controls which operating system and browser settings to migrate.

USMT internal files All other .dll, .xml, .dat, .mui, .inf files that are included with USMT are for internal use. You cannot modify these files.

Syntax This section explains the syntax and usage of the ScanState command-line options. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator.

The ScanState syntax is:

scanstate [StorePath] [/i:[Path\]FileName] [/o] [/v:VerbosityLevel] [/nocompress] [/localonly] [/encrypt /key:KeyString|/keyfile:[Path\]FileName] [/l:[Path\]FileName] [/progress:[Path\]FileName] [/r:TimesToRetry] [/w:SecondsBeforeRetry] [/c] [/p] [/all] [/ui:[DomainName\]UserName]|LocalUserName] [/ue:[DomainName\]UserName]|LocalUserName] [/uel:NumberOfDays|YYYY/MM/DD|0] [/efs:abort|skip|decryptcopy|copyraw] [/genconfig:[Path\]FileName] [/targetxp] [/config:[Path\]FileName] [/?|help]

For example:

For destination computers running Windows Vista:

To create a Config.xml file in the current directory (does not create a store), specify: scanstate /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 To create an encrypted store using Config.xml and the default migration .xml files, specify: scanstate \\fileserver\migration\mystore /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey"

For destination computers running Windows XP:

To create a Config.xml file in the current directory (does not create a store), specify: scanstate /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 To create an encrypted store using Config.xml and the default migration .xml files, specify: scanstate \\fileserver\migration\mystore /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey"

Storage options

Migration rule options USMT provides the following option that you can use to specify what you want to migrate.

Option Description

StorePath Indicates a folder where to save the files and settings (for example, StorePath cannot be c:\). You must specify StorePath on the ScanState command line except when using the /genconfig option. You cannot specify more than one StorePath.

/o Overwrites any existing data in the store. If not specified, ScanState will fail if the store already contains data. You cannot specify this option more than once on a command line.

/encrypt /key:KeyString

or

/encrypt /key:"Key String"

or

/encrypt /keyfile:[Path\]FileName

Encrypts the store with the specified key (password). Encryption is disabled by default. With this option, you will need to specify the encryption key with one of the following ways:

/key:KeyString specifies the encryption key. If there is a space in KeyString, you will need to surround it in quotes. /keyfile:FilePathAndName specifies a .txt file that contains the encryption key

We recommend that KeyString be at least 8 characters long, but it cannot exceed 256 characters. /key and /keyfile cannot be used on the same command line. /encrypt and /nocompress cannot be used on the same command line.

For example:

scanstate /i:miguser.xml /i:migapp.xml \\fileserver\migration\mystore /encrypt /key:mykey

Important 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.

/nocompress

Disables compression of data and saves the files to a hidden folder named "File" at StorePath\USMT3. Compression is enabled by default. You can use the uncompressed store to view what USMT stored, troubleshoot a problem or you can run an antivirus utility against the files. You should only use this option in testing environments because we recommend that you use a compressed store during your actual migration. /nocompress and /encrypt can not be used on the same command line. However, if you do choose to migrate an uncompressed store, LoadState will migrate each file directly from the store to the correct location on the destination computer — without a temporary location.

For example:

scanstate /i:miguser.xml /i:migapp.xml \\fileserver\migration\mystore /nocompress

Option Description

/i:[Path\]FileName

(include)

Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times in order to specify all of your .xml files (MigApp.xml, MigSys.xml, MigUser.xml and any custom .xml files that you create). Path can be a relative or full path. If you do not specify Path, then FileName must be located in the current directory. For more information about which files to specify, see the "xml files" section of the Frequently Asked Questions topic.

(Generate Config.xml)

Generates the optional Config.xml file, but does not create a store. To ensure that this file contains every component, application, and setting that can be migrated, you should create this file on a source computer that contains all the components, applications and settings that will be present on the destination computers. And in addition, you should specify the other (possibly modified) migration .xml files using /i when you specify this option.

Monitoring options USMT provides several options that you can use to analyze problems that occur during migration.

/genconfig:[Path\]FileName

After you create this file, you will need to specify it on the ScanState command line using the /config option.

The only options that you can specify with this option are /i, /v, /l, and /targetxp. You cannot specify StorePath because this option does not create a store. Path can be a relative or full path. If you do not specify Path, then FileName will be created in the current directory.

Examples:

This example creates a Config.xml file in the current directory for a destination computer running Windows Vista: scanstate /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 This example creates a Config.xml file in the current directory for a destination computer running Windows XP: scanstate /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13

/config:[Path\]FileName

Specifies the Config.xml file that ScanState should use to create the store. You cannot specify this option more than once on the command line. Path can be a relative or full path. If you do not specify Path, then FileName must be located in the current directory.

This example creates a store using the Config.xml file, MigUser.xml, and MigApp:

scanstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scan.log

This example migrates the files and settings to the destination computer using Config.xml, MigUser.xml, and MigApp:

loadstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:load.log

/targetxp

Optimizes ScanState when the destination computer is running Windows XP. You should use this option in the following situations:

With the /genconfig option to create a Config.xml file. This will optimize ScanState because the Config.xml file will only contain components that pertain to Windows XP. To create a store. This will optimize ScanState because the store will only contain components that pertain to Windows XP. This will shorten the amount of time that ScanState takes.

/localonly Migrates only files that are stored on the local computer, regardless of the rules in the .xml files that you specify on the command line. You should use this option when you want to exclude the data from external drives on the source computer (USB drives, external hard drives, and so on) and when there are network drives mapped on the source computer. If /localonly is not specified, then ScanState will copy files from these drives into the store.

Note The ScanState log is created by default, but you can specify the name and location of the log with the /l option.

Option Description

/l:[Path\]FileName

Specifies the location and name of the ScanState log.

You cannot store any of the log files in StorePath. Path can be a relative or full path. If you do not specify Path, then the log will be created in the current directory. You can specify /v to adjust the amount of output.

If you run ScanState or LoadState from a shared network resource, you must specify this option or USMT will fail with an error "USMT was unable to create the log file(s)". To fix this issue, specify /l:scan.log.

/v:VerbosityLevel

(Verbosity)

Enables verbose output in the ScanState log. The default is 0. You can specify any number from 0 to 15. However, USMT only uses the levels in the first table. If you specify a number that is not in the first table, USMT follows the mapping in the second table. USMT determines the level based on the following binary bit rules:

Bit 0 stands for verbose output. Bit 1 is not used. Bit 2 stands for status output. Bit 3 stands for debugger output.

VerbosityLevel can be one of the following levels:

If you specify 2, 3, 6, 7, 10, 11, 14, or 15, USMT uses the following mapping to determine VerbosityLevel.

Level Binary Value Explanation 0 0000 Only the default errors and warnings are enabled.1 0001 Enables verbose output. 4 0100 Enables error and status output. 5 0101 Enables verbose and status output. 8 1000 Enables error output to a debugger. 9 1001 Enables verbose output to a debugger. 12 1100 Enables error and status output to a debugger. 13 1101 Enables verbose, status, and debugger output.

Specified Level Binary Value Implied Level 2 0010 0 3 0011 1

User options By default all users are migrated. The only way to specify which users to include and exclude is by using the following options. You cannot exclude users in the migration .xml files or using Config.xml. For more information, see Identify Users and How To Migrate User Accounts.

For example:

scanstate \\fileserver\migration\mystore /v:13 /i:miguser.xml /i:migapp.xml

loadstate \\fileserver\migration\mystore /v:13 /i:miguser.xml /i:migapp.xml

6 0110 4 7 0111 5 10 1010 8 11 1011 9 14 1110 12 15 1111 13

/progress:[Path\]FileName

Creates the optional progress log. You cannot store any of the log files in StorePath. Path can be a relative or full path. If you do not specify Path, then FileName will be created in the current directory.

For example:

scanstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore /progress:prog.log /l:scanlog.log

/c

When specified, ScanState will continue to run even if there are nonfatal errors. Without the /c option, ScanState exits on the first error. When you specify this option, any files or settings that cause an error and are ignored will be logged in the progress log. For example, if there is a large file that will not fit in the store, ScanState will log an error and will continue with the migration. In addition, if a file is open or in use by an application, USMT may not be able to migrate the file and will log an error.

/r:TimesToRetry

(Retry)

Specifies the number of times to retry when an error occurs while saving the user state to a server. The default is three times. This option is helpful in environments where network connectivity is not fully reliable.

While storing the user state, /r will not be able to recover data that is lost due to a network hardware failure (such as a faulty or disconnected network cable) or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem.

/w:SecondsBeforeRetry (Wait)

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.

/p

Generates a space-estimate file called Usmtsize.txt that is saved to StorePath. This option does not collect the user state. You must also specify /nocompress. The estimates are applicable for both compressed and uncompressed stores because the compressed store will always be smaller. Therefore, you can make decisions based on the estimate and then turn compression back on for the final scan.

When you run this option, ScanState uses some temporary storage on the computer to create the file. However, once ScanState is complete, the temporary space is cleared.

The Usmtsize.txt file contains a list of values—one for each cluster size. The first column of numbers is the cluster size and the second column is what the store size will be for that cluster size. The first line is the cluster used for the drive where usmtsize.txt was created. The estimate that you will want to use is the line with the cluster size matching the storage drive (for example, the cluster size of your file server). These estimates use some assumed values and may not always provide a high degree of accuracy in the estimation process.

The following example turns off compression and creates a space-estimate file:

scanstate /i:miguser.xml /i:migapp.xml \\fileserver\migration\mystore /nocompress /p

Notes With Windows 2000, Convert.exe will convert the partition to a 512-byte cluster size. With Windows XP, Convert.exe will determine the best cluster size and will then (in most cases) convert the partition to a 4096-byte cluster size. The Chkdsk.exe command does not use cluster size terminology, but uses the word allocation unit instead. The Defrag.exe report uses cluster size term.

/? or /help Displays help at the command line.

Option Description

/all

Migrates all of the users on the computer.

USMT migrates all user accounts on the computer, unless you specifically exclude an account with /ue or /uel. For this reason, you do not need to specify this option on the command line. However, if you choose to specify /all, you cannot also specify /ui, /ue or /uel.

/ui:DomainName\UserName

or

/ui:DomainName\"User Name"

or

/ui:LocalUserName

(User include)

Migrates the specified user(s). By default, all users are included in the migration. Therefore, this option is only helpful when used with /ue or /uel. You can specify multiple /ui options, but you cannot use /ui with /all. DomainName and UserName can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotes.

For example:

To include only User2 from the Fareast domain, type: /ue:*\* /ui:fareast\user2 To migrate all users from the Fareast domain, and only the users who have been active in the last 30 days (from any domain), type: /uel:30 /ui:fareast\* In this example, a user Farwest\User1 who had last logged in 2 months ago will not be migrated.

/ue, and /ui examples

Examples for /ui and /ue.

The following examples apply to both /ui and /ue. That is, you can replace /ue with /ui to specify to exclude rather than include the specified users.

Using the options together

You can use /uel, /ue, and /ui together in order to migrate only the users that you want migrated. However, if a user is specified with /ui, and also specified to exclude with either /ue or /uel, the user will be included in the migration. For example, if you specify /ui:domain1\* /ue:domain1\user1, then User1 will be migrated because /ui takes precedence.

Encrypted file options You can use the following options to migrate encrypted files. In all cases, by default, USMT fails if an encrypted file is found unless you specify an /efs option. In order to migrate encrypted files, you must change the default behavior.

For more information, see How To Migrate EFS Files and Certificates.

For more examples, see /ue, and /ui examples.

/uel:NumberOfDays

or

/uel:YYYY/MM/DD

or

/uel:0

(User exclude based on last logon)

Migrates only the users that had logged onto the source computer within the specified time period. For example, /uel:30 will only migrate users who had logged on within the last 30 days when ScanState was run. You can specify a number of days or you can specify a date. You cannot use this option with /all.

/uel:0 migrates any users who are currently logged on and any users whose profiles have been loaded. For example, if domain\user1 is logged on and right-clicks an application, clicks Run As, and enters the credentials for domain\user2, then the profiles for both user1 and user2 will be loaded on the computer. If you run ScanState at this time with /uel:0, then both users will be included in the store. /uel:90 migrates users who have logged on within the last 90 days. /uel:1 migrates users who have logged on within the last 24 hours. /uel:2002/1/15 migrates users who have logged on January 15, 2002 or afterwards.

For example:

scanstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore /uel:0

Note USMT excludes users based on the state of the computer when ScanState was run. For example, if a user logs onto the source computer after ScanState is run but before LoadState is run, the logon will not be considered in this option.

/ue:DomainName\UserName

or

/ue:DomainName\"User Name"

or

/ue:LocalUserName

(User exclude)

Excludes the specified user(s) from the migration. You can specify multiple /ue options. You cannot use this option with /all. DomainName and UserName can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotes.

For example:

scanstate /i:miguser.xml /i:migapp.xml \\fileserver\migration\mystore /ue:domain1\user1

For more examples, see /ue, and /ui examples.

Behavior Command Exclude the user named User One in the Fareast domain. /ue:fareast\"user one"Exclude the user named User1 in the Fareast domain. /ue:fareast\user1 Exclude the local user named User1. /ue:user1 Exclude all local and domain users. /ue:*\* Exclude all local users. /ue:* Exclude users in all domains named User1, User2, and so on. /ue:*\user*

Behavior Command Include only User2 from the Fareast domain and exclude all other users. /ue:*\* /ui:fareast\user2

Include only the local user named User1 and exclude all other users. /ue:*\* /ui:user1

Include only the domain users from Domain1, except Domain1\User1.

This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:

On the ScanState command line, type: /ue:* /ui:domain1\* On the LoadState command line, type: /ue:* /ui:domain1\user1

Include only local (non-domain) users. /ue:*\* /ui:* Include only domain users who have logged on in the last 90 days, and only domain users. /uel:90 /ue:*

Note EFS certificates will be migrated automatically when migrating to Windows Vista. Therefore, you should specify the /efs:copyraw option on the ScanState command line to migrate the encrypted files Caution You should take extreme caution when migrating encrypted files. If you migrate an encrypted file without also migrating the certificate, end users will not be able to

Command-line option incompatibility The following tables indicate which command-line options are not compatible on the ScanState command line. If the table entry for a particular combination is blank, the options are compatible and you can use them together. The X symbol means that the options are not compatible. For example, you cannot use the /nocompress option with the /encrypt option.

LoadState Syntax

In this topic Before you begin Syntax Storage options Migration rule options Monitoring options User options

/ue, and /ui examples

Command-line option incompatibility

Before you begin Before you run LoadState, note the following:

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 the start button, 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. You should 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.

access the file after the migration.

Option Explanation /efs:abort Causes ScanState to fail with an error code if an Encrypting File System (EFS) file is found on the source computer. Enabled by default. /efs:skip Causes ScanState to ignore EFS files completely.

/efs:decryptcopy Causes ScanState to decrypt the file if possible before saving it to the store, and to fail if the file cannot be decrypted. If ScanState succeeds, the file will be unencrypted in the store, and once you run LoadState, the file will be copied to the destination computer.

/efs:copyraw

Causes ScanState to copy the files in the encrypted format. The files will be inaccessible on the destination computer until the EFS certificates are migrated. If you use this option, ensure that the certificates will be migrated. You should only use this option in the following two situations.

If the destination computer is running Windows Vista. In this case, EFS certificates will be migrated automatically. However, by default, USMT fails if an encrypted file is found (unless you specify an /efs option). Therefore you should specify /efs:copyraw with ScanState to migrate the encrypted file. Then when you run LoadState, the encrypted file and the EFS certificate will be automatically migrated. . If the destination computer is running Windows XP and you will migrate the certificates manually. You can migrate the EFS certifications using cipher.exe. For more information, see How To Migrate EFS Files and Certificates.

For example:

ScanState /i:miguser.xml /i:migapp.xml \\fileserver\migration\mystore /efs:copyraw

Note You must specify either /key or /keyfile with /encrypt.

You need to be a local or domain administrator to run LoadState unless you specify the /q option. Unless otherwise specified, you can only specify each option once on the command line. The Command-line option incompatibility diagram shows which options you can use together.

Syntax This section explains the syntax and usage of the LoadState command-line options. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator.

The LoadState syntax is:

loadstate StorePath [/i:[Path\]FileName] [/v:VerbosityLevel] [/nocompress] [/decrypt /key:KeyString|/keyfile:[Path\]FileName] [/l:[Path\]FileName] [/progress:[Path\]FileName] [/r:TimesToRetry] [/w:SecondsToWait] [/c] [/all] [/ui:[[DomainName\]UserName]|LocalUserName] [/ue:[[DomainName\]UserName]|LocalUserName] [/uel:NumberOfDays|YYYY/MM/DD|0] [/md:OldDomain:NewDomain] [/mu:OldDomain\OldUserName:[NewDomain\]NewUserName] [/lac:[Password]] [/lae] [/q] [/config:[Path\]FileName] [/?|help]

For example:

To decrypt the store and migrate the files and settings to a computer running Windows Vista, specify: loadstate \\fileserver\migration\mystore /i:migapp.xml /i:miguser.xml /v:13 /decrypt /key:"mykey" To decrypt the store and migrate the files and settings to a computer running Windows XP, specify: loadstate \\fileserver\migration\mystore /i:migsys.xml /i:migapp.xml /i:miguser.xml /v:13 /decrypt /key:"mykey"

Storage options USMT provides the following options that you can use to specify how and where the migrated data is stored.

Migration rule options USMT provides the following option that you can use to specify what you want to migrate.

Option Description

StorePath Indicates the folder where the files and settings data are stored. You must specify StorePath on the LoadState command line. You cannot specify more than one StorePath.

/decrypt /key:KeyString

or

/decrypt /key:"Key String"

or

/decrypt /keyfile:[Path\]FileName

Decrypts the store with the specified key. With this option, you will need to specify the encryption key with one of the following ways:

/key:KeyString specifies the encryption key. If there is a space in KeyString, you will need to surround it in quotes. /keyfile:FilePathAndName specifies a .txt file that contains the encryption key

KeyString cannot exceed 256 characters.

/key and /keyfile cannot be used on the same command line.

/decrypt and /nocompress cannot be used on the same command line.

For example:

loadstate /i:miguser.xml /i:miguser.xml \\fileserver\migration\mystore /decrypt /key:mykey

Important You should use extreme caution with this option because anyone that has access to the LoadState command-line script will also have access to the encryption key.

/nocompress

Specifies that the store is not compressed. You should only use this option in testing environments because we recommend that you use a compressed store during your actual migration. This option cannot be used in with the /decrypt option.

For example:

loadstate /i:miguser.xml /i:miguser.xml \\fileserver\migration\mystore /nocompress

Option Description

/i:[Path\]FileName

(include)

Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times in order to specify all of your .xml files (MigApp.xml, MigSys.xml, MigUser.xml and any custom .xml files that you create). Path can be a relative or full path. If you do not specify Path, then FileName must be located in the current directory.

For more information about which files to specify, see the "xml files" section of the Frequently Asked Questions topic.

/q Allows LoadState to run without administrative credentials. This option will only migrate the settings and account for the user who is currently logged on. Errors will occur if you try to apply settings to a location for which the user does not have sufficient credentials. For example, you will receive an error if a file needs to be written to "C:\Program Files" and the user you are running LoadState under does not have sufficient credentials to that folder.

/config:[Path\]FileName

Specifies the Config.xml file that LoadState should use. You cannot specify this option more than once on the command line. Path can be a relative or full path. If you do not specify Path, then FileName must be located in the current directory.

This example migrates the files and settings based on the rules in Config.xml, MigUser.xml, and MigApp.xml:

loadstate \\fileserver\migration\mystore /config:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:loadstate.log

Monitoring options USMT provides several options that you can use to analyze problems that occur during migration.

User options By default all users are migrated. The only way to specify which users to include and exclude is by using the following options. You cannot exclude users in the migration .xml files or using Config.xml. For more information, see Identify Users.

Option Description

/l:[Path\]FileName

Specifies the location and name of the LoadState log. You cannot store any of the log files in StorePath. Path can be a relative or full path. If you do not specify Path, then the log will be created in the current directory. You can specify /v to adjust the amount of output.

If you run LoadState from a shared network resource, you must specify this option or USMT will fail with an error "USMT was unable to create the log file(s)". To fix this issue, specify /l:load.log.

/v:VerbosityLevel

(Verbosity)

Enables verbose output in the LoadState log. The default is 0. You can specify any number from 0 to 15. However, USMT only uses the levels in the first table. If you specify a number that is not in the first table, USMT follows the mapping in the second table. USMT determines the level based on the following binary bit rules:

Bit 0 stands for verbose output. Bit 1 is not used. Bit 2 stands for status output. Bit 3 stands for debugger output.

VerbosityLevel can be one of the following levels:

If you specify 2, 3, 6, 7, 10, 11, 14, or 15, USMT uses the following mapping to determine VerbosityLevel.

For example:

loadstate \\fileserver\migration\mystore /v:13 /i:migapp.xml /i:miguser.xml

Level Binary Value Explanation 0 0000 Only the default errors and warnings are enabled.1 0001 Enables verbose output. 4 0100 Enables error and status output. 5 0101 Enables verbose and status output. 8 1000 Enables error output to a debugger. 9 1001 Enables verbose output to a debugger. 12 1100 Enables error and status output to a debugger. 13 1101 Enables verbose, status, and debugger output.

Specified Level Binary Value Implied Level 2 0010 0 3 0011 1 6 0110 4 7 0111 5 10 1010 8 11 1011 9 14 1110 12 15 1111 13

/progress:[Path\]FileName

Creates the optional progress log. You cannot store any of the log files in StorePath. Path can be a relative or full path. If you do not specify Path, then FileName will be created in the current directory.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore /progress:prog.log /l:scanlog.log

/c When specified, LoadState will continue to run even if there are nonfatal errors. Without the /c option, LoadState exits on the first error. When you specify this option, any files or settings that cause an error and are ignored will be logged in the progress log. For example, if a file is open or if there is a large file that will not fit on the destination computer, LoadState will log an error and will continue with the migration.

/r:TimesToRetry

(Retry)

Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is 3 times. This option is helpful in environments where network connectivity is not fully reliable.

While restoring the user state, /r will not be able to recover data that is lost due to a network hardware failure (such as a faulty or disconnected network cable) or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem.

/w:SecondsBeforeRetry (Wait)

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. /? or /help Displays help on the command line.

Option Description

Migrates all of the users on the computer.

/all USMT migrates all user accounts on the computer, unless you specifically exclude an account with /ue or /uel. For this reason, you do not need to specify this option on the command line. However, if you choose to specify /all, you cannot also specify /ui, /ue or /uel.

/ui:DomainName\UserName

or

/ui:DomainName\"User Name"

or

/ui:LocalUserName

(User include)

Migrates the specified user(s). By default, all users are included in the migration. Therefore, this option is only helpful when used with /ue or /uel. You can specify multiple /ui options, but you cannot use /ui with /all. DomainName and UserName can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotes.

For example:

To include only User2 from the Fareast domain, type: /ue:*\* /ui:fareast\user2 To migrate all users from the Fareast domain, and only the users who have been active in the last 30 days (from any domain), type: /uel:30 /ui:fareast\* In this example, a user Farwest\User1 who had last logged on 2 months ago will not be migrated.

For more examples, see /uel, /ue, and /ui examples.

/uel:NumberOfDays

or

/uel:YYYY/MM/DD

or

/uel:0

(User exclude based on last logon)

Migrates only the users that had logged onto the source computer within the specified time period. For example, /uel:30 will only migrate users who had logged on within the last 30 days when ScanState was run. You can specify a number of days or you can specify a date. You cannot use this option with /all.

Examples:

/uel:0 migrates accounts that were logged on to the source computer and any accounts whose profiles had been loaded when ScanState was run. For example, if domain\user1 was logged on and right-clicked an application, clicked Run As, and entered the credentials for domain\user2, then the profiles for both user1 and user2 would have been loaded on the computer. If ScanState was run at this time with /uel:0, then both users would be included in the store. /uel:90 migrates users who have logged on within the last 90 days. /uel:1 migrates users who have logged on within the last 24 hours. /uel:2002/1/15 migrates users who have logged on January 15, 2002 or afterwards.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore /uel:0

Note USMT excludes users based on the state of the computer when ScanState was run. For example, if a user logs onto the source computer after ScanState is run but before LoadState is run, the logon will not be considered in this option.

/ue:DomainName\UserName

or

/ue:DomainName\"User Name"

or

/ue:LocalUserName

(User exclude)

Excludes the specified user(s) from the migration. You can specify multiple /ue options but you cannot use /ue with /all. DomainName and UserName can contain the asterisk (*) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotes.

For examples, see /uel, /ue, and /ui examples.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore /ue:domain1\user1

/md:OldDomain:NewDomain

or

/md:LocalComputerName:NewDomain

(move domain)

Specifies a new domain for the user(s). You should use this option to change the domain for users on a computer or to migrate a local user to a domain account. OldDomain may contain the asterisk (*) wildcard character.

You can specify this option more than once. You may want to specify multiple /md options if you are consolidating users across multiple domains to a single domain. For example, you could specify /md:fareast:farwest and /md:farnorth:farwest.

If there are conflicts between two /md commands, the first rule that you specify is applied. For example, if you specify /md:fareast:farwest and /md:fareast:farnorth, then FarEast users would be mapped to the FarWest domain.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore

/progress:prog.log /l:load.log /md:fareast:farwest

Note If you specify an OldDomain that did not exist on the source computer, LoadState will appear to complete successfully (without an error or warning). However, in this case, user(s) will not be moved to NewDomain but will remain in their original domain. For example, if you miss-spell "domain1" and you specify "/md:domai1:domain2", the user(s) will remain in domain1 on the destination computer.

/ue, and /ui examples

Examples for /ui and /ue.

The following examples apply to both /ui and /ue. That is, you can replace /ue with /ui to specify to include rather than include the specified users.

Using the options together

You can use /uel, /ue, and /ui together in order to migrate only the users that you want migrated. However, if a user is specified with /ui, and also specified to exclude with either /ue or /uel, the user will be included in the migration. For example if you specify /ui:domain1\* /ue:domain1\user1, then User1 will be migrated because /ui takes precedence.

Command-line option incompatibility The following tables indicate which command-line options are not compatible on the LoadState command line. If the table entry for a particular combination is blank, the options are compatible and you can use them together. The X symbol means that the options are not compatible. For example, you cannot use the /nocompress option with the /decrypt option.

/mu:OldDomain\OldUserName:[NewDomain\]NewUserName

or

/mu:OldLocalUserName:NewDomain\NewUserName

Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple /mu options. You cannot use wildcard characters with this option.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore

/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1

/lac:[Password]

(local account create)

Specifies that if a user account is a local (non-domain) account, and it does not exist on the destination computer, USMT will create the account on the destination computer but it will be disabled. To enable the account, you must also specify /lae.

If /lac is not specified, any local user accounts (that do not already exist on the destination computer) will not be migrated. Password is the password for the new created account. An empty password is used by default.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore

/progress:prog.log /l:load.log /lac:password /lae

For more information, see Migrating local and domain accounts. For instructions, see How To Migrate User Accounts.

Caution You should use Password with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running LoadState. Also, if the computer has multiple users, all migrated users will have the same password.

/lae

(local account enable)

Enables the account that was created with /lac. You must specify /lac with this option.

For example:

loadstate /i:migapp.xml /i:miguser.xml \\fileserver\migration\mystore

/progress:prog.log /l:load.log /lac:password /lae

For more information, see Migrating local and domain accounts. For instructions, see How To Migrate User Accounts.

Behavior Command Exclude the user named User One in the Fareast domain. /ue:fareast\"user one"Exclude the user named User1 in the Fareast domain. /ue:fareast\user1 Exclude the local user named User1. /ue:user1 Exclude all local and domain users. /ue:*\* Exclude all local users. /ue:* Exclude users in all domains named User1, User2, and so on. /ue:*\user*

Behavior Command Include only User2 from the Fareast domain and exclude all other users. /ue:*\* /ui:fareast\user2

Include only the local user named User1 and exclude all other users. /ue:*\* /ui:user1

Include only the domain users from Domain1, except Domain1\User1.

This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:

On the ScanState command line, type: /ue:* /ui:domain1\* On the LoadState command line, type: /ue:* /ui:domain1\user1

Include only local (non-domain) users. /ue:*\* /ui:* Include only users. /ue:*\* /ui:*

USMT Internal Workflow ScanState process LoadState process

ScanState process When you run ScanState on the source computer, ScanState goes through the following process:

1. First, ScanState parses and validates the command-line parameters. Then, ScanState creates the ScanState.log file and begins logging.

2. ScanState collects information about all the migration components that need to be migrated. A migration component is a logical group of files, registry keys, and values. For example, the set of files, and registry keys and values that store the settings of Adobe Acrobat are grouped into a single migration component. There are three types of components: those that migrate the operating system settings, those that migrate application settings, and those that migrate users’ files. ScanState collects information about the application settings and user data components from the .xml files that are specified on the command line. The operating system settings are collected based on the following:

If the operating system on the destination computer is Windows XP, you must specify /i:MigSys.xml on both ScanState and LoadState command lines in order for any operating system settings to migrate. In addition, you should specify /targetXP with ScanState to indicate to ScanState that the operating system on the destination computer is Windows XP. If the operating system on the destination computer is Windows Vista, the manifests control how the operating system settings are migrated. You cannot modify these files. In this case, if you want to exclude certain operating system settings, you will need to create and modify a Config.xml file.

3. ScanState then determines which user profiles should be migrated. By default, all user profiles on the source computer will be migrated. However, you can include and exclude users using the User Options. The system profile (the "All users" profile (in Windows XP) or the Public profile (in Windows Vista) is always migrated. That is, you cannot exclude these profiles from the migration.

4. In the "Scanning" phase, ScanState does the following for each user profile selected for migration:

1. For each component, ScanState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, then the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.

2. Each component that is selected in the previous step is processed further. Any profile-specific variables (such as CSIDL_PERSONAL) are evaluated in the context of the current profile. For example, if the profile that is being processed belongs to “User1”, then CSIDL_PERSONAL would expand to C:\Users\User1\Documents (assuming that the user profiles are stored in the C:\Users directory).

3. For each selected component, ScanState evaluates the <detects> section. If the condition in the <detects> section evaluates to false, the component is not processed any further. Otherwise, the processing of this component continues.

4. For each selected component, ScanState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is the not system profile and the context of the <rules> section is “User” or “UserAndSystem”, then the rule is processed further. Otherwise, this rule is ignored.

5. ScanState creates a list of migration units that need to be migrated by processing the various subsections under this <rules> section. Each unit is collected if it is mentioned in an <include> subsection — as long as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence in the .xml files, see Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510). In addition, any migration unit (file, registry key or registry values) that is in a <UnconditionalExclude> section will not be migrated.

5. In the "Collecting" phase, ScanState creates a master list of the migration units by combining the lists that were created for each selected user profile.

6. In the "Saving" phase, ScanState writes the migration units that were collected to the store location.

Note For more information about how USMT processes the rules and the .xml files, see Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510).

Note From this point onwards, ScanState does not distinguish between components that migrate operating system settings, those that migrate application settings, and those that migrate users’ files. ScanState processes all components in the same way.

Note ScanState ignores some subsections like <destinationCleanup> and <locationModify>. These sections are only evaluated on the destination computer.

LoadState process The LoadState process is very similar to that of ScanState. ScanState collects migration units (file, registry key, or registry values) from the source computer and saves them to the store. Similarly, LoadState collects migration units from the store, and applies them to the destination computer.

1. First, LoadState parses and validates the command-line parameters. Then, LoadState creates the LoadState.log file and begins logging.

2. LoadState collects information about the migration components that need to be migrated. A migration component is a logical group of files, registry keys, and values. For example, the set of files, and registry keys and values that store the settings of Adobe Acrobat are grouped into a single migration component. LoadState obtains information for the application settings components and user data components from the migration .xml files that are specified on the LoadState command line. The operating system settings are obtained by one of the following:

If the operating system on the destination computer is Windows XP, you must specify /i:MigSys.xml on both ScanState and LoadState command lines in order for any operating system settings to migrate. This is because these tools obtain the components that specify the operating system settings from MigSys.xml. If the operating system on the destination computer is Windows Vista, the manifests control how the operating system settings are migrated. You cannot modify these files. In this case, if you want to exclude certain operating system settings, you will need to create and modify a Config.xml file.

3. LoadState then determines which user profiles should be migrated. By default, all user profiles present on the source computer will be migrated. However, you can include and exclude users using the User Options. The system profile (the "All users" profile (in Windows XP) or the Public profile (in Windows Vista)) is always migrated. That is, you cannot exclude these profiles from the migration.

If you are migrating local user accounts and if the accounts do not already exist on the destination computer, you must specify /lac. If /lac is not specified, any local user accounts that are not already present on the destination computer, will not be migrated. If specified, the /md and /mu options are processed to rename the user profile on the destination computer. For each user profile selected from the store, LoadState creates a corresponding user profile on the destination computer. The destination computer does not need to be connected to the domain for domain user profiles to be created. If USMT cannot determine a domain, USMT will attempt to apply the settings to a local account. For more information, see Identify Users.

4. In the "Scanning" phase, LoadState does the following for each user profile:

1. For each component, LoadState checks the type of the component. If the current user profile is the system profile and the component type is “System” or “UserAndSystem”, the component is selected for this user. Otherwise, the component is ignored. Alternatively, if the current user profile is not the system profile and the component type is “User” or “UserAndSystem”, the component is selected for this user. Otherwise, this component is ignored.

2. Each component that is selected is processed further. Any profile-specific variables (such as CSIDL_PERSONAL) are evaluated in the context of the current profile. For example, if the profile being processed belongs to “User1”, then CSIDL_PERSONAL would expand to C:\Users\User1\Documents (assuming that the user profiles are stored in the C:\Users directory).

3. For each selected component, LoadState evaluates the <rules> sections. For each <rules> section, if the current user profile is the system profile and the context of the <rules> section is “System” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored. Alternatively, if the current user profile is the not system profile and the context of the <rules> section is “User” or “UserAndSystem”, the rule is processed further. Otherwise, this rule is ignored.

4. LoadState creates a master list of migration units by processing the various subsections under the <rules> section. Each migration unit that is in an <include> subsection is migrated as long as there is not a more specific rule for it in an <exclude> subsection in the same <rules> section. For more information about precedence in the .xml files, see Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510). In addition, any migration units (file, registry key or registry values) that are in a <UnconditionalExclude> section will not be migrated.

5. LoadState evaluates the destination computer specific subsections (for example <destinationCleanup> and <locationModify>).

6. If the destination computer is Windows Vista, then the migration units that were collected by ScanState using Downlevel Manifests are processed by LoadState using the corresponding Component Manifest for Windows Vista. The Downlevel Manifests are not used during LoadState.

5. In the "Apply" phase, LoadState writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there is not a <merge> rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally. For example, OriginalFileName(1).OriginalExtension. Some settings (for example, fonts, wallpaper, and screensaver settings) will not take effect until the next time the user logs on. For this reason, you should log off after you run LoadState.

.xml Files

In this topic Overview Migration .xml files Custom .xml file

Note ScanState does not modify or change the source computer in any way — that is, the source computer will not be changed by running ScanState.

Note From this point onwards, LoadState does not distinguish between components that migrate operating system settings, those that migrate application settings, and those that migrate users’ files. LoadState evaluates all components in the same way.

Note LoadState ignores the <detects> section specified in a component. At this point, all specified components are considered to be detected and are selected for migration.

Important It is important to provide the .xml files on the LoadState command line that you want LoadState to consider and use. Otherwise, any destination specific rules (such as <locationModify>) in these .xml files will be ignored, even if the same .xml files were provided during ScanState.

Config.xml Additional information

Overview In order for ScanState and LoadState to use any of the migration .xml files, you need to specify the files on both command lines using the /i option. 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 should 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.

To modify the migration for your needs, you should do one or both of the following.

Modify the migration .xml files . You should modify the .xml files if you want to exclude a portion of a component (for example, to migrate C:\ but exclude all .mp3 files), or want to move data to a new location on the destination computer. To modify these files, you must be familiar with the migration rules and syntax. For ScanState and LoadState to use these files, you will need to specify them on both command lines. Create custom .xml file files. You can also create a custom .xml to migrate settings for another application, or to change the migration behavior to suite your needs. For ScanState and LoadState to use this file, you will need to specify them on both command lines. Create and modify a Config.xml file. Do this if you want to exclude an entire component from the migration (for example, exclude the entire My Documents folder, or exclude the settings for an application). Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. In addition, using this file is the only way to exclude the operating system settings that are migrated to computers running Windows Vista (since MigSys.xml is not applicable in this scenario).

For more information about excluding data, see How To Exclude Files and Settings.

Migration .xml files The following are the migration .xml files that are included with USMT. Each file contains migration rules that control which components are migrated and where they are migrated to the destination computer. You can use the asterisk (*) wildcard character in each of these files. However, you cannot use a question mark (?) as a wildcard.

MigSys.xml. Specify this file on both command lines when the destination computer is running Windows XP to migrate operating system and browser settings.(in addition, you should specify /targetXP). You can modify MigSys.xml. When the source or destination computer is running Windows Vista, this file is not applicable because the operating system and browser settings are migrated using the manifests. Since you cannot modify the manifests, if you want to exclude certain operating system settings in this scenario, you will need to create and modify a Config.xml file. MigApp.xml. Specify this file on both command lines to migrate application settings to computers running both Windows XP and Windows Vista. You can modify MigApp.xml. MigUser.xml. Specify this file on both command lines to migrate user folders, files, and file types to computers running both Windows XP and Windows Vista. You can modify MigUser.xml. This file does not contain rules that migrates specific user accounts. The only way to specify which user accounts to migrate is on the command line using the User Options.

Custom .xml file You can create custom .xml file(s) to customize the migration for your unique needs. For example, you may want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. For ScanState and LoadState to use this file, you will need to specify it on both command lines. For more information, see How To Create a Custom .xml File.

Config.xml This is an optional file that you can create using the /genconfig option on the ScanState command line. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings that are migrated to computers running Windows Vista (because MigSys.xml is not applicable in that scenario). This file has a different format than the migration .xml files because it does not contain any migration rules — it only contains a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the Sample Config.xml file. For this reason, excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. You cannot use wildcard characters in this file.

If you want to include all of the default components, you do not need to create this file. Alternatively, if you are satisfied with the default migration behavior defined in MigSys.xml, MigApp.xml, and MigUser.xml, and you only want to exclude some components, you can create and modify a Config.xml and leave the other .xml files as is.

When you run /genconfig, ScanState reads the other .xml files (that you specify using /i) and the manifests to create a custom list of components that can be migrated from the computer. This file will only contain operating system components, applications and the user document sections that are in both the .xml files and installed on the computer when you run /genconfig. Therefore, you should create this file on a source computer that contains all the components, applications and settings that will be present on the destination computers. This will ensure that this file contains every component that can be migrated. The components are organized into sections: <Applications>, <WindowsComponents>, and <Documents>. To choose not to migrate a component, simply change its entry to migrate="no".

After you create this file, you only need to specify it on the ScanState command line using /config in order for it to effect the migration. However, if you want to exclude additional data that you migrated to the store, simply modify Config.xml and specify the updated file with LoadState. For example, if you collected the My Documents folder in the store, but you decide that you do not want to migrate the My Documents folder to a destination computer, you can modify Config.xml (migrate=no) before you run LoadState and the file will not be migrated. For more information about the precedence that takes place when excluding data, see How To Exclude Files and Settings.

In addition, note the following functionality with this file:

If a parent component is removed from the migration in Config.xml by specifying migrate = "no", then all of its child components will automatically be removed from the migration also (even if the child component is set to migrate = "yes").

If, by mistake, you have two lines of code for the same component where one specifies migrate="no" and the other specifies migrate="yes", the component will be migrated. When creating this file for Windows Vista, you should not specify /i:migsys.xml because MigSys.xml is not applicable. For example, you could run scanstate /genconfig:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scan.log

Examples

Destination computer running Windows Vista:

This command creates a Config.xml file in the current directory (does not create a store): scanstate /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 This command creates an encrypted store using Config.xml and the default migration .xml files: scanstate \\fileserver\migration\mystore /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey" This command decrypts the store and migrates the files and settings: loadstate \\fileserver\migration\mystore /i:migapp.xml /i:miguser.xml /v:13 /decrypt /key:"mykey"

Destination computer running Windows XP:

This command creates a Config.xml file in the current directory (does not create a store): scanstate /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /genconfig:config.xml /v:13 This command creates an encrypted store using Config.xml and the default migration .xml files: scanstate \\fileserver\migration\mystore /targetxp /i:migsys.xml /i:migapp.xml /i:miguser.xml /o /config:config.xml /v:13 /encrypt /key:"mykey" This command decrypts the store and migrates the files and settings: loadstate \\fileserver\migration\mystore /i:migsys.xml /i:migapp.xml /i:miguser.xml /v:13 /decrypt /key:"mykey"

Additional information For more information about how to change the files and settings that are migrated, see Using USMT 3.0. For more information about each XML element, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519). For answers to common questions, see ".xml files" in the Frequently Asked Questions topic. For instructions for using the XML schema to write and validate migration .xml files, see MigXML.xsd.

Using USMT 3.0 This section covers:

How To Migrate User Accounts How To Migrate EFS Files and Certificates How To Create a Custom .xml File How To Exclude Files and Settings How To Reroute Files and Settings How To Include Files and Settings How To Use the XML Schema (MigXML.xsd)

How To Migrate User Accounts By default all users are migrated. The only way to specify which users to include and exclude is on the command line using the User options. You cannot specify users in the migration .xml files or using Config.xml.

To migrate all user accounts and user settings 1. Log on to the source computer as an administrator, and specify:

scanstate \\fileserver\migration\mystore /i:miguser.xml /i:migapp.xml /o

2. Log on to the destination computer as an administrator.

3. Do one of the following:

If you are migrating domain accounts, specify: loadstate \\fileserver\migration\mystore /i:miguser.xml /i:migapp.xml If you are migrating local accounts along with domain accounts, specify:

loadstate \\fileserver\migration\mystore /i:miguser.xml /i:migapp.xml /lac /lae

To migrate two domain accounts (User1 and User2) 1. Log on to the source computer as an administrator, and specify:

scanstate \\fileserver\migration\mystore /ue:*\* /ui:domain1\user1 /ui:domain2\user2 /i:miguser.xml /i:migapp.xml /o

2. Log on to the destination computer as an administrator.

3. Specify the following: loadstate \\fileserver\migration\mystore /i:miguser.xml /i:migapp.xml

To migrate two domain accounts (User1 and User2) and move User1 from the FarEast domain to the FarWest domain

1. Log on to the source computer as an administrator, and specify: scanstate \\fileserver\migration\mystore /ue:*\* /ui:fareast\user1 /ui:fareast\user2 /i:miguser.xml /i:migapp.xml /o

2. Log on to the destination computer as an administrator.

3. Specify the following: loadstate \\fileserver\migration\mystore /mu:fareast\user1:farwest\user2 /i:miguser.xml /i:migapp.xml

How To Migrate EFS Files and Certificates In order to migrate encrypted files, you must change the default behavior using one of the following options. For more information about the /efs options, see How To Migrate EFS Files and Certificates.

To a computer running Windows Vista If the destination computer is running Windows Vista, Encrypting File System (EFS) certificates will be migrated automatically. However, by default, USMT fails if an encrypted file is found (unless you specify an /efs option). Therefore, you must specify /efs:copyraw with ScanState to migrate the encrypted files. Then when you run LoadState on the destination computer, the encrypted file and the EFS certificate will be automatically migrated.

To a computer running Windows XP In order to migrate encrypted files to computers running Windows XP, you must also migrate the Encrypting File System (EFS) certificate. By default, USMT fails if an encrypted file is found (unless you specify an /efs option). In order to migrate encrypted files, you must change the default behavior. When migrating certificates using USMT, the end user is needed both before and after the migration. You can migrate EFS certificates using Cipher.exe or with the Certificates snap-in.

To migrate EFS certificates using Cipher.exe To migrate EFS certificates using the Certificates snap-in

To migrate EFS certificates using Cipher.exe

In order to migrate Encrypting File System (EFS) certificates using Cipher.exe the user who owns the certificate must complete the following procedure.

1. The end user who owns the certificate must log on to the source computer and quit all programs.

2. At the command prompt, run Cipher.exe using the following syntax:

cipher /x[:EFSFilePath] [FileName]

FileName is a file name without extensions, and EFSFilePath is an encrypted filepath. If EFSFilePath is provided, the current user's certificate(s) that is used to encrypt the file will be backed up. Otherwise, the user's current EFS certificate and keys will be backed up. Cipher will create a password-protected .pfx file wherever you specify. For additional information about Cipher.exe, type cipher /?.

3. Once the certificate is stored, the administrator can collect the user state using the /efs:copyraw option on the Scanstate command line. For example:

Note You do not have to specify /lae. This option enables the account that was created with /lac. Instead, 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.

Note The /efs options are not supported on the LoadState command line.

Important You should use extreme caution when migrating encrypted files. If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.

To migrate EFS certificates using Cipher.exe

Important The end user should keep the following issues in mind when determining where to store the .pfx file (the backed-up certificate). First, the file must be stored in a location that will be accessible from the destination computer (for example, a shared folder or removable media). Second, the file should not be stored in the same place as the USMT intermediate store (which will contain the encrypted file). Cipher will password-protect the .pfx file, but this is not a very strong security measure. It would still be a security risk to store the encrypted file and its EFS certificate in the same place.

scanstate \\fileserver\migration\mystore /efs:copyraw /i:migapp.xml /i:migsys.xml /i:miguser.xml /v:13 /targetxp

4. Next, the administrator should install Windows XP and applications as needed on the destination computer, and then restore the user state onto the destination computer using LoadState.

5. Once the migration is complete, the end user must log on to the destination computer, navigate to the backed up certificate, and double-click the .pfx file.

6. The Import Wizard will guide the end user through restoring the EFS certificate. The end user must specify his or her password for the certificate. After completing the Import Wizard, the certificate will be restored.

To migrate EFS certificates using the Certificates snap-in

In order to migrate Encrypting File System (EFS) certificates using the Certificates snap-in, the user who owns the certificate(s) must export the certificate from the source computer before the migration. Then this user must import the certificate on the destination computer after the migration. If either of the procedures are not followed, the file will remain encrypted on the destination computer.

1. The end user who owns the certificate must log on to the source computer.

2. Open Microsoft Management Console (MMC) by typing mmc in the Run dialog box.

3. In the File menu, click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click Add.

5. Select Certificates from the list, click Add, and then select My user account.

6. Click Finish, click Close, and then click OK.

7. Browse to Certificates - Current user\Personal\Certificates.

8. Right-click the certificate that you want to migrate.

9. Click All Tasks and then click Export.

10. The Certificate Export Wizard will help you store the certificate somewhere that is accessible from the destination computer (for example a floppy disk, or shared folder). When prompted, indicate that you want to export the private key along with the certificate. Upon completion, you will receive a message that the export was successful.

11. The administrator can now collect the user state using the /efs:copyraw option on the Scanstate command line. For example:

scanstate \\fileserver\migration\mystore /efs:copyraw /i:migapp.xml /i:migsys.xml /i:miguser.xml /v:13 /targetxp

12. Next, the administrator should install Windows XP and applications as needed on the destination computer and then restore the user state to the destination computer using LoadState.

1. The end user who owns the certificate must log on to the destination computer.

2. Open MMC by typing mmc in the Run dialog box.

3. In the File menu, click Add/Remove Snap-in.

4. In the Add/Remove Snap-in dialog box, click Add.

5. Select Certificates from the list, click Add, and then select My user account.

6. Click Finish, click Close, and then click OK.

7. Browse to Certificates - Current user\Personal.

8. Right-click Personal.

9. Click All Tasks, and then click Import.

10. Use the Certificate Import Wizard to locate the certificate that you exported. When browsing for the certificate, you should select Personal Information Exchange (*.pfx; *.p12) from the Files of type dropdown list box. You will need to enter the password you supplied when you exported the certificate from the destination computer.

11. Upon completion, you will receive a message that the import was successful.

How To Create a Custom .xml File

In this topic Requirements of an .xml file Best practices Creating an .xml file to migrate the settings of an application

Important By default, Scanstate fails with an error code if an EFS file is found on the source computer. In order to migrate EFS files, you must change this behavior using one of the /efs options. To export the certificate from the source computer

To import the certificate onto the destination computer. export the certificate from the source computer

Examples and additional information

You can create custom .xml file(s) to customize the migration for your unique needs — for example to migrate a specific line-of-business application or to change the default migration behavior. For ScanState and LoadState to use this file, you will need to specify it on both command lines.

Requirements of an .xml file When creating custom .xml files, note the following requirements:

The file must be in Unicode Transformation Format-8 (UTF-8). You must save the file in this format, and you must specify <?xml version="1.0" encoding="UTF-8"?> at the beginning of each .xml file. The file must have a unique migration urlid. The urlid of each file that you specify on the command line must be different. If two migration .xml files have the same urlid, the second .xml file that is specified on the command line will not be processed. This is because USMT uses the urlid to define the components within the file. For example, you must specify the following at the beginning of each file. <?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/<CustomFileName>">

Each component in the file must have a display name in order for it to appear in Config.xml. This is because Config.xml defines the components by the display name and the migration urlid. For example, specify <displayName>My Application</displayName>.

For examples of custom .xml files, see XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496).

Best practices The <CustomFileName> in the migration urlid should match the name of the file. Although it is not a requirement, it is good practice for <CustomFileName> to match the name of the file. For example, the following is from MigApp.xml: <?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/migapp">

Use the XML Schema (MigXML.xsd) to write and validate migration .xml files. Use the default migration .xml files as models. To create a custom .xml file, you can use the migration .xml files as models to create your own. If you need to migrate user data files, model your custom .xml file on MigUser.xml. If you need to migrate operating system settings to a computer running Windows XP, model your .xml on MigSys.xml. And to migrate application settings, start with MigApp.xml. We recommend that you create a separate XML file instead of adding your XML code to one of the existing migration .xml files. For example, if you have code that migrates the settings for an application, you should not just add the code to MigApp.xml. This is because MigApp.xml is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, MigApp.xml will be overwritten by the default version of the file and you will lose your customized version. If the destination computer is running Windows Vista, you should not create custom .xml files to alter the operating system settings that are migrated. These settings are migrated by the manifests and you cannot modify those files. In this scenario, if you want to exclude certain operating system settings from the migration, you will need to create and modify a Config.xml file. You can use the asterisk (*) wildcard character in any migration .xml file that you create. However, you cannot use the question mark as a wildcard character in the .xml files.

Creating an .xml file to migrate the settings of an application The rest of this topic defines the process you should go through to author a custom migration .xml file that migrates the settings of an application that is not migrated by default by USMT. We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings.

This topic does not contain information about how to migrate applications that store settings in an application-specific store — only the applications that store the information in files or in the registry. It also does not contain information about how to migrate the data that users create using the application. For example, if the application creates .doc files using a specific template, this topic does not discuss how to migrate the .doc files and templates themselves.

Before you begin Step 1: Verify that the application is installed and that it is the correct version Step 2: Identify what settings to migrate Step 3: Identify how to apply the settings on the destination computer Step 4: Author the Migration XML component for the application Step 5: Test the application settings migration Examples and additional information

Before you begin You will first need to create a test computer that contains the operating system of your source computers, and the application whose settings you want to migrate. For example, if you are planning on migrating from Windows XP to Windows Vista, install Windows XP on your test computer and then install the application.

Step 1: Verify that the application is installed and that it is the correct version Before USMT migrates the settings, you need it to check whether the application is installed on the computer, and that it is the correct version. If the application is not installed on the source computer, you probably do not want USMT to spend time searching for the application’s settings. More importantly, if USMT collects settings for an application that is not installed, it may migrate settings that will cause the destination computer to function incorrectly. If there is more than one version of the application, you should also check for this as well. This is because the new version may not store the settings in the same place, which may lead to unexpected results on the destination computer.

There are many ways to detect if an application is installed. We recommend that you check for an application uninstall key in the registry, and that you search the computer for the executable file that installed the application. It is important that you check for both of these because sometimes different versions of the same application share the same uninstall key. So even if the key is there, it may not correspond to the version of the application that you want.

Check the registry for an application uninstall key

When many applications are installed (especially those installed using the Microsoft Installer (MSI) technology), an application uninstall key is created under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall. For example, when Adobe Acrobat Reader 7 is installed, it creates a key named HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall \{AC76BA86-7AD7-1033-7B44-A70000000000}. Therefore, if a computer contains this key, then Adobe Acrobat Reader 7 is installed on the computer. You can check for the existence of a registry key using the DoesObjectExist helper function.

Usually, you can find this key by searching under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall for the name of the application, the name of the application executable file, or for the name of the company that makes the application. You can use the Registry Editor (Regedit.exe located in the %SystemRoot%) to search the registry.

Check for the file system for the application executable file

You should also check the application binaries for the executable that installed the application. To do this, you will first need to determine where the application is installed and what the name of the executable is. Most applications store the installation location of the application binaries in the registry. You should search the registry for the name of the application, the name of the application executable, or for the name of the company that makes the application, until you find the registry value that contains the installation path. Once you have determined the path to the application executable, you can use the DoesFileVersionMatch helper function to check for the correct version of the application executable. For an example of how to do this, see the MSN Messenger section of MigApp.xml.

Step 2: Identify what settings to collect and where each is stored on the computer Next, you should go through the user interface and make a list of all of the available settings. You can reduce the list if there are settings that you do not want to migrate. To determine where each setting is stored, you will need to change each setting and monitor the activity on the registry and the file system. You do not need to migrate the binary files and registry settings that are made when the application is installed. This is because you will need to reinstall the application onto the destination computer. You only need to migrate those settings that are customizable.

1. Download a file and registry monitoring tool such as the Regmon and Filemon tools from the Sysinternals Web site (http://go.microsoft.com/fwlink/?linkid=36109).

2. Shut down as many applications as possible to limit the registry and file system activity on the computer.

3. Filter the output of the tools so it only displays changes being made by the application.

4. Start the monitoring tool(s), change a setting, and look for registry and file system writes that occurred when you changed the setting. Make sure the changes you make actually take effect. For example, if you are changing a setting in Microsoft Word by selecting a check box in the Options dialog box, the change typically will not take effect until you close the dialog box by clicking OK.

5. When the setting is changed, note the changes to the file system and registry. There may be more than one file or registry values for each setting. You should identify the minimal set of file and registry changes that are required to change this setting. This set of files and registry keys is what you will need to migrate in order to migrate the setting.

Step 3: Identify how to apply the gathered settings If the version of the application on the source computer is the same as the one on the destination computer, then you do not have to modify the collected files and registry keys. By default, USMT migrates the files and registry keys from the source location to the corresponding location on the destination computer. For example, if a file was collected from the C:\Documents and Settings\User1\My Documents folder and the profile directory on the destination computer is located at D:\Users\User1, then USMT will automatically migrate the file to D:\Users\User1\My Documents. However, you may need to modify the location of some settings in the following three cases:

Case 1: The version of the application on the destination computer is newer than the one on the source computer.

In this case, the newer version of the application may be able to read the settings from the source computer without modification. That is, the data collected from an older version of the application is sometimes compatible with the newer version of the application. However, you may need to modify the setting location if either of the following is true:

The newer version of the application has the ability to import settings from an older version. This mapping usually happens the first time a user runs the newer version after the settings have been migrated. Some applications do this automatically after settings are migrated. However, other applications will only do this if the application was upgraded from the older version. This is because when the application is upgraded, a set of files and/or registry keys are installed that indicate the older version of the application was previously installed. If you perform a clean installation of the newer version (which is the case in most migrations), the computer does not contain this set of files and registry keys so the mapping does not occur. In order to trick the newer version of the application into initiating this import process, your migration script may need to create these files and/or registry keys on the destination computer. To identify which files and/or registry keys/values need to be created to cause the import, you should upgrade the older version of the application to the newer one and monitor the changes made to the file system and registry by using the same process described in To determine where each setting is stored. Once you know the set of files that the computer needs, you can use the <addObjects> element to add them to the destination computer. The newer version of the application cannot read settings from the source computer and it is also unable to import the settings into the new format. In this case, you will need to create a mapping for each setting from the old locations to the new locations. To do this, determine where the newer version stores each setting using the process described in To determine where each setting is stored. After you have created the mapping, apply the settings to the new location on the destination computer using the <locationModify> element, and the RelativeMove and ExactMove helper functions.

To determine where each setting is stored

Note Most applications store their settings under the user profile. That is, the settings stored in the file system are under the %UserProfile% directory, and the settings stored in the registry are under the HKEY_CURRENT_USER hive. For these applications you can filter the output of the file and registry monitoring tools to show activity only under these locations. This will considerably reduce the amount of output that you will need to examine.

Note Changing an application setting invariably leads to writing to registry keys. If possible, filter the output of the file and registry monitor tool to display only writes to files and registry keys/values.

Case 2: The destination computer already contains settings for the application.

We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. If you must install the application before the migration, you should delete any existing settings using the <destinationCleanup> element. If for any reason you want to preserve the settings that are on the destination computer, you can use the <merge> element and DestinationPriority helper function.

Case 3: The application overwrites settings when it is installed.

We recommend that you migrate the settings after you install the application, but before the user runs the application for the first time. We recommend this because this ensures that there are no settings on the destination computer when you migrate the settings. Also, when some applications are installed, they overwrite any existing settings that are on the computer. In this scenario, if you migrated the data before you installed the application, your customized settings would be overwritten. This is common for applications that store settings in locations that are outside of the user profile (typically these are settings that apply to all users). These universal settings are sometimes overwritten when an application is installed, and they are replaced by default values. To avoid this, you must install these applications before migrating the files and settings to the destination computer. By default with USMT, data from the source computer overwrites data that already exists in the same location on the destination computer.

Step 4: Authoring the Migration XML component for the application After you have completed steps 1-3, you will need to create a custom migration .xml file that migrates the application based on the information that you now have. You can use the MigApp.xml file as a model because it contains examples of many of the concepts discussed in this topic. You can also see the XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496) for another sample .xml file.

Your script should do the following:

1. Check whether the application and correct version is installed by:

Searching for the installation uninstall key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall using the DoesObjectExist helper function. Checking for the correct version of the application executable file using the DoesFileVersionMatch helper function.

2. If the correct version of the application is installed, then ensure that each setting is migrated to the appropriate location on the destination computer.

If the versions of the applications are the same on both the source and destination computers, migrate each setting using the <include> and <exclude>element. If the version of the application on the destination computer is newer than the one on the source computer, and the application cannot import the settings, your script should either 1) add the set of files that trigger the import using the <addObjects> element or 2) create a mapping that applies the old settings to the correct location on the destination computer using the <locationModify> element, and the RelativeMove and ExactMove helper functions. If you must install the application before migrating the settings, delete any settings that are already on the destination computer using the <destinationCleanup> element.

For information about the .xml elements, see XML Elements Reference.

Step 5: Testing the application settings migration On a test computer, install the operating system that will be installed on the destination computers. For example, if you are planning on migrating from Windows XP to Windows Vista, install Windows Vista and the application. Next, run LoadState on the test computer and verify that all settings migrate. Make corrections if necessary and repeat the process until all the necessary settings are migrated correctly.

To speed up the time it takes to collect and migrate the data, you can migrate only one user at a time, and you can exclude all other components from the migration except the application that you are testing. To specify only User1 in the migration, type: /ue:*\* /ui:user1. For more information, see How To Exclude Files and Settings and User options. To troubleshoot a problem, check the progress log, and the ScanState and LoadState logs, which contain warnings and errors that may point to problems with the migration.

Examples and additional information Examples:

How To Exclude Files and Settings How To Reroute Files and Settings How To Include Files and Settings XML Examples (http://go.microsoft.com/fwlink/?LinkId=73855)

Additional information:

How To Create a Custom .xml File Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519)

Note We recommend that you create a separate .xml file instead of adding your script to MigApp.xml. This is because MigApp.xml is a very large file and it will be difficult to read and edit. In addition, if you reinstall USMT for some reason, MigApp.xml will be overwritten by the default version of the file and you will lose your customized version. Important Some applications store information in the user profile that should not be migrated (for example, application installation paths, the computer name, and so on). You should make sure to exclude these files and registry keys from the migration.

How To Exclude Files and Settings

In this topic When you specify the migration .xml files, USMT migrates the settings and components specified in What Does USMT 3.0 Migrate?. You cannot exclude users in the migration .xml files or using Config.xml. The only way to specify which users to include and exclude is on the command line using the User options. To exclude files and settings, you have the following options.

Modify the migration .xml files or create a custom .xml file. You can use the following elements to specify what to exclude:

<include> and <exclude>: You can use the <include> and <exclude> elements to exclude objects with conditions — for example, to migrate all files located in the C:\ drive, except any .mp3 files. It is important to remember that conflicts and precedence apply to these elements. See http://go.microsoft.com/fwlink/?LinkId=74510 for more information. <unconditionalExclude>: You can use the <unconditionalExclude> element to globally exclude data. This element excludes objects regardless of any other <include> rules that are in the .xml files — for example, to exclude all .mp3 files on the computer or to exclude all files from C:\UserData. That is, this element takes precedence over all other include and exclude rules in the .xml files.

Create a Config.xml: You can create and modify a Config.xml file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating system settings that are migrate to computers running Windows Vista. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax. Additional information

Modify the migration .xml files or create a custom .xml file We recommend that you create a custom .xml file instead of modifying the default migration .xml files. This way, you can keep your changes separate from the default .xml files and it may be easier to track your modifications. You can use the <include> and <exclude> options, and the <unconditionalExclude> option.

<include> and <exclude>

The migration .xml files (specifically MigApp.xml and MigUser.xml) contain the <component> element, which typically represents a self contained component, or an application such as Outlook and Word. To exclude the files and registry settings that are associated with these components, you should use the <include> and <exclude> elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y (where Y is more specific than X). For the syntax of these elements, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519).

Example 1: How to migrate all files from C:\ except .mp3 files Example 2: How to migrate all files located in C:\Data except files in C:\Data\tmp Example 3: How to exclude the files in a folder, but include all subfolders Example 4: How to exclude a file from a specific folder Example 5: How to exclude a file from any location

Example 1: How to migrate all files from C:\ except .mp3 files

The following .xml file migrates all files located in the C:\ drive, except any .mp3 files.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/mp3files"> <!-- This component migrates all files except those with .mp3 extension--> <component type="Documents" context="System"> <displayName _locID="miguser.sharedvideo">MP3 Files</displayName> <role role="Data"> <rules> <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'> <objectSet> <pattern type="File">C:\* [*]</pattern> </objectSet> </include> <exclude> <objectSet> <pattern type="File">C:\* [*.mp3]</pattern> </objectSet> </exclude> </rules> </role> </component> </migration>

Example 2: How to migrate all files located in C:\Data except files in C:\Data\tmp

The following .xml file migrates all files and subfolders in C:\Data, except the files and subfolders in C:\Data\tmp.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName _locID="miguser.sharedvideo">Test component</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File">C:\Data\* [*]</pattern> </objectSet> </include> <exclude> <objectSet>

Note If you specify <exclude>, you should always specify a corresponding <include> rule. This is because if an <include> rule is not specified, the specific files or settings will not be included anyway — that is, they will already be excluded from the migration. So an unaccompanied <exclude> rule is unnecessary.

<pattern type="File"> C:\Data\temp\* [*]</pattern> </objectSet> </exclude> </rules> </role> </component> </migration>

Example 3: How to exclude the files in a folder, but include all subfolders

The following .xml file migrates any subfolders within C:\EngineeringDrafts, but excludes all files that are in C:\EngineeringDrafts.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents without subfolders</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\EngineeringDrafts\* [*]</pattern> </objectSet> </include> <exclude> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [*]</pattern> </objectSet> </exclude> </rules> </role> </component> </migration>

Example 4: How to exclude a file from a specific folder

The following .xml file migrates all files and subfolders in C:\EngineeringDrafts, except for the Sample.doc in C:\EngineeringDrafts.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents except Sample.doc</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\EngineeringDrafts\* [*]</pattern> </objectSet> </include> <exclude> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern> </objectSet> </exclude> </rules> </role> </component> </migration>

Example 5: How to exclude a file from any location

To exclude Sample.doc from wherever it exists on the C: drive, use <pattern> as follows. If multiple files exist with the same name on the C: drive, then all of these files will be excluded.

<pattern type="File"> C:\* [Sample.doc] </pattern>

To exclude Sample.doc from any drive on the computer, use <script> as follows. If multiple files exist with the same name, all such files will be excluded.

<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>

<unconditionalExclude>

If you want to exclude a file type from the migration, regardless of the other <include> or <exclude> rules, you can use the <unconditionalExclude> element. This element excludes objects globally across all components. For example, you should use this element if you want to exclude all .mp3 files from the computer. Or, if you are backing up C:\UserData using another method, you can exclude the entire folder from the migration. You should use this element with caution because if an application needs a file that you exclude, the application may not function properly on the destination computer. For the syntax of this element, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519).

Example 1: How to exclude all .mp3 files Example 2: How to exclude all of the files on a specific drive Example 3: How to exclude registry keys Example 4: How to exclude C:\Windows and C:\Program Files

Example 1: How to exclude all .mp3 files

The following .xml file excludes all .mp3 files from migration:

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/excludefiles"> <component context="System" type="Documents"> <displayName>Test</displayName> <role role="Data"> <rules> <unconditionalExclude> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script> </objectSet> </unconditionalExclude> </rules> </role>

</component> </migration>

Example 2: How to exclude all of the files on a specific drive

The following .xml file excludes only the files located on the C: drive.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/allfiles"> <component type="Documents" context="System"> <displayName>Test</displayName> <role role="Data"> <rules> <unconditionalExclude> <objectSet> <pattern type="File">c:\*[*]</pattern> </objectSet> </unconditionalExclude> </rules> </role> </component> </migration>

Example 3: How to exclude registry keys

This is an .xml file that unconditionally excludes the HKey_Current_User registry key and all subkeys.

<?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser"> <component type="Documents" context="User"> <displayName>Test</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="Registry">HKCU\testReg[*]</pattern> </objectSet> </include> <unconditionalExclude> <objectSet> <pattern type="Registry">HKCU\*[*]</pattern> </objectSet> </unconditionalExclude> </rules> </role> </component> </migration>

Example 4: How to exclude C:\Windows and C:\Program Files

This is an .xml file that unconditionally excludes the system folders of C:\Windows and C:\Program Files. Note that all *.doc, *.xls and *.ppt files will not be migrated because <unconditionalExclude> takes precedence over <include>.

<?xml version="1.0" encoding="UTF-8"?> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/miguser"> <component type="Documents" context="System"> <displayName>Test</displayName> <role role="Data"> <rules> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.xls]", "Fixed")</script> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.ppt]", "Fixed")</script> </objectSet> </include> <unconditionalExclude> <objectSet> <pattern type="File">C:\Program Files\* [*]</pattern> <pattern type="File">C:\Windows\* [*]</pattern> </objectSet> </unconditionalExclude> </rules> </role> </component> </migration>

Create a Config.xml file You can create and modify a Config.xml file if you want to exclude components from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating system settings that are migrate to computers running Windows Vista. Excluding components using this file is easier than modifying the migration .xml files because you do not need to be familiar with the migration rules and syntax.

To exclude the settings for a default application: Specify migrate="no" for the application under the <Applications> section of this file. For example, USMT will not migrate Adobe Acrobat Reader 6.0 or Outlook 2003 in the Sample Config.xml file. To exclude an operating system setting: Specify migrate="no" for the setting under the <WindowsComponents> section. For example, USMT will not migrate the user's Favorites in the Sample Config.xml file. To exclude My Documents: Specify migrate="no" for My Documents under the <Documents> section. For example, see the Sample Config.xml file. Note that any <include> rules in the .xml files will still apply. For example, if you have a rule that includes all the .doc files in My Documents, then only the .doc files will be migrated, but the rest of the files will not.

Additional information For more information, see the following:

How To Create a Custom .xml File Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496) XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519)

How To Reroute Files and Settings To reroute files and settings, we recommend that you should create a custom .xml file and then include this .xml file on both command lines. This way, you can keep your changes separate from the default .xml files and it may be easier to track your modifications.

In this topic To reroute a folder To reroute a specific file To reroute a specific file type Additional Information

To reroute a folder The following custom .xml file migrates directories and the files from C:\EngineeringDrafts into the My Documents folder of every user. %CSIDL_PERSONAL% is the virtual folder representing the My Documents desktop item, which is equivalent to CSIDL_MYDOCUMENTS.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="User"> <displayName>Engineering Drafts Documents to Personal Folder</displayName> <role role="Data"> <rules> <!-- Migrate all directories and files present in c:\EngineeringDrafts folder --> <include> <objectSet> <pattern type="File">C:\EngineeringDrafts\* [*]</pattern> </objectSet> </include> <!-- This migrates all files and directories from C:\EngineeringDrafts to every user’s personal folder.--> <locationModify script="MigXmlHelper.RelativeMove('C:\EngineeringDrafts','%CSIDL_PERSONAL%')"> <objectSet> <pattern type="File">C:\EngineeringDrafts\* [*]</pattern> </objectSet> </locationModify> </rules> </role> </component> </migration>

To reroute a specific file type The following custom .xml file reroutes .mp3 files located in the fixed drives on the source computer into the C:\Music folder on the destination computer.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>All .mp3 files to My Documents</displayName> <role role="Data"> <rules> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script> </objectSet> </include> <!-- Migrates all the .mp3 files in the store to the C:\Music folder during LoadState --> <locationModify script="MigXmlHelper.Move('C:\Music')"> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script> </objectSet> </locationModify> </rules> </role> </component> </migration>

To reroute a specific file The following custom .xml file migrates Sample.doc from C:\EngineeringDrafts into the My Documents folder of every user. %CSIDL_PERSONAL% is the virtual folder representing the My Documents desktop item, which is equivalent to CSIDL_MYDOCUMENTS.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="User"> <displayName>Sample.doc into My Documents</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern> </objectSet> </include> <locationModify script="MigXmlHelper.RelativeMove('C:\EngineeringDrafts','%CSIDL_PERSONAL%')"> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>

</objectSet> </locationModify> </rules> </role> </component> </migration>

Additional information For more information, see the following:

How To Create a Custom .xml File Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519)

How To Include Files and Settings When you specify the migration .xml files, USMT migrates the settings and components specified in What Does USMT 3.0 Migrate?. To include additional files and settings, we recommend that you create a custom .xml file and then include this .xml file on both command lines. This way, you can keep your changes separate from the default .xml files and it may be easier to track your modifications.

In this topic To migrate a single registry key To migrate a specific folder

To migrate a folder from a specific drive To migrate a folder from any location

To migrate a specific file type To migrate a specific file

To migrate a file from a folder To migrate a file from any location

Additional Information

To migrate a single registry key The following .xml file migrates a single registry key.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Application" context="System"> <displayName>Component to migrate only registry value string</displayName> <role role="Settings"> <rules> <include> <objectSet> <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache [Persistent]</p </objectSet> </include> </rules> </role> </component> </migration>

To migrate a specific folder To migrate a folder from a specific drive

Including subfolders

The following .xml file migrates all files and subfolders from C:\EngineeringDrafts to the destination computer.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents including subfolders</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File">C:\EngineeringDrafts\* [*]</pattern> </objectSet> </include> </rules> </role> </component> </migration>

Excluding subfolders

Note You may need to adjust the width of the sidebar on the left to view this topic. For example, if you have to scroll to read the text, move the sidebar to the left.

The following .xml file migrates all files from C:\EngineeringDrafts, but does not migrate any subfolders within C:\EngineeringDrafts.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents without subfolders</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [*]</pattern> </objectSet> </include> </rules> </role> </component> </migration>

To migrate a folder from any location

The following .xml file migrates all files and subfolders of the EngineeringDrafts folder from any drive on the computer. If multiple folders exist with the same name all such files will get migrated.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents folder on any drive on the computer </displayName> <role role="Data"> <rules> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("\EngineeringDrafts\* [*] ", "Fixed")</script> <script>MigXmlHelper.GenerateDrivePatterns ("*\EngineeringDrafts\* [*] ", "Fixed")</script> </objectSet> </include> </rules> </role> </component> </migration>

The following .xml file migrates all files and subfolders of the EngineeringDrafts folder from where ever it exists on the C: drive. If multiple folders exist with the same name all such folders will get migrated

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents EngineeringDrafts folder from where ever it exists on the C: drive <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\*\EngineeringDrafts\* [*]</pattern> <pattern type="File"> C:\EngineeringDrafts\* [*]</pattern> </objectSet> </include> </rules> </role> </component> </migration>

To migrate a file type into a specific folder The following .xml file migrates .mp3 files located in the fixed drives on the source computer into the 'C:\Music folder on the destination computer.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>All .mp3 files to My Documents</displayName> <role role="Data"> <rules> <include> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script> </objectSet> </include> <!-- Migrates all the .mp3 files in the store to the C:\Music folder during LoadState --> <locationModify script="MigXmlHelper.Move('C:\Music')"> <objectSet> <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script> </objectSet> </locationModify> </rules> </role> </component> </migration>

To migrate a specific file The following examples show how to migrate a file from a specific folder, and how to migrate a file from any location.

To migrate a file from a folder

The following .xml file migrates only Sample.doc from C:\EngineeringDrafts to the destination computer.

<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <component type="Documents" context="System"> <displayName>Component to migrate all Engineering Drafts Documents</displayName> <role role="Data"> <rules> <include> <objectSet> <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern> </objectSet>

</include> </rules> </role> </component> </migration>

To migrate a file from any location

To migrate Sample.doc from where ever it exists on the C: drive, use <pattern> as follows. If multiple files exist with the same name on the C: drive, then all of these files will be migrated.

<pattern type="File"> C:\* [Sample.doc] </pattern>

To migrate Sample.doc from any drive on the computer, use <script> as follows. If multiple files exist with the same name, all such files will get migrated.

<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", “Fixed”)</script>

Additional information For more information, see the following:

How To Create a Custom .xml File Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496) XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519)

How To Use the XML Schema (MigXML.xsd) You can use the USMT XML schema (MigXML.xsd) to validate the migration .xml files using an XML authoring tool such as Microsoft Visual Studio. For more information and instructions for how to use Visual Studio 2005, see An Introduction to the XML Tools in Visual Studio 2005 (http://go.microsoft.com/fwlink/?LinkId=74512).

For information about how to use the schema with your authoring tool, see the documentation for your tool.

Troubleshooting Common Issues Log Files Release Notes (http://go.microsoft.com/fwlink/?LinkId=73868)

Common Issues

In this topic General guidelines

User account problems

I am having problems creating local accounts on the destination computer. All of the user accounts were not migrated to the destination computer. User accounts that I excluded were migrated to the destination computer.

Command-line problems

I received the following error "Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters." I received the following error: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory."

XML file problems

I used /genconfig to create a Config.xml file, but I only see a few applications and components that are in MigApp.xml. Shouldn't Config.xml contain all the same applications? I am having problems with a custom .xml file that I have authored and I cannot verify that the syntax is correct.

Migration problems

Files that I specified to exclude are still being migrated. I have specified rules to move a folder to specific location on the destination but it is not migrated correctly. Some application settings are not migrating. After LoadState completes, the new wallpaper does not appear on the destination computer. Yahoo messenger does not work properly after I migrate settings from Windows XP to Windows Vista.

General guidelines When you encounter a problem or error during migration, you can use the following guidelines to help determine the source of the problem.

For a list of the known issues with this product, see the release notes (http://go.microsoft.com/fwlink/?LinkId=73868) Examine the ScanState and LoadState logs, and obtain the exact error message and event ID. In most cases, the event logs indicate why USMT is not working. You should run ScanState and LoadState with the /v:13 option to create a detailed log file. Although this option makes the log large, it is helpful for identifying where something went wrong. Create a progress log using the /progress option to help you monitor your migration. For the source and destination computers, you should obtain operating system information, and the versions of applications such as Microsoft Internet Explorer and any other relevant programs. Then verify the exact steps that are needed to reproduce the problem. This information might help you to better understand what specifically is wrong, and help you to reproduce the issue in your testing environment. 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. For this reason, you should log off after you run LoadState. 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.

User account problems Problem: I'm having problems creating local accounts on the destination computer. Resolution: For more information about creating accounts and migrating local accounts, see Migrating local and domain accounts and How To Migrate User Accounts. Problem: All of the user accounts were not migrated to the destination computer. Causes: There are two possible causes for this problem:

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 the start button, 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. If there are user accounts on the computer that have not been logged onto, then the user account will not be migrated. For example, if you add User1 to the computer, but User1 never logs on, then USMT will not migrate the account.

Problem: User accounts that I excluded were migrated to the destination computer. Cause: The command that you specified may have had conflicting /ui and /ue options. If a user is specified with /ui, and is also specified to be excluded with either /ue or /uel, the user will be included in the migration. For example, if you specify /ui:domain1\* /ue:domain1\user1, then User1 will be migrated because /ui takes precedence. Resolution: For more information about how to use the options together, see /ue, and /ui examples.

Command-line problems Problem: I received the following error "Usage Error: You cannot specify a file path with any of the command-line options that exceeds 256 characters." Cause: You may receive this error in some cases even if you do not specify a long store or file path. This is because the path length is calculated based on the absolute path. For example, if you run scanstate.exe /o store from C:\Program Files\USMT30, then each character in "C:\Program Files\USMT30" will be added to the length of “store” to get the length. Resolution: Ensure that the total path length (store path plus the current directory) does not exceed 256 characters. Problem: I received the following error: "USMT was unable to create the log file(s). Ensure that you have write access to the log directory." Cause: If you are running ScanState or LoadState from a shared network resource, you will receive this error if you do not specify /l. Resolution: To fix this issue in this scenario, specify /l:scan.log or /l:load.log and USMT will not fail with this error.

XML file problems Problem: I used /genconfig to create a Config.xml file, but I only see a few applications and components that are in MigApp.xml. Why does Config.xml not contain all the same applications? Cause: Config.xml will only contain operating system components, applications and the user document sections that are in both the .xml files and installed on the computer when you run /genconfig. Otherwise these applications and components will not show up in Config.xml. Resolution: Install all of the desired applications on the computer before running /genconfig. Then run ScanState with all of the .xml files. For example, if the destination computer is running Windows Vista, run the following: scanstate /genconfig:config.xml /i:miguser.xml /i:migapp.xml /v:13 /l:scanstate.log Problem: I am having problems with a custom .xml file that I have authored and I cannot verify that the syntax is correct. Resolution: You can load the XML schema (MigXML.xsd) that is included with USMT 3.0 into your XML authoring tool. (For examples, see Visual Studio at

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.

http://go.microsoft.com/fwlink/?LinkId=74513). Then, load your XML file in this editor to see if there is a syntax error. In addition, see XML Elements Reference (http://go.microsoft.com/fwlink/?LinkId=64519) for more information about using the .xml elements.

Migration problems Problem: Files that I specified to exclude are still being migrated. Cause: There may be another rule that is including the files. If there is a more specific rule or a conflicting rule, the files will be included in the migration. Resolution: For more information see Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510). Problem: I have specified rules to move a folder to specific location on the destination computer, but it has not migrated correctly. Cause: There may be an error in the XML syntax. Resolution: You can use the USMT XML schema (MigXML.xsd) to write and validate migration .xml files. Also see the examples in the following topics:

Conflicts and Precedence (http://go.microsoft.com/fwlink/?LinkId=74510) How To Exclude Files and Settings How To Reroute Files and Settings How To Include Files and Settings XML Examples (http://go.microsoft.com/fwlink/?LinkId=74496)

Problem: Some application settings are not migrating. Cause: 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. Problem: After LoadState completes, the new wallpaper does not appear on the destination computer. There are two typical causes for this issue.

Cause #1: The first cause is because some settings like fonts, wallpaper, and screensaver settings are not applied by LoadState until after the destination computer has been restarted. Resolution: To fix this issue, log off and then log back in to see the migrated wallpaper. Cause #2: Another cause is if the source computer was running Windows XP and the wallpaper was stored in the Drive:\WINDOWS\Web\Wallpaper folder (which is the default folder where wallpaper is stored in Windows XP). If the wallpaper is in this directory it will not be migrated and the destination computer will have the default Windows Vista wallpaper. This will occur even if the wallpaper was a custom picture that was added to the Drive:\WINDOWS\Web\Wallpaper folder. However, if the user set a picture as the wallpaper that was saved in another location (for example, My Pictures), then the wallpaper will migrate. Resolution: Ensure that the wallpaper images that you want to migrate are not in Drive:\WINDOWS\Web\Wallpaper folder on the source computer. Cause #3: Another cause is if ScanState was not run on Windows XP from an account with administrative credentials. In this case, some operating system settings will not migrate — for example, wallpaper settings, screen saver selections, modem options, media player settings, and Remote Access Service (RAS) connection phone book (.pbk) files and settings. Resolution: Run ScanState (and LoadState) from within an account with administrative credentials.

Problem: Yahoo Messenger does not work properly after I migrate settings from Windows XP to Windows Vista. Cause: Yahoo Messenger cannot connect to the Internet. A common cause of this is if the source and destination computers reside on different networks. Sometimes the connection settings that were migrated are not correct for the destination computer. Resolution: To fix this, open Yahoo Messenger, click Messenger, click Connection Preferences, and click Connection on the left side. Then change the connection settings to align with the network of the destination computer. For example, change the setting to No proxies, Use proxies, Firewall with no proxies, or No network detection based on your needs.

Log Files You can use the ScanState and LoadState logs, as well as the progress log to help monitor your migration. To view the applicable command-line options, see Monitoring options.

Scanstate and Loadstate logs Scanstate and Loadstate logs are both text files that are created when you run each of the tools. Although these logs are targeted mostly at developers, you can use these logs to help monitor the migration. To enable the verbose output, you should specify a verbosity level using the /v option. These logs will provide no valuable information if you do not specify a verbosity level. If the log already exists, the tools append the existing log. The content of the log depends on the command-line options that you use and the verbosity level that you specify.

Progress log You can create a progress log using the /progress option. External tools, such as Microsoft Operations Manager (MOM), can parse the progress log to update your monitoring systems. The first 3 fields in each line are fixed. The fixed fields are:

Date: Date is in the format of day shortNameOfTheMonth year. For example: 08 Jun 2006.

Note You cannot store any of the log files in StorePath. If you do, the log will be written over when USMT is run.

Local time: Time is in hrs:minutes:seconds (24-hour clock). For example: 13:49:13. Migration time: How long USMT was run in hrs:minutes:seconds. For example: 00:00:10.

The rest of the fields are key/value pairs as indicated in the following table.

XML Reference You can view the following topics online at http://go.microsoft.com/fwlink/?LinkId=73855.

General Conventions XML Elements Reference Conflicts and Precedence Recognized Environment Variables XML Examples Relationship of the XML Elements Diagram Additional Resources

Key Value program ScanState.exe or LoadState.exe. productVersion The full product build version of USMT. computerName The name of the computer on which USMT was run. commandLine The full command by which USMT was run. PHASE Defines that a new phase in the migration is starting. Can be one of Initializing, Scanning, Collecting, Saving, Estimating, or Applying.

detectedUser

For ScanState, these are the users that USMT has detected on the computer that can be migrated. For LoadState, these are the users that USMT has detected in the store that can be migrated.

includedInMigration Defines whether the user profile/component is included for migration (Yes or No).

forUser

Specifies either of the following:

The user state being migrated. “This Computer” meaning the files and settings that are user independent.

detectedComponent

Specifies a component detected by USMT

For ScanState, this is a component or application that is installed on the computer. For LoadState, this is a component or application that was detected in the store.

totalSizeInMBToTransfer Total size of the files and settings to migrate in megabytes (MB). totalPercentageCompleted Total percentage of the migration that has been completed by either ScanState or LoadState. collectingUser Specifies which user ScanState is collecting files and setting for. totalMinutesRemaining Time estimate in minutes for the migration to complete.

error

Type of non-fatal error occurred. Can be one of the following:

UnableToCopy: Unable to copy to store because the disk on which the store is located is full. UnableToOpen: Unable to open the file for migration because the file is opened in non-shared mode by another application or service. UnableToCopyCatalog: The store is corrupted. UnableToAccessDevice: Unable to access the device. UnableToApply: Unable to apply file the setting to the destination computer.

objectName The name of the file or setting that caused the non-fatal error

action

Action taken by USMT for the non-fatal error. The values are:

Ignore: USMT ignored and continued with rest of the migration because /c was specified on the command line. Abort: Stopped the migration because /c was not specified.

errorCode The errorCode or return value. numberOfIgnoredErrors The total number of non-fatal errors that USMT ignored. message The message corresponding to the errorCode.