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