User State Migration Tool (USMT) Guide

 

 

Table of Contents

Common Migration Scenarios
What Does USMT Migrate?
Choose a Migration Store Type
Determine What to Migrate
Test Your Migration
Best Practices
Common Migration Scenarios
Published: June 17, 2009
Updated: June 29, 2010
Applies To: Windows 7, Windows Vista

You use Windows® User State Migration Tool (USMT) 4.0 when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing the user's operating-system settings, application settings, and personal files from a source computer and reinstalling them after the upgrade has occurred. One common scenario, when only the operating system is being upgraded is referred to as PC refresh. A second common scenario is known as PC replacement, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
In This Topic

PC Refresh

The following diagram shows a PC refresh migration, also known as a computer refresh 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.

 

Diagram of PC Refresh migration scenario

 

Scenario One: PC refresh using a compressed migration store

For example, a company has just received funds to update all of its computers to Windows® 7. Each employee will keep the same computer, but the operating system on each computer will be updated.

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

Scenario Two: PC refresh using hard-link migration store

For example, a company has just received funds to update the operating system on all of its computers to Windows® 7. Each employee will keep the same computer, but the operating system on each computer will be updated.

  1. An administrator runs the ScanState command-line tool on each computer, specifying the /hardlink command-line option. ScanState saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic as well as minimizing migration failures on computers with very limited space available on the hard drive. 
     
  2. After quarantine of the hard-link migration store, an administrator uninstalls the older operating system. 
     
  3. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7, Microsoft® Office, and other company applications.
     
  4. An administrator runs the LoadState command-line tool on each computer. LoadState restores each user state back on each computer.
     

Scenario Three: PC refresh using Windows.old and the hard-link migration store

For example, a company has just received funds to update all of their computers to Windows 7. Each employee will keep the same computer, but the operating system on each computer will be updated.

  1. An administrator clean installs Windows 7 on each computer, making sure that the Windows.old directory is created by installing Windows 7 without formatting or repartitioning and by selecting a partition that contains Windows XP or Windows Vista.
     
  2. On each computer, an administrator installs the company’s standard operating environment (SOE), which included Windows 7 and other company applications.
     
  3. An administrator runs the ScanState and LoadState command-line tools successively while specifying the /hardlink command-line option.
     

PC Replacement

The following diagram shows a PC replacement 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.

 

Diagram of PC Replacement migration scenario

 

Scenario One: Manual network migration

A company receives 50 new laptops for their managers and needs to reallocate the 50 older laptops to new employees.

  1. An administrator runs the ScanState tool 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 7, Microsoft Office, and other company applications.
     
  3. An administrator runs the LoadState tool 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 7, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
     

Scenario Two: Managed network migration

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 the ScanState tool using Microsoft System Center Configuration Manager (SCCM, a logon script, a batch file, or a non-Microsoft management technology. 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 7, Microsoft Office, and other company applications.
     
  3. On each of the new computers, an administrator runs the LoadState tool using Microsoft System Center Configuration Manager (SCCM), a logon script, a batch file, or a non-Microsoft management technology. LoadState migrates the user states from the migration store to a new computer.
     

Scenario Three: Offline migration using Windows PE

A company is allocating 20 new computers to users in the accounting department. The users all have one computer with their files and settings. In this scenario, each user's one computer will serve as both the source and destination computer.

  1. On each source computer, an administrator boots the machine into Windows PE and runs ScanState to collect the user state to either a server or external hard disk.
     
  2. On each new computer, an administrator installs the company's standard operating environment which includes Windows 7, Microsoft® Office, and other company applications.
     
  3. On each of the new computers, an administrator runs the LoadState tool, restoring the user state from the migration store to the new computer.
     

See Also

Concepts

Plan Your Migration 
 

 
© 2016 Microsoft
 

What Does USMT Migrate?

Published: June 17, 2009

Updated: September 25, 2013

Applies To: Windows 7, Windows Vista

In This Topic

Default Migration Scripts

User State Migration Toolkit (USMT) 4.0 is designed so that an IT engineer can precisely define migrations using the USMT .xml scripting language. USMT provides the following sample scripts:

  • MigApp.XML. Rules to migrate application settings.
     
  • MigDocs.XML. Rules that use the MigXmlHelper.GenerateDocPatterns helper function can be used to automatically find user documents on a computer without the need to author extensive custom migration .xml files.
     
  • MigUser.XML. Rules to migrate user profiles and user data.

    MigUser.xml identifies files in a user’s profile and then does a file name extension-based search of most of the system for other user data. If data does not match either of these criteria, the data will not be migrated. For the most part, this file describes a “core” migration.

    The following data does not migrate with MigUser.xml:
    • Files outside the user profile that do not match one of the file name extensions in MigUser.xml.
       
    • Access control lists (ACLs) for folders outside the user profile.
       

User Data

This section describes the user data that USMT migrates by default, using the MigUser.xml file. It also defines how to migrate access control lists (ACLs).

  • Folders from each user profile. When you specify the MigUser.xml file, USMT migrates files 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 profiles. When you specify the MigUser.xml file, USMT also migrates the following from the All Users profile in Windows® XP, or the Public profile in Windows Vista® or Windows® 7: 

    Shared Documents, Shared Video, Shared Music, Shared desktop files, Shared Pictures, Shared Start menu, and Shared Favorites.
     
  • File types. When you specify the MigUser.xml file, the ScanState tool searches the fixed drives, collects and migrates files that have any of the following file name extensions:

    .accdb, .ch3, .csv, .dif, .doc*, .dot*, .dqy, .iqy, .mcw, .mdb*, .mpp, .one*, .oqy, .or6, .pot*, .ppa, .pps*, .ppt*, .pre, .pst, .pub, .qdf, .qel, .qph, .qsd, .rqy, .rtf, .scd, .sh3, .slk, .txt, .vl*, .vsd, .wk*, .wpd, .wps, .wq1, .wri, .xl*, .xla, .xlb, .xls*.


    noteNote
    The asterisk (*) represents zero or more characters.

     

     

  • Access control lists. USMT 4.0 migrates access control lists (ACLs) for specified files and folders from computers that are running both Windows® XP and Windows Vista. For example, if you migrate a file that is named File1.txt that is read-only for User1 and read/write for User2, these settings will still apply on the destination computer after the migration.
     
ImportantImportant
To migrate ACLs, you must specify the directory to migrate in the MigUser.xml file. Using file patterns like *.doc will not migrate a directory. The source ACL information is migrated only when you explicitly specify the directory. For example, <pattern type="File">c:\test docs</pattern>.

 

 

Operating-System Components

USMT migrates operating-system components to a destination computer that is running Windows 7 from computers that are running Windows XP, Windows Vista, or Windows 7.

noteNote
If you are using USMT 4.0 to migrate a user state to Windows Vista, use the /targetvista option with the ScanState tool. Without the /targetvista command-line option, some operating-system settings can be lost during the migration. For more information, see ScanState Syntax.

 

 

The following components are migrated by default using the manifest files:

  • Accessibility settings
     
  • Address book
     
  • Command-prompt settings
     
  • *Desktop wallpaper
     
  • EFS files
     
  • Favorites
     
  • Folder options
     
  • Fonts
     
  • Group membership. For example, right-click My Computer, and then click Manage. USMT migrates the groups under Local Users and Groups for the users who are included in the migration.
     
  • *Windows Internet Explorer® settings
     
  • Microsoft® Open Database Connectivity (ODBC) settings
     
  • Mouse and keyboard settings
     
  • Network drive mapping
     
  • *Network printer mapping
     
  • *Offline files
     
  • *Phone and modem options
     
  • RAS connection and phone book (.pbk) files
     
  • *Regional settings
     
  • Remote Access
     
  • *Taskbar settings
     
  • Windows Mail. Microsoft Outlook® Express Mail (.dbx) files are migrated from Windows XP.
     
  • *Windows Media® Player
     
  • Windows Rights Management
     

* These settings are not available for an offline migration. For more information, see Offline Migration.

ImportantImportant
This list may not be complete. There may be additional components that are migrated.

 

 

noteNote
Some settings, such as fonts, are not applied by the LoadState tool until after the destination computer has been restarted. For this reason, restart the destination computer after you run the LoadState tool.

 

 

Supported Applications

Although it is not required for all applications, it is good practice to install all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.

noteNote
The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.

 

 

noteNote
USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.

 

 

When you specify the MigApp.xml file, USMT 4.0 migrates the settings for the following applications:

 

Product Version

Adobe Acrobat Reader


9


AOL Instant Messenger


6.8


Apple iTunes


7, 8


Apple QuickTime Player


7


Apple Safari


3.1.2


Google Chrome


beta


Google Picasa


3


Google Talk


beta


IBM Lotus 1-2-3


9.8


IBM Lotus Notes


8


IBM Lotus Organizer


9.8


IBM Lotus WordPro


9.8


Intuit Quicken


2009


Money Plus Business


2008


Money Plus Home


2008


Mozilla Firefox


3


Microsoft Office Access®


2003, 2007, 2010*


Microsoft Office Excel®


2003, 2007, 2010*


Microsoft Office FrontPage®


2003, 2007, 2010*


Microsoft Office OneNote®


2003, 2007, 2010*


Microsoft Office Outlook®


2003, 2007, 2010*


Microsoft Office PowerPoint®


2003, 2007, 2010*


Microsoft Office Publisher


2003, 2007, 2010*


Microsoft Office Word


2003, 2007, 2010*


Opera Software Opera


9.5


Microsoft Outlook Express


(only mailbox file)


Microsoft Project


2003, 2007


Microsoft Office Visio®


2003, 2007


RealPlayer Basic


11


Sage Peachtree


2009


Skype


3.8


Windows Live® Mail


12, 14


Windows Live Messenger


8.5, 14


Windows Live MovieMaker


14


Windows Live Photo Gallery


12, 14


Windows Live Writer


12, 14


Windows Mail


(only shipped with Windows Vista®)


Microsoft Works


9


Yahoo Messenger


9


Zune™


3

* A hotfix is available to support migrating Office 2010 settings. You should install this hotfix before you use USMT, when either the source or destination computer has Office 2010 installed. For more information, see Information about the User State Migration Tool (USMT) 4.0 update.

What USMT Does Not Migrate

The following is a list of the settings that USMT does not migrate. If you have a problem that is not listed here, see Common Issues.

Application Settings

USMT 4.0 does not migrate the following application settings:

  • Settings from earlier 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 earlier version of an application to a later version, except for Microsoft Office, which USMT can migrate from an earlier version to a later version.
     
  • Application settings and some operating-system settings when a local account is created. For example, if you run /lac to create a local account on the destination computer, USMT will migrate the user data, but only some of the operating-system settings, such as wallpaper and screensaver settings, and no application settings will migrate.
     
  • Microsoft Project settings, when migrating from Office 2003 to Office 2007 system.
     
  • ICQ Pro settings, if ICQ Pro is installed in a different location on the destination computer. To successfully migrate the settings of ICQ Pro, you must install ICQ Pro in the same location on the destination computer as it was on the source computer. Otherwise, after you run the LoadState tool, the application will not start. You may encounter problems when:
    • You change the default installation location on 32-bit destination computers. 
       
    • You attempt to migrate from a 32-bit computer to a 64-bit computer. This is because the ICQ Pro default installation directory is different on the two types of computers. When you install ICQ Pro on a 32-bit computer, the default location is "C:\Program Files\...". The ICQ Pro default installation directory on an x64-based computer, however, is “C:\Program Files (x86)\...”.
       

Operating-System Settings

USMT 4.0 does not migrate the following operating-system settings.

  • Local printers, hardware-related settings, drivers, passwords, application binary files, synchronization files, DLL files, or other executable files.
     
  • Permissions for shared folders. After migration, you must manually re-share any folders that were shared on the source computer.
     
  • Files and settings migrating between operating systems with different languages. The operating system of the source computer must match the language of the operating system on the destination computer.
     
  • Customized icons for shortcuts may not migrate.
     
  • Taskbar settings, when the source computer is running Windows XP.
     
  • The following firewall settings when the source computer is running Windows XP.
    • 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 because of increased 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:

  • You should run USMT from an account that has administrative credentials. Otherwise, some data will not migrate. When running the ScanState and LoadState tools on Windows Vista and Windows 7, you must run the tools in Administrator mode from an account that has administrative credentials. If you do not run USMT in Administrator mode, only the user profile that is logged on will be included in the migration. In addition, you must run the ScanState tool on Windows XP from an account with administrative credentials. Otherwise, some operating-system settings will not migrate. To run in Administrator mode, click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
     
  • You can use the /localonly option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify /localonly, see ScanState Syntax.
     

See Also

Concepts

Plan Your Migration 
 

 

 
© 2016 Microsoft
 

Choose a Migration Store Type

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

When planning your migration, you should determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Toolkit (USMT) 4.0 components on your source and destination computers. You should also determine the space needed to create and host the migration store, whether you are using a local share, network share, or storage device.

In This Topic

Migration Store Types

This section describes the three migration store types available in USMT.

Uncompressed (UNC)

The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Microsoft® Windows® Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.

Compressed

The compressed migration store is a single image file that contains all files being migrated and a catalog file. This image file is often encrypted and protected with a password, and cannot be navigated with Windows Explorer.

Hard-Link

A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are “wired” into the file system. You use the new USMT 4.0 hard-link migration store in the PC Refresh scenario only. This is because the hard-link migration store is maintained on the local computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.

You use a command-line option, /hardlink, to create a hard-link migration store, which functions the same as an uncompressed migration store. Files are not duplicated on the local computer when user state is captured, nor are they duplicated when user state is restored. For more information, see Hard-Link Migration Store.

 

The following flowchart illustrates the procedural differences between a local migration store and a remote migration store. In this example, a hard-link migration store is utilized for the local store.

Diagram comparing migration-store types

 

Local Store vs. Remote Store

If you have enough space and you are migrating the user state back to the same computer, 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 a removable device such as a USB flash drive (UFD). 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, 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 another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share C:\store on the destination computer. Then run the ScanState command on the source computer and save the files and settings to \\DestinationComputerName\store. Then, run the LoadState command 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.

ImportantImportant
If possible, have users 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.

 

 

The /localonly Command-Line Option

You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify /localonly, see ScanState Syntax.

See Also

Concepts

Plan Your Migration 
 

 
© 2016 Microsoft
 

Estimate Migration Store Size

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

The disk space requirements for a migration are dependent on the size of the migration store and the type of migration. You can estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure. You can also calculate the disk space requirements using the ScanState tool.

In This Topic

Hard Disk Space Requirements

  • Store. For non-hard-link migrations, you should ensure that there is enough available disk space at the location where you will save your store to contain the data being migrated. You can save your store to another partition, an external storage device such as a USB flash drive or a server. For more information, see Choose a Migration Store Type.
     
  • Source computer. The source computer needs enough available space for the following:
    • 250 megabytes (MB) minimum of hard disk space. Space is needed to support USMT operations, for example, growth in the page file. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tools will not create the migration store if 250 MB of disk space is not available.
       
    • Temporary space for USMT to run. Additional disk space for the USMT tools to operate is required. This does not include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
       
    • Hard-link migration store. It is not necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows® XP and Windows Vista®, this situation is unusual.
       
  • Destination computer. The destination computer needs enough available space for the following:
    • Operating system.
       
    • Applications.
       
    • Data being migrated. It is important to consider that in addition to the files being migrated, registry information will also require hard disk space for storage.
       
    • Temporary space for USMT to run. Additional disk space for the USMT tools to operate is required. The amount of temporary space required can be calculated using the ScanState tool.
       

Calculate Disk Space Requirements using the ScanState Tool

You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It is not necessary to estimate the migration store size for a hard-link migration since this method does not create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer may change during day to day use so it is recommended that you use the calculations as an estimate when planning your migration.

To run the ScanState tool on the source computer with USMT installed,

  1. Open a command prompt with administrator privileges. For example, in Windows Vista, click Start, click All Programs, click Accessories, right-click Command Prompt, and select Run as administrator.
     
  2. Navigate to the USMT tools. For example, type


     
     
    cd /d "c:\program files\Windows AIK\Tools\USMT\<architecture>"
    

    Where <architecture> is x86, ia64, or amd64.
     

  3. Run the ScanState tool to generate an XML report of the space requirements. At the command prompt, type


     
     
    ScanState.exe <StorePath> /p:<path to a file>
    

    Where <StorePath> is a path to a directory where the migration store will be saved and <path to a file> is the path and filename where the XML report for space requirements will be saved. For example,


     
     
    ScanState.exe c:\store /p:c:\spaceRequirements.xml
    

    The migration store will not be created by running this command, but StorePath is a required parameter.
     

The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the My Documents folder to the destination computer. You can specify this in a configuration file when you run the ScanState tool. For more information, see Customize USMT XML Files.

noteNote
To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the /p option, without specifying <path to a file> is still available in USMT 4.0. If you specify only the /p option, the storage space estimations will be created based on USMT 3.x criteria.

 

 

The space requirements report provides two elements, <storeSize> and <temporarySpace>. The <temporarySpace> value shows the disk space, in bytes, that USMT uses to operate during the migration—this does not include the minimum 250 MB needed to support USMT. The <storeSize> value shows the disk space, in bytes, required to host the migration store contents on both the source and destination computers. The following example shows a report generated using /p:<path to a file>.

 
 
<?xml version="1.0" encoding="UTF-8"?>
<PreMigration>
  <storeSize>
    <size clusterSize="4096">11010592768</size>
  </storeSize>
  <temporarySpace>
    <size>58189144</size>
  </temporarySpace>
</PreMigration>

Additionally, USMT performs a compliance check for a required minimum of 250 MB of available disk space and will not create a store if the compliance check fails.

Estimate Migration Store Size

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 computers to arrive at an average for the size of the store that you will need.

The amount of space that is required in the store will vary, depending on the local storage strategies your 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, such as offline-storage files, data sets will be larger. Mobile users 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.

noteNote
You can create a space-estimate file (Usmtsize.txt), by using the legacy /p command-line option to estimate the size of the store.

 

 

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 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary 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 such as Folder Redirection, as long as users will have access to these locations after the migration.
     
  • User system settings: Five megabytes is usually adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that have been installed. It is rare, however, for the user-specific portion of the registry to exceed 5 MB.
     

See Also

 
© 2016 Microsoft
 

Hard-Link Migration Store

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

hard-link migration store enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs and enables entirely new migration scenarios.

In This Topic

When to Use a Hard-Link Migration

You can use a hard-link migration store when your planned migration meets both of the following criteria:

  • You are upgrading the operating system on existing hardware rather than migrating to new computers.
     
  • You are upgrading the operating system on the same volume of the computer.
     

You cannot use a hard-link migration store if your planned migration includes any of the following:

  • You are migrating data from one computer to a second computer.
     
  • You are migrating data from one volume on a computer to another volume, for example from C: to D:.
     
  • You are formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
     

Understanding a Hard-Link Migration

The hard-link migration store is created using the command-line option, /hardlink, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.

When you create a hard link, you give an existing file an additional path. For instance, you could create a hard link to c:\file1.txt called c:\hard link\myFile.txt. These are two paths to the same file. If you open c:\file1.txt, make changes, and save the file, you will see those changes when you open c:\hard link\myFile.txt. If you delete c:\file1.txt, the file still exists on your computer as c:\hardlink\myFile.txt. You must delete both references to the file in order to delete the file.

noteNote
A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.

 

 

For more information about hard links, please see this MSDN topic.

In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows® Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.

As a best practice, we recommend that you delete the hard-link migration store after you confirm that the Loadstate tool has successfully migrated the files. Since Loadstate has created new paths to the files on your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system.

ImportantImportant
Using the /c option will force the Loadstate tool to continue applying files when non-fatal errors occur. If you use the /c option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.

 

 

Keeping the hard-link migration store can result in additional disk space being consumed or problems with some applications for the following reasons:

  • Applications reporting file-system statistics, for example, space used and free space, might incorrectly report these statistics while the hard-link migration store is present. The file may be reported twice because of the two paths that reference that file.
     
  • A hard link may lose its connection to the original file. Some applications save changes to a file by creating a temporary file and then renaming the original to a backup filename. The path that was not used to open the file in this application will continue to refer to the unmodified file. The unmodified file that is not in use is taking up additional disk space. You should create the hard-link migration store just before you perform the migration, and not use applications once the store is created, in order to make sure you are migrating the latest versions of all files.
     
  • Editing the file by using different paths simultaneously may result in data corruption.
     
ImportantImportant
The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links.

 

 

Hard-Link Migration Scenario

For example, a company has decided to deploy Windows® 7 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.

  1. An administrator runs the ScanState command-line tool on each computer, specifying the /hardlink command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.


    noteNote
    As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with Loadstate.

     

     

  2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses.
     
  3. An administrator runs the LoadState command-line tool on each computer. The LoadState tool restores user state back on each computer.
     

Hard-Link Migration Store Details

This section provides details about hard-link migration stores.

Hard Disk Space

The /hardlink command-line option proceeds with creating the migration store only if there is 250 megabytes (MB) of free space on the hard disk. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration.

Hard-Link Store Size Estimation

It is not necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is very large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be quite large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and Windows Vista®, this situation is unusual.

Migration Store Path on Multiple Volumes

Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:

Scanstate /hardlink c:\USMTMIG […]

Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:

C:\USMTMIG\

D:\USMTMIG\

The drive you specify on the command line for the hard-link migration store is important, because it defines where the master migration store should be placed. The master migration store is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the /o option must be used to overwrite the existing data in the store.

Location Modifications

Location modifications that redirect migrated content from one volume to a different volume have an adverse impact on the performance of a hard-link migration. This is because the migrating data that must cross system volumes cannot remain in the hard-link migration store, and must be copied across the system volumes.

Migrating Encrypting File System (EFS) Certificates and Files

To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the /efs:hardlink option in the Scanstate command-line syntax.

If the EFS files are being restored to a different partition, you should use the /efs:copyraw option instead of the /efs:hardlink option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The /efs:copyraw option will copy the files to the new partition in encrypted format.

For more information, see Migrate EFS Files and Certificates and the Encrypted File Options in ScanState Syntax.

Migrating Locked Files with the Hard-Link Migration Store

Files that are locked by an application or the operating system are handled differently when using a hard-link migration store.

Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \Windows directory, which minimizes performance-related issues.

Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service is not being utilized. The volume shadow-copy service cannot be used in conjunction with hard-link migrations. However, by modifying the new <HardLinkStoreControl> section in the Config.xml file, it is possible to enable the migration of files locked by an application.

ImportantImportant
There are some scenarios in which modifying the <HardLinkStoreControl> section in the Config.xml file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use USMTutils.exe to schedule the migration store for deletion on the next restart.

 

 

XML Elements in the Config.xml File

A new section in the Config.xml file allows optional configuration of some of the hard-link migration behavior introduced with the /hardlink option.

 

<Policies>

This element contains elements that describe the policies that USMT follows while creating a migration store.

<HardLinkStoreControl>

This element contains elements that describe how to handle files during the creation of a hard link migration store.

<fileLocked>

This element contains elements that describe how to handle files that are locked for editing.

<createHardLink>

This element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.

Syntax: <createHardLink> [pattern] </createHardLink>

<errorHardLink>

This element defines a standard MigXML pattern that describes file paths where hard links should not be created, if the file is locked for editing by another application.

<errorHardLink> [pattern] </errorHardLink>

ImportantImportant
You must use the /nocompress option with the /hardlink option.

 

 

The following XML sample specifies that files locked by an application under the \Users directory can remain in place during the migration. It also specifies that locked files that are not located in the \Users directory should result in the File in Use error. It is important to exercise caution when specifying the paths using the <createHardLink> tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.

 
 
<Policies>
    <HardLinkStoreControl>
          <fileLocked>
            <createHardLink>c:\Users\* [*]</createHardLink>
            <errorHardLink>C:\* [*]</errorHardLink>
          </fileLocked>
    </HardLinkStoreControl>
</Policies>

See Also

Concepts

Plan Your Migration 
 

 
© 2016 Microsoft
 

Migration Store Encryption

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

This topic discusses USMT options for migration store encryption to protect the integrity of user data during a migration.

USMT 4.0 Encryption Options

USMT 4.0 enables support for stronger encryption algorithms, called Advanced Encryption Standard (AES), in several bit-level options. AES is a National Institute of Standards and Technology (NIST) specification for the encryption of electronic data.

The encryption algorithm you choose must be specified for both the ScanState and LoadState commands, so that these commands can create or read the store during encryption and decryption. The new encryption algorithms can be specified on the ScanState andLoadState command lines by using the /encrypt:"encryptionstrength" and the /decrypt:"encryptionstrength" command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in the Windows® XP, Windows Vista®, and Windows® 7 operating systems. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. You can use the Usmtutils.exe file to determine which encryption algorithms are available to the computers' locales before you begin the migration.

The following table describes the new command-line encryption options in USMT 4.0.

 

Component Option Description

ScanState


/encrypt: <AES, AES_128, AES_192, AES_256, 3DES, 3DES_112>


This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the ScanState tool employs the 3DES algorithm used in USMT 3.0.


LoadState


/decrypt: <AES, AES_128, AES_192, AES_256, 3DES, 3DES_112>


This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the LoadState tool employs the 3DES algorithm used in USMT 3.0.

See Also

Concepts

Plan Your Migration 
 

 
© 2016 Microsoft
 

Determine What to Migrate

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

By default, Windows® User State Migration Tool (USMT) 4.0 migrates the items listed in What Does USMT Migrate?, depending on the migration .xml files you specify. These default settings are often enough for a basic migration.

However, when considering what settings to migrate, you should also consider what settings you would like the user to be able to configure, if any, 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 on unmanaged computers prior to the migration can be locked on the new, managed computers. For example, standard wallpaper, Windows® Internet Explorer® security settings, and 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 (SOE). An SOE is a combination of hardware and software that you distribute to all users. This means selecting a baseline 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

See Also

 
© 2016 Microsoft
 

Identify Users

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

It is important to carefully consider how you plan to migrate users. By default, all users are migrated by Windows® User State Migration Tool (USMT) 4.0. You must specify which users to include by using the command line. You cannot specify users in the .xml files. For instructions on how to migrate users, see Migrate User Accounts.

In This Topic

Migrating Local Accounts

Before migrating local accounts, note the following:

  • You must explicitly specify that local accounts that are not on the destination computer should be migrated. If you are migrating local accounts and the local account does not exist on the destination computer, you must use the /lac option when using the LoadState command. If the /lac option is not specified, no local user accounts will be migrated.
     
  • Consider whether to enable user accounts that are new to the destination computer. The /lae option enables the account that was created with the /lac option. However, if you create a disabled local account by using only the /lac option, a local administrator must enable the account on the destination computer.
     
  • Be careful when specifying a password for local accounts. If you create the local account with a blank password, anyone could log on to that account on the destination computer. If you create the local account with a password, the password is available to anyone with access to the USMT command-line tools.


    noteNote
    If there are multiple users on a computer, and you specify a password with the /lac option, all migrated users will have the same password.

     

     

Migrating Domain Accounts

The source and destination computers do not need to be connected to the domain for domain user profiles to be migrated.

Command-Line Options

USMT provides several options to migrate multiple users on a single computer. The following command-line options specify which users to migrate.

  • Specifying users. You can specify which users to migrate with the /all/ui/uel, and /ue options with both the ScanState and LoadState command-line tools.
     
  • ImportantImportant
    The /uel option excludes users based on the Last Modified date of the Ntuser.dat file. The /uel option is not valid in offline migrations.

     

     

  • Moving users to another domain. You can move user accounts to another domain using the /md option with the LoadState command-line tool.
     
  • Creating local accounts. You can create and enable local accounts using the /lac and /lae options with the LoadState command-line tool.
     
  • Renaming user accounts. You can rename user accounts using the /mu option.


    noteNote
    By default, if a user name is not specified in any of the command-line options, the user will be migrated.

     

     

See Also

 
© 2016 Microsoft
 

Identify Applications Settings

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

When planning for your migration, you should identify which applications and settings you want to migrate. For more information about how to create a custom .xml file to migrate the settings of another application, see Create a Custom XML File.

Applications

First, create and prioritize a list of applications that to be migrated. It may be helpful 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.

Next, 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 the organization. The application owner should have the most experience with an application. The application owner provides insight into how the organization installs, configures, and uses the application.

Application Settings

Next, determine and locate the application settings that to be migrated. You can acquire much of the information that you need for this step when you are testing the new applications for compatibility with the new operating system.

After completing the list of applications that to be migrated, review the list and work with each application owner on a list of settings to be migrated. For each setting, determine whether it needs to be migrated or if the default settings are adequate. Then, determine where the setting is located; for example, in the registry or in an .ini file. Next, consider the following questions to determine what needs to be done to migrate the setting successfully:

  • Is the destination version of the application newer than the source version?
     
  • Do these settings work with the new version?
     
  • Do the settings need to be moved or altered?
     
  • Can the first-run process force the application to appear as if it had run already? If so, does this work correctly, or does it break the application?
     

After answering these questions, create a custom .xml file to migrate settings. Work with the application owner to develop test cases and to determine the file types that need to be migrated for the application.

Locating Where Settings Are Stored

If the storage mechanism or location of a given setting is not clear, it can be difficult to create rules to migrate the setting. Settings can be stored in the registry, within .ini files, or within a text or binary file. To determine the location of a setting, start by checking the vendor’s documentation or their Web site.

If the location of a setting is not documented, you can use tools like Regmon and Filemon from the Sysinternals Web site or a non-Microsoft application-packaging tool to find it. The Regmon tool monitors registry activity, while the Filemon monitors file-system activity. To determine where a setting is stored, start the Regmon and Filemon tools to monitor the registry and file system, and then change the setting. Once you’ve done this, look in the log file for the registry and file-system data being written when you changed the setting, and note where that data is located.

Using an application-packaging tool, you can typically take a system snapshot, make a setting change, and then take another system snapshot to see what has changed. We recommend doing this on a computer that only has Windows® and the relevant application installed. For example, antivirus software can result in many instances of file-system and registry data being read and written. This will make it difficult to find the setting you are looking for. Also, be sure to keep an unprotected computer like this isolated from the network.

See Also

 
© 2016 Microsoft
 

Identify Operating System Settings

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. Windows® User State Migration Tool (USMT) 4.0 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 single-click or double-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 which 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 should migrate any settings that users need to get their jobs done, 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.

noteNote
For more information about how to change the operating-system settings that are migrated, see the Using USMT topic.

 

For information about the operating-system settings that USMT migrates, see the What Does USMT Migrate? topic.

 

 

See Also

 
© 2016 Microsoft
 

Identify File Types, Files, and Folders

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as My DocumentsC:\Data, and company-specified locations, such as \EngineeringDrafts. Next, you should determine and locate the non-standard locations. For non-standard 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® Office Word® primarily uses .doc, .docx and .dotx 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 a folder matching the files' name and location on the source computer. For example, you might have shared data on source machine or you might wish to clean up documents outside the user profiles on the source system. Identify any data that needs to be redirected to a new location in the apply phase. This can be accomplished with location modify rules. 
     

Once you have verified which files and file types that the end users work with regularly, you will need to locate them. Files may be saved to a 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.

To find the registered file types on a computer running Windows XP

  1. Click Start and then click My Computer.

  2. On the Toolsmenu, click Folder Options.

  3. On the File Types tab, the registered files types are displayed in the Registered file types dialog box.

To find the registered file types on a computer running Windows Vista or Windows 7

  1. Click Start. Open Control Panel, click Control Panel Home in Windows Vista, 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 the MigUser.xml file, see Using USMT.

See Also

 
© 2016 Microsoft
 

Test Your Migration

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7

Always test your migration plan in a controlled laboratory setting before you deploy it to your entire organization. In your test environment, you need at least one computer for each type of operating system from which you are migrating data. For example, if you are migrating data from source computers running either Windows® XP or Windows Vista®, you need to test at least one computer running each of these operating systems.

After you have thoroughly tested the entire migration process on a single computer running each of your source operating systems, conduct a pilot migration with a small group of users. After migrating a few typical user states to the intermediate store, note the space required and adjust your initial calculations accordingly. For details about estimating the space needed for your migration, see Estimate Migration Store Size. You might also need to adjust the registry-setting and file-location information in your migration-rule files. If you make changes, test the migration again. Then 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.

If your test migration encounters any errors, examine the ScanState and LoadState logs to obtain the exact USMT return code and associated error messages or Win32® error message. For more information about USMT return codes and error messages, see Return Codes. You can also obtain more information about a Win32® error message by typing net helpmsg and the error message number on the command line.

In most cases, the ScanState and LoadState logs indicate why a USMT migration is failing. We recommend that you use the /v:13 option when testing your migration. This verbosity level can be adjusted in a production migration. Reducing the verbosity level might make it more difficult to diagnose failures that are encountered during production migrations.

noteNote
Running the ScanState and LoadState tools with the /v:13 option creates a detailed log file. Although this option makes the log file large, it is helpful in determining where migration errors occurred.

 

 

Once you have determined that the pilot migration successfully migrated the specified files and settings, you are ready to add USMT 4.0 to the server that is running Microsoft® System Center Configuration Manager (SCCM), or a non-Microsoft management technology. For more information, see this Microsoft Web site.

noteNote
For testing purposes, you can create an uncompressed store using the /nocompress option. When compression is disabled, the ScanState tool saves the files and settings to a hidden folder named "File" at StorePath\USMT. You can use the uncompressed store to view what USMT has stored or to troubleshoot a problem, or you can run an antivirus utility against the files. Additionally, you can also use the /listfiles command-line option and the diagnostic log to list the files that were gathered and to troubleshoot problems with your migration.

 

 

See Also

 
© 2016 Microsoft
 

Best Practices

Published: June 17, 2009

Updated: June 29, 2010

Applies To: Windows 7, Windows Vista

This topic discusses general and security-related best practices when using Windows® User State Migration Tool (USMT) 4.0.

General Best Practices

  • Install applications before running the LoadState tool. Though it is not always essential, it is best practice to install all applications on the destination computer before restoring the user state. This helps ensure that migrated settings are preserved.
     
  • Do not use MigUser.xml and MigDocs.xml together. If you use both .xml files, some migrated files may be duplicated if conflicting instructions are given about target locations. If your data set is unknown, for example, many non-standard file locations are used, MigDocs.xml is a better choice. You can Utilize the /genmigxml command-line option to determine which files will be included in your migration, and to determine if any modifications are necessary. For more information, see Identify File Types, Files, and Folders.
     
  • Close all applications before running either the ScanState or LoadState tools. Although utilizing the /vsc switch can allow the migration of many files that are open with another application it is a best practice to close all applications in order to ensure all files and settings migrate. Without the /vsc or /c switch USMT will fail when it cannot migrate a file or setting. When utilizing the /c option USMT will ignore any files or settings that it cannot migrate and log an error each time.
     
  • Log off after you run the LoadState tool. Some settings, such as 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 the LoadState tool.
     
  • Managed environment. To create a managed environment, you can 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 the LoadState command fails to complete.
     
  • Chkdsk.exe. We recommend that you run Chkdsk.exe before running the ScanState and LoadState tools. Chkdsk.exe creates a status report for a hard disk drive and lists and corrects common errors. For more information about the Chkdsk.exe tool, see this 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. To minimize the impact on network performance, 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. Using this method, you can make any necessary modifications to your plan between groups.
     

Security Best Practices

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, you must consider the following issues:

  • Encrypting File System (EFS). Take extreme caution when migrating encrypted files, because the end user does not need to be logged on to capture the user state. By default, Windows® User State Migration Tool (USMT) 4.0 fails if an encrypted file is found. For more information about EFS best practices, see this article in the Microsoft Knowledge Base. For specific instructions about EFS best practices, see Migrate EFS Files and Certificates.


    ImportantImportant
    If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration.

     

     

  • Encrypt the store. Consider using the /encrypt option with the ScanState command and the /decrypt option with the LoadState command. However, use extreme caution with this set of options, because anyone who has access to the ScanState command-line script also has access to the encryption key.
     
  • Virus scan. We recommend that you scan both the source and destination computers for viruses before running USMT. In addition, you should scan the destination computer image. To help protect data from viruses, we strongly recommend running an antivirus utility before migration.
     
  • 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 must also secure the deployment server, to ensure that the user data that is in the log files is not exposed. We also recommend that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see this Microsoft Web site.
     
  • Password migration. To ensure the privacy of the end users, USMT does not migrate passwords, including those for applications such as Windows Live™ Mail, Microsoft Internet Explorer®, as well as Remote Access Service (RAS) connections and mapped network drives. It is important to make sure that end users know their passwords.
     
  • Local account creation. Before you migrate local accounts, see the Migrating Local Accounts section in the Identify Users topic.
     

See Also

 
© 2016 Microsoft

 

Tags: