diff --git a/windows/deployment/usmt/offline-migration-reference.md b/windows/deployment/usmt/offline-migration-reference.md index 3406fdc071..25d44a98a8 100644 --- a/windows/deployment/usmt/offline-migration-reference.md +++ b/windows/deployment/usmt/offline-migration-reference.md @@ -16,7 +16,6 @@ ms.topic: article # Offline Migration Reference - Offline migration enables the ScanState tool to run inside a different Windows® operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios: - **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine. @@ -33,7 +32,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s ## In This topic - - [What Will Migrate Offline?](#bkmk-whatwillmigrate) - [What Offline Environments are Supported?](#bkmk-offlineenvironments) @@ -48,7 +46,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s ## What Will Migrate Offline? - The following user data and settings migrate offline, similar to an online migration: - Data and registry keys specified in MigXML @@ -67,42 +64,18 @@ For exceptions to what you can migrate offline, see [What Does USMT Migrate?](us ## What Offline Environments are Supported? - The following table defines the supported combination of online and offline operating systems in USMT. - ---- - - - - - - - - - - - - - - - - -
Running Operating SystemOffline Operating System

WinPE 5.0 or greater, with the MSXML library

Windows Vista, Windows 7, Windows 8, Windows 10

Windows 7, Windows 8, Windows 10

Windows.old directory

- - +|Running Operating System|Offline Operating System| +|--- |--- | +|WinPE 5.0 or greater, with the MSXML library|Windows Vista, Windows 7, Windows 8, Windows 10| +|Windows 7, Windows 8, Windows 10|Windows.old directory| **Note**   It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](/previous-versions/windows/it-pro/windows-7/ee424315(v=ws.10)). - - ## User-Group Membership and Profile Control - User-group membership is not preserved during offline migrations. You must configure a **<ProfileControl>** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group: ``` xml @@ -125,84 +98,27 @@ For information about the format of a Config.xml file, see [Config.xml File](usm ## Command-Line Options - An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options: - ----- - - - - - - - - - - - - - - - - - - - - - - - - -
ComponentOptionDescription

ScanState.exe

/offline:<path to offline.xml>

This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.

ScanState.exe

/offlineWinDir:<Windows directory>

This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.

ScanState.exe

/OfflineWinOld:<Windows.old directory>

This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.

+|Component|Option|Description| +|--- |--- |--- | +|ScanState.exe|**/offline:***<path to offline.xml>*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.| +|ScanState.exe|**/offlineWinDir:***<Windows directory>*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.| +|ScanState.exe|**/OfflineWinOld:***<Windows.old directory>*|This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.| - - -You can use only one of the **/offline**,**/offlineWinDir** , or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together. +You can use only one of the **/offline**, **/offlineWinDir**, or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together. ## Environment Variables - The following system environment variables are necessary in the scenarios outlined below. - ----- - - - - - - - - - - - - - - - - - - - -
VariableValueScenario

USMT_WORKING_DIR

Full path to a working directory

Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following:

-
Set USMT_WORKING_DIR=[path to working directory]

MIG_OFFLINE_PLATFORM_ARCH

32 or 64

While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:

-
Set MIG_OFFLINE_PLATFORM_ARCH=32
- - +|Variable|Value|Scenario| +|--- |--- |--- | +|USMT_WORKING_DIR|Full path to a working directory|Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following: 
Set USMT_WORKING_DIR=[path to working directory]
| +|MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system does not match the WinPE and Scanstate.exe architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following: 
Set MIG_OFFLINE_PLATFORM_ARCH=32
| ## Offline.xml Elements - Use an offline.xml file when running the ScanState tool on a computer that has multiple Windows directories. The offline.xml file specifies which directories to scan for windows files. An offline.xml file can be used with the /offline option as an alternative to specifying a single Windows directory path with the /offlineDir option. ### <offline> @@ -256,8 +172,4 @@ The following XML example illustrates some of the elements discussed earlier in ## Related topics - [Plan Your Migration](usmt-plan-your-migration.md) - - - diff --git a/windows/deployment/usmt/understanding-migration-xml-files.md b/windows/deployment/usmt/understanding-migration-xml-files.md index e59e727ee5..f6a8ab4221 100644 --- a/windows/deployment/usmt/understanding-migration-xml-files.md +++ b/windows/deployment/usmt/understanding-migration-xml-files.md @@ -16,14 +16,12 @@ ms.topic: article # Understanding Migration XML Files - -You can modify the behavior of a basic User State Migration Tool (USMT)10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the MigDocs.xml and MigUser.xml files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a Config.xml file to further customize your migration. +You can modify the behavior of a basic User State Migration Tool (USMT) 10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the MigDocs.xml and MigUser.xml files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a Config.xml file to further customize your migration. This topic provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the MigDocs.xml file. The MigDocs.xml file uses the new **GenerateDocPatterns** function available in USMT to automatically find user documents on a source computer. ## In This topic - [Overview of the Config.xml file](#bkmk-config) [Overview of the MigApp.xml file](#bkmk-migapp) @@ -50,27 +48,20 @@ This topic provides an overview of the default and custom migration XML files an ## Overview of the Config.xml file +The Config.xml file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The Config.xml file can be used with other XML files, such as in the following example: `scanstate /i:migapps.xml /i:migdocs.xml /genconfig:c:\myFolder\config.xml`. When used this way, the Config.xml file tightly controls aspects of the migration, including user profiles, data, and settings, without modifying or creating other XML files. For more information about the Config.xml file, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md). -The Config.xml file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The Config.xml file can be used in conjunction with other XML files, such as in the following example: `scanstate /i:migapps.xml /i:migdocs.xml /genconfig:c:\myFolder\config.xml`. When used this way, the Config.xml file tightly controls aspects of the migration, including user profiles, data, and settings, without modifying or creating other XML files. For more information about the Config.xml file, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md). - -**Note**   -When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files. - - +> [!NOTE] +> When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files. ## Overview of the MigApp.xml file - The MigApp.xml file installed with USMT includes instructions to migrate the settings for the applications listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md). You must include the MigApp.xml file when using the ScanState and LoadState tools, by using the `/i` option in order to migrate application settings. The MigDocs.xml and MigUser.xml files do not migrate application settings. You can create a custom XML file to include additional applications. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md). -**Important**   -The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. See the [Sample migration rules for customized versions of XML files](#bkmk-samples) section of this document for more information about migrating .pst files that are not linked to Outlook. - - +> [!Important] +> The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. For more information about migrating .pst files that are not linked to Outlook, see the [Sample migration rules for customized versions of XML files](#bkmk-samples). ## Overview of the MigDocs.xml file - The MigDocs.xml file uses the new **GenerateDocPatterns** helper function to create instructions for USMT to migrate files from the source computer, based on the location of the files. You can use the MigDocs.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The default MigDocs.xml file migrates the following: @@ -141,12 +132,11 @@ You can also use the **/genmigxml** option with the ScanState tool to review and ## Overview of the MigUser.xml file - -The MigUser.xml file includes instructions for USMT to migrate user files based on file name extensions. You can use the MigUser.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigUser.xml file will gather all files from the standard user-profile folders, as well as any files on the computer with the specified file name extensions. +The MigUser.xml file includes instructions for USMT to migrate user files based on file name extensions. You can use the MigUser.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigUser.xml file will gather all files from the standard user-profile folders, and any files on the computer with the specified file name extensions. The default MigUser.xml file migrates the following: -- All files from the standard user-profile folders which are described as: +- All files from the standard user-profile folders, which are described as: - CSIDL\_MYVIDEO @@ -166,7 +156,7 @@ The default MigUser.xml file migrates the following: - Files with the following extensions: - .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\*, .vl\*, .vsd, .mpp, .or6, .accdb, .mdb, .pub + `.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\*`, `.vl\*`, `.vsd`, `.mpp`, `.or6`, `.accdb`, `.mdb`, `.pub` The default MigUser.xml file does not migrate the following: @@ -180,62 +170,30 @@ The default MigUser.xml file does not migrate the following: You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer. -**Note**   -Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than three hundred file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document. - - +> [!NOTE] +> Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than 300 file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document. ## Using multiple XML files - You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with additional migration rules. - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
XML migration fileModifies the following components:

Config.xml file

Operating-system components such as desktop wallpaper and background theme.

-

You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see Customize USMT XML Files and Config.xml File.

MigApps.xml file

Applications settings.

MigUser.xml or MigDocs.xml files

User files and profile settings.

Custom XML files

Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.

- - +|XML migration file|Modifies the following components:| +|--- |--- | +|Config.xml file|Operating-system components such as desktop wallpaper and background theme.
You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).| +|MigApps.xml file|Applications settings.| +|MigUser.xml or MigDocs.xml files|User files and profile settings.| +|Custom XML files|Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.| For example, you can use all of the XML migration file types for a single migration, as in the following example: -``` +```console Scanstate /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml ``` ### XML rules for migrating user files -**Important**   -You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer. - - +> [!IMPORTANT] +> You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer. If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location. The MigUser.xml file migrates only the files with the specified file name extensions. @@ -243,13 +201,10 @@ If you want more control over the migration, you can create custom XML files. Se ## Creating and editing a custom XML file - You can use the **/genmigxml** command-line option to determine which files will be included in your migration. The **/genmigxml** option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary. -**Note**   -If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location. - - +> [!NOTE] +> If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location. To generate the XML migration rules file for a source computer: @@ -259,14 +214,14 @@ To generate the XML migration rules file for a source computer: 3. At the command prompt, type: - ``` + ```console cd /d scanstate.exe /genmigxml: ``` Where *<USMTpath>* is the location on your source computer where you have saved the USMT files and tools, and *<filepath.xml>* is the full path to a file where you can save the report. For example, type: - ``` + ```console cd /d c:\USMT scanstate.exe /genmigxml:"C:\Documents and Settings\USMT Tester\Desktop\genMig.xml" ``` @@ -275,46 +230,27 @@ To generate the XML migration rules file for a source computer: The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes three Boolean values. You can change the settings to modify the way the MigDocs.xml file generates the XML rules for migration. - ----- - - - - - - - - - - - - - - - - - - - - - - - - -
SettingValueDefault Value

ScanProgramFiles

The ScanProgramFiles argument is valid only when the GenerateDocPatterns function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.

-

For example, when set to TRUE, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The GenerateDocPatterns function generates this inclusion pattern for .doc files:

-
<pattern type="File">C:\Program Files\Microsoft Office[.doc]</pattern>
-

If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions.

False

IncludePatterns

The IncludePatterns argument determines whether to generate exclude or include patterns in the XML. When this argument is set to TRUE, the GenerateDocPatterns function generates include patterns and the function must be added under the <include> element. Changing this argument to FALSE generates exclude patterns and the function must be added under the <exclude> element.

True

SystemDrive

The SystemDrive argument determines whether to generate patterns for all fixed drives or only for the system drive. Changing this argument to TRUE restricts all patterns to the system drive.

False

+- `ScanProgramFiles`: This argument is valid only when the **GenerateDocPatterns** function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications. - + **Default value**: False + + For example, when set to **TRUE**, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The **GenerateDocPatterns** function generates this inclusion pattern for `.doc` files: + + `C:\Program Files\Microsoft Office[.doc]` + + If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions. + +- `IncludePatterns`: This argument determines whether to generate exclude or include patterns in the XML. When this argument is set to **TRUE**, the **GenerateDocPatterns** function generates include patterns and the function must be added under the `` element. Changing this argument to **FALSE** generates exclude patterns and the function must be added under the `` element. + + **Default value**: True + +- `SystemDrive`: This argument determines whether to generate patterns for all fixed drives or only for the system drive. Changing this argument to **TRUE** restricts all patterns to the system drive. + + **Default value**: False **Usage:** -``` +```console MigXmlHelper.GenerateDocPatterns ("", "", "") ``` @@ -400,42 +336,24 @@ The user context includes rules for data in the User Profiles directory. When ca - FOLDERID\_RecordedTV -**Note**   -Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable. +> [!NOTE] +> Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable. - + ### Sample migration rules for customized versions of XML files -### Sample migration rules for customized versions of XML files - -**Note**   -For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md). - - +> [!NOTE] +> For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md). ### Exclude rules usage examples In the examples below, the source computer has a .txt file called "new text document" in a directory called "new folder". The default MigDocs.xml behavior migrates the new text document.txt file and all files contained in the "new folder" directory. The rules generated by the function are: - ---- - - - - - - - - - - -

Rule 1

<pattern type="File">d:\new folder[new text document.txt]</pattern>

Rule 2

<pattern type="File">d:\new folder[]</pattern>
+| Rule | Syntax | +|--- |--- | +|Rule 1|`d:\new folder[new text document.txt]`| +|Rule 2|`d:\new folder[]`| - - -To exclude the new text document.txt file as well as any .txt files in "new folder", you can do the following: +To exclude the new text document.txt file and any .txt files in "new folder", you can do the following: **Example 1: Exclude all .txt files in a folder** @@ -513,30 +431,17 @@ For locations outside the user profile, such as the Program Files folder, you ca For more examples of include rules that you can use in custom migration XML files, see [Include Files and Settings](usmt-include-files-and-settings.md). -**Note**   -For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md). - - +> [!NOTE] +> For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md). ## Next steps - -You can include additional rules for the migration in the MigDocs.xml file or other XML migration files. For example, you can use the <locationModify> element to move files from the folder where they were gathered to a different folder, when they are applied to the destination computer. +You can include additional rules for the migration in the MigDocs.xml file or other XML migration files. For example, you can use the `` element to move files from the folder where they were gathered to a different folder, when they are applied to the destination computer. You can use an XML schema (MigXML.xsd) file to validate the syntax of your customized XML files. For more information, see [USMT Resources](usmt-resources.md). ## Related topics - [Exclude Files and Settings](usmt-exclude-files-and-settings.md) [Include Files and Settings](usmt-include-files-and-settings.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-choose-migration-store-type.md b/windows/deployment/usmt/usmt-choose-migration-store-type.md index 6985683c08..871da5bf3b 100644 --- a/windows/deployment/usmt/usmt-choose-migration-store-type.md +++ b/windows/deployment/usmt/usmt-choose-migration-store-type.md @@ -16,51 +16,19 @@ ms.topic: article # Choose a Migration Store Type - One of the main considerations for planning your migration is to 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 Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store. ## In This Section - - ---- - - - - - - - - - - - - - - - - - - -

Migration Store Types Overview

Choose the migration store type that works best for your needs and migration scenario.

Estimate Migration Store Size

Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.

Hard-Link Migration Store

Learn about hard-link migration stores and the scenarios in which they are used.

Migration Store Encryption

Learn about the using migration store encryption to protect user data integrity during a migration.

- - +| Link | Description | +|--- |--- | +|[Migration Store Types Overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.| +|[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.| +|[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they are used.| +|[Migration Store Encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.| ## Related topics - [Plan Your Migration](usmt-plan-your-migration.md) [User State Migration Tool (USMT) How-to topics](usmt-how-to.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-command-line-syntax.md b/windows/deployment/usmt/usmt-command-line-syntax.md index 85adbc467d..0631a98022 100644 --- a/windows/deployment/usmt/usmt-command-line-syntax.md +++ b/windows/deployment/usmt/usmt-command-line-syntax.md @@ -16,40 +16,12 @@ ms.topic: article # User State Migration Tool (USMT) Command-line Syntax - The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation. ## In This Section - - ---- - - - - - - - - - - - - - - -

ScanState Syntax

Lists the command-line options for using the ScanState tool.

LoadState Syntax

Lists the command-line options for using the LoadState tool.

UsmtUtils Syntax

Lists the command-line options for using the UsmtUtils tool.

- - - - - - - - - - - +| Link | Description | +|--- |--- | +|[ScanState Syntax](usmt-scanstate-syntax.md)|Lists the command-line options for using the ScanState tool.| +|[LoadState Syntax](usmt-loadstate-syntax.md)|Lists the command-line options for using the LoadState tool.| +|[UsmtUtils Syntax](usmt-utilities.md)|Lists the command-line options for using the UsmtUtils tool.| diff --git a/windows/deployment/usmt/usmt-configxml-file.md b/windows/deployment/usmt/usmt-configxml-file.md index 084c869c9a..ed444aa11e 100644 --- a/windows/deployment/usmt/usmt-configxml-file.md +++ b/windows/deployment/usmt/usmt-configxml-file.md @@ -16,10 +16,8 @@ ms.topic: article # Config.xml File - ## Config.xml File - The Config.xml file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the **/genconfig** option with the ScanState.exe tool. If you want to include all of the default components, and do not want to change the default store-creation or profile-migration behavior, you do not need to create a Config.xml file. However, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigUser.xml and MigDocs.xml files, but you want to exclude certain components, you can create and modify a Config.xml file and leave the other .xml files unchanged. For example, you must create and modify the Config.xml file if you want to exclude any of the operating-system settings that are migrated. It is necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior. @@ -31,11 +29,8 @@ For more information about using the Config.xml file with other migration files, **Note**   To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration. - - ## In this topic - In USMT there are new migration policies that can be configured in the Config.xml file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. The following elements and parameters are for use in the Config.xml file only. [<Policies>](#bkmk-policies) @@ -74,14 +69,12 @@ In USMT there are new migration policies that can be configured in the Config.xm ## <Policies> - The **<Policies>** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **<Policies>** element are **<ErrorControl>** and **<HardLinkStoreControl>**. The **<Policies>** element is a child of **<Configuration>**. Syntax: ` ` ## <ErrorControl> - The **<ErrorControl>** element is an optional element you can configure in the Config.xml file. The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. - **Number of occurrences**: Once for each component @@ -108,10 +101,8 @@ Additionally, the order in the **<ErrorControl>** section implies priority ``` -**Important**   -The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. - - +> [!IMPORTANT] +> The configurable **<ErrorControl>** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. ### <fatal> @@ -125,35 +116,14 @@ The **<fatal>** element is not required. Syntax: ``*<pattern>*`` - ----- - - - - - - - - - - - - - - -
ParameterRequiredValue

errorCode

No

"any" or "specify system error message here"

- - +|Parameter|Required|Value| +|--- |--- |--- | +|errorCode|No|"any" or "*specify system error message here*"| You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration. ## <fileError> - The **<fileError>** element is not required. - **Number of occurrences**: Once for each component @@ -168,7 +138,6 @@ You use the **<fileError>** element to represent the behavior associated w ## <nonFatal> - The **<nonFatal>** element is not required. - **Number of occurrences**: Once for each component @@ -179,35 +148,14 @@ The **<nonFatal>** element is not required. Syntax: ``*<pattern>*`` - ----- - - - - - - - - - - - - - - -
ParameterRequiredValue

<errorCode>

No

"any" or "specify system error message here". If system error messages are not specified, the default behavior applies the parameter to all system error messages.

- - +|Parameter|Required|Value| +|--- |--- |--- | +|**<errorCode>**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.| You use the **<nonFatal>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration. ## <registryError> - The <registryError>element is not required. - **Number of occurrences**: Once for each component @@ -218,35 +166,14 @@ The <registryError>element is not required. Syntax: `` - ----- - - - - - - - - - - - - - - -
ParameterRequiredValue

<errorCode>

No

"any" or "specify system error message here". If system error messages are not specified, the default behavior applies the parameter to all system error messages.

- - +|Parameter|Required|Value| +|--- |--- |--- | +|**<errorCode>**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.| You use the **<registryError>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration. ## <HardLinkStoreControl> - The **<HardLinkStoreControl>** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **<fileLocked>**. Syntax: ` ` @@ -261,10 +188,8 @@ Syntax: `` The **<HardLinkStoreControl>** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that cannot be copied, even though is technically possible for the link to be created. -**Important**   -The **<ErrorControl>** section can be configured to conditionally ignore file access errors, based on the file’s location. - - +> [!IMPORTANT] +> The **<ErrorControl>** section can be configured to conditionally ignore file access errors, based on the file’s location. ``` xml @@ -282,84 +207,49 @@ The **<ErrorControl>** section can be configured to conditionally ignore f ## <fileLocked> - The **<fileLocked>** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **<fileLocked>** element are processed in the order in which they appear in the XML file. Syntax: `` ## <createHardLink> - The **<createHardLink>** 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: ``*<pattern>*`` ## <errorHardLink> - The **<errorHardLink>** 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. USMT will attempt to copy files under these paths into the migration store. However, if that is not possible, **Error\_Locked** is thrown. This is a standard Windows application programming interface (API) error that can be captured by the **<ErrorControl>** section to either cause USMT to skip the file or abort the migration. Syntax: ``*<pattern>*`` ## <ProfileControl> - This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **<ProfileMigration>** is a child of **<Configuration>**. Syntax: <`ProfileControl> ` ## <localGroups> - This element is used to contain other elements that establish rules for how to migrate local groups. **<localGroups>** is a child of **<ProfileControl>**. Syntax: ` ` ## <mappings> - This element is used to contain other elements that establish mappings between groups. Syntax: ` ` ## <changeGroup> - This element describes the source and destination groups for a local group membership change during the migration. It is a child of **<localGroups>**. The following parameters are defined: - ----- - - - - - - - - - - - - - - - - - - - - - - - - -
ParameterRequiredValue

From

Yes

A valid local group on the source machine that contains users selected for migration on the command line.

To

Yes

A local group that the users are to be moved to during the migration.

appliesTo

Yes

nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.

- - +|Parameter|Required|Value| +|--- |--- |--- | +|From|Yes|A valid local group on the source machine that contains users selected for migration on the command line.| +|To|Yes|A local group that the users are to be moved to during the migration.| +|appliesTo|Yes|nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.| The valid and required children of **<changeGroup>** are **<include>** and **<exclude>**. Although both can be children at the same time, only one is required. @@ -367,21 +257,18 @@ Syntax: ` ` ## <include> - This element specifies that its required child, *<pattern>*, should be included in the migration. Syntax: ```` ## <exclude> - This element specifies that its required child, *<pattern>*, should be excluded from the migration. Syntax: ``` ` ## Sample Config.xml File - Refer to the following sample Config.xml file for additional details about items you can choose to exclude from a migration. ```xml @@ -577,14 +464,4 @@ Refer to the following sample Config.xml file for additional details about items ## Related topics - [USMT XML Reference](usmt-xml-reference.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-conflicts-and-precedence.md b/windows/deployment/usmt/usmt-conflicts-and-precedence.md index c7dc4a18ce..1236299462 100644 --- a/windows/deployment/usmt/usmt-conflicts-and-precedence.md +++ b/windows/deployment/usmt/usmt-conflicts-and-precedence.md @@ -16,7 +16,6 @@ ms.topic: article # Conflicts and Precedence - When you include, exclude, and reroute files and settings, it is important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind. - **If there are conflicting rules within a component, the most specific rule is applied.** However, the <unconditionalExclude> rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#bkmk1) and the first example in [Include and exclude precedence examples](#precexamples)****later in this topic. @@ -33,7 +32,6 @@ When you include, exclude, and reroute files and settings, it is important to kn ## In this topic - **General** - [What is the relationship between rules that are located within different components?](#bkmk2) @@ -60,7 +58,6 @@ When you include, exclude, and reroute files and settings, it is important to kn ## General - ### What is the relationship between rules that are located within different components? Only rules inside the same component can affect each other, depending on specificity, except for the <unconditionalExclude> rule. Rules that are in different components do not affect each other. If there is an <include> rule in one component and an identical <exclude> rule in another component, the data will be migrated because the two rules are independent of each other. @@ -129,7 +126,6 @@ USMT does not distinguish the .xml files based on their name or content. It proc ## The <include> and <exclude> rules - ### What happens when there are conflicting <include> and <exclude> rules? If there are conflicting rules within a component, the most specific rule is applied, except with the <unconditionalExclude> rule, which takes precedence over all other rules. If the rules are equally specific, then the data will be not be migrated. For example if you exclude a file, and include the same file, the file will not be migrated. If there are conflicting rules within different components, the rules do not affect each other because each component is processed independently. @@ -159,212 +155,35 @@ These examples explain how USMT deals with <include> and <exclude> r ### Including and excluding files - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you have the following code in the same componentResulting behaviorExplanation
    -

  • Include rule: <pattern type="File">C:\Dir1* []</pattern>

    • -

  • Exclude rule: <pattern type="File">C:* [.txt]</pattern>

    • -

Migrates all files and subfolders in Dir1 (including all .txt files in C:).

The <exclude> rule does not affect the migration because the <include> rule is more specific.

    -

  • Include rule: <pattern type="File">C:\Dir1* []</pattern>

    • -

  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

    • -

Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders.

Both rules are processed as intended.

    -

  • Include rule: <pattern type="File">C:\Dir1* []</pattern>

    • -

  • Exclude rule: <pattern type="File">C:\Dir1\ * [.txt]</pattern>

    • -

Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders.

Both rules are processed as intended.

    -

  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

    • -

  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

    • -

Nothing will be migrated.

The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule.

    -

  • Include rule: C:\Dir1* [.txt]

    • -

  • Exclude rule: C:\Dir1\Dir2* []

    • -

Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2.

-

No files are migrated from Dir2 or its subfolders.

Both rules are processed as intended.

    -

  • Include rule: C:\Dir1\Dir2* []

    • -

  • Exclude rule: C:\Dir1* [.txt]

    • -

Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2).

Both rules are processed as intended.

+| If you have the following code in the same component | Resulting behavior | Explanation | +|-----|-----|-----| +|
  • Include rule: <pattern type="File">C:\Dir1* []</pattern>
  • Exclude rule: <pattern type="File">C:* [.txt]</pattern>
| Migrates all files and subfolders in Dir1 (including all .txt files in C:). | The <exclude> rule does not affect the migration because the <include> rule is more specific. | +|
  • Include rule: <pattern type="File">C:\Dir1* []</pattern>
  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
| Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders. | Both rules are processed as intended. | +|
  • Include rule: <pattern type="File">C:\Dir1* []</pattern>
  • Exclude rule: <pattern type="File">C:\Dir1\ * [.txt]</pattern>
| Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. | +|
  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
| Nothing will be migrated. | The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule. | +|
  • Include rule: C:\Dir1* [.txt]
  • Exclude rule: C:\Dir1\Dir2* []
| Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2.
No files are migrated from Dir2 or its subfolders. | Both rules are processed as intended. | +|
  • Include rule: C:\Dir1\Dir2* []
  • Exclude rule: C:\Dir1* [.txt]
| Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2). | Both rules are processed as intended. | - - - ----- - - - - - - - - - - - - - - - - - - - - - - - - -
If you have the following code in different componentsResulting behaviorExplanation

Component 1:

-
    -

  • Include rule: <pattern type="File">C:\Dir1* []</pattern>

    • -

  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

    • -
-

Component 2:

-
    -

  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

    • -

  • Exclude rule: <pattern type="File">C:\Dir1* []</pattern>

    • -

Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2).

Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed.

Component 1:

-
    -

  • Include rule: C:\Dir1\Dir2* []

    • -
-

Component 2:

-
    -

  • Exclude rule: C:\Dir1* [.txt]

    • -

Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders.

Both rules are processed as intended.

Component 1:

-
    -

  • Exclude rule: C:\Dir1\Dir2* []

    • -
-

Component 2:

-
    -

  • Include rule: C:\Dir1* [.txt]

    • -

Migrates all .txt files in Dir1 and any subfolders.

Component 1 does not contain an <include> rule, so the <exclude> rule is not processed.

- - +| If you have the following code in different components | Resulting behavior | Explanation | +|-----|----|----| +| Component 1:
  • Include rule: <pattern type="File">C:\Dir1* []</pattern>
  • Exclude rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>

Component 2:
  • Include rule: <pattern type="File">C:\Dir1\Dir2* [.txt]</pattern>
  • Exclude rule: <pattern type="File">C:\Dir1* []</pattern>
| Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed. | +| Component 1:
  • Include rule: C:\Dir1\Dir2* []

Component 2:
  • Exclude rule: C:\Dir1* [.txt]
| Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. | +| Component 1:
  • Exclude rule: C:\Dir1\Dir2* []

Component 2:
  • Include rule: C:\Dir1* [.txt]
| Migrates all .txt files in Dir1 and any subfolders. | Component 1 does not contain an <include> rule, so the <exclude> rule is not processed. | ### Including and excluding registry objects - ----- - - - - - - - - - - - - - - - - - - - - - - - - -
If you have the following code in the same componentResulting behaviorExplanation
    -

  • Include rule: HKLM\Software\Microsoft\Command Processor* []

    • -

  • Exclude Rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor.

Both rules are processed as intended.

    -

  • Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

  • Exclude Rule: HKLM\Software\Microsoft\Command Processor* []

    • -

Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor.

DefaultColor is migrated because the <include> rule is more specific than the <exclude> rule.

    -

  • Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

  • Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

Does not migrate DefaultColor.

The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule.

+| If you have the following code in the same component | Resulting behavior | Explanation | +|-----|-----|-----| +|
  • Include rule:
    HKLM\Software\Microsoft\Command Processor* []
  • Exclude Rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
| Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor. | Both rules are processed as intended. | +|
  • Include rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Exclude Rule:
    HKLM\Software\Microsoft\Command Processor* []
| Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor. | DefaultColor is migrated because the <include> rule is more specific than the <exclude> rule. | +|
  • Include rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Exclude rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
| Does not migrate DefaultColor. | The rules are equally specific, so the <exclude> rule takes precedence over the <include> rule. | - - - ----- - - - - - - - - - - - - - - -
If you have the following code in different componentsResulting behaviorExplanation

Component 1:

-
    -

  • Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

  • Exclude rule: HKLM\Software\Microsoft\Command Processor* []

    • -
-

Component 2:

-
    -

  • Include rule: HKLM\Software\Microsoft\Command Processor* []

    • -

  • Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]

    • -

Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor.

Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed.

- - +| If you have the following code in different components | Resulting behavior | Explanation | +|-----|-----|-----| +| Component 1:
  • Include rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
  • Exclude rule:
    HKLM\Software\Microsoft\Command Processor* []

Component 2:
  • Include rule:
    HKLM\Software\Microsoft\Command Processor* []
  • Exclude rule:
    HKLM\Software\Microsoft\Command Processor [DefaultColor]
| Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor. | Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. | ## File collisions - ### What is the default behavior when there are file collisions? If there is not a <merge> rule, 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, OriginalFileName(2).OriginalExtension, and so on. @@ -399,67 +218,49 @@ You have a custom .xml file that contains the following code: ``` -For this example, the following table describes the resulting behavior if you add the code in the first column to your custom .xml file. +For this example, the following information describes the resulting behavior if you add the code to your custom .xml file. - ---- - - - - - - - - - - - - - - - - - - - - -
If you specify the following codeResulting behavior
<merge script="MigXmlHelper.DestinationPriority()"> 
-   <objectSet> 
-      <pattern type="File">c:\data* []</pattern> 
-   </objectSet> 
-</merge>

During ScanState, all the files will be added to the store.

-

During LoadState, only C:\Data\SampleA.txt will be restored.

<merge script="MigXmlHelper.SourcePriority()"> 
-   <objectSet> 
-      <pattern type="File">c:\data* []</pattern> 
-   </objectSet> 
-</merge>

During ScanState, all the files will be added to the store.

-

During LoadState, all the files will be restored, overwriting the existing files on the destination computer.

<merge script="MigXmlHelper.SourcePriority()"> 
-   <objectSet> 
-      <pattern type="File">c:\data\ [*]</pattern> 
-   </objectSet> 
-</merge>

During ScanState, all the files will be added to the store.

-

During LoadState, the following will occur:

-
    -

  • C:\Data\SampleA.txt will be restored.

    • -

  • C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer.

    • -

  • C:\Data\Folder\SampleB.txt will not be restored.

    • -
+**Example 1** - +```xml + + + c:\data* [] + + +``` + +**Result**: During ScanState, all the files will be added to the store. During LoadState, only C:\Data\SampleA.txt will be restored. + +**Example 2** + +```xml + + + c:\data* [] + + +``` + +**Result**: During ScanState, all the files will be added to the store. +During LoadState, all the files will be restored, overwriting the existing files on the destination computer. + +**Example 3** + +```xml + + + c:\data\ [*] + + +``` + +**Result**: During ScanState, all the files will be added to the store. During LoadState, the following will occur: + +- C:\Data\SampleA.txt will be restored. +- C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer. +- C:\Data\Folder\SampleB.txt will not be restored. ## Related topics - [USMT XML Reference](usmt-xml-reference.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-custom-xml-examples.md b/windows/deployment/usmt/usmt-custom-xml-examples.md index 5096af5a77..7d31c9bdbb 100644 --- a/windows/deployment/usmt/usmt-custom-xml-examples.md +++ b/windows/deployment/usmt/usmt-custom-xml-examples.md @@ -15,26 +15,8 @@ ms.topic: article # Custom XML Examples - -**Note**   -Because the tables in this topic are wide, you may need to adjust the width of its window. - - - -## In This Topic: - - -- [Example 1: Migrating an Unsupported Application](#example) - -- [Example 2: Migrating the My Videos Folder](#example2) - -- [Example 3: Migrating Files and Registry Keys](#example3) - -- [Example 4: Migrating Specific Folders from Various Locations](#example4) - ## Example 1: Migrating an Unsupported Application - The following is a template for the sections that you need to migrate your application. The template is not functional on its own, but you can use it to write your own .xml file. ``` xml @@ -103,37 +85,23 @@ The following is a template for the sections that you need to migrate your appli ## Example 2: Migrating the My Videos Folder +The following sample is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer. -The following is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer. +- **Sample condition**: Verifies that My Videos exists on the source computer: - ---- - - - - - - - - - - - - - - - - - - - - -
CodeBehavior
<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>

Verifies that My Videos exists on the source computer.

<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>

Filters out the shortcuts in My Videos that do not resolve on the destination computer. This has no effect on files that are not shortcuts. For example, if there is a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.

<pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern>

Migrates My Videos for all users.

+ `MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")` - +- **Sample filter**: Filters out the shortcuts in My Videos that do not resolve on the destination computer: + + `` + + This has no effect on files that are not shortcuts. For example, if there is a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering. + +- **Sample pattern**: Migrates My Videos for all users: + + `%CSIDL_MYVIDEO%* [*]` + +**XML file** ```xml @@ -160,41 +128,25 @@ The following is a custom .xml file named CustomFile.xml that migrates My Videos ## Example 3: Migrating Files and Registry Keys +The sample patterns describe the behavior in the following example .xml file. -This table describes the behavior in the following example .xml file. +- **Sample pattern**: Migrates all instances of the file Usmttestfile.txt from all sub-directories under `%ProgramFiles%\USMTTestFolder`: - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
CodeBehavior
<pattern type="File">%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]</pattern>

Migrates all instances of the file Usmttestfile.txt from all sub-directories under %ProgramFiles%\USMTTestFolder.

<pattern type="File">%ProgramFiles%\USMTDIRTestFolder* []</pattern>

Migrates the whole directory under %ProgramFiles%\USMTDIRTestFolder.

<pattern type="Registry">HKCU\Software\USMTTESTKEY* [MyKey]</pattern>

Migrates all instances of MyKey under HKCU\Software\USMTTESTKEY.

<pattern type="Registry">HKLM\Software\USMTTESTKEY* []</pattern>

Migrates the entire registry hive under HKLM\Software\USMTTESTKEY.

+ `%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]` - +- **Sample pattern**: Migrates the whole directory under `%ProgramFiles%\USMTDIRTestFolder`: + + `%ProgramFiles%\USMTDIRTestFolder* []` + +- **Sample pattern**: Migrates all instances of MyKey under `HKCU\Software\USMTTESTKEY`: + + `HKCU\Software\USMTTESTKEY* [MyKey]` + +- **Sample pattern**: Migrates the entire registry hive under `HKLM\Software\USMTTESTKEY`: + + `HKLM\Software\USMTTESTKEY* []` + +**XML file** ``` xml @@ -230,7 +182,7 @@ This table describes the behavior in the following example .xml file. ## Example 4: Migrating Specific Folders from Various Locations -The behavior for this custom .xml file is described within the <`displayName`> tags in the code. +The behavior for this custom .xml file is described within the `` tags in the code. ``` xml @@ -257,12 +209,12 @@ The behavior for this custom .xml file is described within the <`displayName` Component to migrate all user documents except Sample.doc - + C:\UserDocuments\* [*] - + C:\UserDocuments\ [Sample.doc] @@ -277,9 +229,9 @@ The behavior for this custom .xml file is described within the <`displayName` - - - + + + @@ -291,8 +243,8 @@ The behavior for this custom .xml file is described within the <`displayName` - C:\*\Presentations\* [*] - C:\Presentations\* [*] + C:\*\Presentations\* [*] + C:\Presentations\* [*] @@ -303,16 +255,6 @@ The behavior for this custom .xml file is described within the <`displayName` ## Related topics - [USMT XML Reference](usmt-xml-reference.md) [Customize USMT XML Files](usmt-customize-xml-files.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-determine-what-to-migrate.md b/windows/deployment/usmt/usmt-determine-what-to-migrate.md index 418f73f68c..608624844a 100644 --- a/windows/deployment/usmt/usmt-determine-what-to-migrate.md +++ b/windows/deployment/usmt/usmt-determine-what-to-migrate.md @@ -24,30 +24,12 @@ To reduce complexity and increase standardization, your organization should cons ## In This Section - ---- - - - - - - - - - - - - - - - - - - -

Identify Users

Use command-line options to specify which users to migrate and how they should be migrated.

Identify Applications Settings

Determine which applications you want to migrate and prepare a list of application settings to be migrated.

Identify Operating System Settings

Use migration to create a new standard environment on each of the destination computers.

Identify File Types, Files, and Folders

Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.

+| Link | Description | +|--- |--- | +|[Identify Users](usmt-identify-users.md)|Use command-line options to specify which users to migrate and how they should be migrated.| +|[Identify Applications Settings](usmt-identify-application-settings.md)|Determine which applications you want to migrate and prepare a list of application settings to be migrated.| +|[Identify Operating System Settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.| +|[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)|Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.| ## Related topics diff --git a/windows/deployment/usmt/usmt-hard-link-migration-store.md b/windows/deployment/usmt/usmt-hard-link-migration-store.md index 45c699be37..02c53344c8 100644 --- a/windows/deployment/usmt/usmt-hard-link-migration-store.md +++ b/windows/deployment/usmt/usmt-hard-link-migration-store.md @@ -16,12 +16,10 @@ ms.topic: article # Hard-Link Migration Store - -A *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. +A *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](#bkmk-when) [Understanding a Hard-Link Migration](#bkmk-understandhardlinkmig) @@ -46,7 +44,6 @@ A *hard-link migration store* enables you to perform an in-place migration where ## 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. @@ -57,32 +54,27 @@ You cannot use a hard-link migration store if your planned migration includes an - 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 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. -**Note**   -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. +> [!NOTE] +> 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 [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions) +For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions) 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. -**Important**   -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. - - +> [!IMPORTANT] +> 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: @@ -92,22 +84,17 @@ Keeping the hard-link migration store can result in additional disk space being - Editing the file by using different paths simultaneously may result in data corruption. -**Important**   -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. - - +> [!IMPORTANT] +> 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 10 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. - **Note**   - 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. - - + > [!NOTE] + > 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. @@ -115,19 +102,18 @@ For example, a company has decided to deploy Windows 10 on all of their compute > [!NOTE] > During the update of a domain-joined computer, the profiles of users whose SID cannot be resolved will not be migrated. When using a hard-link migration store, it could cause a data loss. - -## Hard-Link Migration Store Details +## 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. +The **/hardlink** command-line option proceeds with creating the migration store only if there are 250 megabytes (MB) of free space on the hard disk. If 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 newer operating systems, this situation is unusual. +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 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 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 newer operating systems, this situation is unusual. ### Migration Store Path on Multiple Volumes @@ -161,57 +147,27 @@ Files that are locked by an application or the operating system are handled diff 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. +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 with hard-link migrations. However, by modifying the new `` section in the Config.xml file, it is possible to enable the migration of files locked by an application. -**Important**   -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. - - +> [!IMPORTANT] +> There are some scenarios in which modifying the `` 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>

+| Element | Description | +|--- |--- | +| `` | This element contains elements that describe the policies that USMT follows while creating a migration store. | +| `` | This element contains elements that describe how to handle files during the creation of a hard link migration store. | +| `` | This element contains elements that describe how to handle files that are locked for editing. | +| `` | 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: `` [pattern] `` | +| `` | 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.

`` [pattern] `` | - +> [!IMPORTANT] +> You must use the **/nocompress** option with the **/HardLink** option. -**Important**   -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 **File in Use<createhardlink>** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete. +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 **File in Use``** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete. ``` xml @@ -226,8 +182,4 @@ The following XML sample specifies that files locked by an application under the ## Related topics - [Plan Your Migration](usmt-plan-your-migration.md) - - - diff --git a/windows/deployment/usmt/usmt-loadstate-syntax.md b/windows/deployment/usmt/usmt-loadstate-syntax.md index 77e214976c..42f918560d 100644 --- a/windows/deployment/usmt/usmt-loadstate-syntax.md +++ b/windows/deployment/usmt/usmt-loadstate-syntax.md @@ -16,29 +16,10 @@ ms.topic: article # LoadState Syntax - This topic discusses the **LoadState** command syntax and options available with it. -## In this topic - - -[Before You Begin](#before) - -[Syntax](#bkmk-s) - -[Storage Options](#bkmk-st) - -[Migration Rule Options](#bkmk-mig) - -[Monitoring Options](#bkmk-mon) - -[User Options](#bkmk-user) - -[Incompatible Command-Line Options](#bkmk-cloi) - ## Before You Begin - Before you run the **LoadState** command, note the following: - To ensure that all operating system settings migrate, we recommend that you run the **LoadState** commands in administrator mode from an account with administrative credentials. @@ -55,7 +36,6 @@ Before you run the **LoadState** command, note the following: ## Syntax - This section explains the syntax and usage of the command-line options available when you use the **LoadState** command. 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** command's syntax is: @@ -71,390 +51,66 @@ For example, to decrypt the store and migrate the files and settings to a comput USMT provides the following options that you can use to specify how and where the migrated data is stored. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command-Line OptionDescription

StorePath

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

/decrypt /key:KeyString

-

or

-

/decrypt /key:"Key String"

-

or

-

/decrypt /keyfile:[Path</em>]FileName

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

-
    -

  • /key:KeyString specifies the encryption key. If there is a space in KeyString, you must surround the argument with quotation marks.

    • -

  • /keyfile:FilePathAndName specifies a text (.txt) file that contains the encryption key

    • -
-

KeyString cannot exceed 256 characters.

-

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

-

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

-
-Important

Use caution with this option, because anyone who has access to the LoadState command-line script will also have access to the encryption key.

-
-
- -
-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey

/decrypt:"encryption strength"

The /decrypt option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see Migration Store Encryption.

/hardlink

Enables user-state data to be restored from a hard-link migration store. The /nocompress parameter must be specified with /hardlink option.

/nocompress

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

-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress

- - +| Command-Line Option | Description | +|--- |--- | +| `StorePath` | Indicates the folder where the files and settings data are stored. You must specify *StorePath* when using the **LoadState** command. 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 in one of the following ways:
  • `/key:`*KeyString* specifies the encryption key. If there is a space in *KeyString*, you must surround the argument with quotation marks.
  • `/keyfile:`*FilePathAndName* specifies a text (.txt) file that contains the encryption key

*KeyString* cannot exceed 256 characters.
The `/key` and `/keyfile` options cannot be used on the same command line.
The `/decrypt` and `/nocompress` options cannot be used on the same command line.
**Important**
Use caution with this option, because anyone who has access to the **LoadState** command-line script will also have access to the encryption key.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey` | +| `/decrypt:`*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). | +| `/hardlink` | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. | +| `/nocompress` | Specifies that the store is not compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option cannot be used with the `/decrypt` option.
For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress` | ## Migration Rule Options - USMT provides the following options to specify what files you want to migrate. - ---- - - - - - - - - - - - - - - - - - - - - -
Command-Line OptionDescription

/i:[Path]FileName

(include)

-

Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). Path can be either a relative or full path. If you do not specify the Path variable, 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.

/config:[Path]FileName

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

-

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

-

loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log

/auto:"path to script files"

This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The /auto option has the same effect as using the following options: /i:MigDocs.xml /i:MigApp.xml /v:5.

- - +| Command-Line 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 to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). *Path* can be either a relative or full path. If you do not specify the *Path* variable, 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](usmt-faq.yml) topic. | +| `/config:`[*Path*]*FileName* | Specifies the Config.xml file that the **LoadState** command should use. You cannot specify this option more than once on the command line. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the *FileName* must be located in the current directory.

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

`loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log` | +| `/auto:`*"path to script files"* | This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | ## Monitoring Options - USMT provides several command-line options that you can use to analyze problems that occur during migration. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command-Line OptionDescription

/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 either a relative or full path. If you do not specify the Path variable, then the log will be created in the current directory. You can specify the /v option to adjust the amount of output.

-

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

/v:<VerbosityLevel>

(Verbosity)

-

Enables verbose output in the LoadState log file. The default value is 0.

-

You can set the VerbosityLevel to one of the following levels:

- ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
LevelExplanation

0

Only the default errors and warnings are enabled.

1

Enables verbose output.

4

Enables error and status output.

5

Enables verbose and status output.

8

Enables error output to a debugger.

9

Enables verbose output to a debugger.

12

Enables error and status output to a debugger.

13

Enables verbose, status, and debugger output.

-

-

For example:

-

loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml

/progress:[Path</em>]FileName

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

-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log

/c

When this option is specified, the LoadState command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there is a large file that will not fit on the computer, the LoadState command will log an error and continue with the migration. Without the /c option, the LoadState command will exit on the first error. You can use the new <ErrorControl> section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the /c command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the /genconfig option now generates a sample <ErrorControl> section that is enabled by specifying error messages and desired behaviors in the Config.xml file.

/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 three times. This option is useful in environments where network connectivity is not reliable.

-

While restoring the user state, the /r option will not 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.

- - +| Command-Line 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 either a relative or full path. If you do not specify the *Path* variable, then the log will be created in the current directory. You can specify the **/v** option to adjust the amount of output.

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

Enables verbose output in the LoadState log file. The default value is 0.
You can set the *VerbosityLevel* to one of the following levels:
  • **0** - Only the default errors and warnings are enabled.
  • **1** - Enables verbose output.
  • **4** - Enables error and status output.
  • **5** - Enables verbose and status output.
  • **8** - Enables error output to a debugger.
  • **9** - Enables verbose output to a debugger.
  • **12** - Enables error and status output to a debugger.
  • **13** - Enables verbose, status, and debugger output.

For example:
`loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml` | +| `/progress:`[*Path*]*FileName* | Creates the optional progress log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* will be created in the current directory.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` | +| `/c` | When this option is specified, the **LoadState** command will continue to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there is a large file that will not fit on the computer, the **LoadState** command will log an error and continue with the migration. Without the **/c** option, the **LoadState** command will exit on the first error. You can use the new <**ErrorControl**> section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the **/c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the **/genconfig** option now generates a sample <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the Config.xml file. | +| `/r:`*``* | **(Retry)**

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

While restoring the user state, the **/r** option will not 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:`*``* | **(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. | ## 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 by using the Config.xml file. For more information, see [Identify Users](usmt-identify-users.md). - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command-Line OptionDescription

/all

Migrates all of the users on the computer.

-

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

/ui:DomainName<em>UserName

-

or

-

/ui:"DomainName<em>User Name"

-

or

-

/ui:ComputerName<em>LocalUserName

(User include)

-

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the /ue option. You can specify multiple /ui options, but you cannot use the /ui option with the /all option. 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 quotations marks.

-

For example:

-
    -

  • To include only User2 from the Corporate domain, type:

    -

    /ue:* /ui:corporate\user2

    • -
-
-Note

If a user is specified for inclusion with the /ui option, and also is specified to be excluded with either the /ue or /uel options, the user will be included in the migration.

-
-
- -
-

For more examples, see the descriptions of the /uel, /ue, and /ui options in this table.

/uel:<NumberOfDays>

-

or

-

/uel:<YYYY/MM/DD>

-

or

-

/uel:0

(User exclude based on last logon)

-

Migrates only the users that logged onto the source computer within the specified time period, based on the Last Modified date of the Ntuser.dat file on the source computer. The /uel option acts as an include rule. For example, the /uel:30 option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the /all option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.

-
-Note

The /uel option is not valid in offline migrations.

-
-
- -
-

Examples:

-
    -

  • /uel:0 migrates accounts that were logged on to the source computer when the ScanState command was run.

    • -

  • /uel:90 migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.

    • -

  • /uel:1 migrates users whose accounts have been modified within the last 24 hours.

    • -

  • /uel:2002/1/15 migrates users who have logged on or whose accounts have been modified since January 15, 2002.

    • -
-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0

/ue:DomainName<em>UserName

-

or

-

/ue:"DomainName<em>User Name"

-

or

-

/ue:ComputerName<em>LocalUserName

(User exclude)

-

Excludes the specified users from the migration. You can specify multiple /ue options but you cannot use the /ue option with the /all option. 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 quotation marks.

-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1

-

For more examples, see the descriptions of the /uel, /ue, and /ui options in this table.

/md:OldDomain:NewDomain

-

or

-

/md:LocalComputerName:NewDomain

(move domain)

-

Specifies a new domain for the user. 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 the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: /md:corporate:fabrikam and /md:farnorth:fabrikam.

-

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

-
-Note

If you specify an OldDomain that did not exist on the source computer, the LoadState command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to NewDomain but will remain in their original domain. For example, if you misspell "contoso" and you specify "/md:contso:fabrikam", the users will remain in contoso on the destination computer.

-
-
- -
-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore

-

/progress:prog.log /l:load.log /md:contoso:fabrikam

/mu:OldDomain<em>OldUserName:[NewDomain]NewUserName

-

or

-

/mu:OldLocalUserName:NewDomain<em>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:migdocs.xml \server\share\migration\mystore

-

/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\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 use the /lae option.

-

If the /lac option 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 newly created account. An empty password is used by default.

-
-Caution

Use the Password variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the LoadState command.

-

Also, if the computer has multiple users, all migrated users will have the same password.

-
-
- -
-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore

-

For instructions, see Migrate User Accounts.

/lae

(local account enable)

-

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

-

For example:

-

loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore

-

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

-

For instructions, see Migrate User Accounts.

- +| 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 the **/ue** or **/uel** options. For this reason, you do not need to specify this option on the command line. However, if you choose to use the **/all** option, you cannot also use the **/ui**, **/ue** or **/uel** options. | +| `/ui:`*DomainName UserName*
or
`/ui:`*"DomainName User Name"*
or
`/ui:`*ComputerName LocalUserName* | **(User include)**

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the **/ue** option. You can specify multiple **/ui** options, but you cannot use the **/ui** option with the **/all** option. *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 quotations marks.
For example:
  • To include only User2 from the Corporate domain, type:
    `/ue:* /ui:corporate\user2`
**Note**
If a user is specified for inclusion with the **/ui** option, and also is specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration.

For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. | +| `/uel:`*``*
or
`/uel:`*``*
or
`/uel:0` | **(User exclude based on last logon)**

Migrates only the users that logged onto the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The **/uel** option acts as an include rule. For example, the **/uel:30** option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the **/all** option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.
**Note**
The **/uel** option is not valid in offline migrations.

Examples:
  • `/uel:0` migrates accounts that were logged on to the source computer when the **ScanState** command was run.
  • `/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.
  • `/uel:1` migrates users whose accounts have been modified within the last 24 hours.
  • `/uel:2002/1/15` migrates users who have logged on or whose accounts have been modified since January 15, 2002.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0` | +| `/ue`:*DomainName UserName*
or
`/ue`*"DomainName User Name"*
or
`/ue`:*ComputerName LocalUserName* | **(User exclude)**

Excludes the specified users from the migration. You can specify multiple **/ue** options but you cannot use the **/ue** option with the **/all** option. *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 quotation marks.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1`
For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. | +| `/md:`*OldDomain*:*NewDomain*
or
`/md:`*LocalComputerName:NewDomain* | **(move domain)**
Specifies a new domain for the user. 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 the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`.

If there are conflicts between two **/md** commands, the first rule that you specify is applied. For example, if you specify the `/md:corporate:fabrikam` and `/md:corporate:farnorth` commands, then Corporate users would be mapped to the Fabrikam domain.
**Note**
If you specify an *OldDomain* that did not exist on the source computer, the **LoadState** command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to *NewDomain* but will remain in their original domain. For example, if you misspell "contoso" and you specify "/md:contso:fabrikam", the users will remain in contoso on the destination computer.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
` /progress:prog.log /l:load.log /md:contoso:fabrikam` | +| `/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:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\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 use the **/lae** option.

If the **/lac** option 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 newly created account. An empty password is used by default.
**Caution**
Use the *Password* variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the **LoadState** command.
Also, if the computer has multiple users, all migrated users will have the same password.

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). | +| `/lae` | **(local account enable)**

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

For example:
`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /lac:password /lae`

For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). | ### Examples for the /ui and /ue options The following examples apply to both the **/ui** and **/ue** options. You can replace the **/ue** option with the **/ui** option to include, rather than exclude, the specified users. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
BehaviorCommand

Exclude the user named User One in the Corporate domain.

/ue:"corporate\user one"

Exclude the user named User1 in the Corporate domain.

/ue:corporate\user1

Exclude the local user named User1.

/ue:%computername%\user1

Exclude all domain users.

/ue:Domain

Exclude all local users.

/ue:%computername%

Exclude users in all domains named User1, User2, and so on.

/ue:\user

- - +| Behavior | Command | +|--- |--- | +| Exclude the user named User One in the Corporate domain. | `/ue:"corporate\user one"` | +| Exclude the user named User1 in the Corporate domain. | `/ue:corporate\user1` | +| Exclude the local user named User1. | `/ue:%computername%\user1` | +| Exclude all domain users. | `/ue:Domain` | +| Exclude all local users. | `/ue:%computername%` | +| Exclude users in all domains named User1, User2, and so on. | `/ue:\user` | ### Using the Options Together @@ -464,247 +120,46 @@ You can use the **/uel**, **/ue** and **/ui** options together to migrate only t **The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user's profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days. - ---- - - - - - - - - - - - - - - - - - - - - - - - - -
BehaviorCommand

Include only User2 from the Fabrikam domain and exclude all other users.

/ue:* /ui:fabrikam\user2

Include only the local user named User1 and exclude all other users.

/ue:* /ui:user1

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

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

-
    -

  • Using the ScanState command-line tool, type: /ue:* /ui:contoso

    • -

  • Using the LoadState command-line tool, type: /ue:contoso\user1

    • -

Include only local (non-domain) users.

/ue: /ui:%computername%*

- - +| Behavior | Command | +|--- |--- | +| Include only User2 from the Fabrikam domain and exclude all other users. | `/ue:* /ui:fabrikam\user2` | +| Include only the local user named User1 and exclude all other users. | `/ue:* /ui:user1` | +| Include only the domain users from Contoso, except Contoso\User1. | This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:
  • Using the **ScanState** command-line tool, type: `/ue:* /ui:contoso`
  • Using the **LoadState** command-line tool, type: `/ue:contoso\user1`
| +| Include only local (non-domain) users. | `/ue: /ui:%computername%*` | ## Incompatible Command-Line Options - The following table indicates which command-line options are not compatible with the **LoadState** command. 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. - ------- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command-Line Option/keyfile/nocompress/genconfig/all

/i

/v

/nocompress

N/A

X

/key

X

X

/decrypt

Required*

X

X

/keyfile

N/A

X

/l

/progress

X

/r

X

/w

X

/c

X

/p

X

N/A

/all

X

/ui

X

X

/ue

X

X

/uel

X

X

/genconfig

N/A

/config

X

StorePath

/md

/mu

/lae

/lac

- - - -**Note** -You must specify either the **/key** or **/keyfile** option with the **/encrypt** option. - +| Command-Line Option | /keyfile | /nocompress | /genconfig | /all | +|--- |--- |--- |--- |--- | +| **/i** | | | | | +| **/v** | | | | | +| **/nocompress** | | N/A | X | | +| **/key** | X | | X | | +| **/decrypt** | Required* | X | X | | +| **/keyfile** | N/A | | X | | +| **/l** | | | | | +| **/progress** | | | X | | +| **/r** | | | X | | +| **/w** | | | X | | +| **/c** | | | X | | +| **/p** | | | X | N/A | +| **/all** | | | X | | +| **/ui** | | | X | X | +| **/ue** | | | X | X | +| **/uel** | | | X | X | +| **/genconfig** | | | N/A | | +| **/config** | | | X | | +| *StorePath* | | | | | +| **/md** | | | | | +| **/mu** | | | | | +| **/lae** | | | | | +| **/lac** | | | | | +> [!NOTE] +> You must specify either the **/key** or **/keyfile** option with the **/encrypt** option. ## Related topics - [XML Elements Library](usmt-xml-elements-library.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-log-files.md b/windows/deployment/usmt/usmt-log-files.md index 63fcf4af6f..3d42379783 100644 --- a/windows/deployment/usmt/usmt-log-files.md +++ b/windows/deployment/usmt/usmt-log-files.md @@ -16,7 +16,6 @@ ms.topic: article # Log Files - You can use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. This topic describes the available command-line options to enable USMT logs, and new XML elements that configure which types of errors are fatal and should halt the migration, which types are non-fatal and should be skipped so that the migration can continue. [Log Command-Line Options](#bkmk-commandlineoptions) @@ -31,66 +30,25 @@ You can use User State Migration Tool (USMT) 10.0 logs to monitor your migratio ## Log Command-Line Options - The following table describes each command-line option related to logs, and it provides the log name and a description of what type of information each log contains. - ----- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Command line OptionFile NameDescription

/l[Path]FileName

Scanstate.log or LoadState.log

Specifies the path and file name of the ScanState.log or LoadState log.

/progress[Path]FileName

Specifies the path and file name of the Progress log.

Provides information about the status of the migration, by percentage complete.

/v[VerbosityLevel]

Not applicable

See the "Monitoring Options" section in ScanState Syntax.

/listfiles[Path]FileName

Specifies the path and file name of the Listfiles log.

Provides a list of the files that were migrated.

Set the environment variable MIG_ENABLE_DIAG to a path to an XML file.

USMTDiag.xml

The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.

+|Command line Option|File Name|Description| +|--- |--- |--- | +|**/l** *[Path]FileName*|Scanstate.log or LoadState.log|Specifies the path and file name of the ScanState.log or LoadState log.| +|**/progress** *[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.| +|**/v** *[VerbosityLevel]*|Not applicable|See the "Monitoring Options" section in [ScanState Syntax](usmt-scanstate-syntax.md).| +|**/listfiles** *[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.| +|Set the environment variable MIG_ENABLE_DIAG to a path to an XML file.|USMTDiag.xml|The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.| - - -**Note**   -You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run. - - +> [!NOTE] +> You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run. ## ScanState and LoadState Logs - ScanState and LoadState logs are text files that are create when you run the ScanState and LoadState tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see Monitoring Options in [ScanState Syntax](usmt-scanstate-syntax.md). ## Progress Log - You can create a progress log using the **/progress** option. External tools, such as Microsoft System Center Operations Manager 2007, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows: - **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2006. @@ -101,137 +59,34 @@ You can create a progress log using the **/progress** option. External tools, su The remaining fields are key/value pairs as indicated in the following table. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
KeyValue

program

ScanState.exe or LoadState.exe.

productVersion

The full product version number of USMT.

computerName

The name of the source or destination computer on which USMT was run.

commandLine

The full command used to run USMT.

PHASE

Reports that a new phase in the migration is starting. This can be one of the following:

-
    -

  • Initializing

    • -

  • Scanning

    • -

  • Collecting

    • -

  • Saving

    • -

  • Estimating

    • -

  • Applying

    • -

detectedUser

    -

  • For the ScanState tool, these are the users USMT detected on the source computer that can be migrated.

    • -

  • For the LoadState tool, these are the users USMT detected in the store that can be migrated.

    • -

includedInMigration

Defines whether the user profile/component is included for migration. Valid values are Yes or No.

forUser

Specifies either of the following:

-
    -

  • The user state being migrated.

    • -

  • This Computer, meaning files and settings that are not associated with a user.

    • -

detectedComponent

Specifies a component detected by USMT.

-
    -

  • For ScanState, this is a component or application that is installed on the source 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 settings for.

totalMinutesRemaining

Time estimate, in minutes, for the migration to complete.

error

Type of non-fatal error that occurred. This 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: Unable to copy because the store is corrupted.

    • -

  • UnableToAccessDevice: Unable to access the device.

    • -

  • UnableToApply: Unable to apply 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: Non-fatal error ignored and the migration continued because the /c option was specified on the command line.

    • -

  • Abort: Stopped the migration because the /c option 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.

- - +| Key | Value | +|-----|-------| +| program | ScanState.exe or LoadState.exe. | +| productVersion | The full product version number of USMT. | +| computerName | The name of the source or destination computer on which USMT was run. | +| commandLine | The full command used to run USMT. | +| PHASE | Reports that a new phase in the migration is starting. This can be one of the following:
  • Initializing
  • Scanning
  • Collecting
  • Saving
  • Estimating
  • Applying
| +| detectedUser |
  • For the ScanState tool, these are the users USMT detected on the source computer that can be migrated.
  • For the LoadState tool, these are the users USMT detected in the store that can be migrated.
| +| includedInMigration | Defines whether the user profile/component is included for migration. Valid values are Yes or No. | +| forUser | Specifies either of the following:
  • The user state being migrated.
  • *This Computer*, meaning files and settings that are not associated with a user.
| +| detectedComponent | Specifies a component detected by USMT.
  • For ScanState, this is a component or application that is installed on the source 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 settings for. | +| totalMinutesRemaining | Time estimate, in minutes, for the migration to complete. | +| error | Type of non-fatal error that occurred. This 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**: Unable to copy because the store is corrupted.
  • **UnableToAccessDevice**: Unable to access the device.
  • **UnableToApply**: Unable to apply 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**: Non-fatal error ignored and the migration continued because the **/c** option was specified on the command line.
  • **Abort**: Stopped the migration because the **/c** option 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. | ## List Files Log - The List files log (Listfiles.txt) provides a list of the files that were migrated. This list can be used to troubleshoot XML issues or can be retained as a record of the files that were gathered into the migration store. The List Files log is only available for ScanState.exe. ## Diagnostic Log - You can obtain the diagnostic log by setting the environment variable MIG\_ENABLE\_DIAG to a path to an XML file. The diagnostic log contains: @@ -244,7 +99,6 @@ The diagnostic log contains: ## Using the Diagnostic Log - The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data that is identified by the component it is associated with in the XML files. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files. The following examples describe common scenarios in which you can use the diagnostic log. @@ -253,7 +107,7 @@ The following examples describe common scenarios in which you can use the diagno Let's imagine that we have the following directory structure and that we want the "data" directory to be included in the migration along with the "New Text Document.txt" file in the "New Folder." The directory of **C:\\data** contains: -``` +```console 01/21/2009 10:08 PM . 01/21/2009 10:08 PM .. 01/21/2009 10:08 PM New Folder @@ -264,7 +118,7 @@ Let's imagine that we have the following directory structure and that we want th The directory of **C:\\data\\New Folder** contains: -``` +```console 01/21/2009 10:08 PM . 01/21/2009 10:08 PM .. 01/21/2009 10:08 PM 0 New Text Document.txt @@ -295,7 +149,7 @@ To migrate these files you author the following migration XML: However, upon testing the migration you notice that the "New Text Document.txt" file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable MIG\_ENABLE\_DIAG set such that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: -``` xml +```xml @@ -316,13 +170,13 @@ Analysis of this XML section reveals the migunit that was created when the migra An analysis of the XML elements reference topic reveals that the <pattern> tag needs to be modified as follows: -``` xml +```xml c:\data\* [*] ``` When the migration is preformed again with the modified tag, the diagnostic log reveals the following: -``` xml +```xml @@ -347,7 +201,7 @@ This diagnostic log confirms that the modified <pattern> value enables the In this scenario, you have the following directory structure and you want all files in the "data" directory to migrate, except for text files. The **C:\\Data** folder contains: -``` +```console Directory of C:\Data 01/21/2009 10:08 PM . @@ -360,7 +214,7 @@ Directory of C:\Data The **C:\\Data\\New Folder\\** contains: -``` +```console 01/21/2009 10:08 PM . 01/21/2009 10:08 PM .. 01/21/2009 10:08 PM 0 New Text Document.txt @@ -397,7 +251,7 @@ You author the following migration XML: However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable MIG\_ENABLE\_DIAG set so that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: -``` xml +```xml @@ -454,7 +308,7 @@ Upon reviewing the diagnostic log, you confirm that the files are still migratin Your revised migration XML script excludes the files from migrating, as confirmed in the diagnostic log: -``` xml +```xml @@ -484,11 +338,3 @@ Your revised migration XML script excludes the files from migrating, as confirme [LoadState Syntax](usmt-loadstate-syntax.md) - - - - - - - - diff --git a/windows/deployment/usmt/usmt-migration-store-encryption.md b/windows/deployment/usmt/usmt-migration-store-encryption.md index c10a7ba4f3..6ba4824bdc 100644 --- a/windows/deployment/usmt/usmt-migration-store-encryption.md +++ b/windows/deployment/usmt/usmt-migration-store-encryption.md @@ -16,62 +16,24 @@ ms.topic: article # Migration Store Encryption - This topic discusses User State Migration Tool (USMT) 10.0 options for migration store encryption to protect the integrity of user data during a migration. ## USMT Encryption Options - USMT 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 the **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** and the **LoadState** 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 Windows 7, Windows 8, and Windows 10 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 command-line encryption options in USMT. - ----- - - - - - - - - - - - - - - - - - - - -
ComponentOptionDescription

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.

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.

- - +|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.| +|**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.| **Important**   Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the UsmtUtils command with the **/ec** option. For more information see [UsmtUtils Syntax](usmt-utilities.md) - - ## Related topics - [Plan Your Migration](usmt-plan-your-migration.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-plan-your-migration.md b/windows/deployment/usmt/usmt-plan-your-migration.md index 7ea0c4d341..3090fc7efd 100644 --- a/windows/deployment/usmt/usmt-plan-your-migration.md +++ b/windows/deployment/usmt/usmt-plan-your-migration.md @@ -16,7 +16,6 @@ ms.topic: article # Plan Your Migration - Before you use the User State Migration Tool (USMT) 10.0 to perform your migration, we recommend that you plan your migration carefully. Planning can help your migration proceed smoothly and can reduce the risk of migration failure. In migration planning, both organizations and individuals must first identify what to migrate, including user settings, applications and application settings, and personal data files and folders. Identifying the applications to migrate is especially important so that you can avoid capturing data about applications that may be phased out. @@ -25,48 +24,14 @@ One of the most important requirements for migrating settings and data is restor ## In This Section - - ---- - - - - - - - - - - - - - - - - - - - - - - -

Common Migration Scenarios

Determine whether you will perform a refresh migration or a replace migration.

What Does USMT Migrate?

Learn which applications, user data, and operating system components USMT migrates.

Choose a Migration Store Type

Choose an uncompressed, compressed, or hard-link migration store.

Determine What to Migrate

Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.

Test Your Migration

Test your migration before you deploy Windows to all users.

- - +| Link | Description | +|--- |--- | +|[Common Migration Scenarios](usmt-common-migration-scenarios.md)|Determine whether you will perform a refresh migration or a replace migration.| +|[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)|Learn which applications, user data, and operating system components USMT migrates.| +|[Choose a Migration Store Type](usmt-choose-migration-store-type.md)|Choose an uncompressed, compressed, or hard-link migration store.| +|[Determine What to Migrate](usmt-determine-what-to-migrate.md)|Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.| +|[Test Your Migration](usmt-test-your-migration.md)|Test your migration before you deploy Windows to all users.| ## Related topics - [USMT XML Reference](usmt-xml-reference.md) - - - - - - - - - diff --git a/windows/deployment/usmt/usmt-recognized-environment-variables.md b/windows/deployment/usmt/usmt-recognized-environment-variables.md index a2ff4251a9..6e522e003e 100644 --- a/windows/deployment/usmt/usmt-recognized-environment-variables.md +++ b/windows/deployment/usmt/usmt-recognized-environment-variables.md @@ -31,441 +31,112 @@ When using the XML files MigDocs.xml, MigApp.xml, and MigUser.xml, you can use e You can use these variables within sections in the .xml files with `context=UserAndSystem`, `context=User`, and `context=System`. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VariableExplanation

ALLUSERSAPPDATA

Same as CSIDL_COMMON_APPDATA.

ALLUSERSPROFILE

Refers to %PROFILESFOLDER%\Public or %PROFILESFOLDER%\all users.

COMMONPROGRAMFILES

Same as CSIDL_PROGRAM_FILES_COMMON.

COMMONPROGRAMFILES(X86)

Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.

CSIDL_COMMON_ADMINTOOLS

Version 10.0. The file-system directory that contains administrative tools for all users of the computer.

CSIDL_COMMON_ALTSTARTUP

The file-system directory that corresponds to the non-localized Startup program group for all users.

CSIDL_COMMON_APPDATA

The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.

CSIDL_COMMON_DESKTOPDIRECTORY

The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop.

CSIDL_COMMON_DOCUMENTS

The file-system directory that contains documents that are common to all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Documents. A typical path is C:\Users\Public\Documents.

CSIDL_COMMON_FAVORITES

The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.

CSIDL_COMMON_MUSIC

The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.

CSIDL_COMMON_PICTURES

The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.

CSIDL_COMMON_PROGRAMS

The file-system directory that contains the directories for the common program groups that appear on the Start menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.

CSIDL_COMMON_STARTMENU

The file-system directory that contains the programs and folders which appear on the Start menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.

CSIDL_COMMON_STARTUP

The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.

CSIDL_COMMON_TEMPLATES

The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.

CSIDL_COMMON_VIDEO

The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.

CSIDL_DEFAULT_APPDATA

Refers to the Appdata folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_LOCAL_APPDATA

Refers to the local Appdata folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_COOKIES

Refers to the Cookies folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_CONTACTS

Refers to the Contacts folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_DESKTOP

Refers to the Desktop folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_DOWNLOADS

Refers to the Downloads folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_FAVORITES

Refers to the Favorites folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_HISTORY

Refers to the History folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_INTERNET_CACHE

Refers to the Internet Cache folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_PERSONAL

Refers to the Personal folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_MYDOCUMENTS

Refers to the My Documents folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_MYPICTURES

Refers to the My Pictures folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_MYMUSIC

Refers to the My Music folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_MYVIDEO

Refers to the My Videos folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_RECENT

Refers to the Recent folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_SENDTO

Refers to the Send To folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_STARTMENU

Refers to the Start Menu folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_PROGRAMS

Refers to the Programs folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_STARTUP

Refers to the Startup folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_TEMPLATES

Refers to the Templates folder inside %DEFAULTUSERPROFILE%.

CSIDL_DEFAULT_QUICKLAUNCH

Refers to the Quick Launch folder inside %DEFAULTUSERPROFILE%.

CSIDL_FONTS

A virtual folder containing fonts. A typical path is C:\Windows\Fonts.

CSIDL_PROGRAM_FILESX86

The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).

CSIDL_PROGRAM_FILES_COMMONX86

A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.

CSIDL_PROGRAM_FILES

The Program Files folder. A typical path is C:\Program Files.

CSIDL_PROGRAM_FILES_COMMON

A folder for components that are shared across applications. A typical path is C:\Program Files\Common.

CSIDL_RESOURCES

The file-system directory that contains resource data. A typical path is C:\Windows\Resources.

CSIDL_SYSTEM

The Windows System folder. A typical path is C:\Windows\System32.

CSIDL_WINDOWS

The Windows directory or system root. This corresponds to the %WINDIR% or %SYSTEMROOT% environment variables. A typical path is C:\Windows.

DEFAULTUSERPROFILE

Refers to the value in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile].

PROFILESFOLDER

Refers to the value in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory].

PROGRAMFILES

Same as CSIDL_PROGRAM_FILES.

PROGRAMFILES(X86)

Refers to the C:\Program Files (x86) folder on 64-bit systems.

SYSTEM

Refers to %WINDIR%\system32.

SYSTEM16

Refers to %WINDIR%\system.

SYSTEM32

Refers to %WINDIR%\system32.

SYSTEMPROFILE

Refers to the value in HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath].

SYSTEMROOT

Refers to the root of the system drive.

WINDIR

Refers to the Windows folder located on the system drive.

- -  +|Variable|Explanation| +|--- |--- | +|**ALLUSERSAPPDATA**|Same as **CSIDL_COMMON_APPDATA**.| +|**ALLUSERSPROFILE**|Refers to %**PROFILESFOLDER**%\Public or %**PROFILESFOLDER**%\all users.| +|**COMMONPROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES_COMMON**.| +|**COMMONPROGRAMFILES**(X86)|Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.| +|**CSIDL_COMMON_ADMINTOOLS**|Version 10.0. The file-system directory that contains administrative tools for all users of the computer.| +|**CSIDL_COMMON_ALTSTARTUP**|The file-system directory that corresponds to the non-localized Startup program group for all users.| +|**CSIDL_COMMON_APPDATA**|The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.| +|**CSIDL_COMMON_DESKTOPDIRECTORY**|The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop.| +|**CSIDL_COMMON_DOCUMENTS**|The file-system directory that contains documents that are common to all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Documents. A typical path is C:\Users\Public\Documents.| +|**CSIDL_COMMON_FAVORITES**|The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.| +|**CSIDL_COMMON_MUSIC**|The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.| +|**CSIDL_COMMON_PICTURES**|The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.| +|**CSIDL_COMMON_PROGRAMS**|The file-system directory that contains the directories for the common program groups that appear on the **Start** menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.| +|**CSIDL_COMMON_STARTMENU**|The file-system directory that contains the programs and folders which appear on the **Start** menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.| +|**CSIDL_COMMON_STARTUP**|The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.| +|**CSIDL_COMMON_TEMPLATES**|The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.| +|**CSIDL_COMMON_VIDEO**|The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.| +|**CSIDL_DEFAULT_APPDATA**|Refers to the Appdata folder inside %**DEFAULTUSERPROFILE**%.| +|C**SIDL_DEFAULT_LOCAL_APPDATA**|Refers to the local Appdata folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_COOKIES**|Refers to the Cookies folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_CONTACTS**|Refers to the Contacts folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_DESKTOP**|Refers to the Desktop folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_DOWNLOADS**|Refers to the Downloads folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_FAVORITES**|Refers to the Favorites folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_HISTORY**|Refers to the History folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_INTERNET_CACHE**|Refers to the Internet Cache folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_PERSONAL**|Refers to the Personal folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_MYDOCUMENTS**|Refers to the My Documents folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_MYPICTURES**|Refers to the My Pictures folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_MYMUSIC**|Refers to the My Music folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_MYVIDEO**|Refers to the My Videos folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_RECENT**|Refers to the Recent folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_SENDTO**|Refers to the Send To folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_STARTMENU**|Refers to the Start Menu folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_PROGRAMS**|Refers to the Programs folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_STARTUP**|Refers to the Startup folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_TEMPLATES**|Refers to the Templates folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_DEFAULT_QUICKLAUNCH**|Refers to the Quick Launch folder inside %**DEFAULTUSERPROFILE**%.| +|**CSIDL_FONTS**|A virtual folder containing fonts. A typical path is C:\Windows\Fonts.| +|**CSIDL_PROGRAM_FILESX86**|The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).| +|**CSIDL_PROGRAM_FILES_COMMONX86**|A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.| +|**CSIDL_PROGRAM_FILES**|The Program Files folder. A typical path is C:\Program Files.| +|**CSIDL_PROGRAM_FILES_COMMON**|A folder for components that are shared across applications. A typical path is C:\Program Files\Common.| +|**CSIDL_RESOURCES**|The file-system directory that contains resource data. A typical path is C:\Windows\Resources.| +|**CSIDL_SYSTEM**|The Windows System folder. A typical path is C:\Windows\System32.| +|**CSIDL_WINDOWS**|The Windows directory or system root. This corresponds to the %**WINDIR**% or %**SYSTEMROOT**% environment variables. A typical path is C:\Windows.| +|**DEFAULTUSERPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]**.| +|**PROFILESFOLDER**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]**.| +|**PROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES**.| +|**PROGRAMFILES(X86)**|Refers to the C:\Program Files (x86) folder on 64-bit systems.| +|**SYSTEM**|Refers to %**WINDIR**%\system32.| +|**SYSTEM16**|Refers to %**WINDIR**%\system.| +|**SYSTEM32**|Refers to %**WINDIR**%\system32.| +|**SYSTEMPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]**.| +|**SYSTEMROOT**|Refers to the root of the system drive.| +|**WINDIR**|Refers to the Windows folder located on the system drive.| ## Variables that are recognized only in the user context - You can use these variables in the .xml files within sections with `context=User` and `context=UserAndSystem`. - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
VariableExplanation

APPDATA

Same as CSIDL_APPDATA.

CSIDL_ADMINTOOLS

The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile.

CSIDL_ALTSTARTUP

The file-system directory that corresponds to the user's non-localized Startup program group.

CSIDL_APPDATA

The file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.

CSIDL_BITBUCKET

The virtual folder that contains the objects in the user's Recycle Bin.

CSIDL_CDBURN_AREA

The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning.

CSIDL_CONNECTIONS

The virtual folder representing Network Connections that contains network and dial-up connections.

CSIDL_CONTACTS

This refers to the Contacts folder in %CSIDL_PROFILE%.

CSIDL_CONTROLS

The virtual folder that contains icons for the Control Panel items.

CSIDL_COOKIES

The file-system directory that serves as a common repository for Internet cookies. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies.

CSIDL_DESKTOP

The virtual folder representing the Windows desktop.

CSIDL_DESKTOPDIRECTORY

The file-system directory used to physically store file objects on the desktop, which should not be confused with the desktop folder itself. A typical path is C:\Users\username\Desktop.

CSIDL_DRIVES

The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.

CSIDL_FAVORITES

The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.

CSIDL_HISTORY

The file-system directory that serves as a common repository for Internet history items.

CSIDL_INTERNET

A virtual folder for Internet Explorer.

CSIDL_INTERNET_CACHE

The file-system directory that serves as a common repository for temporary Internet files. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files

CSIDL_LOCAL_APPDATA

The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.

CSIDL_MYDOCUMENTS

The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.

CSIDL_MYMUSIC

The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.

CSIDL_MYPICTURES

The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.

CSIDL_MYVIDEO

The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.

CSIDL_NETHOOD

A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.

CSIDL_NETWORK

A virtual folder representing My Network Places, the root of the network namespace hierarchy.

CSIDL_PERSONAL

The virtual folder representing the My Documents desktop item. This is equivalent to CSIDL_MYDOCUMENTS.

-

A typical path is C:\Documents and Settings\username\My Documents.

CSIDL_PLAYLISTS

The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.

CSIDL_PRINTERS

The virtual folder that contains installed printers.

CSIDL_PRINTHOOD

The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Printer Shortcuts.

CSIDL_PROFILE

The user's profile folder. A typical path is C:\Users\Username.

CSIDL_PROGRAMS

The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.

CSIDL_RECENT

The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent.

CSIDL_SENDTO

The file-system directory that contains Send To menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.

CSIDL_STARTMENU

The file-system directory that contains Start menu items. A typical path in Windows XP is C:\Documents and Settings\username\Start Menu. A typical path in Windows Vista, Windows 7, or Windows 8 is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu.

CSIDL_STARTUP

The file-system directory that corresponds to the user's Startup program group. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.

CSIDL_TEMPLATES

The file-system directory that serves as a common repository for document templates. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Templates.

HOMEPATH

Same as the standard environment variable.

TEMP

The temporary folder on the computer. A typical path is %USERPROFILE%\AppData\Local\Temp.

TMP

The temporary folder on the computer. A typical path is %USERPROFILE%\AppData\Local\Temp.

USERPROFILE

Same as CSIDL_PROFILE.

USERSID

Represents the current user-account security identifier (SID). For example,

-

S-1-5-21-1714567821-1326601894-715345443-1026.

- -  +|Variable|Explanation| +|--- |--- | +|**APPDATA**|Same as **CSIDL_APPDATA**.| +|**CSIDL_ADMINTOOLS**|The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile.| +|**CSIDL_ALTSTARTUP**|The file-system directory that corresponds to the user's non-localized Startup program group.| +|**CSIDL_APPDATA**|The file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.| +|**CSIDL_BITBUCKET**|The virtual folder that contains the objects in the user's Recycle Bin.| +|**CSIDL_CDBURN_AREA**|The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning.| +|**CSIDL_CONNECTIONS**|The virtual folder representing Network Connections that contains network and dial-up connections.| +|**CSIDL_CONTACTS**|This refers to the Contacts folder in %**CSIDL_PROFILE**%.| +|**CSIDL_CONTROLS**|The virtual folder that contains icons for the Control Panel items.| +|**CSIDL_COOKIES**|The file-system directory that serves as a common repository for Internet cookies. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies.| +|**CSIDL_DESKTOP**|The virtual folder representing the Windows desktop.| +|**CSIDL_DESKTOPDIRECTORY**|The file-system directory used to physically store file objects on the desktop, which should not be confused with the desktop folder itself. A typical path is C:\Users\username\Desktop.| +|**CSIDL_DRIVES**|The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.| +|**CSIDL_FAVORITES**|The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.| +|**CSIDL_HISTORY**|The file-system directory that serves as a common repository for Internet history items.| +|**CSIDL_INTERNET**|A virtual folder for Internet Explorer.| +|**CSIDL_INTERNET_CACHE**|The file-system directory that serves as a common repository for temporary Internet files. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files| +|**CSIDL_LOCAL_APPDATA**|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.| +|**CSIDL_MYDOCUMENTS**|The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.| +|**CSIDL_MYMUSIC**|The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.| +|**CSIDL_MYPICTURES**|The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.| +|**CSIDL_MYVIDEO**|The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.| +|**CSIDL_NETHOOD**|A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.| +|**CSIDL_NETWORK**|A virtual folder representing My Network Places, the root of the network namespace hierarchy.| +|**CSIDL_PERSONAL**|The virtual folder representing the My Documents desktop item. This is equivalent to **CSIDL_MYDOCUMENTS**.
A typical path is C:\Documents and Settings\username\My Documents.| +|**CSIDL_PLAYLISTS**|The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.| +|**CSIDL_PRINTERS**|The virtual folder that contains installed printers.| +|**CSIDL_PRINTHOOD**|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Printer Shortcuts.| +|**CSIDL_PROFILE**|The user's profile folder. A typical path is C:\Users\Username.| +|**CSIDL_PROGRAMS**|The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.| +|**CSIDL_RECENT**|The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent.| +|**CSIDL_SENDTO**|The file-system directory that contains **Send To** menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.| +|**CSIDL_STARTMENU**|The file-system directory that contains **Start** menu items. A typical path in Windows XP is C:\Documents and Settings\username\Start Menu. A typical path in Windows Vista, Windows 7, or Windows 8 is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu.| +|**CSIDL_STARTUP**|The file-system directory that corresponds to the user's Startup program group. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.| +|**CSIDL_TEMPLATES**|The file-system directory that serves as a common repository for document templates. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Templates.| +|**HOMEPATH**|Same as the standard environment variable.| +|**TEMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.| +|**TMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.| +|**USERPROFILE**|Same as **CSIDL_PROFILE**.| +|**USERSID**|Represents the current user-account security identifier (SID). For example,
S-1-5-21-1714567821-1326601894-715345443-1026.| ## Related topics - [USMT XML Reference](usmt-xml-reference.md) - -  - -  - - - - - diff --git a/windows/deployment/usmt/usmt-reference.md b/windows/deployment/usmt/usmt-reference.md index 7e00f19577..a24a5da4cd 100644 --- a/windows/deployment/usmt/usmt-reference.md +++ b/windows/deployment/usmt/usmt-reference.md @@ -16,63 +16,22 @@ ms.topic: article # User State Migration Toolkit (USMT) Reference - ## In This Section - - ---- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

USMT Requirements

Describes operating system, hardware, and software requirements, and user prerequisites.

USMT Best Practices

Discusses general and security-related best practices when using USMT.

How USMT Works

Learn about the processes behind the ScanState and LoadState tools.

Plan Your Migration

Choose what to migrate and the best migration scenario for your enterprise.

User State Migration Tool (USMT) Command-line Syntax

Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.

USMT XML Reference

Learn about customizing a migration with XML files.

Offline Migration Reference

Find requirements, best practices, and other considerations for performing a migration offline.

- - +| Link | Description | +|--- |--- | +|[USMT Requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.| +|[USMT Best Practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.| +|[How USMT Works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.| +|[Plan Your Migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.| +|[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.| +|[USMT XML Reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.| +|[Offline Migration Reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.| ## Related topics - [User State Migration Tool (USMT) Overview Topics](usmt-topics.md) [User State Migration Tool (USMT) How-to topics](usmt-how-to.md) [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md) - - - - - - - - -