mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 18:33:43 +00:00
USMT Refresh 19
This commit is contained in:
Frank Rojas
@ -33,7 +33,7 @@ There are many ways to detect if an application is installed. The best practice
|
||||
|
||||
### Check the registry for an application uninstall key
|
||||
|
||||
When many applications are installed (especially those installed using the Microsoft® Windows® Installer technology), an application uninstall key is created under:
|
||||
When many applications are installed (especially those installed using the Microsoft Windows Installer technology), an application uninstall key is created under:
|
||||
|
||||
`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall`
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ Offline migration enables the ScanState tool to run inside a different Windows o
|
||||
|
||||
- **Windows.old.** The ScanState tool can gather files and settings from the **Windows.old** directory. The **Windows.old** directory is created during Windows installation on a partition that contains a previous installation of Windows. For example, the ScanState tool can run in Windows, gathering files from a previous Windows installation contained in the **Windows.old** directory.
|
||||
|
||||
When you use User State Migration Tool (USMT) to gather and restore user state, offline migration reduces the cost of deployment by:
|
||||
When using the User State Migration Tool (USMT) to gather and restore user state, offline migration reduces the cost of deployment by:
|
||||
|
||||
- **Reducing complexity.** In computer-refresh scenarios, migrations from the **Windows.old** directory reduce complexity by eliminating the need for the ScanState tool to be run before the operating system is deployed. Also, migrations from the **Windows.old** directory enable ScanState and LoadState to be run successively.
|
||||
|
||||
@ -45,7 +45,7 @@ The following user data and settings migrate offline, similar to an online migra
|
||||
|
||||
- Favorites.
|
||||
|
||||
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
For exceptions to what can be migrated offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
|
||||
|
||||
## What offline environments are supported?
|
||||
|
||||
@ -64,7 +64,7 @@ The following table defines the supported combination of online and offline oper
|
||||
|
||||
## User-group membership and profile control
|
||||
|
||||
User-group membership isn't 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:
|
||||
User-group membership isn't preserved during offline migrations. A **\<ProfileControl\>** section must be configured 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
|
||||
<Configuration>
|
||||
@ -94,7 +94,7 @@ An offline migration can either be enabled by using a configuration file on the
|
||||
|*ScanState.exe*|**/offlineWinDir:***\<Windows directory\>*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It's 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. Only use 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 doesn't support using more than one together.
|
||||
Only one of the `/offline`, `/offlineWinDir`, or `/OfflineWinOld` command-line options can be used at a time. USMT doesn't support using more than one together.
|
||||
|
||||
## Environment variables
|
||||
|
||||
|
||||
@ -15,13 +15,13 @@ appliesto:
|
||||
|
||||
# Understanding migration XML files
|
||||
|
||||
You can modify the behavior of a basic User State Migration Tool (USMT) 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 the migration.
|
||||
The behavior of a basic User State Migration Tool (USMT) migration can be modified 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 can be used 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. Custom XML files and a `Config.xml` file can be created and edited to further customize the migration.
|
||||
|
||||
This article 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.
|
||||
|
||||
## Overview of the Config.xml file
|
||||
|
||||
The `Config.xml` file is the configuration file created by the `/genconfig` option of the ScanState tool. You can use it to modify which operating-system components USMT migrates. The `Config.xml` file can be used with other XML files, such as in the following example:
|
||||
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 USMT migrates. The `Config.xml` file can be used with other XML files, such as in the following example:
|
||||
|
||||
`ScanState.exe /i:migapps.xml /i:MigDocs.xml /genconfig:c:\myFolder\Config.xml`
|
||||
|
||||
@ -29,11 +29,11 @@ When used this way, the `Config.xml` file tightly controls aspects of the migrat
|
||||
|
||||
> [!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, rules in other XML files can still migrate the component.
|
||||
> When modifying the XML elements in the `Config.xml` file, set the **migrate** property on an element to **no** instead of deleting the element from the file. If the element is deleted instead of setting the property, rules in other XML files can still migrate the component.
|
||||
|
||||
## 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 don't 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).
|
||||
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). In order to migrate application settings, the `MigApp.xml` file must be included when using the ScanState and LoadState tools by using the `/i` option. The `MigDocs.xml` and `MigUser.xml` files don't migrate application settings. A custom XML file can be created to include additional applications. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
@ -41,7 +41,7 @@ The `MigApp.xml` file installed with USMT includes instructions to migrate the s
|
||||
|
||||
## 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 `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. The `MigDocs.xml` file can be used 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 data:
|
||||
|
||||
@ -107,11 +107,11 @@ The default `MigDocs.xml` file doesn't migrate the following data:
|
||||
|
||||
- Folders that contain installed applications.
|
||||
|
||||
You can also use the `/genmigxml` option with the ScanState tool to review and modify what files are migrated.
|
||||
The `/genmigxml` option can be used with the ScanState tool to review and modify what files are migrated.
|
||||
|
||||
## 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 gathers all files from the standard user-profile folders, and 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. The `MigUser.xml` file can be used with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The `MigUser.xml` file gathers 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 data:
|
||||
|
||||
@ -155,24 +155,24 @@ The default `MigUser.xml` file doesn't migrate the following data:
|
||||
|
||||
- ACLS for files in folders outside the user profile.
|
||||
|
||||
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 the relevant data, regardless of the location of the files. However, this provision can result in a migration that contains more files than intended. For example, if you choose to migrate all **.jpg** files, it can also migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
|
||||
The `MigUser.xml` file can be copied and then the copy modified to include or exclude standard user-profile folders and file name extensions. If all of the extensions for the files that need to be migrated from the source computer are known, use the `MigUser.xml` file to move all of the relevant data, regardless of the location of the files. However, adding in all file extensions that need to be migrated to the `MigUser.xml` file can result in a migration that contains more files than intended. For example, if all **.jpg** files are migrated, it can also 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're migrating more than 300 file types, the migration experience can be slow. For more information about other ways to organize the migration of the data, see the [Using multiple XML files](#using-multiple-xml-files) section of this article.
|
||||
> Each file name extension included 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 more than 300 file types are being migrated, the migration experience can be slow. For more information about other ways to organize the migration of the data, see the [Using multiple XML files](#using-multiple-xml-files) section of this article.
|
||||
|
||||
## 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 more migration rules.
|
||||
Multiple XML files can be used 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. Custom XML files can also be used to supplement these default files with more migration rules.
|
||||
|
||||
|XML migration file|Modifies the following components:|
|
||||
|--- |--- |
|
||||
|**Config.xml file**|Operating-system components such as desktop wallpaper and background theme.<br> 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).|
|
||||
|**Config.xml file**|Operating-system components such as desktop wallpaper and background theme.<br> The `Config.xml` can also be extended 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:
|
||||
For example, all of the XML migration file types can be used for a single migration, as in the following example:
|
||||
|
||||
```cmd
|
||||
ScanState.exe <store> /config:c:\myFolder\Config.xml /i:migapps.xml /i:MigDocs.xml /i:CustomRules.xml
|
||||
@ -182,19 +182,19 @@ ScanState.exe <store> /config:c:\myFolder\Config.xml /i:migapps.xml /i:MigDocs.x
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
> You shouldn't 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. Duplication of some migrated files can occur when conflicting target-location instructions are given in each XML file. The target file is stored once during the migration, but each XML file applies the file to a different location on the destination computer.
|
||||
> The `MigUser.xml` and `MigDocs.xml` files shouldn't be used together in the same command. Using both XML files can result in duplication of some migrated files. Duplication of some migrated files can occur when conflicting target-location instructions are given in each XML file. The target file is stored once during the migration, but each XML file applies the file to a different location on the destination computer.
|
||||
|
||||
If the 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 gathers 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.
|
||||
|
||||
If you want more control over the migration, you can create custom XML files. For more information on creating custom XML files, see [Creating and editing a custom XML file](#creating-and-editing-a-custom-xml-file) for more information.
|
||||
For more control over the migration, create custom XML files. For more information on creating custom XML files, see [Creating and editing a custom XML file](#creating-and-editing-a-custom-xml-file).
|
||||
|
||||
## Creating and editing a custom XML file
|
||||
|
||||
You can use the `/genmigxml` command-line option to determine which files are included in the 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.
|
||||
The `/genmigxml` command-line option can be used to determine which files are included in the migration. The `/genmigxml` option creates a file in a specified location. The XML rules in the file can then be reviewed and if necessary, modifications made.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> If you reinstall USMT, the default migration XML files are overwritten and any customizations you make directly to these files are lost. Consider creating separate XML files for the custom migration rules and saving them in a secure location.
|
||||
> If USMT is reinstalled, the default migration XML files are overwritten and any customizations made to these files are lost. Consider creating separate XML files for the custom migration rules and saving them in a secure location.
|
||||
|
||||
To generate the XML migration rules file for a source computer:
|
||||
|
||||
@ -214,7 +214,7 @@ To generate the XML migration rules file for a source computer:
|
||||
where:
|
||||
|
||||
- **\<USMTpath\>** - location on the source computer of the saved USMT files and tools.
|
||||
- **\<filepath.xml\>** - full path to a file where you can save the report.
|
||||
- **\<filepath.xml\>** - full path to a file where the report can be saved.
|
||||
|
||||
For example, enter:
|
||||
|
||||
@ -225,7 +225,7 @@ To generate the XML migration rules file for a source computer:
|
||||
|
||||
### The GenerateDocPatterns function
|
||||
|
||||
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.
|
||||
The `MigDocs.xml` file calls the `GenerateDocPatterns` function, which takes three Boolean values. The settings can be changed to modify the way the `MigDocs.xml` file generates the XML rules for migration.
|
||||
|
||||
- `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.
|
||||
|
||||
@ -355,11 +355,11 @@ In the following examples, the source computer has a **.txt** file called `new t
|
||||
|Rule 1|`<pattern type="File">d:\new folder[new text document.txt]</pattern>`|
|
||||
|Rule 2|`<pattern type="File">d:\new folder[]</pattern>`|
|
||||
|
||||
To exclude the new text `document.txt` file and any **.txt** files in `new folder`, you can do the following modification:
|
||||
To exclude the new text `document.txt` file and any **.txt** files in `new folder`, the following modifications can be made:
|
||||
|
||||
#### Example 1: Exclude all .txt files in a folder
|
||||
|
||||
To exclude Rule 1, there needs to be an exact match of the file name. However, for Rule 2, you can create a pattern to exclude files by using the file name extension.
|
||||
To exclude Rule 1, there needs to be an exact match of the file name. However, for Rule 2, a pattern can be created to exclude files by using the file name extension.
|
||||
|
||||
```xml
|
||||
<exclude>
|
||||
@ -372,7 +372,7 @@ To exclude Rule 1, there needs to be an exact match of the file name. However, f
|
||||
|
||||
#### Example 2: Use the UnconditionalExclude element to give a rule precedence over include rules
|
||||
|
||||
If you don't know the file name or location of the file, but you do know the file name extension, you can use the `GenerateDrivePatterns` function. However, the rule is less specific than the default include rule generated by the `MigDocs.xml` file, so it doesn't have precedence. You must use the \<UnconditionalExclude\> element to give this rule precedence over the default include rule. For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
If the file name or location of the file isn't known, but the file name extension is known, the `GenerateDrivePatterns` function can be used. However, the rule is less specific than the default include rule generated by the `MigDocs.xml` file, so it doesn't have precedence. The \<UnconditionalExclude\> element must be used to give this rule precedence over the default include rule. For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
|
||||
|
||||
```xml
|
||||
<unconditionalExclude>
|
||||
@ -384,7 +384,7 @@ If you don't know the file name or location of the file, but you do know the fil
|
||||
|
||||
#### Example 3: Use a UserandSystem context component to run rules in both contexts
|
||||
|
||||
If you want the **\<UnconditionalExclude\>** element to apply to both the system and user context, you can create a third component using the **UserandSystem** context. Rules in this component run in both contexts.
|
||||
To apply the **\<UnconditionalExclude\>** element to both the system and user context, a third component can be created using the **UserandSystem** context. Rules in this component run in both contexts.
|
||||
|
||||
```xml
|
||||
<component type="Documents" context="UserandSystem">
|
||||
@ -401,11 +401,11 @@ If you want the **\<UnconditionalExclude\>** element to apply to both the system
|
||||
</component>
|
||||
```
|
||||
|
||||
For more examples of exclude rules that you can use in custom migration XML files, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md).
|
||||
For more examples of exclude rules that can be used in custom migration XML files, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md).
|
||||
|
||||
### Include rules usage examples
|
||||
|
||||
The application data directory is the most common location that you would need to add an include rule for. The `GenerateDocPatterns` function excludes this location by default. If the organization uses an application that saves important data to this location, you can create include rules to migrate the data. For example, the default location for **.pst** files is: `%CSIDL_LOCAL_APPDATA%\Microsoft\Outlook`. The `MigApp.xml` file contains migration rules to move only those **.pst** files that are linked to Microsoft Outlook. To include **.pst** files that aren't linked, you can do the following modification:
|
||||
The application data directory is the most common location that an include rule would need to be added for. The `GenerateDocPatterns` function excludes this location by default. If the organization uses an application that saves important data to this location, include rules can be created to migrate the data. For example, the default location for **.pst** files is: `%CSIDL_LOCAL_APPDATA%\Microsoft\Outlook`. The `MigApp.xml` file contains migration rules to move only those **.pst** files that are linked to Microsoft Outlook. To include **.pst** files that aren't linked, the following modification can be made:
|
||||
|
||||
#### Example 1: Include a file name extension in a known user folder
|
||||
|
||||
@ -421,7 +421,7 @@ This rule includes **.pst** files that are located in the default location, but
|
||||
|
||||
#### Example 2: Include a file name extension in Program Files
|
||||
|
||||
For locations outside the user profile, such as the Program Files folder, you can add the rule to the system context component.
|
||||
For locations outside the user profile, such as the Program Files folder, the rule can be added to the system context component.
|
||||
|
||||
```xml
|
||||
<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
|
||||
@ -431,7 +431,7 @@ For locations outside the user profile, such as the Program Files folder, you ca
|
||||
</include>
|
||||
```
|
||||
|
||||
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).
|
||||
For more examples of include rules that can be used in custom migration XML files, see [Include Files and Settings](usmt-include-files-and-settings.md).
|
||||
|
||||
> [!TIP]
|
||||
>
|
||||
@ -439,9 +439,9 @@ For more examples of include rules that you can use in custom migration XML file
|
||||
|
||||
## 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're applied to the destination computer.
|
||||
Additional rules for the migration can be included in the `MigDocs.xml` file or other XML migration files. For example, the `<locationModify>` element can be used to move files from the folder where they were gathered to a different folder, when they're applied to the destination computer.
|
||||
|
||||
You can use an XML schema (MigXML.xsd) file to validate the syntax of the customized XML files. For more information, see [USMT Resources](usmt-resources.md).
|
||||
An XML schema (`MigXML.xsd`) file can be used to validate the syntax of the customized XML files. For more information, see [USMT Resources](usmt-resources.md).
|
||||
|
||||
## Related articles
|
||||
|
||||
|
||||
@ -25,7 +25,7 @@ This article discusses general and security-related best practices when using Us
|
||||
|
||||
- **Don't use MigUser.xml and MigDocs.xml together.**
|
||||
|
||||
If you use both **.xml** files, some migrated files can be duplicated if conflicting instructions are given about target locations. You can use the `/genmigxml` command-line option to determine which files are included in the migration, and to determine if any modifications are necessary. For more information, see [Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md).
|
||||
If both `MigUser.xml` and `MigDocs.xml` are used together, some migrated files can be duplicated if conflicting instructions are given about target locations. The `/genmigxml` command-line option can be used to determine which files are included in the migration, and to determine if any modifications are necessary. For more information, see [Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md).
|
||||
|
||||
- **Use MigDocs.xml for a better migration experience.**
|
||||
|
||||
@ -33,27 +33,27 @@ This article discusses general and security-related best practices when using Us
|
||||
|
||||
- **Close all applications before running either the ScanState or LoadState tools.**
|
||||
|
||||
Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch, USMT fails when it can't migrate a file or setting. When you use the `/c` option, USMT ignores any files or settings that it can't migrate and log an error each time.
|
||||
Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch, USMT fails when it can't migrate a file or setting. When the `/c` option is used, USMT ignores any files or settings that it can't migrate and log an error each time.
|
||||
|
||||
- **Log off after you run the LoadState.**
|
||||
- **Log off after running the LoadState.**
|
||||
|
||||
Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, you should sign out after you run the LoadState tool.
|
||||
Some settings, such as fonts, wallpaper, and screensaver settings, won't take effect until the next time the user logs on. For this reason, sign out after running the LoadState tool.
|
||||
|
||||
- **Managed environment.**
|
||||
|
||||
To create a managed environment, you can move all of the end user's documents into **Documents** folder (%CSIDL\_PERSONAL%). Microsoft recommends that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders helps to clean up files on the destination computer if the `LoadState.exe` command fails before completion.
|
||||
To create a managed environment, all of the end user's documents can be moved into the **Documents** folder (%CSIDL\_PERSONAL%). Microsoft recommends migrating files into the smallest-possible number of folders on the destination computer. Minimizing folders helps to clean up files on the destination computer if the `LoadState.exe` command fails before completion.
|
||||
|
||||
- **Chkdsk.exe.**
|
||||
|
||||
Microsoft recommends that you run **Chkdsk.exe** before running the ScanState and LoadState tools. **Chkdsk.exe** creates a status report for a hard disk drive and lists and corrects common errors. For more information about the **Chkdsk.exe** tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)).
|
||||
Microsoft recommends running **Chkdsk.exe** before running the ScanState and LoadState tools. **Chkdsk.exe** creates a status report for a hard disk drive and lists and corrects common errors. For more information about the **Chkdsk.exe** tool, see [Chkdsk](/previous-versions/windows/it-pro/windows-xp/bb490876(v=technet.10)).
|
||||
|
||||
- **Migrate in groups.**
|
||||
|
||||
If you decide to perform the migration while users are using the network, it's best to migrate user accounts in groups. To minimize the effect on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to the plan between groups.
|
||||
If the migration is performed while users are using the network, it's best to migrate user accounts in groups. To minimize the effect on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows making sure each phase is successful before starting the next phase. When this method is used, any necessary modifications can be made to the plan between groups.
|
||||
|
||||
## Security best practices
|
||||
|
||||
As the authorized administrator, it's the responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues:
|
||||
As the authorized administrator, it's the responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, the following issues must be considered:
|
||||
|
||||
- **Encrypting File System (EFS).**
|
||||
|
||||
@ -61,7 +61,7 @@ As the authorized administrator, it's the responsibility to protect the privacy
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> If you migrate an encrypted file without also migrating the certificate, end users won't be able to access the file after the migration.
|
||||
> If an encrypted file is migrated without also migrating the certificate, end users won't be able to access the file after the migration.
|
||||
|
||||
- **Encrypt the store.**
|
||||
|
||||
@ -69,11 +69,11 @@ As the authorized administrator, it's the responsibility to protect the privacy
|
||||
|
||||
- **Virus Scan.**
|
||||
|
||||
Microsoft recommends that you scan both the source and destination computers for viruses before running USMT. In addition, you should scan the destination computer image. To help protect data from viruses, Microsoft strongly recommends running an antivirus utility before migration.
|
||||
Microsoft recommends scanning both the source and destination computers for viruses before running USMT. In addition, the destination computer image should be scanned. To help protect data from viruses, Microsoft strongly recommends running an antivirus utility before migration.
|
||||
|
||||
- **Maintain security of the file server and the deployment server.**
|
||||
|
||||
Microsoft recommends that you manage the security of the file and deployment servers. It's important to make sure that the file server where you save the store is secure. You must also secure the deployment server, to ensure that the user data that is in the log files isn't exposed. Microsoft also recommends that you only transmit data over a secure Internet connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://www.microsoft.com/download/details.aspx?id=53353).
|
||||
Microsoft recommends managing the security of the file and deployment servers. It's important to make sure that the file server where the store is saved is secure. The deployment server must also be secured to ensure that the user data that is in the log files isn't exposed. Microsoft also recommends to only transmit data over a secure network connection, such as a virtual private network. For more information about network security, see [Microsoft Security Compliance Manager](https://www.microsoft.com/download/details.aspx?id=53353).
|
||||
|
||||
- **Password Migration.**
|
||||
|
||||
@ -81,13 +81,13 @@ As the authorized administrator, it's the responsibility to protect the privacy
|
||||
|
||||
- **Local Account Creation.**
|
||||
|
||||
Before you migrate local accounts, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) article.
|
||||
Before local accounts are migrated, see the Migrating Local Accounts section in the [Identify Users](usmt-identify-users.md) article.
|
||||
|
||||
## XML file best practices
|
||||
|
||||
- **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools.**
|
||||
|
||||
If you used a particular set of mig\*.xml files in the ScanState tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the LoadState tool.
|
||||
If a particular set of mig\*.xml files are used with the ScanState tool, either called through the `/auto` option, or individually through the `/i` option, then the same option should be used to call the exact same mig\*.xml files in the LoadState tool.
|
||||
|
||||
- **The \<CustomFileName\> in the migration urlid should match the name of the file.**
|
||||
|
||||
@ -108,7 +108,7 @@ As the authorized administrator, it's the responsibility to protect the privacy
|
||||
|
||||
- **Consider the impact on performance when using the \<context\> parameter.**
|
||||
|
||||
The migration performance can be affected when you use the **\<context\>** element with the **\<component\>** element; for example, as in when you want to encapsulate logical units of file- or path-based **\<include\>** and **\<exclude\>** rules.
|
||||
The migration performance can be affected when the **\<context\>** element is used with the **\<component\>** element. For example, when encapsulating logical units of file- or path-based **\<include\>** and **\<exclude\>** rules.
|
||||
|
||||
In the **User** context, a rule is processed one time for each user on the system.
|
||||
|
||||
@ -120,15 +120,15 @@ As the authorized administrator, it's the responsibility to protect the privacy
|
||||
>
|
||||
> The number of times a rule is processed doesn't affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once.
|
||||
|
||||
- **Microsoft recommends that you create a separate .xml file instead of adding .xml code to one of the existing migration .xml files.**
|
||||
- **Microsoft recommends to create a separate .xml file instead of adding .xml code to one of the existing migration .xml files.**
|
||||
|
||||
For example, if you have code that migrates the settings for an application, you shouldn't just add the code to the `MigApp.xml` file.
|
||||
For example, for code that migrates the settings for an application, the code shouldn't just be added to the `MigApp.xml` file.
|
||||
|
||||
- **You should not create custom .xml files to alter the operating system settings that are migrated.**
|
||||
- **Custom .xml files shouldn't be created to alter the operating system settings that are migrated.**
|
||||
|
||||
Manifest files determine what settings are migrated. Manifest files can't be modified. Since manifest files can't be modified, to exclude certain operating system settings from the migration, create and modify a `Config.xml` file instead.
|
||||
|
||||
- **You can use the asterisk (\*) wildcard character in any migration XML file that you create.**
|
||||
- **The asterisk (\*) wildcard character can be used in any migration XML file that is created.**
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# Common Migration Scenarios
|
||||
|
||||
You use the User State Migration Tool (USMT) when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing from a source computer the following user's items:
|
||||
The User State Migration Tool (USMT) can be used when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing from a source computer the following user's items:
|
||||
|
||||
- Operating-system settings.
|
||||
- Application settings.
|
||||
@ -33,44 +33,44 @@ The following diagram shows a PC-refresh migration, also known as a computer ref
|
||||
|
||||
### Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
|
||||
|
||||
A company receives funds to update the operating system on all of its computers in the accounting department to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
|
||||
An organization receives funds to update the operating system on all of its computers in the accounting department to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. On each computer, the administrator boots the machine into WinPE and runs the **ScanState** command-line tool, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
|
||||
|
||||
1. On each computer, the administrator installs the company's standard operating environment (SOE) which includes the latest supported version of Windows and other company applications.
|
||||
1. On each computer, the administrator installs the organization's standard operating environment (SOE) which includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back to each computer.
|
||||
|
||||
### Scenario Two: PC-refresh using a compressed migration store
|
||||
|
||||
A company receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
|
||||
An organization receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
|
||||
|
||||
1. The administrator runs the **ScanState** command-line tool on each computer. **ScanState** saves each user state to a server.
|
||||
|
||||
1. On each computer, the administrator installs the company's standard SOE that includes the latest supported version of Windows and other company applications.
|
||||
1. On each computer, the administrator installs the organization's standard SOE that includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. The administrator runs the **LoadState** command-line tool on each source computer, and **LoadState** restores each user state back to the computer.
|
||||
|
||||
### Scenario Three: PC-refresh using a hard-link migration store
|
||||
|
||||
A company receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
|
||||
An organization receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. The administrator runs the **ScanState** command-line tool on each computer, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
|
||||
|
||||
1. On each computer, the administrator installs the company's SOE that includes the latest supported version of Windows and other company applications.
|
||||
1. On each computer, the administrator installs the organization's SOE that includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back on each computer.
|
||||
|
||||
### Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store
|
||||
|
||||
A company decides to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses **Windows.old** and a hard-link migration store to save each user state to their respective computer.
|
||||
An organization decides to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses **Windows.old** and a hard-link migration store to save each user state to their respective computer.
|
||||
|
||||
1. The administrator clean installs the latest supported version of Windows on each computer. During the install, they make sure that the **Windows.old** directory is created by taking the following actions:
|
||||
|
||||
- Performing the install without formatting or repartitioning the disk.
|
||||
- Selecting a partition that contains the previous version of Windows.
|
||||
|
||||
1. On each computer, the administrator installs the company's SOE that includes company applications.
|
||||
1. On each computer, the administrator installs the organization's SOE that includes organization applications.
|
||||
|
||||
1. The administrator runs the **ScanState** and **LoadState** command-line tools successively on each computer while specifying the `/hardlink /nocompress` command-line options.
|
||||
|
||||
@ -82,33 +82,33 @@ The following diagram shows a PC-replacement migration. First, the administrator
|
||||
|
||||
### Scenario One: Offline migration using Windows PE and an external migration store
|
||||
|
||||
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer with their files and settings. In this scenario, migration is being handled offline, without a network connection.
|
||||
An organization is allocating 20 new computers to users in the accounting department. The users each have a source computer with their files and settings. In this scenario, migration is being handled offline, without a network connection.
|
||||
|
||||
1. On each source computer, an administrator boots the machine into WinPE and runs **ScanState** to collect the user state to either a server or an external hard disk.
|
||||
|
||||
1. On each new computer, the administrator installs the company's SOE that includes the latest supported version of Windows and other company applications.
|
||||
1. On each new computer, the administrator installs the organization's SOE that includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. On each of the new computers, the administrator runs the **LoadState** tool, restoring each user state from the migration store to one of the new computers.
|
||||
|
||||
### Scenario Two: Manual network migration
|
||||
|
||||
A company receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the **ScanState** tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
|
||||
An organization receives 50 new laptops for their managers and needs to reallocate 50 older laptops to new employees. In this scenario, an administrator runs the **ScanState** tool from the cmd prompt on each computer to collect the user states and save them to a server in a compressed migration store.
|
||||
|
||||
1. The administrator runs the **ScanState** tool on each of the manager's old laptops, and saves each user state to a server.
|
||||
|
||||
1. On the new laptops, the administrator installs the company's SOE, which includes the latest supported version of Windows and other company applications.
|
||||
1. On the new laptops, the administrator installs the organization's SOE, which includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. The administrator runs the **LoadState** tool on the new laptops to migrate the managers' user states to the appropriate computer. The new laptops are now ready for the managers to use.
|
||||
|
||||
1. On the old computers, the administrator installs the company's SOE, which includes the latest supported version of Windows, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
|
||||
1. On the old computers, the administrator installs the organization's SOE, which includes the latest supported version of Windows, Microsoft Office, and other organization applications. The old computers are now ready for the new employees to use.
|
||||
|
||||
### Scenario Three: Managed network migration
|
||||
|
||||
A company is allocating 20 new computers to users in the accounting department. The users each have a source computer that contains their files and settings. An administrator uses a management technology such as a sign-in script or a batch file to run **ScanState** on each source computer to collect the user states and save them to a server in a compressed migration store.
|
||||
An organization is allocating 20 new computers to users in the accounting department. The users each have a source computer that contains their files and settings. An administrator uses a management technology such as a sign-in script or a batch file to run **ScanState** on each source computer to collect the user states and save them to a server in a compressed migration store.
|
||||
|
||||
1. On each source computer, the administrator runs the **ScanState** tool using Microsoft Configuration Manager, Microsoft Deployment Toolkit (MDT), a sign-in script, a batch file, or a non-Microsoft management technology. **ScanState** collects the user state from each source computer and then saves it to a server.
|
||||
|
||||
1. On each new computer, the administrator installs the company's SOE, which includes the latest supported version of Windows and other company applications.
|
||||
1. On each new computer, the administrator installs the organization's SOE, which includes the latest supported version of Windows and other organization applications.
|
||||
|
||||
1. On each of the new computers, the administrator runs the **LoadState** tool using Microsoft Configuration Manager, a sign-in script, a batch file, or a non-Microsoft management technology. **LoadState** migrates each user state from the migration store to one of the new computers.
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Config.xml File
|
||||
description: Learn how the Config.xml file is an optional User State Migration Tool (USMT) file that you can create using the /genconfig option with the ScanState.exe tool.
|
||||
description: Learn how the Config.xml file is an optional User State Migration Tool (USMT) file that can be created using the /genconfig option with the ScanState.exe tool.
|
||||
manager: aaroncz
|
||||
ms.author: frankroj
|
||||
ms.prod: windows-client
|
||||
@ -15,11 +15,11 @@ appliesto:
|
||||
|
||||
# Config.xml File
|
||||
|
||||
The `Config.xml` file is an optional User State Migration Tool (USMT) file that you can create using the `/genconfig` option with the ScanState tool. If you want to include all of the default components, and don't want to change the default store-creation or profile-migration behavior, you don't need to create a `Config.xml` file.
|
||||
The `Config.xml` file is an optional User State Migration Tool (USMT) file that can be created using the `/genconfig` option with the ScanState tool. If all of the default components should be included and no changes need to be made to the default store-creation or profile-migration behavior, a `Config.xml` file doesn't need to be created.
|
||||
|
||||
However, if you're 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's necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
|
||||
However, if the default migration behavior defined in the `MigApp.xml`, `MigUser.xml` and `MigDocs.xml` files is satisfactory, but certain components need to be excluded, a `Config.xml` file can be created and modified while leaving the other **.xml** files unchanged. For example, a `Config.xml` file must be created to exclude any of the operating-system settings that are migrated. It's necessary to create and modify the `Config.xml` file to change any of the default store-creation or profile-migration behavior.
|
||||
|
||||
The `Config.xml` file has a different format than the other migration **.xml** files, because it doesn't contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, and user-profile policy and error-control policy. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files, because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in this file.
|
||||
The `Config.xml` file has a different format than the other migration **.xml** files, because it doesn't contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, and user-profile policy and error-control policy. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files, because familiarization with the migration rules and syntax isn't needed. However, wildcard characters can't be used in this file.
|
||||
|
||||
For more information about using the `Config.xml` file with other migration files, such as the `MigDocs.xml` and `MigApps.xml` files, see [Understanding Migration XML Files](understanding-migration-xml-files.md).
|
||||
|
||||
@ -29,7 +29,7 @@ For more information about using the `Config.xml` file with other migration file
|
||||
|
||||
## Migration Policies
|
||||
|
||||
In USMT, there are migration policies that can be configured in the `Config.xml` file. For example, you can configure **\<ErrorControl\>**, **\<ProfileControl\>**, and **\<HardLinkStoreControl\>** options. The following elements and parameters are for use in the `Config.xml` file only.
|
||||
In USMT, there are migration policies that can be configured in the `Config.xml` file. For example, **\<ErrorControl\>**, **\<ProfileControl\>**, and **\<HardLinkStoreControl\>** options can be configured. The following elements and parameters are for use in the `Config.xml` file only.
|
||||
|
||||
### \<Policies\>
|
||||
|
||||
@ -43,7 +43,7 @@ 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.
|
||||
The **\<ErrorControl\>** element is an optional element that can be configured 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, a path can be specified using the (\*) wildcard character.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
|
||||
@ -75,7 +75,7 @@ Additionally, the order in the **\<ErrorControl\>** section implies priority. In
|
||||
|
||||
> [!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.
|
||||
> 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, a path using the (\*) wildcard character can be specified.
|
||||
|
||||
### \<fatal\>
|
||||
|
||||
@ -97,7 +97,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|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.
|
||||
The **\<fatal\>** element can be used to specify that errors matching a specific pattern should cause USMT to halt the migration.
|
||||
|
||||
### \<fileError\>
|
||||
|
||||
@ -115,7 +115,7 @@ Syntax:
|
||||
<fileError> </fileError>
|
||||
```
|
||||
|
||||
You use the **\<fileError\>** element to represent the behavior associated with file errors.
|
||||
The **\<fileError\>** element can be used to represent the behavior associated with file errors.
|
||||
|
||||
### \<nonFatal\>
|
||||
|
||||
@ -137,7 +137,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|**\<errorCode\>**|No|"any" or "*specify system error message*". If system error messages aren't 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 shouldn't cause USMT to halt the migration.
|
||||
The **\<nonFatal\>** element can be used to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
|
||||
|
||||
### \<registryError\>
|
||||
|
||||
@ -159,7 +159,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|**\<errorCode\>**|No|"any" or "*specify system error message here*". If system error messages aren't 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 shouldn't cause USMT to halt the migration.
|
||||
The **\<registryError\>** element can be used to specify that errors matching a specific pattern shouldn't cause USMT to halt the migration.
|
||||
|
||||
### \<HardLinkStoreControl\>
|
||||
|
||||
@ -303,7 +303,7 @@ Syntax:
|
||||
|
||||
## Sample Config.xml File
|
||||
|
||||
The following sample `Config.xml` file contains detailed examples about items you can choose to exclude from a migration.
|
||||
The following sample `Config.xml` file contains detailed examples about items that can be excluded from a migration.
|
||||
|
||||
<br>
|
||||
<br>
|
||||
|
||||
@ -15,19 +15,19 @@ appliesto:
|
||||
|
||||
# Conflicts and precedence
|
||||
|
||||
When you include, exclude, and reroute files and settings, it's important to know how User State Migration Tool (USMT) deals with conflicts and precedence. The following are the most important conflicts and precedence guidelines to keep in mind when working with USMT.
|
||||
When including, excluding, and rerouting files and settings, it's important to know how User State Migration Tool (USMT) deals with conflicts and precedence. The following are the most important conflicts and precedence guidelines to keep in mind when working with USMT.
|
||||
|
||||
- **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?](#what-happens-when-there-are-conflicting-include-and-exclude-rules) and the first example in [\<include\> and \<exclude\> rules precedence examples](#include-and-exclude-rules-precedence-examples) later in this article.
|
||||
|
||||
- **Only rules inside the same component can affect each other, depending on specificity.** Rules that are in different components don't affect each other, except for the **\<unconditionalExclude\>** rule.
|
||||
|
||||
- **If the rules are equally specific, \<exclude\> takes precedence over \<include\>.** For example, if you use the **\<exclude\>** rule to exclude a file and use the **\<include\>** rule to include the same file, the file is excluded.
|
||||
- **If the rules are equally specific, \<exclude\> takes precedence over \<include\>.** For example, if the **\<exclude\>** rule is used to exclude a file and use the **\<include\>** rule to include the same file, the file is excluded.
|
||||
|
||||
- **The ordering of components does not matter.** It doesn't matter which components are listed in which **.xml** file, because each component is processed independently of the other components across all of the **.xml** files.
|
||||
|
||||
- **The ordering of the \<include\> and \<exclude\> rules within a component does not matter.**
|
||||
|
||||
- **You can use the \<unconditionalExclude\> element to globally exclude data.** This element excludes objects, regardless of any other **\<include\>** rules that are in the **.xml** files. For example, you can use the **\<unconditionalExclude\>** element to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`.
|
||||
- **The \<unconditionalExclude\> element can be used to globally exclude data.** This element excludes objects, regardless of any other **\<include\>** rules that are in the **.xml** files. For example, the **\<unconditionalExclude\>** element can be used to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`.
|
||||
|
||||
## General
|
||||
|
||||
@ -35,7 +35,7 @@ When you include, exclude, and reroute files and settings, it's important to kno
|
||||
|
||||
Only rules inside the same component can affect each other, depending on specificity, except for the **\<unconditionalExclude\>** rule. Rules that are in different components don't affect each other. If there's an **\<include\>** rule in one component and an identical **\<exclude\>** rule in another component, the data is migrated because the two rules are independent of each other.
|
||||
|
||||
If you have an **\<include\>** rule in one component and a **\<locationModify\>** rule in another component for the same file, the file is migrated in both places. That is, the file is included based on the **\<include\>** rule, and the file is migrated based on the **\<locationModify\>** rule.
|
||||
If an **\<include\>** rule is in one component and a **\<locationModify\>** rule is in another component for the same file, the file is migrated in both places. That is, the file is included based on the **\<include\>** rule, and the file is migrated based on the **\<locationModify\>** rule.
|
||||
|
||||
The following **.xml** file migrates all files from C:\\Userdocs, including **.mp3** files, because the **\<exclude\>** rule is specified in a separate component.
|
||||
|
||||
@ -71,7 +71,7 @@ The following **.xml** file migrates all files from C:\\Userdocs, including **.m
|
||||
|
||||
### How does precedence work with the Config.xml file?
|
||||
|
||||
Specifying `migrate="no"` in the `Config.xml` file is the same as deleting the corresponding component from the migration **.xml** file. However, if you set `migrate="no"` for the **Documents** folder, but you have a rule similar to the following rule in a migration **.xml** file (which includes all of the **.doc** files from the **Documents** folder), then only the **.doc** files is migrated, and all other files are excluded.
|
||||
Specifying `migrate="no"` in the `Config.xml` file is the same as deleting the corresponding component from the migration **.xml** file. However, if `migrate="no"` is set for the **Documents** folder, but a rule similar to the following rule exists in a migration **.xml** file (which includes all of the **.doc** files from the **Documents** folder), then only the **.doc** files is migrated, and all other files are excluded:
|
||||
|
||||
```xml
|
||||
<include>
|
||||
@ -83,7 +83,7 @@ Specifying `migrate="no"` in the `Config.xml` file is the same as deleting the c
|
||||
|
||||
### How does USMT process each component in an .xml file with multiple components?
|
||||
|
||||
The ordering of components doesn't matter. Each component is processed independently of other components. For example, if you have an **\<include\>** rule in one component and a **\<locationModify\>** rule in another component for the same file, the file is migrated in both places. That is, the file is included based on the **\<include\>** rule, and the file is migrated based on the **\<locationModify\>** rule.
|
||||
The ordering of components doesn't matter. Each component is processed independently of other components. For example, if an **\<include\>** rule is in one component and a **\<locationModify\>** rule is in another component for the same file, the file is migrated in both places. That is, the file is included based on the **\<include\>** rule, and the file is migrated based on the **\<locationModify\>** rule.
|
||||
|
||||
### How are rules processed?
|
||||
|
||||
@ -95,13 +95,13 @@ There are two broad categories of rules.
|
||||
|
||||
### How does USMT combine all of the .xml files that I specify on the command line?
|
||||
|
||||
USMT doesn't distinguish the **.xml** files based on their name or content. It processes each component within the files separately. USMT supports multiple **.xml** files only to make it easier to maintain and organize the components within them. Because USMT uses a urlid to distinguish each component from the others, be sure that each **.xml** file that you specify on the command line has a unique migration urlid.
|
||||
USMT doesn't distinguish the **.xml** files based on their name or content. It processes each component within the files separately. USMT supports multiple **.xml** files only to make it easier to maintain and organize the components within them. Because USMT uses a urlid to distinguish each component from the others, be sure that each **.xml** file that is specified on the command line has a unique migration urlid.
|
||||
|
||||
## 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 isn't migrated. For example if you exclude a file, and include the same file, the file isn't migrated. If there are conflicting rules within different components, the rules don't affect each other because each component is processed independently.
|
||||
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 isn't migrated. For example if the same file is both excluded and included, the file isn't migrated. If there are conflicting rules within different components, the rules don't affect each other because each component is processed independently.
|
||||
|
||||
In the following example, mp3 files aren't excluded from the migration. The mp3 files aren't excluded because directory names take precedence over the file extensions.
|
||||
|
||||
@ -128,7 +128,7 @@ These examples explain how USMT deals with **\<include\>** and **\<exclude\>** r
|
||||
|
||||
### Including and excluding files
|
||||
|
||||
| If you have the following code in the same component | Resulting behavior | Explanation |
|
||||
| If the following code exists in the same component | Resulting behavior | Explanation |
|
||||
|-----|-----|-----|
|
||||
| <ul><li>Include rule: \<pattern type="File"\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type="File"\>C:* [.txt]\</pattern\></li></ul> | Migrates all files and subfolders in Dir1 (including all **.txt** files in C:). | The **\<exclude\>** rule doesn't affect the migration because the **\<include\>** rule is more specific. |
|
||||
| <ul><li>Include rule: \<pattern type="File"\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type="File"\>C:\Dir1\Dir2* [.txt]\</pattern\></li></ul> | 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. |
|
||||
@ -137,7 +137,7 @@ These examples explain how USMT deals with **\<include\>** and **\<exclude\>** r
|
||||
| <ul><li>Include rule: C:\Dir1* [.txt]</li><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> | Migrates the **.txt** files in Dir1 and the **.txt** files from subfolders other than Dir2. <br>No files are migrated from Dir2 or its subfolders. | Both rules are processed as intended. |
|
||||
| <ul><li>Include rule: C:\Dir1\Dir2* []</li><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | 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 components | Resulting behavior | Explanation |
|
||||
| If the following code exists in different components | Resulting behavior | Explanation |
|
||||
|-----|----|----|
|
||||
| Component 1:<ul><li>Include rule: \<pattern type="File"\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type="File"\>C:\Dir1\Dir2* [.txt]\</pattern\></li></ul> <br>Component 2:<ul><li>Include rule: \<pattern type="File"\>C:\Dir1\Dir2* [.txt]\</pattern\></li><li>Exclude rule: \<pattern type="File"\>C:\Dir1* []\</pattern\></li></ul> | Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components don't 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:<ul><li>Include rule: C:\Dir1\Dir2* []</li></ul> <br>Component 2:<ul><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | Migrates all files and subfolders from Dir2 except the **.txt** files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
|
||||
@ -145,13 +145,13 @@ These examples explain how USMT deals with **\<include\>** and **\<exclude\>** r
|
||||
|
||||
### Including and excluding registry objects
|
||||
|
||||
| If you have the following code in the same component | Resulting behavior | Explanation |
|
||||
| If the following code exists in the same component | Resulting behavior | Explanation |
|
||||
|-----|-----|-----|
|
||||
| <ul><li>Include rule: <br>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude Rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor. | Both rules are processed as intended. |
|
||||
| <ul><li>Include rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude Rule: <br>HKLM\Software\Microsoft\Command Processor* []</li></ul> | Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor. | DefaultColor is migrated because the **\<include\>** rule is more specific than the **\<exclude\>** rule. |
|
||||
| <ul><li>Include rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Doesn't 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 components | Resulting behavior | Explanation |
|
||||
| If the following code exists in different components | Resulting behavior | Explanation |
|
||||
|-----|-----|-----|
|
||||
| Component 1:<ul><li>Include rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br>HKLM\Software\Microsoft\Command Processor* []</li></ul> <br>Component 2:<ul><li>Include rule: <br>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude rule: <br>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor. | Rules that are in different components don't affect each other, except for the **\<unconditionalExclude\>** rule. In this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. |
|
||||
|
||||
@ -163,7 +163,7 @@ If there isn't a **\<merge\>** rule, the default behavior for the registry is fo
|
||||
|
||||
### How does the \<merge\> rule work when there are file collisions?
|
||||
|
||||
When a collision is detected, USMT selects the most specific **\<merge\>** rule and apply it to resolve the conflict. For example, if you have a **\<merge\>** rule for **C:\\\* \[\*\]** set to **sourcePriority()** and another **\<merge\>** rule for **C:\\subfolder\\\* \[\*\]** set to **destinationPriority()** , then USMT uses the **destinationPriority()** rule because it's the most specific.
|
||||
When a collision is detected, USMT selects the most specific **\<merge\>** rule and apply it to resolve the conflict. For example, if a **\<merge\>** rule exists for **C:\\\* \[\*\]** set to **sourcePriority()** and another **\<merge\>** rule for **C:\\subfolder\\\* \[\*\]** set to **destinationPriority()** , then USMT uses the **destinationPriority()** rule because it's the most specific.
|
||||
|
||||
### Example scenario
|
||||
|
||||
@ -181,7 +181,7 @@ The destination computer contains the following files:
|
||||
|
||||
- `C:\Data\SampleB.txt`
|
||||
|
||||
You have a custom **.xml** file that contains the following code:
|
||||
A custom **.xml** file contains the following code:
|
||||
|
||||
```xml
|
||||
<include>
|
||||
|
||||
@ -17,9 +17,9 @@ appliesto:
|
||||
|
||||
## Overview
|
||||
|
||||
If you want the ScanState and LoadState tools to use any of the migration **.xml** files, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the **.xml** files to control the migration, specify the same set of **.xml** files for both the `ScanState.exe` and `LoadState.exe` commands. However, the `Config.xml` file with the `/config` option doesn't need to be specified, unless some of the migrated files and settings from the store need to be excluded. For example, you might want to migrate the **Documents** folder to the store but not to the destination computer. To achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. The `LoadState.exe` command then migrates only the files and settings that you want to migrate.
|
||||
To use any of the migration **.xml** files with the ScanState and LoadState tools, specify these files at the command line using the `/i` option. Because the ScanState and LoadState tools need the **.xml** files to control the migration, specify the same set of **.xml** files for both the `ScanState.exe` and `LoadState.exe` commands. However, the `Config.xml` file with the `/config` option doesn't need to be specified, unless some of the migrated files and settings from the store need to be excluded. For example, to migrate the **Documents** folder to the store but not to the destination computer. To achieve this scenario, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. The `LoadState.exe` command then only migrates the desired files and settings.
|
||||
|
||||
If you leave out an **.xml** file from the `LoadState.exe` command, all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified with the `ScanState.exe` command don't apply. For example, if you leave out an **.xml** file, and it contains a rerouting rule such as:
|
||||
If an **.xml** file is left out from the `LoadState.exe` command, all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified with the `ScanState.exe` command don't apply. For example, if an **.xml** file is left out, and it contains a rerouting rule such as:
|
||||
|
||||
`MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`
|
||||
|
||||
@ -27,11 +27,11 @@ USMT doesn't reroute the files, and they're migrated to `C:\data`.
|
||||
|
||||
To modify the migration, do one or more of the following.
|
||||
|
||||
- **Modify the migration .xml files.** If you want to exclude a portion of a component, modify the **.xml** files. For example, to migrate C:\\ but exclude all of the **.mp3** files, or to move data to a new location on the destination computer. To modify these files, you must be familiar with the migration rules and syntax. If you want ScanState and LoadState to use these files, specify them at the command line when each command is entered.
|
||||
- **Modify the migration .xml files.** To exclude a portion of a component, modify the **.xml** files. For example, to migrate C:\\ but exclude all of the **.mp3** files, or to move data to a new location on the destination computer. To modify these files, familiarity with the migration rules and syntax is a must. For ScanState and LoadState to use these files, specify them at the command line when each command is entered.
|
||||
|
||||
- **Create a custom .xml file.** You can also create a custom **.xml** file to migrate settings for another application, or to change the migration behavior to suit the organization's needs. For ScanState and LoadState to use this file, specify them on both command lines.
|
||||
- **Create a custom .xml file.** A custom **.xml** file can also be created to migrate settings for another application, or to change the migration behavior to suit the organization's needs. For ScanState and LoadState to use this file, specify them on both command lines.
|
||||
|
||||
- **Create and modify a Config.xml file.** Create and modify a `Config.xml` file if you want to exclude an entire component from the migration. For example, you can use a `Config.xml` file to exclude the entire **Documents** folder, or exclude the settings for an application. Excluding components using a `Config.xml` file is easier than modifying the migration **.xml** files because you don't need to be familiar with the migration rules and syntax. In addition, using a `Config.xml` file is the only way to exclude the operating system settings from being migrated.
|
||||
- **Create and modify a Config.xml file.** Create and modify a `Config.xml` file to exclude an entire component from the migration. For example, a `Config.xml` file can be used to exclude the entire **Documents** folder, or exclude the settings for an application. Excluding components using a `Config.xml` file is easier than modifying the migration **.xml** files because familiarity with the migration rules and syntax isn't needed. In addition, using a `Config.xml` file is the only way to exclude the operating system settings from being migrated.
|
||||
|
||||
For more information about excluding data, see the [Exclude Files and Settings](usmt-exclude-files-and-settings.md) article.
|
||||
|
||||
@ -41,13 +41,13 @@ This section describes the migration **.xml** files that are included with USMT.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> You can use the asterisk (\*) wildcard character in each of these files. However, you can't use a question mark (?) as a wildcard character.
|
||||
> The asterisk (\*) wildcard character can be used in each of these files. However, a question mark (?) can't be used as a wildcard character.
|
||||
|
||||
- **The MigApp.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate application settings.
|
||||
|
||||
- **The MigDocs.xml file.** Specify this file with both the ScanState and LoadState tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it doesn't find and migrate any application data, program files, or any files in the Windows directory. You can modify the `MigDocs.xml` file.
|
||||
- **The MigDocs.xml file.** Specify this file with both the ScanState and LoadState tools to migrate all user folders and files that are found by the **MigXmlHelper.GenerateDocPatterns** helper function. This helper function finds user data that resides on the root of any drive and in the Users directory. However, it doesn't find and migrate any application data, program files, or any files in the Windows directory. The `MigDocs.xml` file can be modified.
|
||||
|
||||
- **The MigUser.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate user folders, files, and file types. You can modify the `MigUser.xml` file. This file doesn't contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the ScanState and the LoadState user options.
|
||||
- **The MigUser.xml file.** Specify this file with both the `ScanState.exe` and `LoadState.exe` commands to migrate user folders, files, and file types. The `MigUser.xml` file can be modified. This file doesn't contain rules that migrate specific user accounts. The only way to specify which user accounts to migrate is on the command line using the ScanState and the LoadState user options.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
@ -55,25 +55,25 @@ This section describes the migration **.xml** files that are included with USMT.
|
||||
|
||||
## Custom .xml files
|
||||
|
||||
Custom **.xml** files can be created to customize the migration for the organization's unique needs. For example, you might want to create a custom file to migrate a line-of-business application or to modify the default migration behavior. If you want `ScanState.exe` and `LoadState.exe` to use this file, specify it with both commands. For more information, see the [Custom XML examples](usmt-custom-xml-examples.md) article.
|
||||
Custom **.xml** files can be created to customize the migration for the organization's unique needs. For example, a custom **.xml** file can be created to migrate a line-of-business application or to modify the default migration behavior. For `ScanState.exe` and `LoadState.exe` to use this file, specify it with both commands. For more information, see the [Custom XML examples](usmt-custom-xml-examples.md) article.
|
||||
|
||||
## The Config.xml file
|
||||
|
||||
The `Config.xml` file is an optional file that you create using the `/genconfig` option with the `ScanState.exe` command. You should create and modify this file if you want to exclude certain components from the migration. In addition, you must create and modify this file if you want to exclude any of the operating system settings from being migrated. The `Config.xml` file format is different from the migration **.xml** files because it doesn't contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) article. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files. With the `Config.xml`, you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in a `Config.xml` file.
|
||||
The `Config.xml` file is an optional file that is created using the `/genconfig` option with the `ScanState.exe` command. This file should be created and modified to exclude certain components from the migration. In addition, this file must be created and modified to exclude any of the operating system settings from being migrated. The `Config.xml` file format is different from the migration **.xml** files because it doesn't contain any migration rules. It contains only a list of the operating system components, applications, and the user documents that can be migrated. For an example, see the [Config.xml File](usmt-configxml-file.md) article. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files. With the `Config.xml`, familiarity with the migration rules and syntax isn't. However, wildcard characters can't be used in a `Config.xml` file.
|
||||
|
||||
If you want to include all of the default components, you don't need to create the `Config.xml` file. Alternatively, if you're satisfied with the default migration behavior defined in the `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` files, and you want to exclude only some components, you can create and modify a `Config.xml` file and leave the other **.xml** files in their original state.
|
||||
To include all of the default components, a `Config.xml` file doesn't need to be created. Alternatively, if the default migration behavior defined in the `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` files are satisfactory, and only some components need to be excluded, a `Config.xml` file can be created. The other **.xml** files can be left in their original state.
|
||||
|
||||
When you run the `ScanState.exe` command with the `/genconfig` option, `ScanState.exe` reads the other **.xml** files that you specify using the `/i` option to create a custom list of components that can be migrated from the computer. This file contains only operating system components, applications, and the user document sections that are in both of the **.xml** files and that are installed on the computer when you run the `ScanState.exe` command with the `/genconfig` option. Therefore, you should create this file on a source computer that contains all of the components, applications, and settings that are present on the destination computers. Creating the file on the source computer ensures that this file contains every component that can be migrated. The components are organized into sections: \<Applications\>, \<WindowsComponents\>, and \<Documents\>. To choose not to migrate a component, change its entry to `migrate="no"`.
|
||||
When the `ScanState.exe` command is run with the `/genconfig` option, `ScanState.exe` reads the other **.xml** files that are specified using the `/i` option to create a custom list of components that can be migrated from the computer. This file contains only operating system components, applications, and the user document sections that are in both of the **.xml** files and that are installed on the computer when the `ScanState.exe` command is run with the `/genconfig` option. Therefore, this file should be created on a source computer that contains all of the components, applications, and settings that are present on the destination computers. Creating the file on the source computer ensures that this file contains every component that can be migrated. The components are organized into sections: \<Applications\>, \<WindowsComponents\>, and \<Documents\>. To choose not to migrate a component, change its entry to `migrate="no"`.
|
||||
|
||||
After you create this file, you need to specify it only with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if additional data that was migrated to the store needs to be excluded, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if you collected the **Documents** folder in the store, but you decide that you don't want to migrate the **Documents** folder to a destination computer, you can modify the `Config.xml` file to indicate `migrate="no"` before you run the `LoadState.exe` command, and the file aren't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article.
|
||||
After this file is created, it only needs to be specified with the `ScanState.exe` command using the `/Config` option for it to affect the migration. However, if additional data that was migrated to the store needs to be excluded, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. For example, if the **Documents** folder is collected in the store, but the **Documents** folder doesn't need to be migrated to a destination computer, the `Config.xml` file can be modified to indicate `migrate="no"` before the `LoadState.exe` command runs, and the file aren't be migrated. For more information about the precedence that takes place when excluding data, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article.
|
||||
|
||||
In addition, note the following functionality with the `Config.xml` file:
|
||||
|
||||
- If a parent component is removed from the migration in the `Config.xml` file by specifying `migrate="no"`, all of its child components are automatically removed from the migration, even if the child component is set to `migrate="yes"`.
|
||||
|
||||
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component is migrated.
|
||||
- If mistakenly two lines of code exist for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component is migrated.
|
||||
|
||||
- In USMT, there are several migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **\<ErrorControl\>**, **\<ProfileControl\>**, and **\<HardLinkStoreControl\>** options. For more information, see the [Config.xml File](usmt-configxml-file.md) article.
|
||||
- In USMT, there are several migration policies that can be configured in the `Config.xml` file. For example, additional **\<ErrorControl\>**, **\<ProfileControl\>**, and **\<HardLinkStoreControl\>** options can be configured. For more information, see the [Config.xml File](usmt-configxml-file.md) article.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
|
||||
@ -41,7 +41,7 @@ Using an SOE can vastly simplify the migration and reduce overall deployment cha
|
||||
|[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 need to be migrated 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)|For the following items that need to be migrated: <br><ul><li>File types.</li><li>Files.</li><li>Folders.</li><li>Settings.</li></ul> determine where these items might be located. For example:<ul><li>Standard default OS locations.</li><li>Company-specified locations.</li><li>Non-standard locations.</li></ul>|
|
||||
|[Identify file types, files, and folders](usmt-identify-file-types-files-and-folders.md)|For the following items that need to be migrated: <br><ul><li>File types.</li><li>Files.</li><li>Folders.</li><li>Settings.</li></ul> determine where these items might be located. For example:<ul><li>Standard default OS locations.</li><li>Organization-specified locations.</li><li>Non-standard locations.</li></ul>|
|
||||
|
||||
## Related articles
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Estimate Migration Store Size
|
||||
description: Estimate the disk space requirement for a migration so that you can use User State Migration Tool (USMT).
|
||||
description: Estimate the disk space requirement for a migration so that the User State Migration Tool (USMT) can be used.
|
||||
manager: aaroncz
|
||||
ms.author: frankroj
|
||||
ms.prod: windows-client
|
||||
@ -15,11 +15,11 @@ appliesto:
|
||||
|
||||
# Estimate migration store size
|
||||
|
||||
The disk space requirements for a migration are dependent on the size of the migration store and the type of migration. You can estimate the amount of disk space needed for computers in the organization based on information about the organization's infrastructure. You can also calculate the disk space requirements using the ScanState tool.
|
||||
The disk space requirements for a migration are dependent on the size of the migration store and the type of migration. The amount of disk space needed for computers in the organization can be estimated based on information about the organization's infrastructure. Disk space requirements can also be calculated using the ScanState tool.
|
||||
|
||||
## Hard disk space requirements
|
||||
|
||||
- **Store**: For non-hard-link migrations, ensure that there's enough available disk space at the location where the store is saved. The store contains the data being migrated. You can save the store to another partition, an external storage device such as a USB flash drive, or a server. For more information, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md).
|
||||
- **Store**: For non-hard-link migrations, ensure that there's enough available disk space at the location where the store is saved. The store contains the data being migrated. The store can be saved to another partition, an external storage device such as a USB flash drive, or a server. For more information, see [Choose a Migration Store Type](usmt-choose-migration-store-type.md).
|
||||
|
||||
- **Source Computer**: The source computer needs enough available space for the following items:
|
||||
|
||||
@ -41,7 +41,7 @@ The disk space requirements for a migration are dependent on the size of the mig
|
||||
|
||||
## Calculate disk space requirements using the ScanState tool
|
||||
|
||||
You can use the ScanState tool to calculate the disk space requirements for a particular compressed or uncompressed migration. It isn't necessary to estimate the migration store size for a hard-link migration since this method doesn't create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer might change during day-to-day use. For this reason, use the calculations as an estimate when planning the migration.
|
||||
The ScanState tool can be used to calculate the disk space requirements for a particular compressed or uncompressed migration. It isn't necessary to estimate the migration store size for a hard-link migration since this method doesn't create a separate migration store. The ScanState tool provides disk space requirements for the state of the computer at the time the tool is run. The state of the computer might change during day-to-day use. For this reason, use the calculations as an estimate when planning the migration.
|
||||
|
||||
To run the ScanState tool on the source computer with USMT installed:
|
||||
|
||||
@ -74,7 +74,7 @@ To run the ScanState tool on the source computer with USMT installed:
|
||||
|
||||
Although a migration store isn't created by running this command, the *\<StorePath\>* is still a required parameter.
|
||||
|
||||
The ScanState tool also allows you to estimate disk space requirements based on a customized migration. For example, you might not want to migrate the **Documents** folder to the destination computer. You can specify this condition in a configuration file when you run the ScanState tool. For more information, see [Customize USMT XML files](usmt-customize-xml-files.md).
|
||||
The ScanState tool also allows estimation of disk space requirements based on a customized migration. For example, the **Documents** folder might need to be migrated to the destination computer. This condition can be specified in a configuration file when the ScanState tool is run. For more information, see [Customize USMT XML files](usmt-customize-xml-files.md).
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
@ -100,17 +100,17 @@ Additionally, USMT performs a compliance check for a required minimum of 250 MB
|
||||
|
||||
Determine how much space is needed to store the migrated data. Calculations should be based on the volume of e-mail, personal documents, and system settings for each user. The best way to estimate the required space is to survey several computers to arrive at an average for the size of the store that is needed.
|
||||
|
||||
The amount of space that is required in the store varies and depends on the local storage strategies the organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets are smaller. If e-mail is stored locally, such as offline-storage files, data sets are larger. Mobile users typically have larger data sets than workstation users. You should perform tests and inventory the network to determine the average data set size in the organization.
|
||||
The amount of space that is required in the store varies and depends on the local storage strategies the organization uses. For example, one key element that determines the size of migration data sets is e-mail storage. If e-mail is stored centrally, data sets are smaller. If e-mail is stored locally, such as offline-storage files, data sets are larger. Mobile users typically have larger data sets than workstation users. Tests should be performed and the network inventoried to determine the average data set size in the organization.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> You can create a space-estimate file (`Usmtsize.txt`) to estimate the size of the store by using the legacy `/p` command-line option.
|
||||
> A space-estimate file (`Usmtsize.txt`) can be created to estimate the size of the store by using the legacy `/p` command-line option.
|
||||
|
||||
When trying to determine how much disk space is needed, consider the following issues:
|
||||
|
||||
- **E-mail**: If users deal with a large volume of e-mail or keep e-mail on their local computers instead of on a mail server, the e-mail can take up as much disk space as all other user files combined. Prior to migrating user data, make sure that users who store e-mail locally synchronize their inboxes with their mail server.
|
||||
|
||||
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that the organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs more space than a law firm that primarily uses word-processing documents. You don't need to migrate the documents that users store on file servers through mechanisms such as Folder Redirection, as long as users will have access to these locations after the migration.
|
||||
- **User documents**: Frequently, all of a user's documents fit into less than 50 MB of space, depending on the types of files involved. This estimate assumes typical office work, such as word-processing documents and spreadsheets. This estimate can vary substantially based on the types of documents that the organization uses. For example, an architectural firm that predominantly uses computer-aided design (CAD) files needs more space than a law firm that primarily uses word-processing documents. Documents that users store on file servers through mechanisms such as Folder Redirection don't need to be migrated, as long as users will have access to these locations after the migration.
|
||||
|
||||
- **User system settings**: Five megabytes is adequate space to save the registry settings. This requirement can fluctuate, however, based on the number of applications that are installed. It's rare, however, for the user-specific portion of the registry to exceed 5 MB.
|
||||
|
||||
|
||||
@ -33,7 +33,7 @@ Microsoft recommends that you create a custom **.xml** file instead of modifying
|
||||
|
||||
### \<include\> and \<exclude\>
|
||||
|
||||
The migration **.xml** files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, contain the **\<component\>** element, which typically represents a self-contained component or an application such as Microsoft® Office Outlook® and Word. To exclude the files and registry settings that are associated with these components, use the **\<include\>** and **\<exclude\>** elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
|
||||
The migration **.xml** files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, contain the **\<component\>** element, which typically represents a self-contained component or an application such as Microsoft Office Outlook and Word. To exclude the files and registry settings that are associated with these components, use the **\<include\>** and **\<exclude\>** elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
|
||||
@ -23,7 +23,7 @@ Before you modify the **.xml** files, become familiar with the following guideli
|
||||
|
||||
- **XML schema**.
|
||||
|
||||
You can use the User State Migration Tool (USMT) XML schema, MigXML.xsd, to write and validate migration **.xml** files.
|
||||
You can use the User State Migration Tool (USMT) XML schema, `MigXML.xsd`, to write and validate migration **.xml** files.
|
||||
|
||||
- **Conflicts**.
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# 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 functionality is what makes **hard-link migration store** 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 an in-place migration to be performed where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed. This functionality is what makes **hard-link migration store** 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.
|
||||
|
||||
## When to use a hard-link migration
|
||||
|
||||
@ -25,7 +25,7 @@ A hard-link migration store can be used when the planned migration meets both of
|
||||
|
||||
- The operating system is being upgraded on the same volume of the computer.
|
||||
|
||||
You can't use a hard-link migration store if the planned migration includes any of the following tasks:
|
||||
A hard-link migration store can't be used if the planned migration includes any of the following tasks:
|
||||
|
||||
- Data is being migrated from one computer to a different computer.
|
||||
|
||||
@ -37,20 +37,21 @@ You can't use a hard-link migration store if the planned migration includes any
|
||||
|
||||
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 one more path. For instance, you could create a hard link to `c:\file1.txt` called `c:\hard link\myFile.txt`. These two paths relate to the same file. If you open `c:\file1.txt`, make changes, and save the file, you see those changes when you open `c:\hard link\myFile.txt`. If you delete `c:\file1.txt`, the file still exists on the computer as `c:\hardlink\myFile.txt`. You must delete both references to the file in order to delete the file.
|
||||
When a hard link is created, an existing file is given one more path. For instance, a hard link to `c:\file1.txt` can be created called `c:\hard link\myFile.txt`. These two paths relate to the same file. If `c:\file1.txt` is opened, then changes made to the file followed by the file being saved, those changes are seen when `c:\hard link\myFile.txt` is opened. If `c:\file1.txt` is deleted, the file still exists on the computer as `c:\hardlink\myFile.txt`. Both references to the file must be deleted 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.
|
||||
>
|
||||
>A hard link can only be created for a file on the same volume. If a hard-link migration store is copied 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, 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. The hard-link migration store is located as specified by the **ScanState.exe** command-line tool. The contents of the store can be viewed 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, delete the hard-link migration store after you confirm that the files are successfully migrated via the **LoadState** tool. Since **LoadState** creates new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store only deletes one path to the files. It doesn't delete the actual files or the paths to them from the new operating system.
|
||||
As a best practice, delete the hard-link migration store after confirming that the files are successfully migrated via the **LoadState** tool. Since **LoadState** creates new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store only deletes one path to the files. It doesn't delete the actual files or the paths to them from the 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.
|
||||
> Using the `/c` option forces the **LoadState** tool to continue applying files when non-fatal errors occur. If the `/c` option is used, 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 extra disk space being consumed or problems with some applications for the following reasons:
|
||||
|
||||
@ -66,7 +67,7 @@ Keeping the hard-link migration store can result in extra disk space being consu
|
||||
|
||||
## Hard-link migration scenario
|
||||
|
||||
For example, a company decides to deploy the latest supported version of Windows on all of their computers. Each employee keeps the same computer, but the operating system on each computer will be updated.
|
||||
For example, an organization decides to deploy the latest supported version of Windows on all of their computers. Each employee keeps 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.
|
||||
|
||||
@ -74,7 +75,7 @@ For example, a company decides to deploy the latest supported version of Windows
|
||||
>
|
||||
> As a best practice, Microsoft recommends not to create the hard-link migration store until just before the migration is performed in order to migrate the latest versions of files. Software applications shouldn't be used on the computer after creating the migration store until files finish migrating with **LoadState**.
|
||||
|
||||
1. On each computer, an administrator installs the company's standard operating environment (SOE), which includes the latest supported version of Windows and other applications the company currently uses.
|
||||
1. On each computer, an administrator installs the organization's standard operating environment (SOE), which includes the latest supported version of Windows and other applications the organization currently uses.
|
||||
|
||||
1. An administrator runs the **LoadState** command-line tool on each computer. The **LoadState** tool restores user state back on each computer.
|
||||
|
||||
@ -113,7 +114,7 @@ Running this command on a system that contains the operating system on the C: dr
|
||||
|
||||
`D:\USMTMIG\`
|
||||
|
||||
The drive you specify on the command line for the hard-link migration store is important, because it defines where the **master migration store** should be placed. The **master migration store** is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the `/o` option must be used to overwrite the existing data in the store.
|
||||
The drive specified on the command line for the hard-link migration store is important, because it defines where the **master migration store** should be placed. The **master migration store** is the location where data migrating from non-NTFS volumes is stored. This volume must have enough space to contain all of the data that comes from non-NTFS volumes. As in other scenarios, if a migration store already exists at the specified path, the `/o` option must be used to overwrite the existing data in the store.
|
||||
|
||||
### Location modifications
|
||||
|
||||
@ -123,7 +124,7 @@ Location modifications that redirect migrated content from one volume to a diffe
|
||||
|
||||
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the `/efs:hardlink` option in the `ScanState.exe` command-line syntax.
|
||||
|
||||
If the EFS files are being restored to a different partition, you should use the `/efs:copyraw` option instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option copies the files to the new partition in encrypted format.
|
||||
If the EFS files are being restored to a different partition, the `/efs:copyraw` option should be used instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option copies the files to the new partition in encrypted format.
|
||||
|
||||
For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md) and [Encrypted file options](usmt-scanstate-syntax.md#encrypted-file-options).
|
||||
|
||||
@ -131,13 +132,13 @@ For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-
|
||||
|
||||
When an application or the operating system has a lock on a file, the file is handled differently when using a hard-link migration store.
|
||||
|
||||
Operating system locked files can't 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, Microsoft recommends that you don't migrate any files out of the `\Windows` directory, which minimizes performance-related issues.
|
||||
Operating system locked files can't 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, Microsoft recommends not migrating any files out of the `\Windows` directory, which minimizes performance-related issues.
|
||||
|
||||
Application locked files are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service isn't being utilized. The volume shadow-copy service can't be used with hard-link migrations. However, by modifying the new **\<HardLinkStoreControl\>** section in the `Config.xml` file, it's 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.
|
||||
> 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, `UsmtUtils.exe` must be used to schedule the migration store for deletion on the next restart.
|
||||
|
||||
## XML elements in the Config.xml file
|
||||
|
||||
@ -153,7 +154,7 @@ A new section in the `Config.xml` file allows optional configuration of some of
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
> You must use the `/nocompress` option with the `/HardLink` option.
|
||||
> The `/nocompress` option must be used 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 aren't located in the `\Users` directory should result in the **File in Use** error. It's important to exercise caution when specifying the paths using the **`<createhardlink>`** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
|
||||
|
||||
|
||||
@ -15,9 +15,9 @@ appliesto:
|
||||
|
||||
# Identify file types, files, and folders
|
||||
|
||||
When planning the migration, if not using `MigDocs.xml`, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as the **Documents** folder, `C:\Data` , and company-specified locations, such as `\\EngineeringDrafts`. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following items:
|
||||
When a migration is planned and `MigDocs.xml` isn't being used, the file types, files, folders, and settings that need to be migrated should be identified. First, the standard file locations on each computer, such as the **Documents** folder, `C:\Data` , and organization-specified locations, such as `\\EngineeringDrafts`, should be determined. Next, non-standard locations should be determined and located. For non-standard locations, consider the following items:
|
||||
|
||||
- **File types**: Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in the organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis.
|
||||
- **File types**: Consider which file types need to be included and excluded from the migration. This list can be created based on common applications used in the organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis.
|
||||
|
||||
- **Excluded locations**: Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**).
|
||||
|
||||
@ -37,7 +37,7 @@ To find the registered file types on a computer running a currently supported ve
|
||||
|
||||
1. In the window that opens, the registered file types are displayed.
|
||||
|
||||
For more information about how to change the file types, files, and folders that are migrated when you specify the `MigUser.xml` file, see [User State Migration Tool (USMT) how-to articles](usmt-how-to.md).
|
||||
For more information about how to change the file types, files, and folders that are migrated when the `MigUser.xml` file is specified, see [User State Migration Tool (USMT) how-to articles](usmt-how-to.md).
|
||||
|
||||
## Related articles
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Identify Operating System Settings
|
||||
description: Identify which system settings you want to migrate, then use the User State Migration Tool (USMT) to select settings and keep the default values for all others.
|
||||
description: Identify which system settings need to be migrated. The User State Migration Tool (USMT) can then be used to select settings and keep the default values for all others.
|
||||
manager: aaroncz
|
||||
ms.author: frankroj
|
||||
ms.prod: windows-client
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# Identify operating system settings
|
||||
|
||||
When planning the migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. User State Migration Tool (USMT) enables you to migrate select settings and keep the default values for all others. The operating system settings include the following parameters:
|
||||
When the migration is being planned, which operating system settings need to be migrated should be identified. Additionally, to what extent a new standard environment should be created on each of the computers should also be identified. User State Migration Tool (USMT) enables migrating select settings and keep the default values for all others. The operating system settings include the following parameters:
|
||||
|
||||
- **Appearance**
|
||||
|
||||
@ -31,11 +31,11 @@ When planning the migration, you should identify which operating system settings
|
||||
|
||||
- **Internet**
|
||||
|
||||
The Internet factor includes the settings that let you connect to the Internet and control the browser operates. The settings include items such as the home page URL, favorites, bookmarks, cookies, security settings, and proxy settings. These settings might not be supported in all browsers.
|
||||
The Internet factor includes the settings needed to connect to the Internet and controls how the browser operates. The settings include items such as the home page URL, favorites, bookmarks, cookies, security settings, and proxy settings. These settings might not be supported in all browsers.
|
||||
|
||||
- **Mail**
|
||||
|
||||
The mail factor includes the information that you need to connect the mail server, the signature file, views, mail rules, local mail, and contacts. These settings might not be supported in all email applications.
|
||||
The mail factor includes the information needed to connect the mail server, the signature file, views, mail rules, local mail, and contacts. These settings might not be supported in all email applications.
|
||||
|
||||
To help determine which settings to migrate, consider any previous migration experiences and the results of any conducted surveys and tests. Also consider the number of help-desk calls related to operating-system settings from the past, and are able to handle in the future. Also decide how much of the new operating-system functionality needs to be taken advantage of.
|
||||
|
||||
@ -45,7 +45,7 @@ Settings that should be migrated include:
|
||||
- Settings that make the work environment comfortable.
|
||||
- Settings that will reduce help-desk calls after the migration.
|
||||
|
||||
Although it's easy to dismiss migrating user preferences, you should consider the factor of users spending time restoring items such as:
|
||||
Although it's easy to dismiss migrating user preferences, the factor should be considered of users spending time restoring items such as:
|
||||
|
||||
- Wallpaper.
|
||||
- Screen savers.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
---
|
||||
title: Include Files and Settings
|
||||
description: Specify the migration .xml files you want, then use the User State Migration Tool (USMT) to migrate the settings and components specified.
|
||||
description: Specify the migration .xml files that are needed, then use the User State Migration Tool (USMT) to migrate the settings and components specified.
|
||||
manager: aaroncz
|
||||
ms.author: frankroj
|
||||
ms.prod: windows-client
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# Include Files and Settings
|
||||
|
||||
When you specify the migration **.xml** files, User State Migration Tool (USMT) migrates the settings and components specified in [What does USMT migrate?](usmt-what-does-usmt-migrate.md). To include additional files and settings, Microsoft recommends that you create a custom **.xml** file, and then include this file when using both the `ScanState.exe` and `LoadState.exe` commands. By creating a custom **.xml** file, you can keep the changes separate from the default **.xml** files. Creating a custom **.xml** file makes it easier to track modifications.
|
||||
When the migration **.xml** files are specified, User State Migration Tool (USMT) migrates the settings and components specified in [What does USMT migrate?](usmt-what-does-usmt-migrate.md). To include additional files and settings, Microsoft recommends creating a custom **.xml** file, and then include this file when using both the `ScanState.exe` and `LoadState.exe` commands. Creating a custom **.xml** file allows changes to be kept separate from the default **.xml** files. Creating a custom **.xml** file makes it easier to track modifications.
|
||||
|
||||
## Migrate a single registry key
|
||||
|
||||
|
||||
@ -19,7 +19,7 @@ This article describes how to migrate Encrypting File System (EFS) certificates.
|
||||
|
||||
## To migrate EFS files and certificates
|
||||
|
||||
Encrypting File System (EFS) certificates are migrated automatically. However, by default, the User State Migration Tool (USMT) fails if an encrypted file is found unless you specify an `/efs` option. Therefore when a device has EFS encrypted files, you must specify the `/efs` option with any one of the following parameters:
|
||||
Encrypting File System (EFS) certificates are migrated automatically. However, by default, the User State Migration Tool (USMT) fails if an encrypted file is found unless the `/efs` option is specified. Therefore when a device has EFS encrypted files, the `/efs` option must be specified with any one of the following parameters:
|
||||
|
||||
- `abort`
|
||||
- `skip`
|
||||
@ -27,15 +27,15 @@ Encrypting File System (EFS) certificates are migrated automatically. However, b
|
||||
- `copyraw`
|
||||
- `hardlink`
|
||||
|
||||
when running the `ScanState.exe` command to migrate the encrypted files. Then, when you run the `LoadState.exe` command on the destination computer, the encrypted file and the EFS certificate are automatically migrated.
|
||||
when running the `ScanState.exe` command to migrate the encrypted files. Then, when the `LoadState.exe` command is run on the destination computer, the encrypted file and the EFS certificate are automatically migrated.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> The `/efs` options aren't used with the `LoadState.exe` command.
|
||||
|
||||
Before using the **ScanState** tool for a migration that includes encrypted files and EFS certificates, you must ensure that all files in an encrypted folder are encrypted as well or remove the encryption attribute from folders that contain unencrypted files. If the encryption attribute is removed from a file but not from the parent folder, the file is encrypted during the migration using the credentials of the account used to run the **LoadState** tool.
|
||||
Before using the **ScanState** tool for a migration that includes encrypted files and EFS certificates, all files in an encrypted folder must also be encrypted. Otherwise, remove the encryption attribute from folders that contain unencrypted files. If the encryption attribute is removed from a file but not from the parent folder, the file is encrypted during the migration using the credentials of the account used to run the **LoadState** tool.
|
||||
|
||||
You can run the [Cipher.exe](/windows-server/administration/windows-commands/cipher) tool at a Windows command prompt to review and change encryption settings on files and folders. For example, to remove encryption from a folder, at a command prompt enter:
|
||||
The [Cipher.exe](/windows-server/administration/windows-commands/cipher) tool can be run at a Windows command prompt to review and change encryption settings on files and folders. For example, to remove encryption from a folder, at a command prompt enter:
|
||||
|
||||
```cmd
|
||||
cipher.exe /D /S:<PATH>
|
||||
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# Migrate User Accounts
|
||||
|
||||
By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. You can't specify users in the migration XML files or by using the `Config.xml` file.
|
||||
By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. Users can't be specified in the migration XML files or by using the `Config.xml` file.
|
||||
|
||||
## To migrate all user accounts and user settings
|
||||
|
||||
@ -33,20 +33,21 @@ Links to detailed explanations of commands are available in the [Related article
|
||||
|
||||
1. Enter one of the following `LoadState.exe` command lines in a command prompt window:
|
||||
|
||||
- If you're migrating domain accounts, enter:
|
||||
- If migrating domain accounts, enter:
|
||||
|
||||
```cmd
|
||||
LoadState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml
|
||||
```
|
||||
|
||||
- If you're migrating local accounts along with domain accounts, enter:
|
||||
- If migrating local accounts along with domain accounts, enter:
|
||||
|
||||
```cmd
|
||||
LoadState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml /lac /lae
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> You do not have to specify the `/lae` option, which enables the account that was created with the `/lac` option. Instead, you can create a disabled local account by specifying only the `/lac` option, and then a local administrator needs to enable the account on the destination computer.
|
||||
>
|
||||
> The `/lae` option doesn't need to be specified, which enables the account that was created with the `/lac` option. Instead, create a disabled local account by specifying only the `/lac` option, and then a local administrator needs to enable the account on the destination computer.
|
||||
|
||||
## To migrate two domain accounts (User1 and User2)
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ This article discusses User State Migration Tool (USMT) options for migration st
|
||||
|
||||
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.exe` and the `LoadState.exe` 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.exe` and the `LoadState.exe` command lines by using the `/encrypt`:*encryption_strength* and the `/decrypt`:*encryption_strength* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in currently supported versions of Windows. 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 chosen encryption algorithm must be specified for both the `ScanState.exe` and the `LoadState.exe` 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.exe` and the `LoadState.exe` command lines by using the `/encrypt`:*encryption_strength* and the `/decrypt`:*encryption_strength* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in currently supported versions of Windows. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. The `UsmtUtils.exe` file can be used to determine which encryption algorithms are available to the computers' locales before the migration begins.
|
||||
|
||||
The following table describes the command-line encryption options in USMT.
|
||||
|
||||
|
||||
@ -18,15 +18,15 @@ appliesto:
|
||||
|
||||
# User State Migration Tool (USMT) overview
|
||||
|
||||
You can use User State Migration Tool (USMT) to streamline and simplify user state migration during large deployments of Windows operating systems. USMT captures user accounts, user files, operating system settings, and application settings, and then migrates them to a new Windows installation. You can use USMT for both PC replacement and PC refresh migrations. For more information, see [Common migration scenarios](usmt-common-migration-scenarios.md).
|
||||
The User State Migration Tool (USMT) can be used to streamline and simplify user state migration during large deployments of Windows operating systems. USMT captures user accounts, user files, operating system settings, and application settings, and then migrates them to a new Windows installation. USMT can be used for both PC replacement and PC refresh migrations. For more information, see [Common migration scenarios](usmt-common-migration-scenarios.md).
|
||||
|
||||
USMT enables you to do the following actions:
|
||||
USMT enables the following actions:
|
||||
|
||||
- Configure the migration according to the organization's business needs by using the migration rule (.xml) files to control exactly which files and settings are migrated and how they're migrated. For more information about how to modify these files, see [USMT XML reference](usmt-xml-reference.md).
|
||||
|
||||
- Fit the customized migration into the automated deployment process by using the **ScanState** and **LoadState** tools, which control collecting and restoring the user files and settings. For more information, see [User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md).
|
||||
|
||||
- Perform offline migrations. You can run migrations offline by using the ScanState command in Windows Preinstallation Environment (WinPE) or you can perform migrations from previous installations of Windows contained in **Windows.old** directories. For more information about migration types, see [Choose a migration store Type](usmt-choose-migration-store-type.md) and [Offline migration reference](offline-migration-reference.md).
|
||||
- Perform offline migrations. Migrations can be run offline by using the ScanState command in Windows Preinstallation Environment (WinPE) or migrations can be performed from previous installations of Windows contained in **Windows.old** directories. For more information about migration types, see [Choose a migration store Type](usmt-choose-migration-store-type.md) and [Offline migration reference](offline-migration-reference.md).
|
||||
|
||||
## Benefits
|
||||
|
||||
@ -41,7 +41,7 @@ USMT provides the following benefits to businesses that are deploying Windows op
|
||||
|
||||
## Limitations
|
||||
|
||||
USMT is intended for administrators who are performing large-scale automated deployments. If you're only migrating the user states of a few computers, you can use [PCmover Express](https://go.microsoft.com/fwlink/?linkid=620915). PCmover isn't a free utility. PCmover Express is a tool created by Microsoft's partner, Laplink.
|
||||
USMT is intended for administrators who are performing large-scale automated deployments. If the user states of only a few computers are being migrated, [PCmover Express](https://go.microsoft.com/fwlink/?linkid=620915) can be used. PCmover isn't a free utility. PCmover Express is a tool created by Microsoft's partner, Laplink.
|
||||
|
||||
There are some scenarios in which the use of USMT isn't recommended. These scenarios include:
|
||||
|
||||
|
||||
@ -18,11 +18,11 @@ appliesto:
|
||||
|
||||
# Recognized environment variables
|
||||
|
||||
When using the XML files `MigDocs.xml`, `MigApp.xml`, and `MigUser.xml`, you can use environment variables to identify folders that can be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but could have different names or locations on any given computer. For example, the **Documents** folder could be `C:\Users\<Username>\Documents` on one computer and `C:\Users\<Username>\My Documents` on another. You can use the asterisk (\*) wildcard character in `MigUser.xml`, `MigApp.xml` and `MigDoc.xml` files. However, you can't use the asterisk (\*) wildcard characters in the `Config.xml` file.
|
||||
When the XML files `MigDocs.xml`, `MigApp.xml`, and `MigUser.xml` are used, the environment variables can be used to identify folders that can be different on different computers. Constant special item ID list (CSIDL) values provide a way to identify folders that applications use frequently but could have different names or locations on any given computer. For example, the **Documents** folder could be `C:\Users\<Username>\Documents` on one computer and `C:\Users\<Username>\My Documents` on another. The asterisk (\*) wildcard character can be used in the `MigUser.xml`, `MigApp.xml` and `MigDoc.xml` files. However, the asterisk (\*) wildcard character can't be used in the `Config.xml` file.
|
||||
|
||||
## Variables that are processed for the operating system and in the context of each user
|
||||
|
||||
You can use these variables within sections in the **.xml** files with `context=UserAndSystem`, `context=User`, and `context=System`.
|
||||
These variables can be used within sections in the **.xml** files with `context=UserAndSystem`, `context=User`, and `context=System`.
|
||||
|
||||
|Variable|Explanation|
|
||||
|--- |--- |
|
||||
@ -86,12 +86,12 @@ You can use these variables within sections in the **.xml** files with `context=
|
||||
|
||||
## 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`.
|
||||
These variables can be used in the **.xml** files within sections with `context=User` and `context=UserAndSystem`.
|
||||
|
||||
|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_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:\Users\<username>\AppData\Roaming`.|
|
||||
|*CSIDL_BITBUCKET*|The virtual folder that contains the objects in the user's Recycle Bin.|
|
||||
|
||||
@ -17,7 +17,7 @@ appliesto:
|
||||
|
||||
## Supported operating systems
|
||||
|
||||
The User State Migration Tool (USMT) doesn't have any explicit RAM or CPU speed requirements for either the source or destination computers. If the computer complies with the system requirements of the operating system, it also complies with the requirements for USMT. You need an intermediate store location large enough to hold all of the migrated data and settings. The same amount of hard disk space is also needed on the destination computer for the migrated files and settings.
|
||||
The User State Migration Tool (USMT) doesn't have any explicit RAM or CPU speed requirements for either the source or destination computers. If the computer complies with the system requirements of the operating system, it also complies with the requirements for USMT. An intermediate store location large enough to hold all of the migrated data and settings is needed. The same amount of hard disk space is also needed on the destination computer for the migrated files and settings.
|
||||
|
||||
The following table lists the operating systems supported in USMT.
|
||||
|
||||
@ -36,7 +36,7 @@ The following table lists the operating systems supported in USMT.
|
||||
|
||||
## Unsupported scenarios
|
||||
|
||||
- USMT doesn't support any of the Windows Server® operating systems.
|
||||
- USMT doesn't support any of the Windows Server operating systems.
|
||||
- USMT shouldn't be used for migrating between previous versions of Windows. USMT is only meant to:
|
||||
- Migrate to a currently supported version of Windows
|
||||
- Migrate between currently supported versions of Windows, assuming the version of Windows being migrated to is newer or the same as the previous version of Windows being migrated from.
|
||||
@ -51,7 +51,7 @@ For more information about previous releases of the USMT tools, see [User State
|
||||
|
||||
- **Run as administrator.**
|
||||
|
||||
When manually running the **ScanState** and **LoadState** tools, you must run them from an elevated command prompt to ensure that all specified users are migrated. If you don't run USMT from an elevated prompt, only the user profile that is logged on is included in the migration.
|
||||
When the **ScanState** and **LoadState** tools are run, they must be run from an elevated command prompt to ensure that all specified users are migrated. If USMT isn't run from an elevated prompt, only the user profile that is logged on is included in the migration.
|
||||
|
||||
To open an elevated command prompt:
|
||||
|
||||
@ -63,7 +63,7 @@ To open an elevated command prompt:
|
||||
|
||||
> [!IMPORTANT]
|
||||
>
|
||||
> You must run USMT using an account with full administrative permissions, including the following privileges:
|
||||
> USMT must run using an account with full administrative permissions, including the following privileges:
|
||||
>
|
||||
> - SeBackupPrivilege (Back up files and directories)
|
||||
> - SeDebugPrivilege (Debug programs)
|
||||
@ -75,7 +75,7 @@ To open an elevated command prompt:
|
||||
|
||||
### Specify the `/c` option and \<ErrorControl\> settings in the `Config.xml` file
|
||||
|
||||
USMT fails if it can't migrate a file or setting, unless the `/c` option is specified. When you specify the `/c` option, USMT logs an error each time it encounters a file that is in use that didn't migrate, but the migration isn't be interrupted. In USMT, you can specify in the `Config.xml` file, which types of errors should allow the migration to continue, and which should cause the migration to fail. For more information about error reporting, and the **\<ErrorControl\>** element, see [Config.xml file](usmt-configxml-file.md#errorcontrol), [Log files](usmt-log-files.md), and [XML elements library](usmt-xml-elements-library.md).
|
||||
USMT fails if it can't migrate a file or setting, unless the `/c` option is specified. When the `/c` option is specified, USMT logs an error each time it encounters a file that is in use that didn't migrate, but the migration isn't be interrupted. In USMT, which types of errors should allow the migration to continue and which should cause the migration to fail can be specified in the `Config.xml` file. For more information about error reporting, and the **\<ErrorControl\>** element, see [Config.xml file](usmt-configxml-file.md#errorcontrol), [Log files](usmt-log-files.md), and [XML elements library](usmt-xml-elements-library.md).
|
||||
|
||||
## LoadState
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ appliesto:
|
||||
|
||||
- Microsoft Visual Studio
|
||||
|
||||
- You can use the User State Migration Tool (USMT) XML schema (the `MigXML.xsd` file) to validate the migration **.xml** files using an XML authoring tool such as Microsoft® Visual Studio®.
|
||||
- The User State Migration Tool (USMT) XML schema (the `MigXML.xsd` file) can be used to validate the migration **.xml** files using an XML authoring tool such as Microsoft Visual Studio.
|
||||
|
||||
For more information about how to use the schema with an XML authoring environment, see the environment's documentation.
|
||||
|
||||
|
||||
@ -31,7 +31,7 @@ USMT also includes a set of three modifiable **.xml** files:
|
||||
- MigDocs.xml
|
||||
- MigUser.xml
|
||||
|
||||
Additionally, you can create custom **.xml** files to support the organization's migration needs. You can also create a `Config.xml` file to specify files or settings to exclude from the migration.
|
||||
Additionally, custom **.xml** files can be created to support the organization's migration needs. A `Config.xml` file can also be created to specify files or settings to exclude from the migration.
|
||||
|
||||
USMT tools can be used on several versions of Windows operating systems. For more information, see [USMT requirements](usmt-requirements.md). For more information about previous releases of the USMT tools, see [User State Migration Tool (USMT) overview](/previous-versions/windows/hh825227(v=win.10)).
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# User State Migration Tool (USMT) overview articles
|
||||
|
||||
The User State Migration Tool (USMT) provides a highly customizable user-profile migration experience for IT professionals. USMT includes three command-line tools: `ScanState.exe`, `LoadState.exe`, and `UsmtUtils.exe`. USMT also includes a set of three modifiable .xml files: `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`. Additionally, you can create custom **.xml** files to support the organization's migration needs. You can also create a `Config.xml` file to specify files or settings to exclude from the migration.
|
||||
The User State Migration Tool (USMT) provides a highly customizable user-profile migration experience for IT professionals. USMT includes three command-line tools: `ScanState.exe`, `LoadState.exe`, and `UsmtUtils.exe`. USMT also includes a set of three modifiable .xml files: `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`. Additionally, custom **.xml** files can be created to support the organization's migration needs. A `Config.xml` file can also be created to specify files or settings to exclude from the migration.
|
||||
|
||||
## In this section
|
||||
|
||||
@ -23,7 +23,7 @@ The User State Migration Tool (USMT) provides a highly customizable user-profile
|
||||
|------ |----------- |
|
||||
|[User State Migration Tool (USMT) overview](usmt-overview.md)|Describes the benefits and limitations of using USMT.|
|
||||
|[Getting started with the User State Migration Tool (USMT)](getting-started-with-the-user-state-migration-tool.md)|Describes the general process to follow to migrate files and settings, and provides links to more information.|
|
||||
|[Windows upgrade and migration considerations](../upgrade/windows-upgrade-and-migration-considerations.md)|Discusses the Microsoft® tools you can use to move files and settings between installations and special considerations for performing an upgrade or migration.|
|
||||
|[Windows upgrade and migration considerations](../upgrade/windows-upgrade-and-migration-considerations.md)|Discusses the Microsoft tools that can be used to move files and settings between installations and special considerations for performing an upgrade or migration.|
|
||||
|
||||
## Related articles
|
||||
|
||||
|
||||
@ -15,7 +15,7 @@ appliesto:
|
||||
|
||||
# User State Migration Tool (USMT) troubleshooting
|
||||
|
||||
The following table describes articles that address common User State Migration Tool (USMT) issues and questions. These articles describe tools that you can use to troubleshoot issues that arise during the migration.
|
||||
The following table describes articles that address common User State Migration Tool (USMT) issues and questions. These articles describe tools that can be used to troubleshoot issues that arise during the migration.
|
||||
|
||||
## In this section
|
||||
|
||||
@ -23,7 +23,7 @@ The following table describes articles that address common User State Migration
|
||||
|--- |--- |
|
||||
|[Common Issues](/troubleshoot/windows-client/deployment/usmt-common-issues)|Find troubleshooting solutions for common problems in USMT.|
|
||||
|[Frequently Asked Questions](usmt-faq.yml)|Find answers to questions about how to use USMT.|
|
||||
|[Log Files](usmt-log-files.md)|Learn how to enable logging to help you troubleshoot issues in USMT.|
|
||||
|[Log Files](usmt-log-files.md)|Learn how to enable logging to help troubleshoot issues in USMT.|
|
||||
|[Return Codes](/troubleshoot/windows-client/deployment/usmt-return-codes)|Learn how to use return codes to identify problems in USMT.|
|
||||
|[USMT Resources](usmt-resources.md)|Find more information and support for using USMT.|
|
||||
|
||||
|
||||
@ -78,11 +78,11 @@ The syntax for `/extract` is:
|
||||
|-------|-----|
|
||||
| *\<filePath\>* | Path to the USMT migration store. <br><br>For example:<br>`D:\MyMigrationStore\USMT\store.mig` |
|
||||
| *\<destinationPath\>* | Path to the folder where the tool puts the individual files. |
|
||||
| **/i**:*\<includePattern\>* | Specifies a pattern for files to include in the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use `/i`: *\<includePattern\>* and `/e`: *\<excludePattern\>* options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns. |
|
||||
| **/e**:*\<excludePattern\>* | Specifies a pattern for files to omit from the extraction. You can specify more than one pattern. Separate patterns with a comma or a semicolon. You can use `/i`: *\<includePattern\>* and `/e`: *\<excludePattern\>* options in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns. |
|
||||
| **/i**:*\<includePattern\>* | Specifies a pattern for files to include in the extraction. More than one pattern can be specified. Separate patterns with a comma or a semicolon. The `/i`: *\<includePattern\>* and `/e`: *\<excludePattern\>* options can be used in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns. |
|
||||
| **/e**:*\<excludePattern\>* | Specifies a pattern for files to omit from the extraction. More than one pattern can be specified. Separate patterns with a comma or a semicolon. The `/i`: *\<includePattern\>* and `/e`: *\<excludePattern\>* options can be used in the same command. When both include and exclude patterns are used on the command line, include patterns take precedence over exclude patterns. |
|
||||
| **/l**:*\<logfilePath\>* | Specifies the location and name of the log file. |
|
||||
| **/v:***\<VerbosityLevel\>* | **(Verbosity)**<br><br>Enables verbose output in the **UsmtUtils** log file. The default value is 0.<br><br>You can set the *VerbosityLevel* to one of the following levels:<br><ul><li>**0** - Only the default errors and warnings are enabled.</li><li>**1** - Enables verbose output.</li><li>**4** - Enables error and status output.</li><li>**5** - Enables verbose and status output.</li><li>**8** - Enables error output to a debugger.</li><li>**9** - Enables verbose output to a debugger.</li><li>**12** - Enables error and status output to a debugger.</li><li>**13** - Enables verbose, status, and debugger output.</li></ul> |
|
||||
| **/decrypt***\<AlgID\>***/key**:*\<KeyString\>*<br>or<br>**/decrypt***\<AlgID\>***/**:*\<"Key String"\>*<br>or<br>**/decrypt:***\<AlgID\>***/keyfile**:*\<FileName\>* | Specifies that the `/encrypt` option was used to create the migration store with the **ScanState** tool. To decrypt the migration store, you must also specify the `/key` or `/keyfile` option as follows:<br><ul><li>*\<AlgID\>* specifies the cryptographic algorithm that was used to create the migration store on the `ScanState.exe` command line. If no algorithm is specified, **ScanState** and **UsmtUtils** use the 3DES algorithm as a default.<br>*\<AlgID\>* valid values include: `AES_128`, `AES_192`, `AES_256`, `3DES`, or `3DES_112`.</li><li>`/key`: *\<KeyString\>* specifies the encryption key. If there's a space in *\<KeyString\>*, you must surround the argument with quotation marks.</li><li>`/keyfile`:*\<FileName\>* specifies a text (.txt) file that contains the encryption key</li></ul><br>For more information about supported encryption algorithms, see [Migration store encryption](usmt-migration-store-encryption.md). |
|
||||
| **/v:***\<VerbosityLevel\>* | **(Verbosity)**<br><br>Enables verbose output in the **UsmtUtils** log file. The default value is 0.<br><br>The *VerbosityLevel* can be set to one of the following levels:<br><ul><li>**0** - Only the default errors and warnings are enabled.</li><li>**1** - Enables verbose output.</li><li>**4** - Enables error and status output.</li><li>**5** - Enables verbose and status output.</li><li>**8** - Enables error output to a debugger.</li><li>**9** - Enables verbose output to a debugger.</li><li>**12** - Enables error and status output to a debugger.</li><li>**13** - Enables verbose, status, and debugger output.</li></ul> |
|
||||
| **/decrypt***\<AlgID\>***/key**:*\<KeyString\>*<br>or<br>**/decrypt***\<AlgID\>***/**:*\<"Key String"\>*<br>or<br>**/decrypt:***\<AlgID\>***/keyfile**:*\<FileName\>* | Specifies that the `/encrypt` option was used to create the migration store with the **ScanState** tool. To decrypt the migration store, the `/key` or `/keyfile` option must also be specified as follows:<br><ul><li>*\<AlgID\>* specifies the cryptographic algorithm that was used to create the migration store on the `ScanState.exe` command line. If no algorithm is specified, **ScanState** and **UsmtUtils** use the 3DES algorithm as a default.<br>*\<AlgID\>* valid values include: `AES_128`, `AES_192`, `AES_256`, `3DES`, or `3DES_112`.</li><li>`/key`: *\<KeyString\>* specifies the encryption key. If there's a space in *\<KeyString\>*, the argument must be surrounded with quotation marks.</li><li>`/keyfile`:*\<FileName\>* specifies a text (.txt) file that contains the encryption key</li></ul><br>For more information about supported encryption algorithms, see [Migration store encryption](usmt-migration-store-encryption.md). |
|
||||
| **/o** | Overwrites existing output files. |
|
||||
|
||||
Some examples of `/extract` commands:
|
||||
|
||||
@ -120,7 +120,7 @@ USMT migrates operating-system components to a destination computer. The followi
|
||||
|
||||
The use of a **\<ProfileControl\>** section in the `Config.xml` file is required when running an offline migration.
|
||||
|
||||
- Microsoft® Open Database Connectivity (ODBC) settings.
|
||||
- Microsoft Open Database Connectivity (ODBC) settings.
|
||||
|
||||
- Mouse and keyboard settings.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user