From 7f44584cab8a6cd72af2154aa5fb7baf562e5927 Mon Sep 17 00:00:00 2001 From: Frank Rojas <45807133+frankroj@users.noreply.github.com> Date: Thu, 21 Dec 2023 16:34:10 -0500 Subject: [PATCH] USMT Refresh 4 --- ...t-identify-file-types-files-and-folders.md | 12 +++--- ...usmt-identify-operating-system-settings.md | 2 +- .../deployment/usmt/usmt-identify-users.md | 23 +++++----- .../usmt/usmt-include-files-and-settings.md | 33 +++++++------- .../deployment/usmt/usmt-loadstate-syntax.md | 43 ++++++++++--------- 5 files changed, 57 insertions(+), 56 deletions(-) diff --git a/windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md b/windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md index 3547bcbda9..7cee08bbf9 100644 --- a/windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md +++ b/windows/deployment/usmt/usmt-identify-file-types-files-and-folders.md @@ -14,13 +14,13 @@ ms.technology: itpro-deploy When planning for your migration, if not using MigDocs.xml, you should identify the file types, files, folders, and settings that you want to migrate. First, you should determine the standard file locations on each computer, such as **My Documents** , `C:\Data` , and company-specified locations, such as `\\EngineeringDrafts`. Next, you should determine and locate the non-standard locations. For non-standard locations, consider the following items: -- **File types**. Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis. +- **File types**: Consider which file types need to be included and excluded from the migration. You can create this list based on common applications used in your organization. Applications normally use specific file name extensions. For example, Microsoft Office Word primarily uses `.doc`, `.docx` and `.dotx` file name extension. However, it also uses other file types, such as templates (`.dot` files), on a less frequent basis. -- **Excluded locations**. Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**). +- **Excluded locations**: Consider the locations on the computer that should be excluded from the migration (for example, `%WINDIR%` and **Program Files**). -- **New locations**. Decide where files should be migrated to on the destination computer, such as **My Documents**, a designated folder, or a folder matching the files' name and location on the source computer. For example, you might have shared data on source machine or you might wish to clean up documents outside the user profiles on the source system. Identify any data that needs to be redirected to a new location in the apply phase. Redirection can be accomplished with location modify rules. +- **New locations**: Decide where files should be migrated to on the destination computer, such as **My Documents**, a designated folder, or a folder matching the files' name and location on the source computer. For example, shared data might exist on the source machine or documents outside the user profiles on the source system might need to be cleaned up. Identify any data that needs to be redirected to a new location in the Apply phase. Redirection can be accomplished with location modify rules. -Once you've verified which files and file types that the end users work with regularly, you'll need to locate them. Files may be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer. +Once which files and file types that the end users work with regularly is verified, locate the files and file types. Files might be saved to a single folder or scattered across a drive. A good starting point for finding files types to include is to look at the registered file types on the computer. To find the registered file types on a computer running a currently supported version of Windows: @@ -34,8 +34,8 @@ To find the registered file types on a computer running a currently supported ve 1. In the window that opens, the registered file types are displayed. -For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) how-to topics](usmt-how-to.md). +For more information about how to change the file types, files, and folders that are migrated when you specify the MigUser.xml file, see [User State Migration Tool (USMT) how-to articles](usmt-how-to.md). ## Related articles -[Determine what to migrate](usmt-determine-what-to-migrate.md) +- [Determine what to migrate](usmt-determine-what-to-migrate.md). diff --git a/windows/deployment/usmt/usmt-identify-operating-system-settings.md b/windows/deployment/usmt/usmt-identify-operating-system-settings.md index 3c5b72e11f..f87f4c99de 100644 --- a/windows/deployment/usmt/usmt-identify-operating-system-settings.md +++ b/windows/deployment/usmt/usmt-identify-operating-system-settings.md @@ -28,7 +28,7 @@ When planning for your migration, you should identify which operating system set - **Internet** - The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your home page URL, favorites, bookmarks, cookies, security settings, and proxy settings. + The Internet factor includes the settings that let you connect to the Internet and control how your browser operates. The settings include items such as your home page URL, favorites, bookmarks, cookies, security settings, and proxy settings. These settings might not be supported in all browsers. - **Mail** diff --git a/windows/deployment/usmt/usmt-identify-users.md b/windows/deployment/usmt/usmt-identify-users.md index 40a4f58cb6..d16bbab476 100644 --- a/windows/deployment/usmt/usmt-identify-users.md +++ b/windows/deployment/usmt/usmt-identify-users.md @@ -1,5 +1,5 @@ --- -title: Identify Users (Windows 10) +title: Identify Users description: Learn how to identify users you plan to migrate, and how to migrate local accounts and domain accounts. manager: aaroncz ms.author: frankroj @@ -8,25 +8,26 @@ author: frankroj ms.topic: article ms.localizationpriority: medium ms.technology: itpro-deploy -ms.date: 11/01/2022 +ms.date: 12/21/2023 --- # Identify users -It's important to carefully consider how you plan to migrate users. By default, all users are migrated by User State Migration Tool (USMT) 5.0. 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 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). ## 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 will be migrated. +- **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. - **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. - **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. > [!NOTE] -> If there are multiple users on a computer, and you specify a password with the `/lac` option, all migrated users will have the same password. +> +> If there are multiple users on a computer, and a password is specified with the `/lac` option, all migrated users have the same password. ## Migrating domain accounts @@ -39,7 +40,8 @@ USMT provides several options to migrate multiple users on a single computer. Th - **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. > [!IMPORTANT] - > The `/uel` option excludes users based on the **LastModified** date of the `Ntuser.dat` file. The `/uel` option is not valid in offline migrations. + > + > 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. @@ -48,10 +50,11 @@ USMT provides several options to migrate multiple users on a single computer. Th - **Renaming user accounts.** You can rename user accounts using the `/mu` option. > [!NOTE] - >By default, if a user name is not specified in any of the command-line options, the user will be migrated. + > + > By default, if a user name isn't specified in any of the command-line options, the user is migrated. ## Related articles -- [Determine what to migrate](usmt-determine-what-to-migrate.md) -- [ScanState syntax](usmt-scanstate-syntax.md) -- [LoadState syntax](usmt-loadstate-syntax.md) +- [Determine what to migrate](usmt-determine-what-to-migrate.md). +- [ScanState syntax](usmt-scanstate-syntax.md). +- [LoadState syntax](usmt-loadstate-syntax.md). diff --git a/windows/deployment/usmt/usmt-include-files-and-settings.md b/windows/deployment/usmt/usmt-include-files-and-settings.md index 8e5821354c..f9b267cb37 100644 --- a/windows/deployment/usmt/usmt-include-files-and-settings.md +++ b/windows/deployment/usmt/usmt-include-files-and-settings.md @@ -1,22 +1,22 @@ --- -title: Include Files and Settings (Windows 10) -description: Specify the migration .xml files you want, then use the User State Migration Tool (USMT) 10.0 to migrate the settings and components specified. +title: Include Files and Settings +description: Specify the migration .xml files you want, then use the User State Migration Tool (USMT) to migrate the settings and components specified. manager: aaroncz ms.author: frankroj ms.prod: windows-client author: frankroj -ms.date: 11/01/2022 +ms.date: 12/21/2023 ms.topic: article ms.technology: itpro-deploy --- # Include Files and Settings -When you specify the migration .xml files, User State Migration Tool (USMT) 10.0 migrates the settings and components specified in [What does USMT migrate?](usmt-what-does-usmt-migrate.md). To include additional files and settings, we recommend that you create a custom .xml file, and then include this file when using both the `ScanState.exe` and `LoadState.exe` commands. By creating a custom .xml file, you can keep your changes separate from the default .xml files, which makes it easier to track your modifications. +When you specify the migration **.xml** files, User State Migration Tool (USMT) migrates the settings and components specified in [What does USMT migrate?](usmt-what-does-usmt-migrate.md). To include additional files and settings, we recommend that you create a custom **.xml** file, and then include this file when using both the `ScanState.exe` and `LoadState.exe` commands. By creating a custom **.xml** file, you can keep your changes separate from the default **.xml** files. Creating a custom **.xml** file makes it easier to track modifications. ## Migrate a single registry key -The following .xml file migrates a single registry key. +The following **.xml** file migrates a single registry key. ```xml @@ -41,7 +41,7 @@ The following examples show how to migrate a folder from a specific drive, and f ### Migrate a folder from a specific drive -- **Including subfolders.** The following .xml file migrates all files and subfolders from `C:\EngineeringDrafts` to the destination computer. +- **Including subfolders.** The following **.xml** file migrates all files and subfolders from `C:\EngineeringDrafts` to the destination computer. ```xml @@ -60,7 +60,7 @@ The following examples show how to migrate a folder from a specific drive, and f ``` -- **Excluding subfolders.** The following .xml file migrates all files from `C:\EngineeringDrafts`, but it doesn't migrate any subfolders within `C:\EngineeringDrafts`. +- **Excluding subfolders.** The following **.xml** file migrates all files from `C:\EngineeringDrafts`, but it doesn't migrate any subfolders within `C:\EngineeringDrafts`. ```xml @@ -81,7 +81,7 @@ The following examples show how to migrate a folder from a specific drive, and f ### Migrate a folder from any location -The following .xml file migrates all files and subfolders of the `EngineeringDrafts` folder from any drive on the computer. If multiple folders exist with the same name, then all files with this name are migrated. +The following **.xml** file migrates all files and subfolders of the `EngineeringDrafts` folder from any drive on the computer. If multiple folders exist with the same name, then all files with this name are migrated. ```xml @@ -101,7 +101,7 @@ The following .xml file migrates all files and subfolders of the `EngineeringDra ``` -The following .xml file migrates all files and subfolders of the `EngineeringDrafts` folder from any location on the `C:\` drive. If multiple folders exist with the same name, they're all migrated. +The following **.xml** file migrates all files and subfolders of the `EngineeringDrafts` folder from any location on the `C:\` drive. If multiple folders exist with the same name, they're all migrated. ```xml @@ -123,7 +123,7 @@ The following .xml file migrates all files and subfolders of the `EngineeringDra ## Migrate a file type into a specific folder -The following .xml file migrates `.mp3` files located in the specified drives on the source computer into the `C:\Music` folder on the destination computer. +The following **.xml** file migrates `.mp3` files located in the specified drives on the source computer into the `C:\Music` folder on the destination computer. ```xml @@ -152,7 +152,7 @@ The following .xml file migrates `.mp3` files located in the specified drives on The following examples show how to migrate a file from a specific folder, and how to migrate a file from any location. -- **To migrate a file from a folder.** The following .xml file migrates only the `Sample.doc` file from `C:\EngineeringDrafts` on the source computer to the destination computer. +- **To migrate a file from a folder.** The following **.xml** file migrates only the `Sample.doc` file from `C:\EngineeringDrafts` on the source computer to the destination computer. ```xml @@ -185,10 +185,7 @@ The following examples show how to migrate a file from a specific folder, and ho ## Related articles -[Customize USMT XML files](usmt-customize-xml-files.md) - -[Custom XML examples](usmt-custom-xml-examples.md) - -[Conflicts and precedence](usmt-conflicts-and-precedence.md) - -[USMT XML reference](usmt-xml-reference.md) +- [Customize USMT XML files](usmt-customize-xml-files.md). +- [Custom XML examples](usmt-custom-xml-examples.md). +- [Conflicts and precedence](usmt-conflicts-and-precedence.md). +- [USMT XML reference](usmt-xml-reference.md). diff --git a/windows/deployment/usmt/usmt-loadstate-syntax.md b/windows/deployment/usmt/usmt-loadstate-syntax.md index e5c04fe082..1b3fd73570 100644 --- a/windows/deployment/usmt/usmt-loadstate-syntax.md +++ b/windows/deployment/usmt/usmt-loadstate-syntax.md @@ -1,18 +1,18 @@ --- -title: LoadState Syntax (Windows 10) +title: LoadState Syntax description: Learn about the syntax and usage of the command-line options available when you use the LoadState command. manager: aaroncz ms.author: frankroj ms.prod: windows-client author: frankroj -ms.date: 11/01/2022 +ms.date: 12/21/2023 ms.topic: article ms.technology: itpro-deploy --- # LoadState syntax -The `LoadState.exe` command is used with the User State Migration Tool (USMT) 10.0 to restore a store previously captured by the `ScanState.exe` command onto a destination computer. This article discusses the `LoadState.exe` command syntax and the options available with it. +The `LoadState.exe` command is used with the User State Migration Tool (USMT) to restore a store previously captured by the `ScanState.exe` command onto a destination computer. This article discusses the `LoadState.exe` command syntax and the options available with it. ## Before you begin @@ -26,7 +26,7 @@ Before you run the `LoadState.exe` command, note the following items: - Unless otherwise specified, you can use each option only once when running a tool on the command line. -- **LoadState** doesn't require domain controller access to apply domain profiles. This functionality is available without any additional configuration. It isn't necessary for the source computer to have had domain controller access when the user profile was gathered using **ScanState**. However, domain profiles are inaccessible until the destination computer is joined to the domain. +- **LoadState** doesn't require domain controller access to apply domain profiles. This functionality is available without any additional configuration. It isn't necessary for the source computer to have domain controller access when the user profile was gathered using **ScanState**. However, domain profiles are inaccessible until the destination computer is joined to the domain. - The [Incompatible command-line options](#incompatible-command-line-options) table lists which options you can use together and which command-line options are incompatible. @@ -53,7 +53,7 @@ USMT provides the following options that you can use to specify how and where th | Command-Line Option | Description | |--- |--- | | **StorePath** | Indicates the folder where the files and settings data are stored. You must specify *StorePath* when using the `LoadState.exe` command. You can't specify more than one *StorePath*. | -| **/decrypt /key**:*KeyString*
or
**/decrypt /key**:"*Key String*"
or
**/decrypt /keyfile**:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, you'll need to specify the encryption key in one of the following ways:
  • `/key`:*KeyString* specifies the encryption key. If there's a space in *KeyString*, you must surround the argument with quotation marks (`"`).
  • `/keyfile`:*FilePathAndName* specifies a text (`.txt`) file that contains the encryption key

*KeyString* can't exceed 256 characters.
The `/key` and `/keyfile` options can't be used on the same command line.
The `/decrypt` and `/nocompress` options can't be used on the same command line.
**Important**
Use caution when using the `/key` or `keyfile` options. For example, anyone who has access to scripts that run the `LoadState.exe` command with these options will also have access to the encryption key.

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /decrypt /key:mykey` | +| **/decrypt /key**:*KeyString*
or
**/decrypt /key**:"*Key String*"
or
**/decrypt /keyfile**:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, the encryption key needs to be specified in one of the following ways:
  • `/key`:*KeyString* specifies the encryption key. If there's a space in *KeyString*, you must surround the argument with quotation marks (`"`).
  • `/keyfile`:*FilePathAndName* specifies a text (`.txt`) file that contains the encryption key

*KeyString* can't exceed 256 characters.
The `/key` and `/keyfile` options can't be used on the same command line.
The `/decrypt` and `/nocompress` options can't be used on the same command line.
**Important**
Use caution when using the `/key` or `keyfile` options. For example, anyone who has access to scripts that run the `LoadState.exe` command with these options also have access to the encryption key.

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /decrypt /key:mykey` | | **/decrypt**:*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). | | **/hardlink** | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. | | **/nocompress** | Specifies that the store isn't compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option can't be used with the `/decrypt` option.
For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /nocompress` | @@ -64,9 +64,9 @@ USMT provides the following options to specify what files you want to migrate. | Command-Line Option | Description | |--- |--- | -| **/i**:[*Path*]*FileName* | **(include)**
Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom .xml files that you create). *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* must be located in the current directory.

For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.yml) article. | +| **/i**:[*Path*]*FileName* | **(include)**
Specifies an **.xml** file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your **.xml** files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom **.xml** files that you create). *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* must be located in the current directory.

For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.yml) article. | | **/config**:[*Path*]*FileName* | Specifies the `Config.xml` file that the `LoadState.exe` command should use. You can't specify this option more than once on the command line. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the *FileName* must be located in the current directory.

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

`LoadState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:5 /l:LoadState.log` | -| **/auto**:*"path to script files"* | This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | +| **/auto**:*"path to script files"* | This option enables you to specify the location of the default **.xml** files and then launch your migration. If no path is specified, USMT uses the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | ## Monitoring options @@ -74,27 +74,27 @@ USMT provides several command-line options that you can use to analyze problems | Command-Line Option | Description | |--- |--- | -| **/l**:[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the log will be created in the current directory. You can specify the `/v` option to adjust the verbosity of the log.

If you run the `LoadState.exe` command from a shared network resource, you must specify the `l` option, or USMT will fail with the error:

***USMT was unable to create the log file(s)***

To fix this issue, make sure to specify the `/l` option when running `LoadState.exe` from a shared network resource. | +| **/l**:[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the log is created in the current directory. You can specify the `/v` option to adjust the verbosity of the log.

If you run the `LoadState.exe` command from a shared network resource, you must specify the `l` option, or USMT fails with the error:

***USMT was unable to create the log file(s)***

To fix this issue, make sure to specify the `/l` option when running `LoadState.exe` from a shared network resource. | | **/v**:*``* | **(Verbosity)**

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

For example:
`LoadState.exe \server\share\migration\mystore /v:5 /i:MigDocs.xml /i:MigApp.xml` | -| **/progress**:[*Path*]*FileName* | Creates the optional progress log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* will be created in the current directory.

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

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

While restoring the user state, the `/r` option won't recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. | +| **/progress**:[*Path*]*FileName* | Creates the optional progress log. You can't store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then *FileName* is created in the current directory.

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

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

When the user state is being restored, the `/r` option doesn't recover data that is lost due to a network-hardware failure, such as a faulty or disconnected network cable, or when a virtual private network (VPN) connection fails. The retry option is intended for large, busy networks where connectivity is satisfactory, but communication latency is a problem. | | **/w**:*``* | **(Wait)**

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. | | **/?** or **/help** | Displays Help on the command line. | ## User options -By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You can't exclude users in the migration .xml files or by using the `Config.xml` file. For more information, see [Identify Users](usmt-identify-users.md). +By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You can't exclude users in the migration **.xml** files or by using the `Config.xml` file. For more information, see [Identify Users](usmt-identify-users.md). | Command-Line Option | Description | |--- |--- | | **/all** | Migrates all of the users on the computer.

USMT migrates all user accounts on the computer, unless you specifically exclude an account with the `/ue` or `/uel` options. For this reason, you don't need to specify this option on the command line. However, if you choose to use the `/all` option, you can't also use the `/ui`, `/ue` or `/uel` options. | -| **/ui**:*DomainName UserName*
or
**/ui**:*"DomainName User Name"*
or
**/ui**:*ComputerName LocalUserName* | **(User include)**

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the `/ue` option. You can specify multiple `/ui` options, but you can't use the `/ui` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk (`*`) wildcard character. When you specify a user name that contains spaces, you'll need to surround it with quotations marks (`"`).

For example, to include only **User2** from the Corporate domain, enter:

`/ue:* /ui:corporate\user2`

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

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

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

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

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /uel:0` | -| **/ue**:*DomainName\UserName*
or
**/ue** *"DomainName\User Name"*
or
**/ue**:*ComputerName\LocalUserName* | **(User exclude)**

Excludes the specified users from the migration. You can specify multiple `/ue` options but you can't use the `/ue` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk (`*`) wildcard character. When you specify a user name that contains spaces, you'll need to surround it with quotation marks (`"`).

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /ue:contoso\user1`
For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. | -| **/md**:*OldDomain*:*NewDomain*
or
**/md**:*LocalComputerName:NewDomain* | **(Move domain)**

Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. *OldDomain* may contain the asterisk () wildcard character.

You can specify this option more than once. You may want to specify multiple `/md` options if you're consolidating users across multiple domains to a single domain. For example, you could specify the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`.

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

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`
` /progress:Progress.log /l:LoadState.log /md:contoso:fabrikam` | +| **/ui**:*DomainName UserName*
or
**/ui**:*"DomainName User Name"*
or
**/ui**:*ComputerName LocalUserName* | **(User include)**

Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the `/ue` option. You can specify multiple `/ui` options, but you can't use the `/ui` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk (`*`) wildcard character. When user name that contains spaces is specified, it needs to be surrounded with quotations marks (`"`).

For example, to include only **User2** from the Corporate domain, enter:

`/ue:* /ui:corporate\user2`

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

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

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

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

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

Excludes the specified users from the migration. You can specify multiple `/ue` options but you can't use the `/ue` option with the `/all` option. *DomainName* and *UserName* can contain the asterisk (`*`) wildcard character. When a user name that contains spaces is specified, it needs to be surround with quotation marks (`"`).

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /ue:contoso\user1`
For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. | +| **/md**:*OldDomain*:*NewDomain*
or
**/md**:*LocalComputerName:NewDomain* | **(Move domain)**

Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. *OldDomain* might contain the asterisk () wildcard character.

This option can be specified more than once. If consolidating users across multiple domains to a single domain, multiple `/md` options might need to be specified. For example, to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain, specify the following settings: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`.

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

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`
` /progress:Progress.log /l:LoadState.log /md:contoso:fabrikam` | | **/mu**:*OldDomain OldUserName*:[*NewDomain*]*NewUserName*
or
**/mu**:*OldLocalUserName*:*NewDomain NewUserName* | **(Move user)**

Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple `/mu` options. You can't use wildcard characters with this option.

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`
`/progress:Progress.log /l:LoadState.log /mu:contoso\user1:fabrikam\user1` | -| **/lac**:[*Password*] | **(Local account create)**

Specifies that if a user account is a local (non-domain) account, and it doesn't exist on the destination computer, USMT will create the account on the destination computer but it will be disabled. To enable the account, you must also use the `/lae` option.

If the `/lac` option isn't specified, any local user accounts that don't already exist on the destination computer won't be migrated.

*Password* is the password for the newly created account. An empty password is used by default.
**Caution**
Use the *Password* variable with caution because it's provided in plain text and can be obtained by anyone with access to the computer that is running the `LoadState.exe` command.
Also, if the computer has multiple users, all migrated users will have the same password.

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | +| **/lac**:[*Password*] | **(Local account create)**

If a user account is:
  • A local (non-domain) account
  • It doesn't exist on the destination computer
this setting specifies to create the account on the destination computer. However, the account is disabled. To enable the account, you must also use the `/lae` option.

If the `/lac` option isn't specified, any local user accounts that don't already exist on the destination computer aren't migrated.

*Password* is the password for the newly created account. An empty password is used by default.
**Caution**
Use the *Password* variable with caution. The *Password* variable is provided in plain text and anyone with access to the computer that is running the `LoadState.exe` command can obtain the password.
Also, if the computer has multiple users, all migrated users have the same password.

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | | `/lae` | **(Local account enable)**

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

For example:
`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore`
`/progress:Progress.log /l:LoadState.log /lac:password /lae`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | ### Examples for the /ui and /ue options @@ -114,15 +114,15 @@ The following examples apply to both the **/ui** and **/ue** options. You can re You can use the `/uel`, `/ue` and `/ui` options together to migrate only the users that you want migrated. -**The /ui option has precedence over the /ue and /uel options.** If a user is included using the `/ui` option and also excluded using either the `/ue` or `/uel` options, the user will be included in the migration. For example, if you specify `/ui:contoso\* /ue:contoso\user1`, then User1 will be migrated, because the `/ui` option takes precedence over the `/ue` option. +**The /ui option has precedence over the /ue and /uel options.** If a user is included using the `/ui` option and also excluded using either the `/ue` or `/uel` options, the user is included in the migration. For example, if `/ui:contoso\* /ue:contoso\user1` is specified, then User1 is migrated, because the `/ui` option takes precedence over the `/ue` option. -**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the `/uel` option, that user's profile will be migrated even if they're excluded by using the `/ue` option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they've logged on to the computer within the last 14 days. +**The /uel option takes precedence over the /ue option.** If a user logged on within the specified time period set by the `/uel` option, that user's profile is migrated even if they're excluded by using the `/ue` option. For example, if you specify `/ue:contoso\user1 /uel:14`, then User1 is migrated if they logged on to the computer within the last 14 days. | Behavior | Command | |--- |--- | | Include only User2 from the Fabrikam domain and exclude all other users. | `/ue:* /ui:fabrikam\user2` | | Include only the local user named User1 and exclude all other users. | `/ue:* /ui:user1` | -| Include only the domain users from Contoso, except Contoso\User1. | This behavior can't be completed using a single command. Instead, to migrate this set of users, you'll need to specify the following options:
  • Using the **ScanState** command-line tool, enter:
    `/ue:* /ui:contoso`
  • Using the **LoadState** command-line tool, enter:
    `/ue:contoso\user1`
| +| Include only the domain users from Contoso, except Contoso\User1. | This behavior can't be completed using a single command. Instead, to migrate this set of users, specify the following options:
  • Using the **ScanState** command-line tool, enter:
    `/ue:* /ui:contoso`
  • Using the **LoadState** command-line tool, enter:
    `/ue:contoso\user1`
| | Include only local (non-domain) users. | `/ue: /ui:%computername%*` | ## Incompatible command-line options @@ -156,8 +156,9 @@ The following table indicates which command-line options aren't compatible with | **/lac** | | | | | > [!NOTE] +> > You must specify either the `/key` or `/keyfile` option with the `/encrypt` option. ## Related articles -[XML elements library](usmt-xml-elements-library.md) +- [XML elements library](usmt-xml-elements-library.md).