deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 10:53:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

USMT Refresh 18

Browse Source
This commit is contained in:
Frank Rojas
2024-01-02 18:34:02 -05:00
parent 34613933ad
commit af0d007483
29 changed files with 104 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
windows/deployment/usmt/migration-store-types-overview.md
View File

@ -1,6 +1,6 @@
---
title: Migration Store Types Overview
description: Learn about the migration store types and how to determine which migration store type best suits your needs.
description: Learn about the migration store types and how to determine which migration store type best suits the organization's needs.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
@ -15,7 +15,7 @@ appliesto:
# Migration Store Types Overview
When planning your migration, you should determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) components on your source and destination computers. You should also determine the space needed to create and host the migration store, whether you're using a local share, network share, or storage device.
When a migration is being planned, which migration store type best meets the organization's needs should be determined. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) components on the source and destination computers. The space needed to create and host the migration store should also be determined, whether using a local share, network share, or storage device.
## Migration store types
@ -23,7 +23,7 @@ This section describes the three migration store types available in USMT.
### Uncompressed (UNC)
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. You can use Windows Explorer to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
The uncompressed (UNC) migration store is an uncompressed directory with a mirror image of the folder hierarchy being migrated. Each directory and file retains the same access permissions that it has on the local file system. Windows Explorer can be used to view this migration store type. Settings are stored in a catalog file that also describes how to restore files on the destination computer.
### Compressed
@ -31,9 +31,9 @@ The compressed migration store is a single image file that contains all files be
### Hard-Link
A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are "wired" into the file system. You use the new USMT hard-link migration store in the PC Refresh scenario only. Hard-link migration stores are only used in Refresh scenarios because the hard-link migration store is maintained on the local computer. The hard-link store is maintained on the computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.
A hard-link migration store functions as a map that defines how a collection of bits on the hard disk are "wired" into the file system. The USMT hard-link migration store is only used in the PC Refresh scenario. Hard-link migration stores are only used in Refresh scenarios because the hard-link migration store is maintained on the local computer. The hard-link store is maintained on the computer while the old operating system is removed and the new operating system is installed. Using a hard-link migration store saves network bandwidth and minimizes the server use needed to accomplish the migration.
You use the command-line option `/hardlink` to create a hard-link migration store, which functions the same as an uncompressed migration store. Files aren't duplicated on the local computer when user state is captured. They also aren't duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
The command-line option `/hardlink` is used to create a hard-link migration store, which functions the same as an uncompressed migration store. Files aren't duplicated on the local computer when user state is captured. They also aren't duplicated when user state is restored. For more information, see [Hard-Link Migration Store](usmt-hard-link-migration-store.md).
The following flowchart illustrates the procedural differences between a local migration store and a remote migration store. In this example, a hard-link migration store is used for the local store.
@ -41,9 +41,9 @@ The following flowchart illustrates the procedural differences between a local m
## Local store vs. remote store
If you have enough space and you're migrating the user state back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, depending on the imaging technology that you're using, you might be able to store the data on the partition that is being re-imaged if the data can be protected from deletion during the process. To increase performance, store the data on high-speed drives that use a high-speed network connection. It's also good practice to ensure that the migration is the only task the server is performing.
If there's enough space and the user state is being migrated back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. The data can also be stored locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, the data might be able to be stored on the partition that is being re-imaged if the data can be protected from deletion during the imaging process. One example of an imaging technology that is capable of storing the data on the partition that is being reimaged is Microsoft Configuration Manager. To increase performance, store the data on high-speed drives that use a high-speed network connection. It's also good practice to ensure that the migration is the only task the server is performing.
If there isn't enough local disk space, or if you're moving the user state to another computer, then you must store the data remotely such as in one of the following destinations:
If there isn't enough local disk space, or if moving the user state to another computer, then the data must be stored remotely such as in one of the following destinations:
- Shared folder.
- Removable media.
@ -57,7 +57,7 @@ For example:
1. Run the `LoadState.exe` command on the destination computer and specify `C:\Store` as the store location.
By doing this process, you don't need to save the files to a server.
By doing this process, files don't need to be stored to a server.
> [!IMPORTANT]
>
@ -65,8 +65,8 @@ By doing this process, you don't need to save the files to a server.
### The /localonly command-line option
You should use this option to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when you specify `/LocalOnly`, see [ScanState Syntax](usmt-scanstate-syntax.md).
This option should be used to exclude the data from removable drives and network drives mapped on the source computer. For more information about what is excluded when `/LocalOnly` is specified, see [ScanState Syntax](usmt-scanstate-syntax.md).
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).

2
windows/deployment/usmt/offline-migration-reference.md
View File

@ -192,4 +192,4 @@ The following XML example illustrates some of the elements discussed earlier in
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).

18
windows/deployment/usmt/understanding-migration-xml-files.md
View File

@ -15,7 +15,7 @@ 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 your migration.
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.
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.
@ -155,11 +155,11 @@ 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 your 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.
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.
> [!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 your data, see the [Using multiple XML files](#using-multiple-xml-files) section of this article.
> 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.
## Using multiple XML files
@ -184,17 +184,17 @@ ScanState.exe <store> /config:c:\myFolder\Config.xml /i:migapps.xml /i:MigDocs.x
>
> 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.
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` is a better choice than the `MigUser.xml` file, because the `MigDocs.xml` file 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 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.
## Creating and editing a custom XML file
You can use the `/genmigxml` command-line option to determine which files are included in your migration. The `/genmigxml` option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary.
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.
> [!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 your custom migration rules and saving them in a secure location.
> 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.
To generate the XML migration rules file for a source computer:
@ -213,7 +213,7 @@ To generate the XML migration rules file for a source computer:
where:
- **\<USMTpath\>** - location on your source computer of the saved USMT files and tools.
- **\<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.
For example, enter:
@ -405,7 +405,7 @@ For more examples of exclude rules that you can use in custom migration XML file
### 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 your company 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 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:
#### Example 1: Include a file name extension in a known user folder
@ -441,7 +441,7 @@ For more examples of include rules that you can use in custom migration XML file
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.
You can use an XML schema (MigXML.xsd) file to validate the syntax of your customized XML files. For more information, see [USMT Resources](usmt-resources.md).
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).
## Related articles

16
windows/deployment/usmt/usmt-best-practices.md
View File

@ -25,11 +25,11 @@ 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 your 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 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).
- **Use MigDocs.xml for a better migration experience.**
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` file 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, and on registered file type by querying the registry for registered application extensions. The `MigUser.xml` file migrates only the files with the specified file extensions.
If the data set is unknown or if many files are stored outside of the standard user-profile folders, the `MigDocs.xml` file 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, and on registered file type by querying the registry for registered application extensions. The `MigUser.xml` file migrates only the files with the specified file extensions.
- **Close all applications before running either the ScanState or LoadState tools.**
@ -49,11 +49,11 @@ This article discusses general and security-related best practices when using Us
- **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 your plan between 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.
## Security best practices
As the authorized administrator, it is your responsibility to protect the privacy of the users and maintain security during and after the migration. In particular, you must consider the following issues:
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:
- **Encrypting File System (EFS).**
@ -104,11 +104,11 @@ As the authorized administrator, it is your responsibility to protect the privac
- **Use the default migration XML files as models.**
To create a custom **.xml** file, you can use the migration **.xml** files as models to create your own. If you need to migrate user data files, model your custom **.xml** file on `MigUser.xml`. To migrate application settings, model your custom **.xml** file on the `MigApp.xml` file.
To create a custom **.xml** file, migration **.xml** files can be used as models to create customized versions. If user data files need to be migrated, model the custom **.xml** file on `MigUser.xml`. To migrate application settings, model the custom **.xml** file on the `MigApp.xml` file.
- **Consider the impact on performance when using the \<context\> parameter.**
Your 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 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.
In the **User** context, a rule is processed one time for each user on the system.
@ -120,7 +120,7 @@ As the authorized administrator, it is your responsibility to protect the privac
>
> 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 your .xml code to one of the existing migration .xml files.**
- **Microsoft recommends that you 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.
@ -137,4 +137,4 @@ As the authorized administrator, it is your responsibility to protect the privac
## Related articles
- [Migration store encryption](usmt-migration-store-encryption.md).
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).

12
windows/deployment/usmt/usmt-choose-migration-store-type.md
View File

@ -1,6 +1,6 @@
---
title: Choose a Migration Store Type
description: Learn how to choose a migration store type and estimate the amount of disk space needed for computers in your organization.
description: Learn how to choose a migration store type and estimate the amount of disk space needed for computers in the organization.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
@ -15,9 +15,9 @@ appliesto:
# Choose a migration store type
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine the following items:
One of the main considerations for planning the migration is to determine which migration store type best meets the organization's needs. As part of these considerations, determine the following items:
- How much space is required to run the User State Migration Tool (USMT) components on your source and destination computers.
- How much space is required to run the User State Migration Tool (USMT) components on the source and destination computers.
- How much space is needed to create and host the migration store.
- Whether a local share, network share, or storage device should be used.
- Ensure that user date integrity is maintained by encrypting the migration store.
@ -26,12 +26,12 @@ One of the main considerations for planning your migration is to determine which
| Link | Description |
|--- |--- |
|[Migration store types overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
|[Estimate migration store size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.|
|[Migration store types overview](migration-store-types-overview.md)|Choose the migration store type that works best for the organization's needs and migration scenario.|
|[Estimate migration store size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in the organization based on information about the organization's infrastructure.|
|[Hard-link migration store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they're used.|
|[Migration store encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
## Related articles
- [Plan your migration](usmt-plan-your-migration.md)
- [Plan the migration](usmt-plan-your-migration.md)
- [User State Migration Tool (USMT) how-articles](usmt-how-to.md)

2
windows/deployment/usmt/usmt-common-migration-scenarios.md
View File

@ -114,6 +114,6 @@ A company is allocating 20 new computers to users in the accounting department.
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).
- [Choose a migration store type](usmt-choose-migration-store-type.md).
- [Offline migration reference](offline-migration-reference.md).

2
windows/deployment/usmt/usmt-configxml-file.md
View File

@ -25,7 +25,7 @@ For more information about using the `Config.xml` file with other migration file
> [!NOTE]
>
> To exclude a component from the `Config.xml` file, set the **migrate** value to **no**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from your migration.
> To exclude a component from the `Config.xml` file, set the **migrate** value to **no**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from the migration.
## Migration Policies

40
windows/deployment/usmt/usmt-conflicts-and-precedence.md
View File

@ -15,13 +15,13 @@ 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. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind.
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.
- **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 will be excluded.
- **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.
- **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.
@ -33,9 +33,9 @@ When you include, exclude, and reroute files and settings, it's important to kno
### What is the relationship between rules that are located within different components?
Only rules inside the same component can affect each other, depending on specificity, except for the **\<unconditionalExclude\>** rule. Rules that are in different components don't affect each other. If there's an **\<include\>** rule in one component and an identical **\<exclude\>** rule in another component, the data will be migrated because the two rules are independent of each other.
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 will be migrated in both places. That is, it will be included based on the **\<include\>** rule, and it will be migrated based on the **\<locationModify\>** rule.
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 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 one shown below in a migration **.xml** file (which includes all of the **.doc** files from the **Documents** folder), then only the **.doc** files will be migrated, and all other files will be excluded.
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.
```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 will be migrated in both places. That is, it will be included based on the **\<include\>** rule, and it will be migrated based on the **\<locationModify\>** rule.
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.
### How are rules processed?
@ -101,9 +101,9 @@ USMT doesn't distinguish the **.xml** files based on their name or content. It p
### 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 won't be migrated. For example if you exclude a file, and include the same file, the file won't be 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 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.
In the following example, mp3 files won't be excluded from the migration. The mp3 files won't be excluded because directory names take precedence over the file extensions.
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.
```xml
<include>
@ -120,7 +120,7 @@ In the following example, mp3 files won't be excluded from the migration. The mp
### \<include\> and \<exclude\> rules precedence examples
These examples explain how USMT deals with **\<include\>** and **\<exclude\>** rules. When the rules are in different components, the resulting behavior will be the same regardless of whether the components are in the same or in different migration **.xml** files.
These examples explain how USMT deals with **\<include\>** and **\<exclude\>** rules. When the rules are in different components, the resulting behavior is the same regardless of whether the components are in the same or in different migration **.xml** files.
- [Including and excluding files](#including-and-excluding-files)
@ -133,7 +133,7 @@ These examples explain how USMT deals with **\<include\>** and **\<exclude\>** r
| <ul><li>Include rule: \<pattern type=&quot;File&quot;\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type=&quot;File&quot;\>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=&quot;File&quot;\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type=&quot;File&quot;\>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. |
| <ul><li>Include rule: \<pattern type=&quot;File&quot;\>C:\Dir1* []\</pattern\></li><li>Exclude rule: \<pattern type=&quot;File&quot;\>C:\Dir1\ * [.txt]\</pattern\></li></ul> | Migrates all files and subfolders in C:\Dir1, except the **.txt** files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
| <ul><li>Include rule: \<pattern type=&quot;File&quot;\>C:\Dir1\Dir2* [.txt]\</pattern\></li><li>Exclude rule: \<pattern type=&quot;File&quot;\>C:\Dir1\Dir2* [.txt]\</pattern\></li></ul> | Nothing will be migrated. | The rules are equally specific, so the **\<exclude\>** rule takes precedence over the **\<include\>** rule. |
| <ul><li>Include rule: \<pattern type=&quot;File&quot;\>C:\Dir1\Dir2* [.txt]\</pattern\></li><li>Exclude rule: \<pattern type=&quot;File&quot;\>C:\Dir1\Dir2* [.txt]\</pattern\></li></ul> | Nothing is migrated. | The rules are equally specific, so the **\<exclude\>** rule takes precedence over the **\<include\>** rule. |
| <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. |
@ -153,7 +153,7 @@ These examples explain how USMT deals with **\<include\>** and **\<exclude\>** r
| If you have the following code 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. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. |
| 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. |
## File collisions
@ -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 will select 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 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.
### Example scenario
@ -191,7 +191,7 @@ You have a custom **.xml** file that contains the following code:
</include>
```
For this example, the following information describes the resulting behavior if you add the code to your custom **.xml** file.
For this example, the following information describes the resulting behavior if the code is added to the custom **.xml** file.
#### Example 1
@ -203,7 +203,7 @@ For this example, the following information describes the resulting behavior if
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, only `C:\Data\SampleA.txt` will be restored.
**Result**: During ScanState, all the files are added to the store. During LoadState, only `C:\Data\SampleA.txt` is restored.
#### Example 2
@ -215,8 +215,8 @@ For this example, the following information describes the resulting behavior if
</merge>
```
**Result**: During ScanState, all the files will be added to the store.
During LoadState, all the files will be restored, overwriting the existing files on the destination computer.
**Result**: During ScanState, all the files are added to the store.
During LoadState, all the files are restored, overwriting the existing files on the destination computer.
#### Example 3
@ -228,11 +228,11 @@ During LoadState, all the files will be restored, overwriting the existing files
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, the following actions will occur:
**Result**: During ScanState, all the files are added to the store. During LoadState, the following actions occur:
- `C:\Data\SampleA.txt` will be restored.
- `C:\Data\SampleB.txt` will be restored, overwriting the existing file on the destination computer.
- `C:\Data\Folder\SampleB.txt` won't be restored.
- `C:\Data\SampleA.txt` is restored.
- `C:\Data\SampleB.txt` is restored, overwriting the existing file on the destination computer.
- `C:\Data\Folder\SampleB.txt` aren't restored.
## Related articles

2
windows/deployment/usmt/usmt-custom-xml-examples.md
View File

@ -17,7 +17,7 @@ appliesto:
## Example 1: Migrating an unsupported application
The following template is a template for the sections that you need to migrate your application. The template isn't functional on its own, but you can use it to write your own **.xml** file.
The following template is a template for the sections that are needed to migrate applications. The template isn't functional on its own, but it can be used to write custom **.xml** file.
**Template**
<br>

6
windows/deployment/usmt/usmt-customize-xml-files.md
View File

@ -29,7 +29,7 @@ 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.
- **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 your needs. For ScanState and LoadState to use this file, specify them on both command lines.
- **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 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.
@ -55,7 +55,7 @@ This section describes the migration **.xml** files that are included with USMT.
## Custom .xml files
You can create custom **.xml** files to customize the migration for your 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, 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.
## The Config.xml file
@ -77,7 +77,7 @@ In addition, note the following functionality with the `Config.xml` file:
> [!NOTE]
>
> To exclude a component from the `Config.xml` file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from your migration.
> To exclude a component from the `Config.xml` file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from the migration.
### Examples

10
windows/deployment/usmt/usmt-estimate-migration-store-size.md
View File

@ -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 your organization based on information about your 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. 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.
## 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 your store to another partition, an external storage device such as a USB flash drive or a server. For more information, see [Choose a Migration Store Type](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. 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).
- **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 your migration.
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.
To run the ScanState tool on the source computer with USMT installed:
@ -100,7 +100,7 @@ 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 your 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. You should perform tests and inventory the network to determine the average data set size in the organization.
> [!NOTE]
>
@ -110,7 +110,7 @@ When trying to determine how much disk space is needed, consider the following i
- **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 your 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. 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 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.

4
windows/deployment/usmt/usmt-exclude-files-and-settings.md
View File

@ -29,7 +29,7 @@ Methods to customize the migration and include and exclude files and settings in
## Create a custom .xml file
Microsoft recommends that you create a custom **.xml** file instead of modifying the default migration **.xml** files. When you use a custom **.xml** file, you can keep your changes separate from the default **.xml** file, which makes it easier to track your modifications.
Microsoft recommends that you create a custom **.xml** file instead of modifying the default migration **.xml** files. When you use a custom **.xml** file, you can keep the changes separate from the default **.xml** file, which makes it easier to track the modifications.
### \<include\> and \<exclude\>
@ -285,7 +285,7 @@ For more information, see [Config.xml File](usmt-configxml-file.md).
> [!NOTE]
>
> To exclude a component from the `Config.xml` file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from your migration.
> To exclude a component from the `Config.xml` file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the `Config.xml` file doesn't exclude the component from the migration.
## Related articles

4
windows/deployment/usmt/usmt-faq.yml
View File

@ -62,7 +62,7 @@ sections:
- question: |
How do I install USMT?
answer: |
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in your environment. The USMT binaries can then be copied from the USMT directory located on the original computer where the Windows ADK was installed to additional client computers.
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in the environment. The USMT binaries can then be copied from the USMT directory located on the original computer where the Windows ADK was installed to additional client computers.
- question: |
How do I uninstall USMT?
@ -105,7 +105,7 @@ sections:
- question: |
Can I use custom **.xml** files that were written for USMT 5.0?
answer: |
Yes. You can use custom **.xml** files that were written for USMT 5.0 with newer versions of USMT. However, in order to use new USMT functionality, you must revisit your custom USMT files and refresh them to include the new command-line options and XML elements.
Yes. You can use custom **.xml** files that were written for USMT 5.0 with newer versions of USMT. However, in order to use new USMT functionality, you must revisit the custom USMT files and refresh them to include the new command-line options and XML elements.
- question: |
How can I validate the **.xml** files?

8
windows/deployment/usmt/usmt-hard-link-migration-store.md
View File

@ -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 your planned migration includes any of the following tasks:
You can't use a hard-link migration store if the planned migration includes any of the following tasks:
- Data is being migrated from one computer to a different computer.
@ -37,7 +37,7 @@ You can't use a hard-link migration store if your 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 your computer as `c:\hardlink\myFile.txt`. You must delete both references to the file in order to delete the file.
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.
> [!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.
@ -72,7 +72,7 @@ For example, a company decides to deploy the latest supported version of Windows
> [!NOTE]
>
> As a best practice, Microsoft recommends that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with **LoadState**.
> 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.
@ -170,4 +170,4 @@ The following XML sample specifies that files locked by an application under the
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).

6
windows/deployment/usmt/usmt-how-to.md
View File

@ -21,12 +21,12 @@ The following table lists articles that describe how to use User State Migration
| Link | Description |
|------ |----------- |
|[Exclude files and settings](usmt-exclude-files-and-settings.md)|Create a custom **.xml** file to exclude files, file types, folders, or registry settings from your migration.|
|[Exclude files and settings](usmt-exclude-files-and-settings.md)|Create a custom **.xml** file to exclude files, file types, folders, or registry settings from the migration.|
|[Extract files from a compressed USMT migration store](usmt-extract-files-from-a-compressed-migration-store.md)|Recover files from a compressed migration store after installing the operating system.|
|[Include files and settings](usmt-include-files-and-settings.md)|Create a custom **.xml** file to include files, file types, folders, or registry settings in your migration.|
|[Include files and settings](usmt-include-files-and-settings.md)|Create a custom **.xml** file to include files, file types, folders, or registry settings in the migration.|
|[Migrate application settings](migrate-application-settings.md)|Migrate the settings of an application that the `MigApp.xml` file doesn't include by default.|
|[Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md)|Migrate Encrypting File System (EFS) certificates by using USMT.|
|[Migrate user accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in your migration.|
|[Migrate user accounts](usmt-migrate-user-accounts.md)|Specify the users to include and exclude in the migration.|
|[Reroute files and settings](usmt-reroute-files-and-settings.md)|Create a custom **.xml** file to reroute files and settings during a migration.|
|[Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md)|Determine whether a compressed migration store is intact, or whether it contains corrupt files or a corrupt catalog.|

6
windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md
View File

@ -1,6 +1,6 @@
---
title: Identify File Types, Files, and Folders
description: Learn how to identify the file types, files, folders, and settings that you want to migrate when you're planning your migration.
description: Identify the file types, files, folders, and settings that need to be migrated when planning the migration.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
@ -15,9 +15,9 @@ appliesto:
# Identify file types, files, and folders
When planning for your migration, if not using `MigDocs.xml`, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as 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 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:
- **File types**: Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis.
- **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.
- **Excluded locations**: Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**).

6
windows/deployment/usmt/usmt-identify-operating-system-settings.md
View File

@ -15,7 +15,7 @@ appliesto:
# Identify operating system settings
When planning for your migration, you should identify which operating system settings you want to migrate and to what extent you want to create a new standard environment on each of the computers. 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 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:
- **Appearance**
@ -31,11 +31,11 @@ When planning for your migration, you should identify which operating system set
- **Internet**
The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your 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 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.
- **Mail**
The mail factor includes the information that you need to connect to your mail server, your signature file, views, mail rules, local mail, and contacts.
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.
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.

2
windows/deployment/usmt/usmt-include-files-and-settings.md
View File

@ -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 your changes separate from the default **.xml** files. Creating a custom **.xml** file makes it easier to track modifications.
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.
## Migrate a single registry key

8
windows/deployment/usmt/usmt-loadstate-syntax.md
View File

@ -59,7 +59,7 @@ USMT provides the following options that you can use to specify how and where th
| **/decrypt /key**:*KeyString* <br>or <br>**/decrypt /key**:"*Key String*" <br>or <br>**/decrypt /keyfile**:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, the encryption key needs to be specified in one of the following ways:<ul><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`:*FilePathAndName* specifies a text (`.txt`) file that contains the encryption key</li></ul> <br>*KeyString* can't exceed 256 characters. <br>The `/key` and `/keyfile` options can't be used on the same command line. <br>The `/decrypt` and `/nocompress` options can't be used on the same command line. <br><div class="alert">**Important** <br> Use caution when using the `/key` or `keyfile` options. For example, anyone who has access to scripts that run the `LoadState.exe` command with these options also have access to the encryption key.</div> <br>For example: <br>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /decrypt /key:mykey` |
| **/decrypt**:*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). |
| **/hardlink** | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. |
| **/nocompress** | Specifies that the store isn't compressed. You should only use this option in testing environments. Microsoft recommends that you use a compressed store during your actual migration. This option can't be used with the `/decrypt` option. <br>For example: <br>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /nocompress` |
| **/nocompress** | Specifies that the store isn't compressed. You should only use this option in testing environments. Microsoft recommends that you use a compressed store during the actual migration. This option can't be used with the `/decrypt` option. <br>For example: <br>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /nocompress` |
## Migration rule options
@ -67,9 +67,9 @@ USMT provides the following options to specify what files you want to migrate.
| Command-Line Option | Description |
|--- |--- |
| **/i**:[*Path*]*FileName* | **(include)** <br>Specifies an **.xml** file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your **.xml** files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom **.xml** files that you create). *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* must be located in the current directory. <br><br>For more information about which files to specify, see the &quot;XML files&quot; section of the [Frequently Asked Questions](usmt-faq.yml) article. |
| **/i**:[*Path*]*FileName* | **(include)** <br>Specifies an **.xml** file that contains rules that define what state to migrate. You can specify this option multiple times to include all of the **.xml** files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom **.xml** files that you create). *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* must be located in the current directory. <br><br>For more information about which files to specify, see the &quot;XML files&quot; section of the [Frequently Asked Questions](usmt-faq.yml) article. |
| **/config**:[*Path*]*FileName* | Specifies the `Config.xml` file that the `LoadState.exe` command should use. You can't specify this option more than once on the command line. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the *FileName* must be located in the current directory. <br><br>This example migrates the files and settings based on the rules in the `Config.xml`, `MigDocs.xml`, and `MigApp.xml` files: <br><br>`LoadState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:5 /l:LoadState.log` |
| **/auto**:*"path to script files"* | This option enables you to specify the location of the default **.xml** files and then launch your migration. If no path is specified, USMT uses the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. |
| **/auto**:*"path to script files"* | This option enables you to specify the location of the default **.xml** files and then launch the migration. If no path is specified, USMT uses the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. |
## Monitoring options
@ -80,7 +80,7 @@ USMT provides several command-line options that you can use to analyze problems
| **/l**:[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the log is created in the current directory. You can specify the `/v` option to adjust the verbosity of the log. <br><br>If you run the `LoadState.exe` command from a shared network resource, you must specify the `l` option, or USMT fails with the error:<br><br>***USMT was unable to create the log file(s)***<br><br> To fix this issue, make sure to specify the `/l` option when running `LoadState.exe` from a shared network resource. |
| **/v**:*`<VerbosityLevel>`* | **(Verbosity)** <br><br>Enables verbose output in the **LoadState** log file. The default value is 0. <br>You can set the *VerbosityLevel* to one of the following levels:<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><br>For example: <br>`LoadState.exe \server\share\migration\mystore /v:5 /i:MigDocs.xml /i:MigApp.xml` |
| **/progress**:[*Path*]*FileName* | Creates the optional progress log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* is created in the current directory. <br><br>For example: <br>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /progress:Progress.log /l:loadlog.log` |
| **/c** | When this option is specified, the `LoadState.exe` command continues to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there's a large file that doesn't fit on the computer, the `LoadState.exe` command logs an error and continue with the migration. Without the `/c` option, the `LoadState.exe` command exits on the first error. You can use the new \<**ErrorControl**\> section in the `Config.xml` file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This error control enables the `/c` command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the `/genconfig` option now generates a sample \<**ErrorControl**\> section that is enabled by specifying error messages and desired behaviors in the `Config.xml` file. |
| **/c** | When this option is specified, the `LoadState.exe` command continues to run, even if non-fatal errors occur. Any files or settings that cause an error are logged in the progress log. For example, if there's a large file that doesn't fit on the computer, the `LoadState.exe` command logs an error and continue with the migration. Without the `/c` option, the `LoadState.exe` command exits on the first error. You can use the new \<**ErrorControl**\> section in the `Config.xml` file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This error control enables the `/c` command-line option to safely skip all input/output (I/O) errors in the environment. In addition, the `/genconfig` option now generates a sample \<**ErrorControl**\> section that is enabled by specifying error messages and desired behaviors in the `Config.xml` file. |
| **/r**:*`<TimesToRetry>`* | **(Retry)** <br><br>Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity isn't reliable. <br><br>When the user state is being restored, the `/r` option doesn't recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. |
| **/w**:*`<SecondsBeforeRetry>`* | **(Wait)** <br><br>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
| **/?** or **/help** | Displays Help on the command line. |

10
windows/deployment/usmt/usmt-log-files.md
View File

@ -1,6 +1,6 @@
---
title: USMT Log Files
description: Learn how to use User State Migration Tool (USMT) logs to monitor your migration and to troubleshoot errors and failed migrations.
description: Learn how to use User State Migration Tool (USMT) logs to monitor the migration and to troubleshoot errors and failed migrations.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
@ -15,7 +15,7 @@ appliesto:
# USMT log files
You can use User State Migration Tool (USMT) logs to monitor your migration and to troubleshoot errors and failed migrations. This article describes the available command-line options to enable USMT logs. It also describes new XML elements that can be used to configure:
You can use User State Migration Tool (USMT) logs to monitor the migration and to troubleshoot errors and failed migrations. This article describes the available command-line options to enable USMT logs. It also describes new XML elements that can be used to configure:
- Which types of errors are fatal and should halt the migration.
- Which types are non-fatal and should be skipped so that the migration can continue.
@ -37,11 +37,11 @@ The following table describes each command-line option related to logs, and it p
## ScanState and LoadState logs
**ScanState** and **LoadState** logs are text files that are create when you run the **ScanState** and **LoadState** tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see [Monitoring options](usmt-scanstate-syntax.md#monitoring-options) in [ScanState syntax](usmt-scanstate-syntax.md).
**ScanState** and **LoadState** logs are text files that are create when you run the **ScanState** and **LoadState** tools. You can use these logs to help monitor the migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see [Monitoring options](usmt-scanstate-syntax.md#monitoring-options) in [ScanState syntax](usmt-scanstate-syntax.md).
## Progress log
You can create a progress log using the `/progress` option. External tools, such as Microsoft System Center Operations Manager, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows:
You can create a progress log using the `/progress` option. External tools, such as Microsoft System Center Operations Manager, can parse the progress log to update the monitoring systems. The first three fields in each line are fixed as follows:
- **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2023.
@ -298,7 +298,7 @@ Upon reviewing the diagnostic log, you confirm that the files are still migratin
</migration>
```
Your revised migration XML script excludes the files from migrating, as confirmed in the diagnostic log:
The revised migration XML script excludes the files from migrating, as confirmed in the diagnostic log:
```xml
<MigUnitList>

4
windows/deployment/usmt/usmt-migration-store-encryption.md
View File

@ -32,8 +32,8 @@ The following table describes the command-line encryption options in USMT.
> [!IMPORTANT]
>
> Some encryption algorithms might not be available on your systems. You can verify which algorithms are available by running the `UsmtUtils.exe` command with the `/ec` option. For more information, see [UsmtUtils syntax](usmt-utilities.md).
> Some encryption algorithms might not be available on some systems. Which algorithms are available can be verified by running the `UsmtUtils.exe` command with the `/ec` option. For more information, see [UsmtUtils syntax](usmt-utilities.md).
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).

4
windows/deployment/usmt/usmt-overview.md
View File

@ -22,9 +22,9 @@ You can use User State Migration Tool (USMT) to streamline and simplify user sta
USMT enables you to do the following actions:
- Configure your migration according to your 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).
- 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 your customized migration into your 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).
- 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).

2
windows/deployment/usmt/usmt-reference.md
View File

@ -22,7 +22,7 @@ appliesto:
|[USMT requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.|
|[USMT best practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.|
|[How USMT works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.|
|[Plan your migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.|
|[Plan the migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for the organization.|
|[User State Migration Tool (USMT) command-line syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.|
|[USMT XML reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.|
|[Offline Migration reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.|

4
windows/deployment/usmt/usmt-requirements.md
View File

@ -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 your 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. 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 following table lists the operating systems supported in USMT.
@ -98,6 +98,6 @@ This documentation assumes that IT professionals using USMT understand command-l
## Related articles
- [Plan your migration](usmt-plan-your-migration.md).
- [Plan the migration](usmt-plan-your-migration.md).
- [Estimate migration store size](usmt-estimate-migration-store-size.md).
- [User State Migration Tool (USMT) overview articles](usmt-topics.md).

2
windows/deployment/usmt/usmt-reroute-files-and-settings.md
View File

@ -15,7 +15,7 @@ appliesto:
# Reroute Files and Settings
To reroute files and settings, create a custom **.xml** file and specify the **.xml** file name on both the `ScanState.exe` and `LoadState.exe` command-lines. Th custom **.xml** file enables you to keep your changes separate from the default **.xml** files, so that it's easier to track your modifications.
To reroute files and settings, create a custom **.xml** file and specify the **.xml** file name on both the `ScanState.exe` and `LoadState.exe` command-lines. The custom **.xml** file enables keeping changes separate from the default **.xml** files, so that it's easier to track modifications.
## Reroute a folder

2
windows/deployment/usmt/usmt-resources.md
View File

@ -23,7 +23,7 @@ appliesto:
- 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®.
For more information about how to use the schema with your XML authoring environment, see the environment's documentation.
For more information about how to use the schema with an XML authoring environment, see the environment's documentation.
- [Ask the Directory Services Team blog](https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/bg-p/AskDS).

2
windows/deployment/usmt/usmt-technical-reference.md
View File

@ -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 your migration needs. You can also create a `Config.xml` file to specify files or settings to exclude from the migration.
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.
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)).

2
windows/deployment/usmt/usmt-topics.md
View File

@ -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 your 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, 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.
## In this section

2
windows/deployment/usmt/usmt-troubleshooting.md
View File

@ -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 your migration.
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.
## In this section