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

USMT Refresh 24

Browse Source
This commit is contained in:
Frank Rojas
2024-01-03 12:23:22 -05:00
parent 2dbfb6c10d
commit 1492491a6a
47 changed files with 140 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md
View File

@ -7,7 +7,7 @@ ms.prod: windows-client
author: frankroj
ms.topic: article
ms.technology: itpro-deploy
ms.date: 01/02/2024
ms.date: 01/03/2024
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>

6
windows/deployment/usmt/migrate-application-settings.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,7 +15,7 @@ appliesto:
# Migrate Application Settings
A custom **.xml** file can be created to migrate specific line-of-business application settings or to change the default migration behavior of the User State Migration Tool (USMT). For ScanState and LoadState to use this file, the custom **.xml** file must be specified on both command lines.
A custom **.xml** file can be created to migrate specific line-of-business application settings or to change the default migration behavior of the User State Migration Tool (USMT). For **ScanState** and **LoadState** to use this file, the custom **.xml** file must be specified on both command lines.
This article defines how to author a custom migration **.xml** file that migrates the settings of an application that isn't migrated by default using `MigApp.xml`. The settings should be migrated after the application is installed, but before the user runs the application for the first time.
@ -153,7 +153,7 @@ To speed up the time it takes to collect and migrate the data, only one user can
/ue:*\* /ui:user1
```
For more information, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article and the [User options](usmt-scanstate-syntax.md#user-options) section in the [ScanState syntax](usmt-scanstate-syntax.md) article. To troubleshoot a problem, check the progress log, the ScanState log, and the LoadState log. The logs contain warnings and errors that could point to problems with the migration.
For more information, see the [Exclude files and settings](usmt-exclude-files-and-settings.md) article and the [User options](usmt-scanstate-syntax.md#user-options) section in the [ScanState syntax](usmt-scanstate-syntax.md) article. To troubleshoot a problem, check the progress log, the **ScanState** log, and the **LoadState** log. The logs contain warnings and errors that could point to problems with the migration.
## Related articles

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,19 +15,19 @@ appliesto:
# Offline Migration Reference
Offline migration enables the ScanState tool to run inside a different Windows operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
Offline migration enables the **ScanState** tool to run inside a different Windows operating system than the Windows operating system from which **ScanState** is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **Windows PE.** The **ScanState** tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
- **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.
- **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 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.
- **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.
- **Improving performance.** When USMT runs in an offline Windows Preinstallation Environment (WinPE) environment, it has better access to the hardware resources. Running USMT in WinPE can increase performance on older machines with limited hardware resources and numerous installed software applications.
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the ScanState tool from within WinPE.
- **New recovery scenario.** In scenarios where a machine no longer restarts properly, it might be possible to gather user state with the **ScanState** tool from within WinPE.
## What migrates offline?
@ -60,7 +60,7 @@ The following table defines the supported combination of online and offline oper
> [!NOTE]
>
> It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [BitLocker operations guide: Suspend and resume](/windows/security/operating-system-security/data-protection/bitlocker/operations-guide#suspend-and-resume). If using a Microsoft Configuration Manager task sequence, see [Task sequence steps: Disable BitLocker](/mem/configmgr/osd/understand/task-sequence-steps#BKMK_DisableBitLocker).
> It is possible to run the **ScanState** tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [BitLocker operations guide: Suspend and resume](/windows/security/operating-system-security/data-protection/bitlocker/operations-guide#suspend-and-resume). If using a Microsoft Configuration Manager task sequence, see [Task sequence steps: Disable BitLocker](/mem/configmgr/osd/understand/task-sequence-steps#BKMK_DisableBitLocker).
## User-group membership and profile control
@ -103,11 +103,11 @@ System environment variables are necessary in the scenarios outlined in the foll
|Variable|Value|Scenario|
|--- |--- |--- |
|**USMT_WORKING_DIR**|Full path to a working directory|Required when USMT binaries are located on read-only media, which doesn't support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following command:<br><br> `Set USMT_WORKING_DIR=<path to working directory>`|
|**MIG_OFFLINE_PLATFORM_ARCH**|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system doesn't match the WinPE and `ScanState.exe` architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. Specifying the architecture is required when auto-detection of the offline architecture doesn't function properly. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following command:<br><br> `Set MIG_OFFLINE_PLATFORM_ARCH=32`|
|**MIG_OFFLINE_PLATFORM_ARCH**|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system doesn't match the WinPE and `ScanState.exe` architecture. This environment variable enables the 32-bit **ScanState** application to gather data from a computer with 64-bit architecture, or the 64-bit **ScanState** application to gather data from a computer with 32-bit architecture. Specifying the architecture is required when auto-detection of the offline architecture doesn't function properly. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following command:<br><br> `Set MIG_OFFLINE_PLATFORM_ARCH=32`|
## Offline.xml elements
Use an `Offline.xml` file when running the ScanState tool on a computer that has multiple Windows directories. The `Offline.xml` file specifies which directories to scan for windows files. An `Offline.xml` file can be used with the `/offline` option as an alternative to specifying a single Windows directory path with the `/offlineDir` option.
Use an `Offline.xml` file when running the **ScanState** tool on a computer that has multiple Windows directories. The `Offline.xml` file specifies which directories to scan for windows files. An `Offline.xml` file can be used with the `/offline` option as an alternative to specifying a single Windows directory path with the `/offlineDir` option.
### \<offline\>
@ -131,7 +131,7 @@ Syntax:
### \<path\>
This element is a required child of **\<winDir\>** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool's working directory.
This element is a required child of **\<winDir\>** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the **ScanState** tool's working directory.
Syntax:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -21,7 +21,7 @@ This article provides an overview of the default and custom migration XML files
## Overview of the Config.xml file
The `Config.xml` file is the configuration file created by the `/genconfig` option of the ScanState tool. It can be used to modify which operating-system components 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`
@ -33,7 +33,7 @@ When used this way, the `Config.xml` file tightly controls aspects of the migrat
## 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). 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).
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. 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 `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.
The `/genmigxml` option can be used 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. 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 `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:
@ -159,11 +159,11 @@ The `MigUser.xml` file can be copied and then the copy modified to include or ex
> [!NOTE]
>
> 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.
> 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
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.
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:|
|--- |--- |

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

@ -37,7 +37,7 @@ This article discusses general and security-related best practices when using Us
- **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, sign out after running 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.**
@ -45,11 +45,11 @@ This article discusses general and security-related best practices when using Us
- **Chkdsk.exe.**
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)).
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 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.
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, any necessary modifications can be made to the plan between groups.
## Security best practices
@ -69,7 +69,7 @@ As the authorized administrator, it's the responsibility to protect the privacy
- **Virus Scan.**
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.
Microsoft recommends to scan 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.**
@ -87,7 +87,7 @@ As the authorized administrator, it's the responsibility to protect the privacy
- **Specify the same set of mig\*.xml files in both the ScanState and the LoadState tools.**
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.
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.**

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

8
windows/deployment/usmt/usmt-command-line-syntax.md
View File

@ -1,11 +1,11 @@
---
title: User State Migration Tool (USMT) Command-line Syntax
description: Learn about the User State Migration Tool (USMT) command-line syntax for using the ScanState tool, LoadState tool, and UsmtUtils tool.
description: Learn about the User State Migration Tool (USMT) command-line syntax for using the **ScanState** tool, **LoadState** tool, and UsmtUtils tool.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -21,6 +21,6 @@ The User State Migration Tool (USMT) migrates user files and settings during lar
| Link | Description |
|--- |--- |
|[ScanState syntax](usmt-scanstate-syntax.md)|Lists the command-line options for using the ScanState tool.|
|[LoadState syntax](usmt-loadstate-syntax.md)|Lists the command-line options for using the LoadState tool.|
|[**ScanState** syntax](usmt-scanstate-syntax.md)|Lists the command-line options for using the **ScanState** tool.|
|[LoadState syntax](usmt-loadstate-syntax.md)|Lists the command-line options for using the **LoadState** tool.|
|[UsmtUtils syntax](usmt-utilities.md)|Lists the command-line options for using the UsmtUtils tool.|

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,7 +15,7 @@ appliesto:
# 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.
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 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.

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -91,7 +91,7 @@ There are two broad categories of rules.
- **Rules that affect the behavior of both the ScanState and LoadState tools**. For example, the **\<include\>**, **\<exclude\>**, and **\<unconditionalExclude\>** rules are processed for each component in the **.xml** files. For each component, USMT creates an include list and an exclude list. Some of the rules in the component might be discarded due to specificity, but all of the remaining rules are processed. For each **\<include\>** rule, USMT iterates through the elements to see if any of the locations need to be excluded. USMT enumerates all of the objects and creates a list of objects it's going to collect for each user. Once the list is complete, each of the objects is stored or migrated to the destination computer.
- **Rules that affect the behavior of only the LoadState tool**. For example, the **\<locationModify\>**, **\<contentModify\>**, and **\<destinationCleanup\>** rules don't affect ScanState. They're processed only with LoadState. First, the LoadState tool determines the content and location of each component based on the **\<locationModify\>** and **\<contentModify\>** rules. Then, LoadState processes all of the **\<destinationCleanup\>** rules and deletes data from the destination computer. Lastly, LoadState applies the components to the computer.
- **Rules that affect the behavior of only the LoadState tool**. For example, the **\<locationModify\>**, **\<contentModify\>**, and **\<destinationCleanup\>** rules don't affect ScanState. They're processed only with LoadState. First, the **LoadState** tool determines the content and location of each component based on the **\<locationModify\>** and **\<contentModify\>** rules. Then, **LoadState** processes all of the **\<destinationCleanup\>** rules and deletes data from the destination computer. Lastly, **LoadState** applies the components to the computer.
### How does USMT combine all of the .xml files that I specify on the command line?

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

@ -7,7 +7,7 @@ ms.prod: windows-client
author: frankroj
ms.topic: article
ms.technology: itpro-deploy
ms.date: 01/02/2024
ms.date: 01/03/2024
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -17,7 +17,7 @@ appliesto:
## Overview
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.
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 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:
@ -27,9 +27,9 @@ 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.** 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.
- **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.** 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 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 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.
@ -45,9 +45,9 @@ This section describes the migration **.xml** files that are included with USMT.
- **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. The `MigDocs.xml` file can be modified.
- **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. 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.
- **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 by using the [ScanState User options](usmt-scanstate-syntax.md#user-options) and the [LoadState User options](usmt-loadstate-syntax.md#user-options).
> [!NOTE]
>

2
windows/deployment/usmt/usmt-determine-what-to-migrate.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,7 +15,7 @@ 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. 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.
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
@ -25,7 +25,7 @@ The disk space requirements for a migration are dependent on the size of the mig
- **E250 megabytes (MB) minimum of hard disk space**: Space is needed to support the User State Migration Tool (USMT) operations, for example, growth in the page file. If every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless of the size of the migration. The USMT tool that captures data (ScanState) doesn't create the migration store if 250 MB of disk space isn't available.
- **Temporary space for USMT to run**: Extra disk space is required for the USMT tools to operate. This disk space requirement doesn't include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the ScanState tool.
- **Temporary space for USMT to run**: Extra disk space is required for the USMT tools to operate. This disk space requirement doesn't include the minimum 250 MB needed to create the migration store. The amount of temporary space required can be calculated using the **ScanState** tool.
- **Hard-link migration store**: It isn't necessary to estimate the size of a hard-link migration store. The only case where the hard-link store can be large is when non-NTFS file volumes exist on the system and those volumes contain data being migrated.
@ -37,13 +37,13 @@ The disk space requirements for a migration are dependent on the size of the mig
- **Data being migrated**: Data being migrated includes files and registry information.
- **Temporary space for USMT to run**: Extra disk space is required for the USMT tools to operate. The amount of temporary space required can be calculated using the ScanState tool.
- **Temporary space for USMT to run**: Extra disk space is required for the USMT tools to operate. The amount of temporary space required can be calculated using the **ScanState** tool.
## Calculate disk space requirements using the ScanState tool
## Calculate disk space requirements using the **ScanState** tool
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.
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:
To run the **ScanState** tool on the source computer with USMT installed:
1. Open a command prompt with administrator privileges.
@ -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 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).
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]
>

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,7 +15,7 @@ appliesto:
# Exclude files and settings
When the migration **.xml** files `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` are specified, the User State Migration Tool (USMT) migrates the settings and components listed, as discussed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md) A custom **.xml** file can be created to further specify what to include or exclude in the migration. In addition, a `Config.xml` file can be created to exclude an entire component from a migration. However, users can't be excluded by using the migration **.xml** files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the user options on the command line in the ScanState tool. For more information, see the [User options](usmt-scanstate-syntax.md#user-options) section of the [ScanState syntax](usmt-scanstate-syntax.md) article.
When the migration **.xml** files `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` are specified, the User State Migration Tool (USMT) migrates the settings and components listed, as discussed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md) A custom **.xml** file can be created to further specify what to include or exclude in the migration. In addition, a `Config.xml` file can be created to exclude an entire component from a migration. However, users can't be excluded by using the migration **.xml** files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the user options on the command line in the **ScanState** tool. For more information, see the [User options](usmt-scanstate-syntax.md#user-options) section of the [ScanState syntax](usmt-scanstate-syntax.md) article.
Methods to customize the migration and include and exclude files and settings include:
@ -273,7 +273,7 @@ The following **.xml** file unconditionally excludes the system folders of `C:\W
## Create a Config XML File
A `Config.xml` file can be created and modified to exclude components from the migration. Excluding components using this file is easier than modifying the migration **.xml** files because familiarity with the migration rules and syntax isn't required. `Config.xml` is an optional file that can be created using the `/genconfig` command-line option with the ScanState tool. For example, the `Config.xml` file can be used to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
A `Config.xml` file can be created and modified to exclude components from the migration. Excluding components using this file is easier than modifying the migration **.xml** files because familiarity with the migration rules and syntax isn't required. `Config.xml` is an optional file that can be created using the `/genconfig` command-line option with the **ScanState** tool. For example, the `Config.xml` file can be used to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
- **To exclude the settings for a default application:** Specify `migrate="no"` for the application under the **\<Applications\>** section of the `Config.xml` file.

2
windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -11,7 +11,7 @@ metadata:
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: faq
title: Frequently Asked Questions
summary: |

40
windows/deployment/usmt/usmt-general-conventions.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -19,43 +19,43 @@ This article describes the XML helper functions.
## General XML guidelines
Before you modify the **.xml** files, become familiar with the following guidelines:
Before modifying the **.xml** files, become familiar with the following guidelines:
- **XML schema**.
- **XML schema.**
You can use the User State Migration Tool (USMT) XML schema, `MigXML.xsd`, to write and validate migration **.xml** files.
The User State Migration Tool (USMT) XML schema, `MigXML.xsd`, can be used to write and validate migration **.xml** files.
- **Conflicts**.
- **Conflicts.**
In general, when there are conflicts within the XML schema, the most specific pattern takes precedence. For more information, see [Conflicts and precedence](usmt-conflicts-and-precedence.md).
- **Required elements**.
- **Required elements.**
The required elements for a migration **.xml** file are **\<migration\>**, **\<component\>**, **\<role\>**, and **\<rules\>**.
- **Required child elements**.
- **Required child elements.**
- USMT doesn't fail with an error if you don't specify the required child elements. However, you must specify the required child elements for the parent element to affect the migration.
- USMT doesn't fail with an error if the required child elements aren't specified. However, the required child elements must be specified for the parent element to affect the migration.
- The required child elements apply only to the first definition of the element. If these elements are defined and then referred to using their name, the required child elements don't apply. For example, if you define `<detects name="Example">` in **\<namedElements\>**, and you specify `<detects name="Example"/>` in **\<component\>** to refer to this element, the definition inside **\<namedElements\>** must have the required child elements, but the **\<component\>** element doesn't need to have the required child elements.
- The required child elements apply only to the first definition of the element. If these elements are defined and then referred to using their name, the required child elements don't apply. For example, if `<detects name="Example">` is defined in **\<namedElements\>**, and `<detects name="Example"/>` is specified in **\<component\>** to refer to this element, the definition inside **\<namedElements\>** must have the required child elements, but the **\<component\>** element doesn't need to have the required child elements.
- **File names with brackets**.
- **File names with brackets.**
If you're migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character. The carat (^) character must be directly before the bracket for the bracket character to be valid. For example, if there's a file named **file].txt**, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern>` instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
If a file that has a bracket character (\[ or \]) in the file name is being migrated, a carat (^) character must be inserted. The carat (^) character must be directly before the bracket for the bracket character to be valid. For example, if there's a file named **file].txt**, `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern>` must be specified instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
- **Using quotation marks**.
- **Using quotation marks.**
When you surround code in quotation marks, you can use either double ("") or single (') quotation marks.
When code is surrounded in quotation marks, either the double ("") or the single (') quotation marks can be used.
## Helper functions
You can use the XML helper functions in the [XML elements library](usmt-xml-elements-library.md) to change migration behavior. Before you use these functions in an **.xml** file, note the following items:
The XML helper functions in the [XML elements library](usmt-xml-elements-library.md) can be used to change migration behavior. Before using these functions in an **.xml** file, note the following items:
- **All of the parameters are strings**.
- **All of the parameters are strings.**
- **You can leave NULL parameters blank**.
- **NULL parameters can be left blank.**
As with parameters with a default value convention, if you have a NULL parameter at the end of a list, you can leave it out. For example, the following function:
As with parameters with a default value convention, if there's a NULL parameter at the end of a list, it can be left out. For example, the following function:
```cmd
SomeFunction("My String argument",NULL,NULL)
@ -67,7 +67,7 @@ You can use the XML helper functions in the [XML elements library](usmt-xml-elem
SomeFunction("My String argument")
```
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object**.
- **The encoded location used in all the helper functions is an unambiguous string representation for the name of an object.**
The encoded location is composed of the node part, optionally followed by the leaf enclosed in square brackets. This format makes a clear distinction between nodes and leaves.
@ -91,11 +91,11 @@ You can use the XML helper functions in the [XML elements library](usmt-xml-elem
The registry is represented in a similar way. The default value of a registry key is represented as an empty **\[\]** construct. For example, the default value for the `HKLM\SOFTWARE\MyKey` registry key is **HKLM\\SOFTWARE\\MyKey\[\]**.
- **You specify a location pattern in a way that is similar to how you specify an actual location**.
- **A location pattern is specified in a way that is similar to how an actual location is specified.**
The exception is that both the node and leaf part accept patterns. However, a pattern from the node doesn't extend to the leaf.
For example, the pattern **c:\\Windows\\\\\*** matches the `\Windows` directory and all subdirectories, but it doesn't match any of the files in those directories. To match the files as well, you must specify **c:\\Windows\\\*\[\*\]**.
For example, the pattern **c:\\Windows\\\\\*** matches the `\Windows` directory and all subdirectories, but it doesn't match any of the files in those directories. To match the files as well, **c:\\Windows\\\*\[\*\]** must be specified.
## Related articles

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

18
windows/deployment/usmt/usmt-how-it-works.md
View File

@ -7,7 +7,7 @@ ms.prod: windows-client
author: frankroj
ms.topic: article
ms.technology: itpro-deploy
ms.date: 01/02/2024
ms.date: 01/03/2024
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>
@ -23,7 +23,7 @@ USMT includes two tools that migrate settings and data: **ScanState** and **Load
## The ScanState process
When you run the **ScanState** tool on the source computer, it goes through the following process:
When the **ScanState** tool runs on the source computer, it goes through the following process:
1. It parses and validates the command-line parameters, creates the `ScanState.log` file, and then begins logging.
@ -39,9 +39,9 @@ When you run the **ScanState** tool on the source computer, it goes through the
The **ScanState** tool collects information about the application settings and user data components from the **.xml** files that are specified on the command line.
In currently supported versions of Windows, the manifest files control how the operating-system settings are migrated. You can't modify these files. If you want to exclude certain operating-system settings, you must create and modify a `Config.xml` file.
In currently supported versions of Windows, the manifest files control how the operating-system settings are migrated. These files can't be modified. To exclude certain operating-system settings, a `Config.xml` file must be created and modified.
1. **ScanState** determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, you can include and exclude users using the User Options. The public profile in a source computer running currently supported versions of Windows is always migrated, and you can't exclude these profiles from the migration.
1. **ScanState** determines which user profiles should be migrated. By default, all user profiles on the source computer are migrated. However, users can be included and excluded using the [User options](usmt-scanstate-syntax.md#user-options). The System profile and the Public profile in a source computer running currently supported versions of Windows is always migrated, and these profiles can't be excluded from the migration.
1. In the **Scanning** phase, **ScanState** does the following for each user profile selected for migration:
@ -83,11 +83,11 @@ The **LoadState** process is similar to the **ScanState** process. The **ScanSta
**LoadState** obtains information for the application-settings components and user-data components from the migration **.xml** files that are specified by the `LoadState.exe` command.
In currently supported versions of Windows, the manifest files control how the operating-system settings are migrated. You can't modify these files. If you want to exclude certain operating-system settings, you must create and modify a `Config.xml` file.
In currently supported versions of Windows, the manifest files control how the operating-system settings are migrated. These files can't be modified. To exclude certain operating-system settings, a `Config.xml` file must be created and modified.
1. **LoadState** determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, you can include and exclude users using the **User Options**. The system profile, the Public profile in a source computer running currently supported versions of Windows is always migrated and you can't exclude these profiles from the migration.
1. **LoadState** determines which user profiles should be migrated. By default, all user profiles present on the source computer are migrated. However, users can be included and excluded using the [User options](usmt-loadstate-syntax.md#user-options). The System profile and the Public profile in a source computer running currently supported versions of Windows is always migrated and these profiles can't be excluded from the migration.
- If you're migrating local user accounts and if the accounts don't already exist on the destination computer, you must use the `/lac` command-line option. If you don't specify the `/lac` option, any local user accounts that aren't already present on the destination computer, aren't migrated.
- If local user accounts are being migrated and if the accounts don't already exist on the destination computer, the `/lac` command-line option must be used. If the `/lac` option isn't specified, any local user accounts that aren't already present on the destination computer, aren't migrated.
- When specified with the `LoadState.exe` command, the `/md` and `/mu` options are processed to rename the user profile on the destination computer.
@ -117,9 +117,9 @@ The **LoadState** process is similar to the **ScanState** process. The **ScanSta
> [!IMPORTANT]
>
> It's important to specify the **.xml** files with the `LoadState.exe` command if you want **LoadState** to use them. Otherwise, any destination-specific rules, such as **\<locationModify\>**, in these **.xml** files are ignored, even if the same **.xml** files were provided when the `ScanState.exe` command ran.
> For **LoadState** to use the **.xml** files, it's important to specify them with the `LoadState.exe` command. Otherwise, any destination-specific rules, such as **\<locationModify\>**, in these **.xml** files are ignored, even if the same **.xml** files were provided when the `ScanState.exe` command ran.
1. In the **Apply** phase, **LoadState** writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there isn't a **\<merge\>** rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, don't take effect until the next time the user logs on. For this reason, you should sign out when the `LoadState.exe` command actions are finished.
1. In the **Apply** phase, **LoadState** writes the migration units that were collected to the various locations on the destination computer. If there are conflicts and there isn't a **\<merge\>** rule for the object, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally, for example, OriginalFileName(1).OriginalExtension. Some settings, such as fonts, wallpaper, and screen-saver settings, don't take effect until the next time the user logs on. For this reason, sign out when the `LoadState.exe` command actions are finished.
## Related articles

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/usmt-identify-application-settings.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

20
windows/deployment/usmt/usmt-identify-users.md
View File

@ -1,6 +1,6 @@
---
title: Identify Users
description: Learn how to identify users you plan to migrate, and how to migrate local accounts and domain accounts.
description: Learn how to identify users that need to be migrated, and how to migrate local accounts and domain accounts.
manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
@ -8,7 +8,7 @@ author: frankroj
ms.topic: article
ms.localizationpriority: medium
ms.technology: itpro-deploy
ms.date: 01/02/2024
ms.date: 01/03/2024
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>
@ -16,17 +16,17 @@ appliesto:
# Identify users
It's important to carefully consider how you plan to migrate users. By default, User State Migration Tool (USMT) migrates all users. You must specify which users to include by using the command line. You can't specify users in the **.xml** files. For instructions on how to migrate users, see [Migrate user accounts](usmt-migrate-user-accounts.md).
It's important to carefully consider and plan how users are migrated. By default, User State Migration Tool (USMT) migrates all users. Which users to include must be specified by using the command line. Users can't be specified in the **.xml** files. For instructions on how to migrate users, see [Migrate user accounts](usmt-migrate-user-accounts.md).
## Migrating local accounts
Before migrating local accounts, be aware of the following items:
- **You must explicitly specify that local accounts that are not on the destination computer should be migrated**. If you're migrating local accounts and the local account doesn't exist on the destination computer, you must use the `/lac` option when using the `LoadState.exe` command. If the `/lac` option isn't specified, no local user accounts are migrated.
- **Local accounts that aren't on the destination computer must be explicitly specified if they should be migrated.** If migrating local accounts and the local account doesn't exist on the destination computer, the `/lac` option must be specified when using the `LoadState.exe` command. If the `/lac` option isn't specified, no local user accounts are migrated.
- **Consider whether to enable user accounts that are new to the destination computer.** The `/lae` option enables the account that was created with the `/lac` option. However, if you create a disabled local account by using only the `/lac` option, a local administrator must enable the account on the destination computer.
- **Consider whether to enable user accounts that are new to the destination computer.** The `/lae` option enables the account that was created with the `/lac` option. However, if a disabled local account is created by using only the `/lac` option, a local administrator must enable the account on the destination computer.
- **Be careful when specifying a password for local accounts.** If you create the local account with a blank password, anyone could sign in that account on the destination computer. If you create the local account with a password, the password is available to anyone with access to the USMT command-line tools.
- **Be careful when specifying a password for local accounts.** If the local account is created with a blank password, anyone could sign in that account on the destination computer. If the local account is created with a password, the password is available to anyone with access to the USMT command-line tools.
> [!NOTE]
>
@ -40,17 +40,17 @@ The source and destination computers don't need to be connected to the domain fo
USMT provides several options to migrate multiple users on a single computer. The following command-line options specify which users to migrate.
- **Specifying users.** You can specify which users to migrate with the `/all`, `/ui`, `/uel`, and `/ue` options with both the **ScanState** and **LoadState** command-line tools.
- **Specifying users.** Which users to migrate can be specified with the `/all`, `/ui`, `/uel`, and `/ue` options with both the **ScanState** and **LoadState** command-line tools.
> [!IMPORTANT]
>
> The `/uel` option excludes users based on the **LastModified** date of the `Ntuser.dat` file. The `/uel` option isn't valid in offline migrations.
- **Moving users to another domain.** You can move user accounts to another domain using the `/md` option with the **LoadState** command-line tool.
- **Moving users to another domain.** User accounts can be moved to another domain using the `/md` option with the **LoadState** command-line tool.
- **Creating local accounts.** You can create and enable local accounts using the `/lac` and `/lae` options with the **LoadState** command-line tool.
- **Creating local accounts.** Local accounts can be created and enabled using the `/lac` and `/lae` options with the **LoadState** command-line tool.
- **Renaming user accounts.** You can rename user accounts using the `/mu` option.
- **Renaming user accounts.** User accounts can be renamed using the `/mu` option.
> [!NOTE]
>

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -15,7 +15,7 @@ appliesto:
# USMT log files
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:
User State Migration Tool (USMT) logs can be used 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.
@ -33,15 +33,16 @@ The following table describes each command-line option related to logs, and it p
|Set the environment variable **MIG_ENABLE_DIAG** to a path to an XML file.|`USMTDiag.xml`|The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.|
> [!NOTE]
> You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run.
>
> The log files can't be stored in *StorePath*. If the log files are stored in *StorePath*, the log files are overwritten when USMT runs.
## 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 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).
**ScanState** and **LoadState** logs are text files that are created when the **ScanState** and **LoadState** tools run. These logs can be used to help monitor the migration. The content of the log depends on the command-line options that are used and the verbosity level that is specified. 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 the monitoring systems. The first three fields in each line are fixed as follows:
A progress log can be created 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.
@ -79,7 +80,7 @@ The List files log (`Listfiles.txt`) provides a list of the files that were migr
## Diagnostic log
You can obtain the diagnostic log by setting the environment variable **MIG_ENABLE_DIAG** to a path to an XML file.
The diagnostic log can be obtained by setting the environment variable **MIG_ENABLE_DIAG** to a path to an XML file.
The diagnostic log contains:
@ -93,7 +94,7 @@ The diagnostic log contains:
The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data. In the XML files, the component identifies the migunit that the migunit is associated with. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files.
The following examples describe common scenarios in which you can use the diagnostic log.
The following examples describe common scenarios in which the diagnostic log can be used.
**Why is this file not migrating when I authored an "include" rule for it?**
@ -117,7 +118,7 @@ The directory of `C:\data\New Folder` contains:
1 File(s) 0 bytes
```
To migrate these files you author the following migration XML:
To migrate these files the following migration XML is authored:
```xml
<?xml version="1.0" encoding="UTF-8"?>
@ -139,7 +140,7 @@ To migrate these files you author the following migration XML:
</migration>
```
However, upon testing the migration you notice that the **New Text Document.txt** file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable **MIG_ENABLE_DIAG** set such that the diagnostic log is generated. Searching the diagnostic log for the component **DATA1** reveals the following XML section:
However, upon testing the migration, the **New Text Document.txt** file is noticed that it wasn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable **MIG_ENABLE_DIAG** set such that the diagnostic log is generated. Searching the diagnostic log for the component **DATA1** reveals the following XML section:
```xml
<MigUnitList>
@ -191,7 +192,7 @@ This diagnostic log confirms that the modified **\<pattern\>** value enables the
**Why is this file migrating when I authored an exclude rule excluding it?**
In this scenario, you have the following directory structure and you want all files in the **Data** directory to migrate, except for text files. The `C:\Data` folder contains:
In this scenario, the following directory structure exists and all files in the **Data** directory should migrate, except for text files. The `C:\Data` folder contains:
```cmd
Directory of C:\Data
@ -213,7 +214,7 @@ The `C:\Data\New Folder\` contains:
1 File(s) 0 bytes
```
You author the following migration XML:
The following migration XML is authored:
```xml
<?xml version="1.0" encoding="UTF-8"?>
@ -241,7 +242,7 @@ You author the following migration XML:
</component>
```
However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable **MIG_ENABLE_DIAG** set so that the diagnostic log is generated. Searching the diagnostic log for the component **DATA1** reveals the following XML section:
However, upon testing the migration, all the text files are noticed that they're still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable **MIG_ENABLE_DIAG** set so that the diagnostic log is generated. Searching the diagnostic log for the component **DATA1** reveals the following XML section:
```xml
<MigUnitList>
@ -267,7 +268,7 @@ However, upon testing the migration you notice that all the text files are still
</Perform>
```
Upon reviewing the diagnostic log, you confirm that the files are still migrating, and that it's a problem with the authored migration XML rule. You author an update to the migration XML script as follows:
When the diagnostic log is reviewed, the files are still migrating is confirmed, and that it's a problem with the authored migration XML rule. An update is authored to the migration XML script as follows:
```xml
<?xml version="1.0" encoding="UTF-8"?>

2
windows/deployment/usmt/usmt-migrate-efs-files-and-certificates.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

4
windows/deployment/usmt/usmt-migrate-user-accounts.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -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. Users can't be specified 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 [ScanState User options](usmt-scanstate-syntax.md#user-options) and the [LoadState User options](usmt-loadstate-syntax.md#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

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

@ -6,7 +6,7 @@ ms.technology: itpro-deploy
author: frankroj
manager: aaroncz
ms.author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: overview
ms.collection:
- highpri
@ -26,7 +26,7 @@ USMT enables the following actions:
- 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. 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).
- 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

2
windows/deployment/usmt/usmt-plan-your-migration.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/usmt-recognized-environment-variables.md
View File

@ -6,7 +6,7 @@ ms.technology: itpro-deploy
manager: aaroncz
ms.author: frankroj
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: conceptual
ms.collection:
- highpri

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:
@ -21,7 +21,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.|
|[How USMT works](usmt-how-it-works.md)|Learn about the processes behind the **ScanState** and **LoadState** tools.|
|[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.|

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/usmt-test-your-migration.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/usmt-what-does-usmt-migrate.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/usmt-xml-elements-library.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

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

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto:

2
windows/deployment/usmt/xml-file-requirements.md
View File

@ -5,7 +5,7 @@ manager: aaroncz
ms.author: frankroj
ms.prod: windows-client
author: frankroj
ms.date: 01/02/2024
ms.date: 01/03/2024
ms.topic: article
ms.technology: itpro-deploy
appliesto: