From f9c0c375e323132bdc451ba42084b07413d5b730 Mon Sep 17 00:00:00 2001 From: Frank Rojas <45807133+frankroj@users.noreply.github.com> Date: Wed, 3 Jan 2024 10:15:23 -0500 Subject: [PATCH] USMT Refresh 22 --- .../deployment/usmt/usmt-conflicts-and-precedence.md | 10 +++++----- windows/deployment/usmt/usmt-scanstate-syntax.md | 4 ++-- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/windows/deployment/usmt/usmt-conflicts-and-precedence.md b/windows/deployment/usmt/usmt-conflicts-and-precedence.md index 9a7478500e..29b8404a44 100644 --- a/windows/deployment/usmt/usmt-conflicts-and-precedence.md +++ b/windows/deployment/usmt/usmt-conflicts-and-precedence.md @@ -130,16 +130,16 @@ These examples explain how USMT deals with **\** and **\** r | If the following code exists in the same component | Resulting behavior | Explanation | |-----|-----|-----| -| | Migrates all files and subfolders in Dir1 (including all **.txt** files in C:). | The **\** rule doesn't affect the migration because the **\** rule is more specific. | -|
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\
| Migrates all files and subfolders in C:\Dir1, except the **.txt** files in C:\Dir1\Dir2 and its subfolders. | Both rules are processed as intended. | -|
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\ * [.txt]\
| Migrates all files and subfolders in C:\Dir1, except the **.txt** files in C:\Dir1 and its subfolders. | Both rules are processed as intended. | -|
  • Include rule: \C:\Dir1\Dir2* [.txt]\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\
| Nothing is migrated. | The rules are equally specific, so the **\** rule takes precedence over the **\** rule. | +|
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:* [.txt]\
| Migrates all files and subfolders in Dir1 (including all **.txt** files in C:). | The **\** rule doesn't affect the migration because the **\** rule is more specific. | +|
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\
| Migrates all files and subfolders in C:\Dir1, except the **.txt** files in C:\Dir1\Dir2 and its subfolders. | Both rules are processed as intended. | +|
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\ * [.txt]\
| Migrates all files and subfolders in C:\Dir1, except the **.txt** files in C:\Dir1 and its subfolders. | Both rules are processed as intended. | +|
  • Include rule: \C:\Dir1\Dir2* [.txt]\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\
| Nothing is migrated. | The rules are equally specific, so the **\** rule takes precedence over the **\** rule. | |
  • Include rule: C:\Dir1* [.txt]
  • Exclude rule: C:\Dir1\Dir2* []
| Migrates the **.txt** files in Dir1 and the **.txt** files from subfolders other than Dir2.
No files are migrated from Dir2 or its subfolders. | Both rules are processed as intended. | |
  • Include rule: C:\Dir1\Dir2* []
  • Exclude rule: C:\Dir1* [.txt]
| Migrates all files and subfolders of Dir2, except the **.txt** files from Dir1 and any subfolders of Dir1 (including Dir2). | Both rules are processed as intended. | | If the following code exists in different components | Resulting behavior | Explanation | |-----|----|----| -| Component 1:
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\

Component 2:
  • Include rule: \C:\Dir1\Dir2* [.txt]\
  • Exclude rule: \C:\Dir1* []\
| Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components don't affect each other, except for the **\** rule. Therefore, in this example, although some **.txt** files were excluded when Component 1 was processed, they were included when Component 2 was processed. | +| Component 1:
  • Include rule: \C:\Dir1* []\
  • Exclude rule: \C:\Dir1\Dir2* [.txt]\

Component 2:
  • Include rule: \C:\Dir1\Dir2* [.txt]\
  • Exclude rule: \C:\Dir1* []\
| Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components don't affect each other, except for the **\** rule. Therefore, in this example, although some **.txt** files were excluded when Component 1 was processed, they were included when Component 2 was processed. | | Component 1:
  • Include rule: C:\Dir1\Dir2* []

Component 2:
  • Exclude rule: C:\Dir1* [.txt]
| Migrates all files and subfolders from Dir2 except the **.txt** files in C:\Dir1 and its subfolders. | Both rules are processed as intended. | | Component 1:
  • Exclude rule: C:\Dir1\Dir2* []

Component 2:
  • Include rule: C:\Dir1* [.txt]
| Migrates all **.txt** files in Dir1 and any subfolders. | Component 1 doesn't contain an **\** rule, so the **\** rule isn't processed. | diff --git a/windows/deployment/usmt/usmt-scanstate-syntax.md b/windows/deployment/usmt/usmt-scanstate-syntax.md index eba9501ee5..25a1b1d5e8 100644 --- a/windows/deployment/usmt/usmt-scanstate-syntax.md +++ b/windows/deployment/usmt/usmt-scanstate-syntax.md @@ -106,7 +106,7 @@ USMT provides the following options to specify what files to migrate. | Command-Line Option | Description | |-----|-----| -| **/i:**[*Path*]*FileName* | **(include)**

Specifies an **.xml** file that contains rules that define what user, application, or system state to migrate. This option can be specified multiple times to include all of the **.xml** files (`MigApp.xml`, `MigDocs.xml`, and any custom **.xml** files that are created). *Path* can be either a relative or full path. If the *Path* variable isn't specified, 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 user, application, or system state to migrate. This option can be specified multiple times to include all of the **.xml** files (`MigApp.xml`, `MigDocs.xml`, and any custom **.xml** files that are created). *Path* can be either a relative or full path. If the *Path* variable isn't specified, 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. | | **/genconfig:**[*Path*]*FileName* | (Generate **Config.xml**)

Generates the optional `Config.xml` file, but doesn't create a migration store. To ensure that this file contains everything that needs to be migrated, create this file on a source computer that contains all of the:
  • components
  • applications
  • settings
present on the destination computers. In addition, the other migration **.xml** files should be specified, using the **/i** option, when this option is specified.

After this file is created, it can be used with the `ScanState.exe` command using the **/config** option.

The only options that can be specified with this option are the `/i`, `/v`, and `/l` options. *StorePath* can't be specified, because the `/genconfig` option doesn't create a store. *Path* can be either a relative or full path. If the *Path* variable isn't specified, then *FileName* is created in the current directory.

Examples:
  • The following example creates a `Config.xml` file in the current directory:
    `ScanState.exe /i:MigApp.xml /i:MigDocs.xml /genconfig:Config.xml /v:13`
| | **/config:**[*Path*]*FileName* | Specifies the `Config.xml` file that the `ScanState.exe` command should use to create the store. This option can't be used more than once on the command line. *Path* can be either a relative or full path. If the *Path* variable isn't specified, then *FileName* must be located in the current directory.

The following example creates a store using the `Config.xml` file, `MigDocs.xml`, and `MigApp.xml` files:
`ScanState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:ScanState.log`

The following example migrates the files and settings to the destination computer using 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:13 /l:LoadState.log` | | **/auto:** *path to script files* | This option enables specifying the location of the default **.xml** files. If no path is specified, USMT references 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`. | @@ -130,7 +130,7 @@ USMT provides several options that can be used to analyze problems that occur du | **/c** | When this option is specified, the `ScanState.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 in the store, the `ScanState.exe` command logs an error and continue with the migration. In addition, if a file is open or in use by an application, USMT might not be able to migrate the file and logs an error. Without the `/c` option, the `ScanState.exe` command exits on the first error.

The \<**ErrorControl**\> section in the `Config.xml` file can be used to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This advantage in the `Config.xml` file 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:***\* | **(Retry)**

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

When the user state is stored, the `/r` option can'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. | -| **/p:***\* | When the `ScanState.exe` command runs, it creates an **.xml** file in the path specified. This **.xml** file includes improved space estimations for the migration store. The following example shows how to create this **.xml** file:
`ScanState.exe C:\MigrationLocation [additional parameters]`
`/p:"C:\MigrationStoreSize.xml"`

For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).

To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the `/p` option can be used, without specifying *\"pathtoafile\"*, in USMT. If only the `/p` option is specified, the storage space estimations are created in the same manner as with USMT 3.x releases. | +| **/p:***\* | When the `ScanState.exe` command runs, it creates an **.xml** file in the path specified. This **.xml** file includes improved space estimations for the migration store. The following example shows how to create this **.xml** file:
`ScanState.exe C:\MigrationLocation [additional parameters]`
`/p:"C:\MigrationStoreSize.xml"`

For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).

To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, the `/p` option can be used, without specifying *"pathtoafile"*, in USMT. If only the `/p` option is specified, the storage space estimations are created in the same manner as with USMT 3.x releases. | | **/?** or **/help** | Displays Help at the command line. | ## User options