deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 21:37:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Freshness 04-12-2023 7

Browse Source
This commit is contained in:
Frank Rojas 2023-12-06 13:16:59 -05:00
parent 9444811f5f
commit acdc9a8615
7 changed files with 188 additions and 92 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -110,7 +110,9 @@ Use an `Offline.xml` file when running the ScanState tool on a computer that has
This element contains other elements that define how an offline migration is to be performed. This element contains other elements that define how an offline migration is to be performed.
```XML Syntax:
```xml
<offline> </offline> <offline> </offline>
``` ```
@ -118,7 +120,9 @@ This element contains other elements that define how an offline migration is to
This element is a required child of **&lt;offline&gt;** and contains information about how the offline volume can be selected. The migration is performed from the first element of **&lt;winDir&gt;** that contains a valid Windows system volume. This element is a required child of **&lt;offline&gt;** and contains information about how the offline volume can be selected. The migration is performed from the first element of **&lt;winDir&gt;** that contains a valid Windows system volume.
```XML Syntax:
```xml
<winDir> </winDir> <winDir> </winDir>
``` ```
@ -126,13 +130,17 @@ This element is a required child of **&lt;offline&gt;** and contains information
This element is a required child of **&lt;winDir&gt;** 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 **&lt;winDir&gt;** and contains a file path pointing to a valid Windows directory. Relative paths are interpreted from the ScanState tool's working directory.
```XML Syntax:
```xml
<path> C:\Windows </path> <path> C:\Windows </path>
``` ```
or when used with the **&lt;mappings&gt;** element: or when used with the **&lt;mappings&gt;** element:
```XML Syntax:
```xml
<path> C:\, D:\ </path> <path> C:\, D:\ </path>
``` ```
@ -140,7 +148,9 @@ or when used with the **&lt;mappings&gt;** element:
This element is an optional child of **&lt;offline&gt;**. When specified, the **&lt;mappings&gt;** element overrides the automatically detected WinPE drive mappings. Each child **&lt;path&gt;** element provides a mapping from one system volume to another. Additionally, mappings between folders can be provided, since an entire volume can be mounted to a specific folder. This element is an optional child of **&lt;offline&gt;**. When specified, the **&lt;mappings&gt;** element overrides the automatically detected WinPE drive mappings. Each child **&lt;path&gt;** element provides a mapping from one system volume to another. Additionally, mappings between folders can be provided, since an entire volume can be mounted to a specific folder.
```XML Syntax:
```xml
<mappings> </mappings> <mappings> </mappings>
``` ```
@ -148,13 +158,17 @@ This element is an optional child of **&lt;offline&gt;**. When specified, the **
This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn't present, the default behavior is that the migration doesn't fail. This element is an optional child of **&lt;offline&gt;**. The **&lt;failOnMultipleWinDir&gt;** element allows the user to specify that the migration should fail when USMT detects that there are multiple instances of Windows installed on the source machine. When the **&lt;failOnMultipleWinDir&gt;** element isn't present, the default behavior is that the migration doesn't fail.
```XML Syntax:
```xml
<failOnMultipleWinDir>1</failOnMultipleWinDir> <failOnMultipleWinDir>1</failOnMultipleWinDir>
``` ```
or or
```XML Syntax:
```xml
<failOnMultipleWinDir>0</failOnMultipleWinDir> <failOnMultipleWinDir>0</failOnMultipleWinDir>
``` ```
@ -162,7 +176,7 @@ or
The following XML example illustrates some of the elements discussed earlier in this article. The following XML example illustrates some of the elements discussed earlier in this article.
```XML ```xml
<offline> <offline>
<winDir> <winDir>
<path>C:\Windows</path> <path>C:\Windows</path>

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

@ -208,7 +208,7 @@ To generate the XML migration rules file for a source computer:
ScanState.exe /genmigxml: <filepath.xml> ScanState.exe /genmigxml: <filepath.xml>
``` ```
Where: where:
- **&lt;USMTpath&gt;** - location on your source computer of the saved USMT files and tools. - **&lt;USMTpath&gt;** - location on your source computer of the saved USMT files and tools.
- **&lt;filepath.xml&gt;** - full path to a file where you can save the report. - **&lt;filepath.xml&gt;** - full path to a file where you can save the report.

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

@ -1,18 +1,18 @@
--- ---
title: USMT Best Practices (Windows 10) title: USMT Best Practices
description: This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0. description: This article discusses general and security-related best practices when using User State Migration Tool (USMT).
manager: aaroncz manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
author: frankroj author: frankroj
ms.date: 11/01/2022 ms.date: 12/06/2023
ms.topic: article ms.topic: article
ms.technology: itpro-deploy ms.technology: itpro-deploy
--- ---
# USMT best practices # USMT best practices
This article discusses general and security-related best practices when using User State Migration Tool (USMT) 10.0. This article discusses general and security-related best practices when using User State Migration Tool (USMT).
## General best practices ## General best practices
@ -22,15 +22,15 @@ This article discusses general and security-related best practices when using Us
- **Don't use MigUser.xml and MigDocs.xml together** - **Don't use MigUser.xml and MigDocs.xml together**
If you use both .xml files, some migrated files may be duplicated if conflicting instructions are given about target locations. You can use the `/genmigxml` command-line option to determine which files will be included in your migration, and to determine if any modifications are necessary. For more information, see [Identify file types, files, and folders](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 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).
- **Use MigDocs.xml for a better migration experience** - **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 will gather 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 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.
- **Close all applications before running either the ScanState or LoadState tools** - **Close all applications before running either the ScanState or LoadState tools**
Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch USMT will fail when it can't migrate a file or setting. When you use the `/c` option, USMT will ignore any files or settings that it can't migrate and log an error each time. Although using the `/vsc` switch can allow the migration of many files that are open with another application, it's a best practice to close all applications in order to ensure all files and settings migrate. Without the `/vsc` or `/c` switch, USMT fails when it can't migrate a file or setting. When you use the `/c` option, USMT ignores any files or settings that it can't migrate and log an error each time.
- **Log off after you run the LoadState** - **Log off after you run the LoadState**
@ -38,7 +38,7 @@ This article discusses general and security-related best practices when using Us
- **Managed environment** - **Managed environment**
To create a managed environment, you can move all of the end user's documents into My Documents (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders will help you to clean up files on the destination computer, if the `LoadState.exe` command fails before completion. To create a managed environment, you can move all of the end user's documents into My Documents (%CSIDL\_PERSONAL%). We recommend that you migrate files into the smallest-possible number of folders on the destination computer. Minimizing folders helps to clean up files on the destination computer if the `LoadState.exe` command fails before completion.
- **Chkdsk.exe** - **Chkdsk.exe**
@ -46,7 +46,7 @@ This article discusses general and security-related best practices when using Us
- **Migrate in groups** - **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 impact on network performance, determine the size of the groups based on the size of each user account. Migrating in phases also allows you to make sure each phase is successful before starting the next phase. Using this method, you can make any necessary modifications to your plan between groups. 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.
## Security best practices ## Security best practices
@ -57,7 +57,8 @@ As the authorized administrator, it is your responsibility to protect the privac
Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md). Take extreme caution when migrating encrypted files, because the end user doesn't need to be logged on to capture the user state. By default, USMT fails if an encrypted file is found. For specific instructions about EFS best practices, see [Migrate EFS Files and Certificates](usmt-migrate-efs-files-and-certificates.md).
> [!NOTE] > [!NOTE]
> If you migrate an encrypted file without also migrating the certificate, end users will not be able to access the file after the migration. >
> If you migrate an encrypted file without also migrating the certificate, end users won't be able to access the file after the migration.
- **Encrypt the store** - **Encrypt the store**
@ -73,7 +74,7 @@ As the authorized administrator, it is your responsibility to protect the privac
- **Password Migration** - **Password Migration**
To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications such as Windows Live™ Mail, Microsoft Internet Explorer®, and Remote Access Service (RAS) connections and mapped network drives. It's important to make sure that end users know their passwords. To ensure the privacy of the end users, USMT doesn't migrate passwords, including passwords for applications or mapped network drives. It's important to make sure that end users know their passwords.
- **Local Account Creation** - **Local Account Creation**
@ -96,11 +97,11 @@ As the authorized administrator, it is your responsibility to protect the privac
- **Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax** - **Use the XML Schema (MigXML.xsd) when authoring .xml files to validate syntax**
The `MigXML.xsd` schema file shouldn't be included on the command line or in any of the .xml files. The `MigXML.xsd` schema file shouldn't be included on the command line or in any of the **.xml** files.
- **Use the default migration XML files as models** - **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, 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.
- **Consider the impact on performance when using the &lt;context&gt; parameter** - **Consider the impact on performance when using the &lt;context&gt; parameter**
@ -113,7 +114,8 @@ As the authorized administrator, it is your responsibility to protect the privac
In the **UserAndSystem** context, a rule is processed one time for each user on the system and one time for the system. In the **UserAndSystem** context, a rule is processed one time for each user on the system and one time for the system.
> [!NOTE] > [!NOTE]
> The number of times a rule is processed does not affect the number of times a file is migrated. The USMT migration engine ensures that each file migrates only once. >
> 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.
- **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files** - **We recommend that you create a separate .xml file instead of adding your .xml code to one of the existing migration .xml files**
@ -121,15 +123,15 @@ As the authorized administrator, it is your responsibility to protect the privac
- **You should not create custom .xml files to alter the operating system settings that are migrated** - **You should not create custom .xml files to alter the operating system settings that are migrated**
These settings are migrated by manifests and you can't modify those files. If you want to exclude certain operating system settings from the migration, you should create and modify a `Config.xml` file. Manifest files determine what settings are migrated. Manifest files can't be modified. Since manifest files can't be modified, to exclude certain operating system settings from the migration, create and modify a `Config.xml` file instead.
- **You can use the asterisk (\*) wildcard character in any migration XML file that you create** - **You can use the asterisk (\*) wildcard character in any migration XML file that you create**
> [!NOTE] > [!NOTE]
> The question mark is not valid as a wildcard character in USMT .xml files. >
> The question mark isn't valid as a wildcard character in USMT **.xml** files.
## Related articles ## Related articles
[Migration store encryption](usmt-migration-store-encryption.md) - [Migration store encryption](usmt-migration-store-encryption.md).
- [Plan your migration](usmt-plan-your-migration.md).
[Plan your migration](usmt-plan-your-migration.md)

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

@ -1,18 +1,23 @@
--- ---
title: Choose a Migration Store Type (Windows 10) 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 your organization.
manager: aaroncz manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
author: frankroj author: frankroj
ms.date: 11/01/2022 ms.date: 12/06/2023
ms.topic: article ms.topic: article
ms.technology: itpro-deploy ms.technology: itpro-deploy
--- ---
# Choose a migration store type # Choose a migration store type
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you're using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store. 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:
- How much space is required to run the User State Migration Tool (USMT) components on your 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.
## In this section ## In this section
@ -25,6 +30,5 @@ One of the main considerations for planning your migration is to determine which
## Related articles ## Related articles
[Plan your migration](usmt-plan-your-migration.md) - [Plan your migration](usmt-plan-your-migration.md)
- [User State Migration Tool (USMT) how-articles](usmt-how-to.md)
[User State Migration Tool (USMT) how-to topics](usmt-how-to.md)

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

@ -1,18 +1,18 @@
--- ---
title: User State Migration Tool (USMT) Command-line Syntax (Windows 10) 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 manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
author: frankroj author: frankroj
ms.date: 11/01/2022 ms.date: 12/06/2023
ms.topic: article ms.topic: article
ms.technology: itpro-deploy ms.technology: itpro-deploy
--- ---
# User State Migration Tool (USMT) command-line syntax # User State Migration Tool (USMT) command-line syntax
The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation. The User State Migration Tool (USMT) migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation.
## In this Section ## In this Section

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

@ -1,62 +1,71 @@
--- ---
title: Common Migration Scenarios (Windows 10) title: Common Migration Scenarios
description: See how the User State Migration Tool (USMT) 10.0 is used when planning hardware and/or operating system upgrades. description: See how the User State Migration Tool (USMT) is used when planning hardware and/or operating system upgrades.
manager: aaroncz manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
author: frankroj author: frankroj
ms.date: 11/01/2022 ms.date: 12/23/2023
ms.topic: article ms.topic: article
ms.technology: itpro-deploy ms.technology: itpro-deploy
--- ---
# Common Migration Scenarios # Common Migration Scenarios
You use the User State Migration Tool (USMT) 10.0 when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing the user's operating-system settings, application settings, and personal files from a source computer and reinstalling them on a destination computer after the upgrade has occurred. You use the User State Migration Tool (USMT) when hardware and/or operating system upgrades are planned for a large number of computers. USMT manages the migration of an end-user's digital identity by capturing from a source computer the following user's items:
One common scenario is when the operating system is upgraded on existing hardware without the hardware being replaced. This scenario is referred to as *PC-refresh*. A second common scenario is known as *PC replacement*, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system. - Operating-system settings.
- Application settings.
- Personal files.
Once these items are capture, they're reinstalled on a destination computer after the upgrade completes.
One common scenario is when the operating system is upgraded on existing hardware without the hardware being replaced. This scenario is referred to as **PC-refresh**. A second common scenario is known as **PC replacement**, where one piece of hardware is being replaced, typically by newer hardware and a newer operating system.
## PC-refresh ## PC-refresh
The following diagram shows a PC-refresh migration, also known as a computer refresh migration. First, the administrator migrates the user state from a source computer to an intermediate store. After installing the operating system, the administrator migrates the user state back to the source computer. The following diagram shows a PC-refresh migration, also known as a computer refresh migration. First, the administrator migrates the user state from a source computer to an intermediate store. After the administrator installs the operating system, they migrate the user state back to the source computer.
![usmt pc refresh scenario.](images/dep-win8-l-usmt-pcrefresh.jpg) ![usmt pc refresh scenario.](images/dep-win8-l-usmt-pcrefresh.jpg)
### Scenario One: PC-refresh offline using Windows PE and a hard-link migration store ### Scenario One: PC-refresh offline using Windows PE and a hard-link migration store
A company has received funds to update the operating system on all of its computers in the accounting department to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer. A company receives funds to update the operating system on all of its computers in the accounting department to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, the update is being handled offline, without a network connection. An administrator uses Windows Preinstallation Environment (WinPE) and a hard-link migration store to save each user state to their respective computer.
1. On each computer, the administrator boots the machine into WinPE and runs the **ScanState** command-line tool, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive. 1. On each computer, the administrator boots the machine into WinPE and runs the **ScanState** command-line tool, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
2. On each computer, the administrator installs the company's standard operating environment (SOE) which includes Windows 10 and other company applications. 2. On each computer, the administrator installs the company's standard operating environment (SOE) which includes the latest supported version of Windows and other company applications.
3. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back to each computer. 3. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back to each computer.
### Scenario Two: PC-refresh using a compressed migration store ### Scenario Two: PC-refresh using a compressed migration store
A company has received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server. A company receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a compressed migration store to save the user states to a server.
1. The administrator runs the **ScanState** command-line tool on each computer. **ScanState** saves each user state to a server. 1. The administrator runs the **ScanState** command-line tool on each computer. **ScanState** saves each user state to a server.
2. On each computer, the administrator installs the company's standard SOE that includes Windows 10 and other company applications. 2. On each computer, the administrator installs the company's standard SOE that includes the latest supported version of Windows and other company applications.
3. The administrator runs the **LoadState** command-line tool on each source computer, and **LoadState** restores each user state back to the computer. 3. The administrator runs the **LoadState** command-line tool on each source computer, and **LoadState** restores each user state back to the computer.
### Scenario Three: PC-refresh using a hard-link migration store ### Scenario Three: PC-refresh using a hard-link migration store
A company has received funds to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer. A company receives funds to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses a hard-link migration store to save each user state to their respective computer.
1. The administrator runs the **ScanState** command-line tool on each computer, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive. 1. The administrator runs the **ScanState** command-line tool on each computer, specifying the `/hardlink /nocompress` command-line options. **ScanState** saves the user state to a hard-link migration store on each computer, improving performance by minimizing network traffic and minimizing migration failures on computers with limited space available on the hard drive.
2. On each computer, the administrator installs the company's SOE that includes Windows 10 and other company applications. 2. On each computer, the administrator installs the company's SOE that includes the latest supported version of Windows and other company applications.
3. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back on each computer. 3. The administrator runs the **LoadState** command-line tool on each computer. **LoadState** restores each user state back on each computer.
### Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store ### Scenario Four: PC-refresh using Windows.old folder and a hard-link migration store
A company has decided to update the operating system on all of its computers to Windows 10. Each employee will keep the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses Windows.old and a hard-link migration store to save each user state to their respective computer. A company decides to update the operating system on all of its computers to the latest supported version of Windows. Each employee keeps the same computer, but the operating system on each computer will be updated. In this scenario, an administrator uses Windows.old and a hard-link migration store to save each user state to their respective computer.
1. The administrator clean installs Windows 10 on each computer, making sure that the Windows.old directory is created by installing Windows 10 without formatting or repartitioning and by selecting a partition that contains the previous version of Windows. 1. The administrator clean installs the latest supported version of Windows on each computer. During the install, they make sure that the Windows.old directory is created by taking the following actions:
- Performing the install without formatting or repartitioning the disk.
- Selecting a partition that contains the previous version of Windows.
2. On each computer, the administrator installs the company's SOE that includes company applications. 2. On each computer, the administrator installs the company's SOE that includes company applications.
@ -64,7 +73,7 @@ A company has decided to update the operating system on all of its computers to
## PC-replacement ## PC-replacement
The following diagram shows a PC-replacement migration. First, the administrator migrates the user state from the source computer to an intermediate store. After installing the operating system on the destination computer, the administrator migrates the user state from the store to the destination computer. The following diagram shows a PC-replacement migration. First, the administrator migrates the user state from the source computer to an intermediate store. After the administrator installs the operating system on the destination computer, they migrate the user state from the store to the destination computer.
![usmt pc replace scenario.](images/dep-win8-l-usmt-pcreplace.jpg) ![usmt pc replace scenario.](images/dep-win8-l-usmt-pcreplace.jpg)
@ -74,7 +83,7 @@ A company is allocating 20 new computers to users in the accounting department.
1. On each source computer, an administrator boots the machine into WinPE and runs **ScanState** to collect the user state to either a server or an external hard disk. 1. On each source computer, an administrator boots the machine into WinPE and runs **ScanState** to collect the user state to either a server or an external hard disk.
2. On each new computer, the administrator installs the company's SOE that includes Windows 10 and other company applications. 2. On each new computer, the administrator installs the company's SOE that includes the latest supported version of Windows and other company applications.
3. On each of the new computers, the administrator runs the **LoadState** tool, restoring each user state from the migration store to one of the new computers. 3. On each of the new computers, the administrator runs the **LoadState** tool, restoring each user state from the migration store to one of the new computers.
@ -84,11 +93,11 @@ A company receives 50 new laptops for their managers and needs to reallocate 50
1. The administrator runs the **ScanState** tool on each of the manager's old laptops, and saves each user state to a server. 1. The administrator runs the **ScanState** tool on each of the manager's old laptops, and saves each user state to a server.
2. On the new laptops, the administrator installs the company's SOE, which includes Windows 10 and other company applications. 1. On the new laptops, the administrator installs the company's SOE, which includes the latest supported version of Windows and other company applications.
3. The administrator runs the **LoadState** tool on the new laptops to migrate the managers' user states to the appropriate computer. The new laptops are now ready for the managers to use. 1. The administrator runs the **LoadState** tool on the new laptops to migrate the managers' user states to the appropriate computer. The new laptops are now ready for the managers to use.
4. On the old computers, the administrator installs the company's SOE, which includes Windows 10, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use. 1. On the old computers, the administrator installs the company's SOE, which includes the latest supported version of Windows, Microsoft Office, and other company applications. The old computers are now ready for the new employees to use.
### Scenario Three: Managed network migration ### Scenario Three: Managed network migration
@ -96,14 +105,12 @@ A company is allocating 20 new computers to users in the accounting department.
1. On each source computer, the administrator runs the **ScanState** tool using Microsoft Configuration Manager, Microsoft Deployment Toolkit (MDT), a sign-in script, a batch file, or a non-Microsoft management technology. **ScanState** collects the user state from each source computer and then saves it to a server. 1. On each source computer, the administrator runs the **ScanState** tool using Microsoft Configuration Manager, Microsoft Deployment Toolkit (MDT), a sign-in script, a batch file, or a non-Microsoft management technology. **ScanState** collects the user state from each source computer and then saves it to a server.
2. On each new computer, the administrator installs the company's SOE, which includes Windows 10 and other company applications. 1. On each new computer, the administrator installs the company's SOE, which includes the latest supported version of Windows and other company applications.
3. On each of the new computers, the administrator runs the **LoadState** tool using Microsoft Configuration Manager, a sign-in script, a batch file, or a non-Microsoft management technology. **LoadState** migrates each user state from the migration store to one of the new computers. 1. On each of the new computers, the administrator runs the **LoadState** tool using Microsoft Configuration Manager, a sign-in script, a batch file, or a non-Microsoft management technology. **LoadState** migrates each user state from the migration store to one of the new computers.
## Related articles ## Related articles
[Plan your migration](usmt-plan-your-migration.md) - [Plan your migration](usmt-plan-your-migration.md).
- [Choose a migration store type](usmt-choose-migration-store-type.md).
[Choose a migration store type](usmt-choose-migration-store-type.md) - [Offline migration reference](offline-migration-reference.md).
[Offline migration reference](offline-migration-reference.md)

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

@ -1,22 +1,22 @@
--- ---
title: Config.xml File (Windows 10) title: Config.xml File
description: Learn how the Config.xml file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the /genconfig option with the ScanState.exe tool. description: Learn how the Config.xml file is an optional User State Migration Tool (USMT) file that you can create using the /genconfig option with the ScanState.exe tool.
manager: aaroncz manager: aaroncz
ms.author: frankroj ms.author: frankroj
ms.prod: windows-client ms.prod: windows-client
author: frankroj author: frankroj
ms.date: 11/01/2022 ms.date: 12/06/2023
ms.topic: article ms.topic: article
ms.technology: itpro-deploy ms.technology: itpro-deploy
--- ---
# Config.xml File # Config.xml File
The `Config.xml` file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the `/genconfig` option with the ScanState tool. If you want to include all of the default components, and don't want to change the default store-creation or profile-migration behavior, you don't need to create a `Config.xml` file. The `Config.xml` file is an optional User State Migration Tool (USMT) file that you can create using the `/genconfig` option with the ScanState tool. If you want to include all of the default components, and don't want to change the default store-creation or profile-migration behavior, you don't need to create a `Config.xml` file.
However, if you're satisfied with the default migration behavior defined in the `MigApp.xml`, `MigUser.xml` and `MigDocs.xml` files, but you want to exclude certain components, you can create and modify a `Config.xml` file and leave the other .xml files unchanged. For example, you must create and modify the `Config.xml` file if you want to exclude any of the operating-system settings that are migrated. It's necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior. However, if you're satisfied with the default migration behavior defined in the `MigApp.xml`, `MigUser.xml` and `MigDocs.xml` files, but you want to exclude certain components, you can create and modify a `Config.xml` file and leave the other **.xml** files unchanged. For example, you must create and modify the `Config.xml` file if you want to exclude any of the operating-system settings that are migrated. It's necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
The `Config.xml` file has a different format than the other migration .xml files, because it doesn't contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, and user-profile policy and error-control policy. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration .xml files, because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in this file. The `Config.xml` file has a different format than the other migration **.xml** files, because it doesn't contain any migration rules. It contains only a list of the operating-system components, applications, user documents that can be migrated, and user-profile policy and error-control policy. For this reason, excluding components using the `Config.xml` file is easier than modifying the migration **.xml** files, because you don't need to be familiar with the migration rules and syntax. However, you can't use wildcard characters in this file.
For more information about using the `Config.xml` file with other migration files, such as the `MigDocs.xml` and `MigApps.xml` files, see [Understanding Migration XML Files](understanding-migration-xml-files.md). For more information about using the `Config.xml` file with other migration files, such as the `MigDocs.xml` and `MigApps.xml` files, see [Understanding Migration XML Files](understanding-migration-xml-files.md).
@ -25,13 +25,17 @@ For more information about using the `Config.xml` file with other migration file
## Migration Policies ## Migration Policies
In USMT there are new migration policies that can be configured in the `Config.xml` file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. The following elements and parameters are for use in the `Config.xml` file only. In USMT, there are migration policies that can be configured in the `Config.xml` file. For example, you can configure **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. The following elements and parameters are for use in the `Config.xml` file only.
### &lt;Policies&gt; ### &lt;Policies&gt;
The **&lt;Policies&gt;** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **&lt;Policies&gt;** element are **&lt;ErrorControl&gt;** and **&lt;HardLinkStoreControl&gt;**. The **&lt;Policies&gt;** element is a child of **&lt;Configuration&gt;**. The **&lt;Policies&gt;** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **&lt;Policies&gt;** element are **&lt;ErrorControl&gt;** and **&lt;HardLinkStoreControl&gt;**. The **&lt;Policies&gt;** element is a child of **&lt;Configuration&gt;**.
Syntax: `<Policies>` `</Policies>` Syntax:
```xml
<Policies> </Policies>
```
### &lt;ErrorControl&gt; ### &lt;ErrorControl&gt;
@ -43,9 +47,13 @@ The **&lt;ErrorControl&gt;** element is an optional element you can configure in
- **Child elements**: The **&lt;fileError&gt;** and **&lt;registryError&gt;** element - **Child elements**: The **&lt;fileError&gt;** and **&lt;registryError&gt;** element
Syntax: `<ErrorControl>` `</ErrorControl>` Syntax:
The following example specifies that all locked files, regardless of their location (including files in C:\\Users), should be ignored. However, the migration fails if any file in C:\\Users can't be accessed because of any other reason. In the example below, the **&lt;ErrorControl&gt;** element ignores any problems in migrating registry keys that match the supplied pattern, and it resolves them to an **Access denied** error. ```xml
<ErrorControl> </ErrorControl>
```
The following example specifies that all locked files, regardless of their location (including files in C:\\Users), should be ignored. However, the migration fails if any file in C:\\Users can't be accessed because of any other reason. In the following example, the **&lt;ErrorControl&gt;** element ignores any problems in migrating registry keys that match the supplied pattern, and it resolves them to an **Access denied** error.
Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority. In this example, the first **&lt;nonFatal&gt;** tag takes precedence over the second **&lt;fatal&gt;** tag. This precedence is applied, regardless of how many tags are listed. Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority. In this example, the first **&lt;nonFatal&gt;** tag takes precedence over the second **&lt;fatal&gt;** tag. This precedence is applied, regardless of how many tags are listed.
@ -74,7 +82,11 @@ The **&lt;fatal&gt;** element isn't required.
- **Child elements**: None. - **Child elements**: None.
Syntax: `<fatal errorCode="any">` *&lt;pattern&gt;* `</fatal>` Syntax:
```xml
<fatal errorCode="any"> <*pattern*> </fatal>
```
|Parameter|Required|Value| |Parameter|Required|Value|
|--- |--- |--- | |--- |--- |--- |
@ -92,7 +104,11 @@ The **&lt;fileError&gt;** element isn't required.
- **Child elements**: **&lt;nonFatal&gt;** and **&lt;fatal&gt;** - **Child elements**: **&lt;nonFatal&gt;** and **&lt;fatal&gt;**
Syntax: `<fileError>` `</fileError>` Syntax:
```xml
<fileError> </fileError>
```
You use the **&lt;fileError&gt;** element to represent the behavior associated with file errors. You use the **&lt;fileError&gt;** element to represent the behavior associated with file errors.
@ -106,7 +122,11 @@ The **&lt;nonFatal&gt;** element isn't required.
- **Child elements**: None. - **Child elements**: None.
Syntax: `<nonfatal errorCode="any">` *&lt;pattern&gt;* `</nonFatal>` Syntax:
```xml
<nonfatal errorCode="any"> <*pattern*> </nonFatal>
```
|Parameter|Required|Value| |Parameter|Required|Value|
|--- |--- |--- | |--- |--- |--- |
@ -124,7 +144,11 @@ The **&lt;registryError&gt;** element isn't required.
- **Child elements**: **&lt;nonfatal&gt;** and **&lt;fatal&gt;** - **Child elements**: **&lt;nonfatal&gt;** and **&lt;fatal&gt;**
Syntax: `<registryError>` `</registryError>` Syntax:
```xml
<registryError> </registryError>
```
|Parameter|Required|Value| |Parameter|Required|Value|
|--- |--- |--- | |--- |--- |--- |
@ -136,7 +160,11 @@ You use the **&lt;registryError&gt;** element to specify that errors matching a
The **&lt;HardLinkStoreControl&gt;** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **&lt;fileLocked&gt;**. The **&lt;HardLinkStoreControl&gt;** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **&lt;fileLocked&gt;**.
Syntax: `<HardLinkStoreControl>` `</HardLinkStoreControl>` Syntax:
```xml
<HardLinkStoreControl> </HardLinkStoreControl>
```
- **Number of occurrences**: Once for each component - **Number of occurrences**: Once for each component
@ -144,9 +172,13 @@ Syntax: `<HardLinkStoreControl>` `</HardLinkStoreControl>`
- **Child elements**: **&lt;fileLocked&gt;** - **Child elements**: **&lt;fileLocked&gt;**
Syntax: `<HardLinkStoreControl>` `</HardLinkStoreControl>` Syntax:
The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that can't be copied, even though is technically possible for the link to be created. ```xml
<HardLinkStoreControl> </HardLinkStoreControl>
```
The following **&lt;HardLinkStoreControl&gt;** sample code specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that can't be copied, even though is technically possible for the link to be created.
> [!IMPORTANT] > [!IMPORTANT]
> The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file's location. > The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file's location.
@ -169,37 +201,61 @@ The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links
The **&lt;fileLocked&gt;** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **&lt;fileLocked&gt;** element are processed in the order in which they appear in the XML file. The **&lt;fileLocked&gt;** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **&lt;fileLocked&gt;** element are processed in the order in which they appear in the XML file.
Syntax: `<fileLocked>` `</fileLocked>` Syntax:
```xml
<fileLocked> </fileLocked>
```
### &lt;createHardLink&gt; ### &lt;createHardLink&gt;
The **&lt;createHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application. The **&lt;createHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.
Syntax: `<createHardLink>` *&lt;pattern&gt;* `</createHardLink>` Syntax:
```xml
<createHardLink> <*pattern*> </createHardLink>
```
### &lt;errorHardLink&gt; ### &lt;errorHardLink&gt;
The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links shouldn't be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that isn't possible, **Error\_Locked** is thrown. This error is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration. The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links shouldn't be created if the file is locked for editing by another application. USMT attempts to copy files under these paths into the migration store. However, if that isn't possible, **Error\_Locked** is thrown. This error is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration.
Syntax: `<errorHardLink>` *&lt;pattern&gt;* `</errorHardLink>` Syntax:
```xml
<errorHardLink> <*pattern*> </errorHardLink>
```
### &lt;ProfileControl&gt; ### &lt;ProfileControl&gt;
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **&lt;ProfileMigration&gt;** is a child of **&lt;Configuration&gt;**. This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **&lt;ProfileMigration&gt;** is a child of **&lt;Configuration&gt;**.
Syntax: &lt;`ProfileControl>` `</ProfileControl>` Syntax:
```xml
<ProfileControl>` `</ProfileControl>
```
### &lt;localGroups&gt; ### &lt;localGroups&gt;
This element is used to contain other elements that establish rules for how to migrate local groups. **&lt;localGroups&gt;** is a child of **&lt;ProfileControl&gt;**. This element is used to contain other elements that establish rules for how to migrate local groups. **&lt;localGroups&gt;** is a child of **&lt;ProfileControl&gt;**.
Syntax: `<localGroups>` `</localGroups>` Syntax:
```xml
<localGroups> </localGroups>
```
### &lt;mappings&gt; ### &lt;mappings&gt;
This element is used to contain other elements that establish mappings between groups. This element is used to contain other elements that establish mappings between groups.
Syntax: `<mappings>` `</mappings>` Syntax:
```xml
<mappings> </mappings>
```
### &lt;changeGroup&gt; ### &lt;changeGroup&gt;
@ -213,23 +269,36 @@ This element describes the source and destination groups for a local group membe
The valid and required children of **&lt;changeGroup&gt;** are **&lt;include&gt;** and **&lt;exclude&gt;**. Although both can be children at the same time, only one is required. The valid and required children of **&lt;changeGroup&gt;** are **&lt;include&gt;** and **&lt;exclude&gt;**. Although both can be children at the same time, only one is required.
Syntax: `<changeGroup From="Group1" To= "Group2">` `</changeGroup>` Syntax:
```xml
<changeGroup From="Group1" To= "Group2"> </changeGroup>
```
### &lt;include&gt; ### &lt;include&gt;
This element specifies that its required child, *&lt;pattern&gt;*, should be included in the migration. This element specifies that its required child, *&lt;pattern&gt;*, should be included in the migration.
Syntax: `<include>` `</include>` Syntax:
```xml
<include> </include>
```
### &lt;exclude&gt; ### &lt;exclude&gt;
This element specifies that its required child, *&lt;pattern&gt;*, should be excluded from the migration. This element specifies that its required child, *&lt;pattern&gt;*, should be excluded from the migration.
Syntax: `<exclude>` `</exclude>` Syntax:
```xml
<exclude> </exclude>
```
## Sample Config.xml File ## Sample Config.xml File
Refer to the following sample `Config.xml` file for more details about items you can choose to exclude from a migration. The following sample `Config.xml` file contains detailed examples about items you can choose to exclude from a migration.
<br> <br>
<br> <br>
<details> <details>
@ -430,4 +499,4 @@ Refer to the following sample `Config.xml` file for more details about items you
## Related articles ## Related articles
[USMT XML reference](usmt-xml-reference.md) - [USMT XML reference](usmt-xml-reference.md).