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

Metadata update deployment/usmt 22

Browse Source
This commit is contained in:
Frank Rojas
2022-11-05 01:02:25 -04:00
parent 67296bca16
commit 95295e74e0
20 changed files with 300 additions and 297 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -34,7 +34,7 @@ This article outlines the general process that you should follow to migrate file
6. Create a [Config.xml File](usmt-configxml-file.md) if you want to exclude any components from the migration. To create this file, use the [ScanState Syntax](usmt-scanstate-syntax.md) option together with the other .xml files when you use the `ScanState.exe` command. For example, the following command creates a `Config.xml` file by using the `MigDocs.xml` and `MigApp.xml` files:
`scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scanstate.log`
`ScanState.exe /genconfig:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:ScanState.log`
7. Review the migration state of the components listed in the `Config.xml` file, and specify `migrate=no` for any components that you don't want to migrate.
@ -42,19 +42,19 @@ This article outlines the general process that you should follow to migrate file
1. Back up the source computer.
2. Close all applications. If some applications are running when you run the `Scanstate.exe` command, USMT might not migrate all of the specified data. For example, if Microsoft® Office Outlook® is open, USMT might not migrate PST files.
2. Close all applications. If some applications are running when you run the `ScanState.exe` command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
> [!NOTE]
> USMT will fail if it cannot migrate a file or setting unless you specify the `/C` option. When you specify the `/C` option, USMT will ignore the errors, and log an error every time that it encounters a file that is being used that USMT did not migrate. You can use the `<ErrorControl>` section in the `Config.xml` file to specify which errors should be ignored, and which should cause the migration to fail.
3. Run the `Scanstate.exe` command on the source computer to collect files and settings. You should specify all of the .xml files that you want the `Scanstate.exe` command to use. For example,
3. Run the `ScanState.exe` command on the source computer to collect files and settings. You should specify all of the .xml files that you want the `ScanState.exe` command to use. For example,
`scanstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`
`ScanState.exe \\server\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:ScanState.log`
> [!NOTE]
> If the source computer is running Windows 7, or Windows 8, you must run the `Scanstate.exe` command in **Administrator** mode. To run in **Administrator** mode, right-click **Command Prompt**, and then select **Run As Administrator**. For more information about the how the `Scanstate.exe` command processes and stores the data, see [How USMT Works](usmt-how-it-works.md).
> If the source computer is running Windows 7, or Windows 8, you must run the `ScanState.exe` command in **Administrator** mode. To run in **Administrator** mode, right-click **Command Prompt**, and then select **Run As Administrator**. For more information about the how the `ScanState.exe` command processes and stores the data, see [How USMT Works](usmt-how-it-works.md).
4. Run the `USMTUtils.exe` command with the `/Verify` option to ensure that the store you created isn't corrupted.
4. Run the `UsmtUtils.exe` command with the `/Verify` option to ensure that the store you created isn't corrupted.
## Step 3: Prepare the destination computer and restore files and settings
@ -63,20 +63,20 @@ This article outlines the general process that you should follow to migrate file
2. Install all applications that were on the source computer. Although it isn't always required, we recommend installing all applications on the destination computer before you restore the user state. This makes sure that migrated settings are preserved.
> [!NOTE]
> The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft&reg; Office, which USMT can migrate from an older version to a newer version.
> The application version that is installed on the destination computer should be the same version as the one on the source computer. USMT does not support migrating the settings for an older version of an application to a newer version. The exception to this is Microsoft Office, which USMT can migrate from an older version to a newer version.
3. Close all applications. If some applications are running when you run the `Loadstate.exe` command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
3. Close all applications. If some applications are running when you run the `LoadState.exe ` command, USMT might not migrate all of the specified data. For example, if Microsoft Office Outlook is open, USMT might not migrate PST files.
> [!NOTE]
> Use `/C` to continue your migration if errors are encountered, and use the `<ErrorControl>` section in the `Config.xml` file to specify which errors should be ignored, and which errors should cause the migration to fail.
4. Run the `Loadstate.exe` command on the destination computer. Specify the same set of .xml files that you specified when you used the `Scanstate.exe` command. However, you don't have to specify the `Config.xml` file, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, modify the `Config.xml` file and specify the updated file by using the `Loadstate.exe` command. Then, the `Loadstate.exe` command will migrate only the files and settings that you want to migrate. For more information about how the `Loadstate.exe` command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
4. Run the `LoadState.exe ` command on the destination computer. Specify the same set of .xml files that you specified when you used the `ScanState.exe` command. However, you don't have to specify the `Config.xml` file, unless you want to exclude some of the files and settings that you migrated to the store. For example, you might want to migrate the My Documents folder to the store, but not to the destination computer. To do this, modify the `Config.xml` file and specify the updated file by using the `LoadState.exe ` command. Then, the `LoadState.exe ` command will migrate only the files and settings that you want to migrate. For more information about how the `LoadState.exe ` command processes and migrates data, see [How USMT Works](usmt-how-it-works.md).
For example, the following command migrates the files and settings:
`loadstate.exe \\server\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log`
`LoadState.exe \\server\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:LoadState.log`
> [!NOTE]
> Run the `Loadstate.exe` command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
> Run the `LoadState.exe ` command in administrator mode. To do this, right-click **Command Prompt**, and then click **Run As Administrator**.
5. Sign out after you run the `Loadstate.exe` command. Some settings (for example, fonts, wallpaper, and screen saver settings) won't take effect until the next time that the user logs on.
5. Sign out after you run the `LoadState.exe ` command. Some settings (for example, fonts, wallpaper, and screen saver settings) won't take effect until the next time that the user logs on.

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

@ -41,7 +41,7 @@ The following flowchart illustrates the procedural differences between a local m
If you have enough space and you're migrating the user state back to the same computer, storing data on a local device is normally the best option to reduce server storage costs and network performance issues. You can store the data locally either on a different partition or on a removable device such as a USB flash drive (UFD). Also, depending on the imaging technology that you're using, you might be able to store the data on the partition that is being re-imaged, if the data will be protected from deletion during the process. To increase performance, store the data on high-speed drives that use a high-speed network connection. It's also good practice to ensure that the migration is the only task the server is performing.
If there isn't enough local disk space, or if you're moving the user state to another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share `C:\store` on the destination computer. Then run the `ScanState.exe` command on the source computer and save the files and settings to `\\<DestinationComputerName>\store`. Then, run the `Loadstate.exe` command on the destination computer and specify `C:\Store` as the store location. By doing this process, you don't need to save the files to a server.
If there isn't enough local disk space, or if you're moving the user state to another computer, then you must store the data remotely. For example, you can store it in on a shared folder, on removable media such as a UFD drive, or you can store it directly on the destination computer. For example, create and share `C:\store` on the destination computer. Then run the `ScanState.exe` command on the source computer and save the files and settings to `\\<DestinationComputerName>\store`. Then, run the `LoadState.exe ` command on the destination computer and specify `C:\Store` as the store location. By doing this process, you don't need to save the files to a server.
> [!IMPORTANT]
> If possible, have users store their data within their `%UserProfile%\My Documents` and `%UserProfile%\Application Data` folders. This will reduce the chance of USMT missing critical user data that is located in a directory that USMT is not configured to check.

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

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Offline Migration Reference
Offline migration enables the ScanState tool to run inside a different Windows&reg; operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
Offline migration enables the ScanState tool to run inside a different Windows operating system than the Windows operating system from which ScanState is gathering files and settings. There are two primary offline scenarios:
- **Windows PE.** The ScanState tool can be run from within Windows PE, gathering files and settings from the offline Windows operating system on that machine.
@ -41,7 +41,7 @@ The following user data and settings migrate offline, similar to an online migra
- EFS files
- Internet Explorer&reg; Favorites
- Internet Explorer Favorites
For exceptions to what you can migrate offline, see [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)
@ -85,7 +85,7 @@ An offline migration can either be enabled by using a configuration file on the
|Component|Option|Description|
|--- |--- |--- |
|ScanState.exe|**/offline:***&lt;path to offline.xml&gt;*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.|
|ScanState.exe|**/offline:***&lt;path to Offline.xml&gt;*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.|
|ScanState.exe|**/offlineWinDir:***&lt;Windows directory&gt;*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It's only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.|
|ScanState.exe|**/OfflineWinOld:***&lt;Windows.old directory&gt;*|This command-line option enables the offline migration mode and starts the migration from the location specified. It's only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.|
@ -98,11 +98,11 @@ The following system environment variables are necessary in the scenarios outlin
|Variable|Value|Scenario|
|--- |--- |--- |
|USMT_WORKING_DIR|Full path to a working directory|Required when USMT binaries are located on read-only media, which doesn't support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following command: <br/><pre class="syntax"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre>|
|MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system doesn't match the WinPE and `Scanstate.exe` architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. Specifying the architecture is required when auto-detection of the offline architecture doesn't function properly. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following command: <br/><pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre>|
|MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system doesn't match the WinPE and `ScanState.exe` architecture. This environment variable enables the 32-bit ScanState application to gather data from a computer with 64-bit architecture, or the 64-bit ScanState application to gather data from a computer with 32-bit architecture. Specifying the architecture is required when auto-detection of the offline architecture doesn't function properly. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following command: <br/><pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre>|
## Offline.xml elements
Use an `offline.xml` file when running the ScanState tool on a computer that has multiple Windows directories. The `offline.xml` file specifies which directories to scan for windows files. An `offline.xml` file can be used with the `/offline` option as an alternative to specifying a single Windows directory path with the `/offlineDir` option.
Use an `Offline.xml` file when running the ScanState tool on a computer that has multiple Windows directories. The `Offline.xml` file specifies which directories to scan for windows files. An `Offline.xml` file can be used with the `/offline` option as an alternative to specifying a single Windows directory path with the `/offlineDir` option.
### &lt;offline&gt;

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

@ -21,7 +21,7 @@ This article provides an overview of the default and custom migration XML files
The `Config.xml` file is the configuration file created by the `/genconfig` option of the ScanState tool; it can be used to modify which operating-system components are migrated by USMT. The `Config.xml` file can be used with other XML files, such as in the following example:
`scanstate.exe /i:migapps.xml /i:migdocs.xml /genconfig:c:\myFolder\Config.xml`
`ScanState.exe /i:migapps.xml /i:MigDocs.xml /genconfig:c:\myFolder\Config.xml`
When used this way, the `Config.xml` file tightly controls aspects of the migration, including user profiles, data, and settings, without modifying or creating other XML files. For more information about the `Config.xml` file, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).
@ -157,7 +157,7 @@ You can use multiple XML files with the ScanState and LoadState tools. Each of t
|XML migration file|Modifies the following components:|
|--- |--- |
|Config.xml file|Operating-system components such as desktop wallpaper and background theme.<br/> You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).|
|Config.xml file|Operating-system components such as desktop wallpaper and background theme.<br/> You can also overload `Config.xml` to include some application and document settings by generating the `Config.xml` file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).|
|MigApps.xml file|Applications settings.|
|MigUser.xml or `MigDocs.xml` files|User files and profile settings.|
|Custom XML files|Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.|
@ -165,7 +165,7 @@ You can use multiple XML files with the ScanState and LoadState tools. Each of t
For example, you can use all of the XML migration file types for a single migration, as in the following example:
```console
Scanstate.exe <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml
ScanState.exe <store> /config:c:\myFolder\Config.xml /i:migapps.xml /i:MigDocs.xml /i:customrules.xml
```
### XML rules for migrating user files
@ -196,14 +196,14 @@ To generate the XML migration rules file for a source computer:
```console
cd /d <USMTpath>
scanstate.exe /genmigxml: <filepath.xml>
ScanState.exe /genmigxml: <filepath.xml>
```
Where *&lt;USMTpath&gt;* is the location on your source computer where you've saved the USMT files and tools, and *&lt;filepath.xml&gt;* is the full path to a file where you can save the report. For example, enter:
```console
cd /d c:\USMT
scanstate.exe /genmigxml:"C:\Documents and Settings\USMT Tester\Desktop\genMig.xml"
ScanState.exe /genmigxml:"C:\Documents and Settings\USMT Tester\Desktop\genMig.xml"
```
### The GenerateDocPatterns function

16
windows/deployment/usmt/usmt-common-issues.md
View File

@ -108,8 +108,8 @@ To remove encryption from files that have already been migrated incorrectly, you
**Resolution:** You can use the `/mu` option when you run the **LoadState** tool to specify a new name for the user. For example,
``` syntax
loadstate.exe /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore
/progress:prog.log /l:load.log /mu:fareast\user1:farwest\user1
LoadState.exe /i:MigApp.xml /i:MigDocs.xml \\server\share\migration\mystore
/progress:Progress.log /l:LoadState.log /mu:fareast\user1:farwest\user1
```
## Command-line problems
@ -126,19 +126,19 @@ The following sections describe common command-line problems. Expand the section
**Cause:** If you're running the **ScanState** or **LoadState** tools from a shared network resource, you'll receive this error message if you don't specify `/l`.
**Resolution:** To fix this issue in this scenario, specify the `/l:scan.log` or `/l:load.log` option.
**Resolution:** To fix this issue in this scenario, specify the `/l:ScanState.log` or `/l:LoadState.log` option.
## XML file problems
The following sections describe common XML file problems. Expand the section to see recommended solutions.
### I used the /genconfig option to create a Config.xml file, but I see only a few applications and components that are in MigApp.xml. Why does Config.xml not contain all of the same applications?
### I used the `/genconfig` option to create a `Config.xml` file, but I see only a few applications and components that are in `MigApp.xml`. Why does `Config.xml` not contain all of the same applications?
**Cause:** `Config.xml` will contain only operating system components, applications, and the user document sections that are in both of the .xml files and are installed on the computer when you run the `/genconfig` option. Otherwise, these applications and components won't appear in the `Config.xml` file.
**Resolution:** Install all of the desired applications on the computer before running the `/genconfig` option. Then run `ScanState.exe` with all of the .xml files. For example, run the following command:
`scanstate.exe /genconfig:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:scanstate.log`
`ScanState.exe /genconfig:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:5 /l:ScanState.log`
### I'm having problems with a custom .xml file that I authored, and I can't verify that the syntax is correct
@ -194,7 +194,7 @@ There are three typical causes for this issue.
**Resolution:** Run the **ScanState** and **LoadState** tools from within an account with administrative credentials.
--->
### I included MigApp.xml in the migration, but some PST files aren't migrating
### I included `MigApp.xml` in the migration, but some `PST` files aren't migrating
**Cause:** The `MigApp.xml` file migrates only the PST files that are linked to Outlook profiles.
@ -247,7 +247,7 @@ The following sections describe common offline migration problems. Expand the se
**Resolution:** Use a Security Identifier (SID) to include a user when running the **ScanState** tool. For example:
``` syntax
Scanstate.exe /ui:S1-5-21-124525095-708259637-1543119021*
ScanState.exe /ui:S1-5-21-124525095-708259637-1543119021*
```
The wild card (\*) at the end of the SID will migrate the *SID*\_Classes key as well.
@ -281,7 +281,7 @@ The following sections describe common hard-link migration problems. Expand the
**Resolution:** Use the UsmtUtils tool to delete the store or change the store name. For example, at a command prompt, enter:
``` syntax
USMTutils.exe /rd <storedir>
UsmtUtils.exe /rd <storedir>
```
You should also reboot the machine.

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

@ -78,15 +78,15 @@ In addition, note the following functionality with the `Config.xml` file:
- The following command creates a `Config.xml` file in the current directory, but it doesn't create a store:
`scanstate /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:5`
`ScanState.exe /i:MigApp.xml /i:MigDocs.xml /genconfig:Config.xml /v:5`
- The following command creates an encrypted store using the `Config.xml` file and the default migration .xml files:
`scanstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:5 /encrypt /key:"mykey"`
`ScanState.exe \\server\share\migration\mystore /i:MigApp.xml /i:MigDocs.xml /o /config:Config.xml /v:5 /encrypt /key:"mykey"`
- The following command decrypts the store and migrates the files and settings:
`loadstate \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:5 /decrypt /key:"mykey"`
`LoadState.exe \\server\share\migration\mystore /i:MigApp.xml /i:MigDocs.xml /v:5 /decrypt /key:"mykey"`
## Additional information

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

@ -1,6 +1,6 @@
---
title: Exclude Files and Settings (Windows 10)
description: In this article, learn how to exclude files and settings when creating a custom .xml file and a config.xml file.
description: In this article, learn how to exclude files and settings when creating a custom .xml file and a Config.xml file.
ms.reviewer:
manager: aaroncz
ms.author: frankroj
@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Exclude files and settings
When you specify the migration .xml files, `MigApp.xml`, `Migdocs.xml`, and `MigUser.xml`, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a `Config.xml` file to exclude an entire component from a migration. You can't, however, exclude users by using the migration .xml files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the user options on the command line in the ScanState tool. For more information, see the [User options](usmt-scanstate-syntax.md#user-options) section of the [ScanState syntax](usmt-scanstate-syntax.md) article.
When you specify the migration .xml files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, the User State Migration Tool (USMT) 10.0 migrates the settings and components listed, as discussed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md) You can create a custom .xml file to further specify what to include or exclude in the migration. In addition you can create a `Config.xml` file to exclude an entire component from a migration. You can't, however, exclude users by using the migration .xml files or the `Config.xml` file. The only way to specify which users to include and exclude is by using the user options on the command line in the ScanState tool. For more information, see the [User options](usmt-scanstate-syntax.md#user-options) section of the [ScanState syntax](usmt-scanstate-syntax.md) article.
Methods to customize the migration and include and exclude files and settings include:

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

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Extract files from a compressed USMT migration store
When you migrate files and settings during a typical PC-refresh migration, you usually create a compressed migration store file on the intermediate store. This migration store is a single image file that contains all files being migrated as well as a catalog file. To protect the compressed file, you can encrypt it by using different encryption algorithms. When you migrate the file back to the source computer after the operating system is installed, you can run the **USMTUtils** command with the `/extract` option to recover the files from the compressed migration store. You can also use the **USMTUtils** command with the `/extract` option any time you need to recover data from a migration store.
When you migrate files and settings during a typical PC-refresh migration, you usually create a compressed migration store file on the intermediate store. This migration store is a single image file that contains all files being migrated as well as a catalog file. To protect the compressed file, you can encrypt it by using different encryption algorithms. When you migrate the file back to the source computer after the operating system is installed, you can run the **UsmtUtils** command with the `/extract` option to recover the files from the compressed migration store. You can also use the **UsmtUtils** command with the `/extract` option any time you need to recover data from a migration store.
Options used with the `/extract` option can specify:
@ -25,12 +25,12 @@ Options used with the `/extract` option can specify:
In addition, you can specify the file patterns that you want to extract by using the `/i` option to include file patterns or the `/e` option to exclude file patterns. When both the `/i` option and the `/e` option are used in the same command, include patterns take precedence over exclude patterns. Note that this is different from the include and exclude rules used in the **ScanState** and **LoadState** tools.
### To run the USMTUtils tool with the /extract option
### To run the UsmtUtils tool with the /extract option
To extract files from the compressed migration store onto the destination computer, use the following USMTUtils syntax:
To extract files from the compressed migration store onto the destination computer, use the following UsmtUtils syntax:
``` syntax
usmtutils.exe /extract <filePath> <destinationPath> [/i:<includePattern>] [/e:<excludePattern>] [/l:<logfile>] [/decrypt[:<AlgID>] {/key:<keystring> | /keyfile:<filename>}] [/o]
UsmtUtils.exe /extract <filePath> <destinationPath> [/i:<includePattern>] [/e:<excludePattern>] [/l:<logfile>] [/decrypt[:<AlgID>] {/key:<keystring> | /keyfile:<filename>}] [/o]
```
Where the placeholders have the following values:
@ -45,7 +45,7 @@ Where the placeholders have the following values:
- **&lt;excludePattern&gt;** specifies the pattern for the files to omit from the extraction.
- **&lt;AlgID&gt;** is the cryptographic algorithm that was used to create the migration store on the `scanstate.exe` command line.
- **&lt;AlgID&gt;** is the cryptographic algorithm that was used to create the migration store on the `ScanState.exe` command line.
- **&lt;logfile&gt;** is the location and name of the log file.
@ -58,7 +58,7 @@ Where the placeholders have the following values:
To extract everything from a compressed migration store to a file on the `C:\` drive, enter:
``` syntax
usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
UsmtUtils.exe /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
```
### To extract specific file types from an encrypted compressed migration store
@ -66,7 +66,7 @@ usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig C:\ExtractedStore
To extract specific files, such as `.txt` and `.pdf` files, from an encrypted compressed migration store, enter:
``` syntax
usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt,*.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt
UsmtUtils.exe /extract D:\MyMigrationStore\USMT\store.mig /i:"*.txt,*.pdf" C:\ExtractedStore /decrypt /keyfile:D:\encryptionKey.txt
```
In this example, the file is encrypted and the encryption key is located in a text file called encryptionKey.
@ -76,7 +76,7 @@ In this example, the file is encrypted and the encryption key is located in a te
To extract all files except for one file type, such as `.exe` files, from an encrypted compressed migration store, enter:
``` syntax
usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtutilslog.txt
UsmtUtils.exe /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedStore /decrypt:AES_128 /key:password /l:C:\usmtutilslog.txt
```
### To extract file types using the include pattern and the exclude pattern
@ -84,14 +84,14 @@ usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig /e:*.exe C:\ExtractedS
To extract files from a compressed migration store, and to exclude files of one type (such as .exe files) while including only specific files, use both the include pattern and the exclude pattern, as in this example:
``` syntax
usmtutils.exe /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o
UsmtUtils.exe /extract D:\MyMigrationStore\USMT\store.mig /i:myProject.* /e:*.exe C:\ExtractedStore /o
```
In this example, if there is a myProject.exe file, it will also be extracted because the include pattern option takes precedence over the exclude pattern option.
## Related articles
[USMTUtils syntax](usmt-utilities.md)
[UsmtUtils syntax](usmt-utilities.md)
[Return codes](usmt-return-codes.md)

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

@ -42,12 +42,12 @@ When you create a hard link, you give an existing file one more path. For instan
For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It's located where specified by the **Scanstate** command-line tool and you can view the contents of the store by using Windows&reg; Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store. However, as with creating the store, the same hard-link functionality is used to keep files in-place.
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It's located where specified by the **ScanState.exe** command-line tool and you can view the contents of the store by using Windows Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store. However, as with creating the store, the same hard-link functionality is used to keep files in-place.
As a best practice, it is recommended that you delete the hard-link migration store after you confirm that the **Loadstate** tool has successfully migrated the files. Since **Loadstate** has created new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files, and won't delete the actual files or the paths to them from the new operating system.
As a best practice, it's recommended that you delete the hard-link migration store after you confirm that the **LoadState** tool has successfully migrated the files. Since **LoadState** has created new paths to the files on the new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files, and won't delete the actual files or the paths to them from the new operating system.
> [!IMPORTANT]
> Using the `/c` option will force the **Loadstate** tool to continue applying files when non-fatal errors occur. If you use the `/c` option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
> Using the `/c` option will force the **LoadState** tool to continue applying files when non-fatal errors occur. If you use the `/c` option, you should verify that no errors are reported in the logs before deleting the hard-link migration store in order to avoid data loss.
Keeping the hard-link migration store can result in extra disk space being consumed or problems with some applications for the following reasons:
@ -86,13 +86,13 @@ The `/hardlink` command-line option proceeds with creating the migration store o
### Hard-link store size estimation
It isn't necessary to estimate the size of a hard-link migration store. Estimating the size of a migration store is only useful in scenarios where the migration store is large, and on NTFS volumes the hard-link migration store will require much less incremental space than other store options. The only case where the local store can be large is when non-NTFS file systems exist on the system and contain data being migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
It isn't necessary to estimate the size of a hard-link migration store since hard-link migration store on NTFS volumes will be relatively small and require much less incremental space than other store options. Estimating the size of a migration store is only useful in scenarios where the migration store is large. The only case where the local store can be large with hard-link migrations is when non-NTFS file systems exist on the system and the non-NTFS files system contain data that needs to be migrated. Since NTFS has been the default file system format for Windows XP and newer operating systems, this situation is unusual.
### Migration store path on multiple volumes
Separate hard-link migration stores are created on each NTFS volume that contain data being migrated. In this scenario, the primary migration-store location will be specified on the command line, and should be the operating-system volume. Migration stores with identical names and directory names will be created on every volume containing data being migrated. For example:
`Scanstate.exe /hardlink c:\USMTMIG […]`
`ScanState.exe /hardlink c:\USMTMIG […]`
Running this command on a system that contains the operating system on the C: drive and the user data on the D: drive will generate migration stores in the following locations, assuming that both drives are NTFS:
@ -108,7 +108,7 @@ Location modifications that redirect migrated content from one volume to a diffe
### Migrating Encrypting File System (EFS) certificates and files
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the `/efs:hardlink` option in the `Scanstate.exe` command-line syntax.
To migrate Encrypting File System (EFS) files to a new installation of an operating system on the same volume of the computer, specify the `/efs:hardlink` option in the `ScanState.exe` command-line syntax.
If the EFS files are being restored to a different partition, you should use the `/efs:copyraw` option instead of the `/efs:hardlink` option. Hard links can only be created for files on the same volume. Moving the files to another partition during the migration requires a copy of the files to be created on the new partition. The `/efs:copyraw` option will copy the files to the new partition in encrypted format.
@ -123,7 +123,7 @@ Files that are locked by the operating system can't remain in place and must be
Files that are locked by an application are treated the same in hard-link migrations as in other scenarios when the volume shadow-copy service isn't being utilized. The volume shadow-copy service can't be used with hard-link migrations. However, by modifying the new **&lt;HardLinkStoreControl&gt;** section in the `Config.xml` file, it's possible to enable the migration of files locked by an application.
> [!IMPORTANT]
> There are some scenarios in which modifying the **&lt;HardLinkStoreControl&gt;** section in the `Config.xml` file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use `USMTutils.exe` to schedule the migration store for deletion on the next restart.
> There are some scenarios in which modifying the **&lt;HardLinkStoreControl&gt;** section in the `Config.xml` file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use `UsmtUtils.exe` to schedule the migration store for deletion on the next restart.
## XML elements in the Config.xml file

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

@ -38,14 +38,14 @@ This section explains the syntax and usage of the command-line options available
The `LoadState.exe` command's syntax is:
<!--
`loadstate.exe StorePath [/i:[Path\]FileName] [/v:VerbosityLevel] [/nocompress] [/decrypt /key:KeyString|/keyfile:[Path\]FileName] [/l:[Path\]FileName] [/progress:[Path\]FileName] [/r:TimesToRetry] [/w:SecondsToWait] [/c] [/all] [/ui:[DomainName|ComputerName\]UserName] [/ue:[[DomainName|ComputerName\]UserName] [/uel:NumberOfDays|YYYY/MM/DD|0] [/md:OldDomain:NewDomain] [/mu:OldDomain\OldUserName:[NewDomain\]NewUserName] [/lac:[Password]] [/lae] [/config:[Path\]FileName] [/?|help]`
`LoadState.exe StorePath [/i:[Path\]FileName] [/v:VerbosityLevel] [/nocompress] [/decrypt /key:KeyString|/keyfile:[Path\]FileName] [/l:[Path\]FileName] [/progress:[Path\]FileName] [/r:TimesToRetry] [/w:SecondsToWait] [/c] [/all] [/ui:[DomainName|ComputerName\]UserName] [/ue:[[DomainName|ComputerName\]UserName] [/uel:NumberOfDays|YYYY/MM/DD|0] [/md:OldDomain:NewDomain] [/mu:OldDomain\OldUserName:[NewDomain\]NewUserName] [/lac:[Password]] [/lae] [/config:[Path\]FileName] [/?|help]`
-->
> loadstate.exe *StorePath* \[/i:\[*Path*\\\]*FileName*\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/decrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsToWait*\] \[/c\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/md:*OldDomain*:*NewDomain*\] \[/mu:*OldDomain*\\*OldUserName*:\[*NewDomain*\\\]*NewUserName*\] \[/lac:\[*Password*\]\] \[/lae\] \[/config:\[*Path*\\\]*FileName*\] \[/?|help\]
> LoadState.exe *StorePath* \[/i:\[*Path*\\\]*FileName*\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/decrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsToWait*\] \[/c\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/md:*OldDomain*:*NewDomain*\] \[/mu:*OldDomain*\\*OldUserName*:\[*NewDomain*\\\]*NewUserName*\] \[/lac:\[*Password*\]\] \[/lae\] \[/config:\[*Path*\\\]*FileName*\] \[/?|help\]
For example, to decrypt the store and migrate the files and settings to a computer, type the following command:
`loadstate.exe \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /v:13 /decrypt /key:"mykey"`
`LoadState.exe \\server\share\migration\mystore /i:MigApp.xml /i:MigDocs.xml /v:13 /decrypt /key:"mykey"`
## Storage options
@ -54,10 +54,10 @@ 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* <br/>or <br/>**/decrypt /key**:"*Key String*" <br/>or <br/>**/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:<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 will 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 /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, you'll need to specify the encryption key 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 will 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. We recommend 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. We recommend 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` |
## Migration rule options
@ -66,7 +66,7 @@ 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 &quot;XML files&quot; 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` |
| **/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 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`. |
## Monitoring options
@ -76,8 +76,8 @@ 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. <br/><br/>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:<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* will be created in the current directory. <br/><br/>For example: <br/>`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` |
| **/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* will be 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 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 &lt;**ErrorControl**&gt; 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 &lt;**ErrorControl**&gt; 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/>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. |
| **/w**:*`<SecondsBeforeRetry>`* | **(Wait)** <br/><br/>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
@ -91,12 +91,12 @@ By default, all users are migrated. The only way to specify which users to inclu
|--- |--- |
| **/all** | Migrates all of the users on the computer. <br/><br/>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* <br/>or <br/>**/ui**:*"DomainName User Name"* <br/>or <br/>**/ui**:*ComputerName LocalUserName* | **(User include)** <br/><br/>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 (`"`). <br/><br/>For example, to include only **User2** from the Corporate domain, enter: <br/><br/>`/ue:* /ui:corporate\user2`<br/><br/><div class="alert">**Note** <br/>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.</div> <br/> For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. |
| **/uel**:*`<NumberOfDays>`* <br/>or <br/>**/uel**:*`<YYYY/MM/DD>`* <br/>or <br/>**/uel**:0 | **(User exclude based on last logon)** <br/><br/>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. <div class="alert">**Note** <br/>The `/uel` option isn't valid in offline migrations.</div> <br/>Examples:<ul><li>`/uel:0` migrates accounts that were logged on to the source computer when the `ScanState.exe` command was run.</li><li>`/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>`/uel:1` migrates users whose accounts have been modified within the last 24 hours.</li><li>`/uel:2020/2/15` migrates users who have logged on or whose accounts have been modified since February 15, 2020.</li></ul> <br/>For example: <br/>`loadstate.exe/i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0` |
| **/ue**:*DomainName\UserName* <br/>or <br/>**/ue** *"DomainName\User Name"* <br/>or <br/>**/ue**:*ComputerName\LocalUserName* | **(User exclude)** <br/><br/>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 (`"`). <br/><br/>For example: <br/>`loadstate.exe/i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1` <br/>For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. |
| **/md**:*OldDomain*:*NewDomain* <br/>or <br/>**/md**:*LocalComputerName:NewDomain* | **(Move domain)** <br/><br/>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. <br/><br/>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`. <br/><br/>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. <div class="alert"> **Note** <br/>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.</div> <br/> For example: <br/>`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>` /progress:prog.log /l:load.log /md:contoso:fabrikam` |
| **/mu**:*OldDomain OldUserName*:[*NewDomain*]*NewUserName* <br/>or <br/>**/mu**:*OldLocalUserName*:*NewDomain NewUserName* | **(Move user)** <br/><br/>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. <br/><br/>For example: <br/>`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1` |
| **/lac**:[*Password*] | **(Local account create)** <br/><br/>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. <br/><br/>If the `/lac` option isn't specified, any local user accounts that don't already exist on the destination computer won't be migrated. <br/><br/>*Password* is the password for the newly created account. An empty password is used by default. <div class="alert"> **Caution** <br/>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. <br/>Also, if the computer has multiple users, all migrated users will have the same password.</div> <br/>For example: <br/>`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/><br/>For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). |
| `/lae` | **(Local account enable)** <br/><br/>Enables the account that was created with the `/lac` option. You must specify the `/lac` option with this option. <br/><br/>For example: <br/>`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>`/progress:prog.log /l:load.log /lac:password /lae` <br/><br/>For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). |
| **/uel**:*`<NumberOfDays>`* <br/>or <br/>**/uel**:*`<YYYY/MM/DD>`* <br/>or <br/>**/uel**:0 | **(User exclude based on last logon)** <br/><br/>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. <div class="alert">**Note** <br/>The `/uel` option isn't valid in offline migrations.</div> <br/>Examples:<ul><li>`/uel:0` migrates accounts that were logged on to the source computer when the `ScanState.exe` command was run.</li><li>`/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>`/uel:1` migrates users whose accounts have been modified within the last 24 hours.</li><li>`/uel:2020/2/15` migrates users who have logged on or whose accounts have been modified since February 15, 2020.</li></ul> <br/>For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /uel:0` |
| **/ue**:*DomainName\UserName* <br/>or <br/>**/ue** *"DomainName\User Name"* <br/>or <br/>**/ue**:*ComputerName\LocalUserName* | **(User exclude)** <br/><br/>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 (`"`). <br/><br/>For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /ue:contoso\user1` <br/>For more examples, see the descriptions of the `/uel`, `/ue`, and `/ui` options in this table. |
| **/md**:*OldDomain*:*NewDomain* <br/>or <br/>**/md**:*LocalComputerName:NewDomain* | **(Move domain)** <br/><br/>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. <br/><br/>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`. <br/><br/>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. <div class="alert"> **Note** <br/>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.</div> <br/> For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore` <br/>` /progress:Progress.log /l:LoadState.log /md:contoso:fabrikam` |
| **/mu**:*OldDomain OldUserName*:[*NewDomain*]*NewUserName* <br/>or <br/>**/mu**:*OldLocalUserName*:*NewDomain NewUserName* | **(Move user)** <br/><br/>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. <br/><br/>For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore` <br/>`/progress:Progress.log /l:LoadState.log /mu:contoso\user1:fabrikam\user1` |
| **/lac**:[*Password*] | **(Local account create)** <br/><br/>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. <br/><br/>If the `/lac` option isn't specified, any local user accounts that don't already exist on the destination computer won't be migrated. <br/><br/>*Password* is the password for the newly created account. An empty password is used by default. <div class="alert"> **Caution** <br/>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. <br/>Also, if the computer has multiple users, all migrated users will have the same password.</div> <br/>For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore` <br/><br/>For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). |
| `/lae` | **(Local account enable)** <br/><br/>Enables the account that was created with the `/lac` option. You must specify the `/lac` option with this option. <br/><br/>For example: <br/>`LoadState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore` <br/>`/progress:Progress.log /l:LoadState.log /lac:password /lae` <br/><br/>For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). |
### Examples for the /ui and /ue options

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

@ -31,7 +31,7 @@ The following table describes each command-line option related to logs, and it p
|Command line Option|File Name|Description|
|--- |--- |--- |
|**/l**"*[Path]FileName*|`Scanstate.log` or `LoadState.log`|Specifies the path and file name of the **ScanState** log or **LoadState** log.|
|**/l**"*[Path]FileName*|`ScanState.exe.log` or `LoadState.log`|Specifies the path and file name of the **ScanState** log or **LoadState** log.|
|**/progress**:*[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.|
|**/v**:*[VerbosityLevel]*|Not applicable|See [Monitoring options](usmt-scanstate-syntax.md#monitoring-options) in [ScanState syntax](usmt-scanstate-syntax.md).|
|**/listfiles**:*[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.|

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

@ -13,7 +13,7 @@ ms.technology: itpro-deploy
# Migrate User Accounts
By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. You can't specify users in the migration XML files or by using the Config.xml file.
By default, all users are migrated. The only way to specify which users to include and exclude is on the command line by using the User options. You can't specify users in the migration XML files or by using the `Config.xml` file.
## To migrate all user accounts and user settings
@ -21,24 +21,24 @@ Links to detailed explanations of commands are available in the [Related article
1. Sign into the source computer as an administrator.
2. Enter the following `scanstate.exe` command line in a command prompt window:
2. Enter the following `ScanState.exe` command line in a command prompt window:
`scanstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /o`
`ScanState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml /o`
3. Sign into the destination computer as an administrator.
4. Enter one of the following `loadstate.exe` command lines in a command prompt window:
4. Enter one of the following `LoadState.exe ` command lines in a command prompt window:
- If you're migrating domain accounts, enter:
``` syntax
loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml
LoadState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml
```
- If you're migrating local accounts along with domain accounts, enter:
``` syntax
loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml /lac /lae
LoadState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml /lac /lae
```
> [!NOTE]
@ -50,15 +50,15 @@ Links to detailed explanations of commands are available in the [Related article
1. Sign into the source computer as an administrator.
2. Enter the following `scanstate.exe` command line in a command prompt window:
2. Enter the following `ScanState.exe` command line in a command prompt window:
`scanstate.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:migdocs.xml /i:migapp.xml /o`
`ScanState.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:fabrikam\user2 /i:MigDocs.xml /i:MigApp.xml /o`
3. Sign into the destination computer as an administrator.
4. Enter the following `loadstate.exe` command line in a command prompt window:
4. Enter the following `LoadState.exe ` command line in a command prompt window:
`loadstate.exe \\server\share\migration\mystore /i:migdocs.xml /i:migapp.xml`
`LoadState.exe \\server\share\migration\mystore /i:MigDocs.xml /i:MigApp.xml`
## To migrate two domain accounts (User1 and User2) and move User1 from the Contoso domain to the Fabrikam domain
@ -66,15 +66,15 @@ Links to detailed explanations of commands are available in the [Related article
1. Sign into the source computer as an administrator.
2. Enter the following `scanstate.exe` command line in a command prompt window:
2. Enter the following `ScanState.exe` command line in a command prompt window:
`scanstate.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:migdocs.xml /i:migapp.xml /o`
`ScanState.exe \\server\share\migration\mystore /ue:*\* /ui:contoso\user1 /ui:contoso\user2 /i:MigDocs.xml /i:MigApp.xml /o`
3. Sign into the destination computer as an administrator.
4. Enter the following `loadstate.exe` command line in a command prompt window:
4. Enter the following `LoadState.exe ` command line in a command prompt window:
`loadstate.exe \\server\share\migration\mystore /mu:contoso\user1:fabrikam\user2 /i:migdocs.xml /i:migapp.xml`
`LoadState.exe \\server\share\migration\mystore /mu:contoso\user1:fabrikam\user2 /i:MigDocs.xml /i:MigApp.xml`
## Related articles

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

@ -19,7 +19,7 @@ This article discusses User State Migration Tool (USMT) 10.0 options for migrati
USMT enables support for stronger encryption algorithms, called Advanced Encryption Standard (AES), in several bit-level options. AES is a National Institute of Standards and Technology (NIST) specification for the encryption of electronic data.
The encryption algorithm you choose must be specified for both the `ScanState.exe` and the `LoadState.exe` commands, so that these commands can create or read the store during encryption and decryption. The new encryption algorithms can be specified on the `ScanState.exe` and the `LoadState.exe` command lines by using the `/encrypt`:*encryptionstrength* and the `/decrypt`:*encryptionstrength* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in Windows 7, Windows 8, and Windows 10 operating systems. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. You can use the `Usmtutils.exe` file to determine which encryption algorithms are available to the computers' locales before you begin the migration.
The encryption algorithm you choose must be specified for both the `ScanState.exe` and the `LoadState.exe` commands, so that these commands can create or read the store during encryption and decryption. The new encryption algorithms can be specified on the `ScanState.exe` and the `LoadState.exe` command lines by using the `/encrypt`:*encryptionstrength* and the `/decrypt`:*encryptionstrength* command-line options. All of the encryption application programming interfaces (APIs) used by USMT are available in Windows 7, Windows 8, and Windows 10 operating systems. However, export restrictions might limit the set of algorithms that are available to computers in certain locales. You can use the `UsmtUtils.exe` file to determine which encryption algorithms are available to the computers' locales before you begin the migration.
The following table describes the command-line encryption options in USMT.

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

@ -64,7 +64,7 @@ To open an elevated command prompt:
## Config.xml
### Specify the /c option and &lt;ErrorControl&gt; settings in the Config.xml file
### Specify the `/c` option and &lt;ErrorControl&gt; settings in the `Config.xml` file
USMT will fail if it can't migrate a file or setting, unless you specify the `/c` option. When you specify the `/c` option, USMT logs an error each time it encounters a file that is in use that didn't migrate, but the migration won't be interrupted. In USMT, you can specify in the `Config.xml` file, which types of errors should allow the migration to continue, and which should cause the migration to fail. For more information about error reporting, and the **&lt;ErrorControl&gt;** element, see [Config.xml file](usmt-configxml-file.md#errorcontrol), [Log files](usmt-log-files.md), and [XML elements library](usmt-xml-elements-library.md).

6
windows/deployment/usmt/usmt-return-codes.md
View File

@ -156,7 +156,7 @@ The following information lists each return code by numeric value, along with th
| Error message | Troubleshooting, mitigation, workarounds |
| --- | --- |
| **Multiple Windows installations found** | Listfiles.txt couldn't be created. Verify that the location you specified for the creation of this file is valid. |
| **Software malfunction or unknown exception** | Check all loaded .xml files for errors, common error when using `/i` to load the Config.xml file. |
| **Software malfunction or unknown exception** | Check all loaded .xml files for errors, common error when using `/i` to load the `Config.xml` file. |
| **Unable to find a valid Windows directory to proceed with requested offline operation; Check if offline input file is present and has valid entries** | Verify that the offline input file is present and that it has valid entries. USMT couldn't find valid offline operating system. Verify your offline directory mapping. |
### 27: USMT_INVALID_STORE_LOCATION
@ -272,8 +272,8 @@ The following information lists each return code by numeric value, along with th
| Error message | Troubleshooting, mitigation, workarounds |
| --- | --- |
| **Error reading Config.xml** | Review ScanState log or LoadState log for details about command-line errors in the Config.xml file. |
| **File argument is invalid for /config** | Check the command line you used to load the Config.xml file. You can use online Help by typing `/?` on the command line. |
| **Error reading Config.xml** | Review ScanState log or LoadState log for details about command-line errors in the `Config.xml` file. |
| **File argument is invalid for /config** | Check the command line you used to load the `Config.xml` file. You can use online Help by typing `/?` on the command line. |
### 40: USMT_ERROR_UNABLE_CREATE_PROGRESS_LOG

28
windows/deployment/usmt/usmt-scanstate-syntax.md
View File

@ -39,15 +39,15 @@ This section explains the syntax and usage of the command-line options available
The `ScanState.exe` command's syntax is:
> scanstate.exe \[*StorePath*\] \[/apps\] \[/ppkg:*FileName*\] \[/i:\[*Path*\\\]*FileName*\] \[/o\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/localonly\] \[/encrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsBeforeRetry*\] \[/c\] \[/p\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/efs:abort|skip|decryptcopy|copyraw\] \[/genconfig:\[*Path*\\\]*FileName*\[/config:\[*Path*\\\]*FileName*\] \[/?|help\]
> ScanState.exe \[*StorePath*\] \[/apps\] \[/ppkg:*FileName*\] \[/i:\[*Path*\\\]*FileName*\] \[/o\] \[/v:*VerbosityLevel*\] \[/nocompress\] \[/localonly\] \[/encrypt /key:*KeyString*|/keyfile:\[Path\\\]*FileName*\] \[/l:\[*Path*\\\]*FileName*\] \[/progress:\[*Path*\\\]*FileName*\] \[/r:*TimesToRetry*\] \[/w:*SecondsBeforeRetry*\] \[/c\] \[/p\] \[/all\] \[/ui:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/ue:\[*DomainName*|*ComputerName*\\\]*UserName*\] \[/uel:*NumberOfDays*|*YYYY/MM/DD*|0\] \[/efs:abort|skip|decryptcopy|copyraw\] \[/genconfig:\[*Path*\\\]*FileName*\[/config:\[*Path*\\\]*FileName*\] \[/?|help\]
For example, to create a `Config.xml` file in the current directory, use:
`scanstate.exe /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:13`
`ScanState.exe /i:MigApp.xml /i:MigDocs.xml /genconfig:Config.xml /v:13`
To create an encrypted store using the `Config.xml` file and the default migration .xml files, use:
`scanstate.exe \\server\share\migration\mystore /i:migapp.xml /i:migdocs.xml /o /config:config.xml /v:13 /encrypt /key:"mykey"`
`ScanState.exe \\server\share\migration\mystore /i:MigApp.xml /i:MigDocs.xml /o /config:Config.xml /v:13 /encrypt /key:"mykey"`
## Storage options
@ -59,9 +59,9 @@ To create an encrypted store using the `Config.xml` file and the default migrati
| **/o** | Required to overwrite any existing data in the migration store or `Config.xml` file. If not specified, the `ScanState.exe` command will fail if the migration store already contains data. You can't use this option more than once on a command line. |
| **/vsc** | This option enables the volume shadow-copy service to migrate files that are locked or in use. This command-line option eliminates most file-locking errors that are typically encountered by the **&lt;ErrorControl&gt;** section. <br/><br/>This option is only used with the **ScanState** executable file and can't be combined with the `/hardlink` option. |
| **/hardlink** | Enables the creation of a hard-link migration store at the specified location. The `/nocompress` option must be specified with the `/hardlink` option. |
| **/encrypt** [{**/key:** *&lt;KeyString&gt;* &#124; **/keyfile**:*&lt;file&gt;*]} | Encrypts the store with the specified key. Encryption is disabled by default. With this option, you'll need to specify the encryption key-in one of the following ways: <ul><li>`/key`: *KeyString* specifies the encryption key. If there's a space in *KeyString*, you'll need to surround *KeyString* with quotation marks (`"`).</li><li>`/keyfile`: *FilePathAndName* specifies a text (`.txt`) file that contains the encryption key.</li></ul> <br/>*KeyString* is recommended to be at least eight characters long, but it can't exceed 256 characters. The `/key` and `/keyfile` options can't be used on the same command line. The `/encrypt` and `/nocompress` options can't be used on the same command line. <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 `ScanState.exe` command with these options will also have access to the encryption key.</div> <br/>The following example shows the `ScanState.exe` command and the `/key` option: <br/>`scanstate.exe /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /encrypt /key:mykey` |
| **/encrypt** [{**/key:** *&lt;KeyString&gt;* &#124; **/keyfile**:*&lt;file&gt;*]} | Encrypts the store with the specified key. Encryption is disabled by default. With this option, you'll need to specify the encryption key-in one of the following ways: <ul><li>`/key`: *KeyString* specifies the encryption key. If there's a space in *KeyString*, you'll need to surround *KeyString* with quotation marks (`"`).</li><li>`/keyfile`: *FilePathAndName* specifies a text (`.txt`) file that contains the encryption key.</li></ul> <br/>*KeyString* is recommended to be at least eight characters long, but it can't exceed 256 characters. The `/key` and `/keyfile` options can't be used on the same command line. The `/encrypt` and `/nocompress` options can't be used on the same command line. <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 `ScanState.exe` command with these options will also have access to the encryption key.</div> <br/>The following example shows the `ScanState.exe` command and the `/key` option: <br/>`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \server\share\migration\mystore /encrypt /key:mykey` |
| **/encrypt**:*&lt;EncryptionStrength&gt;* | The `/encrypt` option accepts a command-line parameter to define the encryption strength to be used for encryption of the migration store. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). |
| **/nocompress** | Disables compression of data and saves the files to a hidden folder named &quot;File&quot; at *StorePath*\USMT. Compression is enabled by default. Combining the `/nocompress` option with the `/hardlink` option generates a hard-link migration store. You can use the uncompressed store to view what USMT stored, troubleshoot a problem, or run an antivirus utility against the files. You should use this option only in testing environments, because we recommend that you use a compressed store during your actual migration, unless you're combining the `/nocompress` option with the `/hardlink` option. <br/><br/>The `/nocompress` and `/encrypt` options can't be used together in one statement on the command line. However, if you do choose to migrate an uncompressed store, the `LoadState.exe` command will migrate each file directly from the store to the correct location on the destination computer without a temporary location. <br/><br/>For example:<br/>`scanstate.exe /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /nocompress` |
| **/nocompress** | Disables compression of data and saves the files to a hidden folder named &quot;File&quot; at *StorePath*\USMT. Compression is enabled by default. Combining the `/nocompress` option with the `/hardlink` option generates a hard-link migration store. You can use the uncompressed store to view what USMT stored, troubleshoot a problem, or run an antivirus utility against the files. You should use this option only in testing environments, because we recommend that you use a compressed store during your actual migration, unless you're combining the `/nocompress` option with the `/hardlink` option. <br/><br/>The `/nocompress` and `/encrypt` options can't be used together in one statement on the command line. However, if you do choose to migrate an uncompressed store, the `LoadState.exe` command will migrate each file directly from the store to the correct location on the destination computer without a temporary location. <br/><br/>For example:<br/>`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \server\share\migration\mystore /nocompress` |
## Run the ScanState command on an offline Windows system
@ -89,7 +89,7 @@ There are several benefits to running the `ScanState.exe` command on an offline
|Command-Line Option|Definition|
|--- |--- |
|**/offline:** *"path to an offline.xml file"*|This option is used to define a path to an offline .xml file that might specify other offline migration options, for example, an offline Windows directory or any domain or folder redirection required in your migration.|
|**/offline:** *"path to an Offline.xml file"*|This option is used to define a path to an offline .xml file that might specify other offline migration options, for example, an offline Windows directory or any domain or folder redirection required in your migration.|
|**/offlinewindir:** *"path to a Windows directory"*|This option specifies the offline Windows directory that the `ScanState.exe` command gathers user state from. The offline directory can be Windows.old when you run the `ScanState.exe` command in Windows or a Windows directory when you run the `ScanState.exe` command in WinPE.|
|**/offlinewinold:** *"Windows.old directory"*|This command-line option enables the offline migration mode and starts the migration from the location specified. It's only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.|
@ -100,8 +100,8 @@ USMT provides the following options to specify what files you want to migrate.
| Command-Line Option | Description |
|-----|-----|
| **/i:**[*Path*]*FileName* | **(include)** <br/><br/>Specifies an .xml file that contains rules that define what user, application, or system state to migrate. You can specify this option multiple times to include all of your .xml files (`MigApp.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 &quot;XML Files&quot; section of the [Frequently asked questions](usmt-faq.yml) article. |
| **/genconfig:**[*Path*]*FileName* | (Generate **Config.xml**) <br/><br/>Generates the optional `Config.xml` file, but doesn't create a migration store. To ensure that this file contains every component, application and setting that can be migrated, you should create this file on a source computer that contains all the components, applications, and settings that will be present on the destination computers. In addition, you should specify the other migration .xml files, using the **/i** option, when you specify this option.<br/><br/>After you create this file, you'll need to make use of it with the `ScanState.exe` command using the **/config** option.<br/><br/>The only options that you can specify with this option are the `/i`, `/v`, and `/l` options. You can't specify *StorePath*, because the `/genconfig` option doesn't create a store. *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.<br/><br/>Examples: <ul><li>The following example creates a `Config.xml` file in the current directory:<br/>`scanstate.exe /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:13`</li></ul> |
| **/config:**[*Path*]*FileName* | Specifies the `Config.xml` file that the `ScanState.exe` command should use to create the store. You can't use 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 *FileName* must be located in the current directory.<br/><br/>The following example creates a store using the `Config.xml` file, `MigDocs.xml`, and `MigApp.xml` files:<br/>`scanstate.exe \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:scan.log`<br/><br/>The following example migrates the files and settings to the destination computer using the `Config.xml`, `MigDocs.xml`, and `MigApp.xml` files:<br/>`loadstate.exe \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log` |
| **/genconfig:**[*Path*]*FileName* | (Generate **Config.xml**) <br/><br/>Generates the optional `Config.xml` file, but doesn't create a migration store. To ensure that this file contains every component, application and setting that can be migrated, you should create this file on a source computer that contains all the components, applications, and settings that will be present on the destination computers. In addition, you should specify the other migration .xml files, using the **/i** option, when you specify this option.<br/><br/>After you create this file, you'll need to make use of it with the `ScanState.exe` command using the **/config** option.<br/><br/>The only options that you can specify with this option are the `/i`, `/v`, and `/l` options. You can't specify *StorePath*, because the `/genconfig` option doesn't create a store. *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.<br/><br/>Examples: <ul><li>The following example creates a `Config.xml` file in the current directory:<br/>`ScanState.exe /i:MigApp.xml /i:MigDocs.xml /genconfig:Config.xml /v:13`</li></ul> |
| **/config:**[*Path*]*FileName* | Specifies the `Config.xml` file that the `ScanState.exe` command should use to create the store. You can't use 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 *FileName* must be located in the current directory.<br/><br/>The following example creates a store using the `Config.xml` file, `MigDocs.xml`, and `MigApp.xml` files:<br/>`ScanState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:ScanState.log`<br/><br/>The following example migrates the files and settings to the destination computer using the `Config.xml`, `MigDocs.xml`, and `MigApp.xml` files:<br/>`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 you to specify the location of the default .xml files and then begin the migration. If no path is specified, USMT will reference 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`. |
| **/genmigxml:** *path to a file* | This option specifies that the `ScanState.exe` command should use the document finder to create and export an .xml file that defines how to migrate all of the files on the computer on which the `ScanState.exe` command is running. |
| **/targetwindows8** | Optimizes `ScanState.exe` when using USMT 10.0 to migrate a user state to Windows 8 or Windows 8.1 instead of Windows 10. You should use this command-line option in the following scenarios: <ul><li>**To create a `Config.xml` file by using the `/genconfig` option.** Using the `/targetwindows8` option optimizes the `Config.xml` file so that it only contains components that relate to Windows 8 or Windows 8.1.</li><li>**To create a migration store.** Using the `/targetwindows8` option ensures that the **ScanState** tool gathers the correct set of operating system settings. Without the `/targetwindows8` command-line option, some settings can be lost during the migration.</li></ul> |
@ -119,12 +119,12 @@ USMT provides several options that you can use to analyze problems that occur du
|-----|-----|
| **/listfiles**:&lt;FileName&gt; | You can use the `/listfiles` command-line option with the `ScanState.exe` command to generate a text file that lists all of the files included in the migration. |
| **/l:**[*Path*]*FileName* | Specifies the location and name of the **ScanState** log. <br/><br/>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 use the `/v` option to adjust the amount of output. <br/><br/>If you run the `ScanState.exe` command from a shared network resource, you must specify the `/l` option, or USMT will fail with the following 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 `ScanState.exe` from a shared network resource. |
| **/v:***&lt;VerbosityLevel&gt;* | **(Verbosity)**<br/><br/>Enables verbose output in the **ScanState** log file. The default value is 0. <br/><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/>`scanstate.exe \server\share\migration\mystore /v:13 /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.<br/><br/>For example: <br/>`scanstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:scanlog.log` |
| **/v:***&lt;VerbosityLevel&gt;* | **(Verbosity)**<br/><br/>Enables verbose output in the **ScanState** log file. The default value is 0. <br/><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/>`ScanState.exe \server\share\migration\mystore /v:13 /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.<br/><br/>For example: <br/>`ScanState.exe /i:MigApp.xml /i:MigDocs.xml \server\share\migration\mystore /progress:Progress.log /l:scanlog.log` |
| **/c** | When this option is specified, the `ScanState.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 in the store, the `ScanState.exe` command will log an error and continue with the migration. In addition, if a file is open or in use by an application, USMT may not be able to migrate the file and will log an error. Without the `/c` option, the `ScanState.exe` command will exit on the first error.<br/><br/>You can use the new &lt;**ErrorControl**&gt; 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 advantage in the `Config.xml` file 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 &lt;**ErrorControl**&gt; section that is enabled by specifying error messages and desired behaviors in the `Config.xml` file. |
| **/r:***&lt;TimesToRetry&gt;* | **(Retry)**<br/><br/>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.<br/><br/>While storing the user state, the `/r` option won't be able to 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:***&lt;SecondsBeforeRetry&gt;* | **(Wait)**<br/><br/>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
| **/p:***&lt;pathToFile&gt;* | When the `ScanState.exe` command runs, it will create 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:<br/>`Scanstate.exe C:\MigrationLocation [additional parameters]`<br/>`/p:"C:\MigrationStoreSize.xml"`<br/><br/>For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).<br/><br/>To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the `/p` option, without specifying *&quot;pathtoafile&quot;*, in USMT. If you specify only the `/p` option, the storage space estimations are created in the same manner as with USMT3.x releases. |
| **/p:***&lt;pathToFile&gt;* | When the `ScanState.exe` command runs, it will create 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:<br/>`ScanState.exe C:\MigrationLocation [additional parameters]`<br/>`/p:"C:\MigrationStoreSize.xml"`<br/><br/>For more information, see [Estimate Migration Store Size](usmt-estimate-migration-store-size.md).<br/><br/>To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the `/p` option, without specifying *&quot;pathtoafile&quot;*, in USMT. If you specify only the `/p` option, the storage space estimations are created in the same manner as with USMT3.x releases. |
| **/?** or **/help** | Displays Help at the command line. |
## User options
@ -135,8 +135,8 @@ By default, all users are migrated. The only way to specify which users to inclu
|-----|-----|
| **/all** | Migrates all of the users on the computer. <br/><br/>USMT migrates all user accounts on the computer, unless you specifically exclude an account with either 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 specify the `/all` option, you can't also use the `/ui`, `/ue` or `/uel` options. |
| **/ui**:*&lt;DomainName&gt;*&#92;*&lt;UserName&gt;*<br/>or<br/>**/ui**:*&lt;ComputerName&gt;*&#92;*&lt;LocalUserName&gt;* | **(User include)** <br/><br/>Migrates the specified users. By default, all users are included in the migration. Therefore, this option is helpful only when used with the `/ue` or `/uel` options. 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 quotation marks (`"`). <div class="alert">**Note**<br/>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.</div><br/>For example:<br/><ul><li>To include only **User2** from the Fabrikam domain, enter:<br/><br/>`/ue:*\* /ui:fabrikam\user2`<br/><br/></li><li>To migrate all users from the Fabrikam domain, and only the user accounts from other domains that have been active or otherwise modified in the last 30 days, enter:<br/><br/>`/uel:30 /ui:fabrikam\*`<br/><br/>In this example, a user account from the Contoso domain that was last modified two months ago won't be migrated.</li></ul><br/>For more examples, see the descriptions of the `/ue` and `/ui` options in this table. |
| **/uel**:*&lt;NumberOfDays&gt;*<br/>or<br/>**/uel**:*&lt;YYYY/MM/DD&gt;*<br/>or<br/>**/uel:0** | **(User exclude based on last logon)**<br/><br/>Migrates the users that logged on to 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 account was modified, within the last 30 days from the date when the `ScanState.exe` command is run.<br/><br/>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 in to another computer, that sign-in instance isn't considered by USMT. <div class="alert">**Note**<br/>The `/uel` option isn't valid in offline migrations.</div><ul><li>`/uel:0` migrates any users who are currently logged on.</li><li>`/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>`/uel:1` migrates users whose account has been modified within the last 24 hours.</li><li>`/uel:2020/2/15` migrates users who have logged on or been modified February 15, 2020 or afterwards.</li></ul> <br/>For example: <br/>`scanstate.exe /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /uel:0` |
| **/ue**:*&lt;DomainName&gt;*&#92;*&lt;UserName&gt;*<br/>-or-<br/><br/>**/ue**:*&lt;ComputerName&gt;*&#92;*&lt;LocalUserName&gt;* | **(User exclude)**<br/><br/>Excludes the specified users from the migration. You can specify multiple `/ue` options. You can't use this option with the `/all` option. *&lt;DomainName&gt;* and *&lt;UserName&gt;* can contain the asterisk (`*`) wildcard character. When you specify a user name that contains spaces, you need to surround it with quotation marks (`"`).<br/><br/>For example:<br/>`scanstate.exe /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /ue:contoso\user1` |
| **/uel**:*&lt;NumberOfDays&gt;*<br/>or<br/>**/uel**:*&lt;YYYY/MM/DD&gt;*<br/>or<br/>**/uel:0** | **(User exclude based on last logon)**<br/><br/>Migrates the users that logged on to 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 account was modified, within the last 30 days from the date when the `ScanState.exe` command is run.<br/><br/>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 in to another computer, that sign-in instance isn't considered by USMT. <div class="alert">**Note**<br/>The `/uel` option isn't valid in offline migrations.</div><ul><li>`/uel:0` migrates any users who are currently logged on.</li><li>`/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>`/uel:1` migrates users whose account has been modified within the last 24 hours.</li><li>`/uel:2020/2/15` migrates users who have logged on or been modified February 15, 2020 or afterwards.</li></ul> <br/>For example: <br/>`ScanState.exe /i:MigApp.xml /i:MigDocs.xml \\server\share\migration\mystore /uel:0` |
| **/ue**:*&lt;DomainName&gt;*&#92;*&lt;UserName&gt;*<br/>-or-<br/><br/>**/ue**:*&lt;ComputerName&gt;*&#92;*&lt;LocalUserName&gt;* | **(User exclude)**<br/><br/>Excludes the specified users from the migration. You can specify multiple `/ue` options. You can't use this option with the `/all` option. *&lt;DomainName&gt;* and *&lt;UserName&gt;* can contain the asterisk (`*`) wildcard character. When you specify a user name that contains spaces, you need to surround it with quotation marks (`"`).<br/><br/>For example:<br/>`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \\server\share\migration\mystore /ue:contoso\user1` |
## How to use /ui and /ue
@ -184,7 +184,7 @@ For more information, see [Migrate EFS Files and Certificates](usmt-migrate-efs-
| **/efs:abort** | Causes the `ScanState.exe` command to fail with an error code, if an Encrypting File System (EFS) file is found on the source computer. Enabled by default. |
| **/efs:skip** | Causes the `ScanState.exe` command to ignore EFS files. |
| **/efs:decryptcopy** | Causes the `ScanState.exe` command to decrypt the file, if possible, before saving it to the migration store, and to fail if the file can't be decrypted. If the `ScanState.exe` command succeeds, the file will be unencrypted in the migration store, and once you run the `LoadState.exe` command, the file will be copied to the destination computer. |
| **/efs:copyraw** | Causes the `ScanState.exe` command to copy the files in the encrypted format. The files will be inaccessible on the destination computer until the EFS certificates are migrated. EFS certificates will be automatically migrated; however, by default USMT fails if an encrypted file is found, unless you specify an `/efs` option. Therefore you should specify the `/efs:copyraw` option with the `ScanState.exe` command to migrate the encrypted file. Then, when you run the `LoadState.exe` command, the encrypted file and the EFS certificate will be automatically migrated.<br/><br/>For example: <br/>`scanstate.exe /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /efs:copyraw` <div class="alert">**Important** <br/>All files must be encrypted if the parent folder is encrypted. If the encryption attribute on a file inside an encrypted folder has been removed, the file will be encrypted during the migration using the credentials of the account used to run the **LoadState** tool. For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md).</div>|
| **/efs:copyraw** | Causes the `ScanState.exe` command to copy the files in the encrypted format. The files will be inaccessible on the destination computer until the EFS certificates are migrated. EFS certificates will be automatically migrated; however, by default USMT fails if an encrypted file is found, unless you specify an `/efs` option. Therefore you should specify the `/efs:copyraw` option with the `ScanState.exe` command to migrate the encrypted file. Then, when you run the `LoadState.exe` command, the encrypted file and the EFS certificate will be automatically migrated.<br/><br/>For example: <br/>`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \server\share\migration\mystore /efs:copyraw` <div class="alert">**Important** <br/>All files must be encrypted if the parent folder is encrypted. If the encryption attribute on a file inside an encrypted folder has been removed, the file will be encrypted during the migration using the credentials of the account used to run the **LoadState** tool. For more information, see [Migrate EFS files and certificates](usmt-migrate-efs-files-and-certificates.md).</div>|
## Incompatible command-line options

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

@ -32,7 +32,7 @@ USMT includes three command-line tools:
USMT also includes a set of three modifiable .xml files:
- MigApp.xml
- `MigApp.xml`
- MigDocs.xml
- MigUser.xml

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

File diff suppressed because it is too large Load Diff

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

@ -20,7 +20,7 @@ This section contains articles that you can use to work with and to customize th
| Link | Description |
|--- |--- |
|[Understanding migration XML files](understanding-migration-xml-files.md)|Provides an overview of the default and custom migration XML files and includes guidelines for creating and editing a customized version of the MigDocs.xml file.|
|[Config.xml file](usmt-configxml-file.md)|Describes the Config.xml file and policies concerning its configuration.|
|[Config.xml file](usmt-configxml-file.md)|Describes the `Config.xml` file and policies concerning its configuration.|
|[Customize USMT XML files](usmt-customize-xml-files.md)|Describes how to customize USMT XML files.|
|[Custom XML examples](usmt-custom-xml-examples.md)|Gives examples of XML files for various migration scenarios.|
|[Conflicts and precedence](usmt-conflicts-and-precedence.md)|Describes the precedence of migration rules and how conflicts are handled.|

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

@ -37,7 +37,7 @@ The following sections demonstrate how to run the `UsmtUtils.exe` command with t
To verify the condition of a compressed migration store, use the following UsmtUtils syntax:
> usmtutils.exe /verify\[:&lt;*reportType*&gt;\] &lt;*filePath*&gt; \[/l:&lt;*logfile*&gt;\] \[/decrypt \[:&lt;*AlgID*&gt;\] {/key:&lt;*keystring*&gt; | /keyfile:&lt;*filename*&gt;}\]
> UsmtUtils.exe /verify\[:&lt;*reportType*&gt;\] &lt;*filePath*&gt; \[/l:&lt;*logfile*&gt;\] \[/decrypt \[:&lt;*AlgID*&gt;\] {/key:&lt;*keystring*&gt; | /keyfile:&lt;*filename*&gt;}\]
Where the placeholders have the following values:
@ -60,7 +60,7 @@ Where the placeholders have the following values:
To verify whether the migration store is intact or whether it contains corrupted files or a corrupted catalog, enter:
``` syntax
usmtutils.exe /verify D:\MyMigrationStore\store.mig
UsmtUtils.exe /verify D:\MyMigrationStore\store.mig
```
Because no report type is specified, **UsmtUtils** displays the default summary report.
@ -70,7 +70,7 @@ Because no report type is specified, **UsmtUtils** displays the default summary
To verify whether the catalog file is corrupted or intact, enter:
``` syntax
usmtutils.exe /verify:catalog D:\MyMigrationStore\store.mig
UsmtUtils.exe /verify:catalog D:\MyMigrationStore\store.mig
```
## To verify the status of all files
@ -78,7 +78,7 @@ usmtutils.exe /verify:catalog D:\MyMigrationStore\store.mig
To verify whether there are any corrupted files in the compressed migration store, and to specify the name and location of the log file, enter:
``` syntax
usmtutils.exe /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
UsmtUtils.exe /verify:all D:\MyMigrationStore\store.mig /decrypt /l:D:\UsmtUtilsLog.txt`
```
In addition to verifying the status of all files, this example decrypts the files. Because no encryption algorithm is specified, **UsmtUtils** uses the default 3DES cryptographic algorithm.
@ -88,7 +88,7 @@ In addition to verifying the status of all files, this example decrypts the file
In this example, the log file will only list the files that became corrupted during the **ScanState** process. This list will include the catalog file if it's also corrupted.
``` syntax
usmtutils.exe /verify:failureonly D:\MyMigrationStore\USMT\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt
UsmtUtils.exe /verify:failureonly D:\MyMigrationStore\USMT\store.mig /decrypt:AES_192 /keyfile:D:\encryptionKey.txt
```
This example also decrypts the files by specifying the cryptographic algorithm and the location of the file that contains the encryption key.