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

USMT Refresh 23

Browse Source
This commit is contained in:
Frank Rojas
2024-01-03 11:01:18 -05:00
parent f9c0c375e3
commit 2dbfb6c10d
5 changed files with 42 additions and 44 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -15,29 +15,29 @@ appliesto:
# Exclude files and settings
When you specify the migration **.xml** files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, the User State Migration Tool (USMT) 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 the migration **.xml** files `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml` are specified, the User State Migration Tool (USMT) migrates the settings and components listed, as discussed in [What does USMT migrate?](usmt-what-does-usmt-migrate.md) A custom **.xml** file can be created to further specify what to include or exclude in the migration. In addition, a `Config.xml` file can be created to exclude an entire component from a migration. However, users can't be excluded 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:
- [Create a custom .xml file](#create-a-custom-xml-file). You can use the following elements to specify what to exclude:
- [Create a custom .xml file](#create-a-custom-xml-file). The following elements can be used to specify what to exclude:
- [Include and exclude](#include-and-exclude): You can use the **\<include\>** and **\<exclude\>** elements to exclude objects with conditions. For example, you can migrate all files located in the `C:\` drive, except any `.mp3` files. It's important to remember that [Conflicts and precedence](usmt-conflicts-and-precedence.md) apply to these elements.
- [Include and exclude](#include-and-exclude): The **\<include\>** and **\<exclude\>** elements can be used to exclude objects with conditions. For example, all files located in the `C:\` drive can be migrated, except any `.mp3` files. It's important to remember that [Conflicts and precedence](usmt-conflicts-and-precedence.md) apply to these elements.
- [unconditionalExclude](#example-1-how-to-migrate-all-files-from-c-except-mp3-files): You can use the **\<unconditionalExclude\>** element to globally exclude data. This element takes precedence over all other include and exclude rules in the **.xml** files. Therefore, this element excludes objects regardless of any other **\<include\>** rules that are in the **.xml** files. For example, you can exclude all **.mp3** files on the computer, or you can exclude all files from C:\\UserData.
- [unconditionalExclude](#example-1-how-to-migrate-all-files-from-c-except-mp3-files): The **\<unconditionalExclude\>** element can be used to globally exclude data. This element takes precedence over all other include and exclude rules in the **.xml** files. Therefore, this element excludes objects regardless of any other **\<include\>** rules that are in the **.xml** files. For example, all **.mp3** files can be excluded on the computer, or all files from C:\\UserData can be excluded.
- [Create a Config.xml file](#create-a-config-xml-file): You can create and modify a `Config.xml` file to exclude an entire component from the migration. For example, you can use this file to exclude the settings for one of the default applications. In addition, creating and modifying a `Config.xml` file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration **.xml** files because you don't need to be familiar with the migration rules and syntax.
- [Create a Config.xml file](#create-a-config-xml-file): A `Config.xml` file can be created and modified to exclude an entire component from the migration. For example, this file can be used to exclude the settings for one of the default applications. In addition, creating and modifying a `Config.xml` file is the only way to exclude the operating-system settings that are migrated to computers running Windows. Excluding components using this file is easier than modifying the migration **.xml** files because familiarity with the migration rules and syntax isn't required.
## Create a custom .xml file
Microsoft recommends that you create a custom **.xml** file instead of modifying the default migration **.xml** files. When you use a custom **.xml** file, you can keep the changes separate from the default **.xml** file, which makes it easier to track the modifications.
Microsoft recommends creating a custom **.xml** file instead of modifying the default migration **.xml** files. When a custom **.xml** file is used, the changes can be kept separate from the default **.xml** file, which makes it easier to track the modifications.
### \<include\> and \<exclude\>
The migration **.xml** files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, contain the **\<component\>** element, which typically represents a self-contained component or an application such as Microsoft Office Outlook and Word. To exclude the files and registry settings that are associated with these components, use the **\<include\>** and **\<exclude\>** elements. For example, you can use these elements to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
The migration **.xml** files, `MigApp.xml`, `MigDocs.xml`, and `MigUser.xml`, contain the **\<component\>** element, which typically represents a self-contained component or an application such as Microsoft Office Outlook and Word. To exclude the files and registry settings that are associated with these components, use the **\<include\>** and **\<exclude\>** elements. For example, these elements can be used to migrate all files and settings with pattern X except files and settings with pattern Y, where Y is more specific than X. For the syntax of these elements, see [USMT XML Reference](usmt-xml-reference.md).
> [!NOTE]
>
> If you specify an **\<exclude\>** rule, always specify a corresponding **\<include\>** rule. Otherwise, if you don't specify an **\<include\>** rule, the specific files or settings aren't included. They're already excluded from the migration. Thus, an unaccompanied **\<exclude\>** rule is unnecessary.
> If an **\<exclude\>** rule is specified, always specify a corresponding **\<include\>** rule. Otherwise, if an **\<include\>** rule isn't specified, the specific files or settings aren't included. They're already excluded from the migration. Thus, an unaccompanied **\<exclude\>** rule is unnecessary.
- [Example 1: How to migrate all files from C:\\ except .mp3 files](#example-1-how-to-migrate-all-files-from-c-except-mp3-files)
@ -273,13 +273,13 @@ The following **.xml** file unconditionally excludes the system folders of `C:\W
## Create a Config XML File
You can create and modify a `Config.xml` file if you want to exclude components from the migration. Excluding components using this file is easier than modifying the migration **.xml** files because you don't need to be familiar with the migration rules and syntax. `Config.xml` is an optional file that you can create using the `/genconfig` command-line option with the ScanState tool. For example, you can use the `Config.xml` file to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
A `Config.xml` file can be created and modified to exclude components from the migration. Excluding components using this file is easier than modifying the migration **.xml** files because familiarity with the migration rules and syntax isn't required. `Config.xml` is an optional file that can be created using the `/genconfig` command-line option with the ScanState tool. For example, the `Config.xml` file can be used to exclude the settings for one of the default applications. In addition, creating and modifying this file is the only way to exclude the operating-system settings that are migrated to computers running Windows.
- **To exclude the settings for a default application:** Specify `migrate="no"` for the application under the **\<Applications\>** section of the `Config.xml` file.
- **To exclude an operating system setting:** Specify `migrate="no"` for the setting under the **\<WindowsComponents\>** section.
- **To exclude the Documents folder:** Specify `migrate="no"` for the **Documents** folder under the **\<Documents\>** section. Any **\<include\>** rules in the **.xml** files are still applied. For example, if you have a rule that includes all the **.docx** files in the **Documents** folder, then **.docx** files are still migrated. However, any additional files that aren't **.docx** aren't migrated.
- **To exclude the Documents folder:** Specify `migrate="no"` for the **Documents** folder under the **\<Documents\>** section. Any **\<include\>** rules in the **.xml** files are still applied. For example, if a rule exists that includes all the **.docx** files in the **Documents** folder, then **.docx** files are still migrated. However, any additional files that aren't **.docx** aren't migrated.
For more information, see [Config.xml File](usmt-configxml-file.md).

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

@ -15,7 +15,7 @@ appliesto:
# 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 files and settings are migrated during a typical PC-refresh migration, a compressed migration store file is usually created 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, it can be encrypted by using different encryption algorithms. When the file is migrated back to the source computer after the operating system is installed, the **UsmtUtils** command can be run with the `/extract` option to recover the files from the compressed migration store. The **UsmtUtils** command with the `/extract` option can also be used any time data needs to be recovered from a migration store.
Options used with the `/extract` option can specify:
@ -25,7 +25,7 @@ Options used with the `/extract` option can specify:
- Include and exclude patterns for selective data extraction.
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. The `/i` and the `/e` options are different from the include and exclude rules used in the **ScanState** and **LoadState** tools.
In addition, the file patterns that need to be extracted can be specified 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. The `/i` and the `/e` options are different from the include and exclude rules used in the **ScanState** and **LoadState** tools.
## To run the UsmtUtils tool with the /extract option
@ -41,7 +41,7 @@ Where the placeholders have the following values:
- **\<filePath\>** is the location of the migration store.
- **\<destination path\>** is the location of the file where you want the **/extract** option to put the extracted migration store contents.
- **\<destination path\>** is the location of the file where the **/extract** option should put the extracted migration store contents.
- **\<includePattern\>** specifies the pattern for the files to include in the extraction.

56
windows/deployment/usmt/usmt-faq.yml
View File

@ -33,12 +33,12 @@ sections:
- Uncompressed store
- question: |
Can I store the files and settings directly on the destination computer or do I need a server?
Can the files and settings be stored directly on the destination computer or is a server needed?
answer: |
You don't need to save the files to a server. If you're moving the user state to a new computer, you can create the store on:
Files don't need to be saved to a server. If moving the user state to a new computer, the store can be created on:
- A shared folder.
- On media that you can remove, such as a USB flash drive (UFD).
- On removable media, such as a USB flash drive (UFD).
- Directly on the destination computer.
To store it directly on the destination computer:
@ -50,31 +50,31 @@ sections:
1. Run the **LoadState** tool on the destination computer and specify `C:\store` as the store location.
- question: |
Can I migrate data between operating systems with different languages?
Can data be migrated between operating systems with different languages?
answer: |
No. USMT doesn't support migrating data between operating systems with different languages; the source computer's operating-system language must match the destination computer's operating-system language.
- question: |
Can I change the location of the temporary directory on the destination computer?
Can the location of the temporary directory on the destination computer be changed?
answer: |
Yes. The environment variable `USMT\_WORKING\_DIR` can be changed to an alternative temporary directory. There are some offline migration scenarios where changing the temporary directory is necessary, for example, when the USMT binaries are located on read-only Windows Preinstallation Environment (WinPE) boot media.
- question: |
How do I install USMT?
How is USMT installed?
answer: |
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), you need to install the Windows ADK package on at least one computer in the environment. The USMT binaries can then be copied from the USMT directory located on the original computer where the Windows ADK was installed to additional client computers.
Because USMT is included in Windows Assessment and Deployment Kit (Windows ADK), the Windows ADK package needs to be installed on at least one computer in the environment. The USMT binaries can then be copied from the USMT directory located on the original computer where the Windows ADK was installed to additional client computers.
- question: |
How do I uninstall USMT?
How is USMT uninstalled?
answer: |
For computers that have the Windows ADK installed, uninstalling the Windows ADK from the computer uninstalls USMT. For client computers that don't have the Windows ADK installed, you can delete the USMT directory to uninstall USMT.
For computers that have the Windows ADK installed, uninstalling the Windows ADK from the computer uninstalls USMT. For client computers that don't have the Windows ADK installed, the USMT directory can be deleted to uninstall USMT.
- name: Files and Settings
questions:
- question: |
How can I exclude a folder or a certain type of file from the migration?
How can a folder or a certain type of file be excluded from the migration?
answer: |
You can use the **\<unconditionalExclude\>** element to globally exclude data from the migration. For example, you can use this element to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`. This element excludes objects regardless of any other **\<include\>** rules that are in the **.xml** files. For an example, see **\<unconditionalExclude\>** in the [Exclude files and settings](usmt-exclude-files-and-settings.md) article. For the syntax of this element, see [XML elements library](usmt-xml-elements-library.md).
The **\<unconditionalExclude\>** element can be used to globally exclude data from the migration. For example, this element can be used to exclude all MP3 files on the computer or to exclude all files from `C:\UserData`. This element excludes objects regardless of any other **\<include\>** rules that are in the **.xml** files. For an example, see **\<unconditionalExclude\>** in the [Exclude files and settings](usmt-exclude-files-and-settings.md) article. For the syntax of this element, see [XML elements library](usmt-xml-elements-library.md).
- question: |
What happens to files that were located on a drive that don't exist on the destination computer?
@ -90,7 +90,7 @@ sections:
- name: USMT .xml Files
questions:
- question: |
Where can I get examples of USMT **.xml** files?
Where are there examples of USMT **.xml** files?
answer: |
The following articles include examples of USMT **.xml** files:
@ -103,37 +103,37 @@ sections:
- [Custom XML examples](usmt-custom-xml-examples.md)
- question: |
Can I use custom **.xml** files that were written for USMT 5.0?
Can custom **.xml** files that were written for USMT 5.0 be used?
answer: |
Yes. You can use custom **.xml** files that were written for USMT 5.0 with newer versions of USMT. However, in order to use new USMT functionality, you must revisit the custom USMT files and refresh them to include the new command-line options and XML elements.
Yes. Custom **.xml** files that were written for USMT 5.0 can be used with newer versions of USMT. However, in order to use new USMT functionality, the custom USMT files must be revisited and refreshed to include the new command-line options and XML elements.
- question: |
How can I validate the **.xml** files?
How can the **.xml** files be validated?
answer: |
You can use the USMT XML Schema (`MigXML.xsd`) to write and validate migration **.xml** files.
The USMT XML Schema (`MigXML.xsd`) can be used to write and validate migration **.xml** files.
- question: |
Why must I list the **.xml** files with both the `ScanState.exe` and `LoadState.exe` commands?
Why must the **.xml** files be included with both the `ScanState.exe` and `LoadState.exe` commands?
answer: |
The **.xml** files aren't copied to the store as in previous versions of USMT. Because the **ScanState** and **LoadState** tools need the **.xml** files to control the migration, you must specify the same set of **.xml** files for the `ScanState.exe` and `LoadState.exe` commands. If you used a particular set of mig\*.xml files in the **ScanState** tool, either called through the `/auto` option, or individually through the `/i` option, then you should use same option to call the exact same mig\*.xml files in the **LoadState** tool. However, the `Config.xml` file doesn't need to be specified, unless files and settings that were migrated to the store need to be excluded. For example, you might want to migrate the **Documents** folder to the store, but not to the destination computer. To do this type of migration, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. **LoadState** migrates only the files and settings that you want to migrate.
The **.xml** files aren't copied to the store as in previous versions of USMT. Because the **ScanState** and **LoadState** tools need the **.xml** files to control the migration, the same set of **.xml** files must be specified for the `ScanState.exe` and `LoadState.exe` commands. If a particular set of mig\*.xml files were used in the **ScanState** tool, either called through the `/auto` option, or individually through the `/i` option, then the same option should be used to call the exact same mig\*.xml files in the **LoadState** tool. However, the `Config.xml` file doesn't need to be specified, unless files and settings that were migrated to the store need to be excluded. For example, the **Documents** folder might be migrated to the store, but not to the destination computer. To do this type of migration, modify the `Config.xml` file and specify the updated file with the `LoadState.exe` command. **LoadState** migrates only the desired files and settings.
If you exclude an **.xml** file from the `LoadState.exe` command, then all of the data that is in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified for the `ScanState.exe` command don't apply. For example, if you exclude a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`.
If an **.xml** file is excluded from the `LoadState.exe` command, then all of the data in the store that was migrated with the missing **.xml** files are migrated. However, the migration rules that were specified for the `ScanState.exe` command don't apply. For example, if a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")` is excluded, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`.
- question: |
Which files can I modify and specify on the command line?
Which files can be modified and specified on the command line?
answer: |
You can specify the `MigUser.xml` and `MigApp.xml` files on the command line. You can modify each of these files. Manifests control the migration of operating system settings. Manifests can't be modified. If you want to exclude certain operating-system settings or any other components, create and modify the `Config.xml` file.
The `MigUser.xml`, `MigApp.xml`, and `MigDocs.xml` files can be specified on the command line. Each of these files can be modified. Manifests control the migration of operating system settings. Manifests can't be modified. To exclude certain operating-system settings or any other components, create and modify the `Config.xml` file.
- question: |
What happens if I don't specify the **.xml** files on the command line?
What happens if the **.xml** files aren't specified on the command line?
answer: |
- **ScanState**
If you don't specify any files with the `ScanState.exe` command, all user accounts and default operating system components are migrated.
If no files are specified with the `ScanState.exe` command, all user accounts and default operating system components are migrated.
- **LoadState**
If you don't specify any files with the `LoadState.exe` command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in **.xml** files with the `ScanState.exe` command doesn't apply. For example, if you exclude a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")`, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`.
If no files are specified with the `LoadState.exe` command, all data that is in the store is migrated. However, any target-specific migration rules that were specified in **.xml** files with the `ScanState.exe` command doesn't apply. For example, if a `MigApp.xml` file that has a rerouting rule such as `MigsysHelperFunction.RelativeMove("c:\data", "%CSIDL_PERSONAL%")` is excluded, USMT doesn't reroute the files. Instead, it migrates them to `C:\data`.
- name: Conflicts and Precedence
questions:
@ -147,8 +147,6 @@ additionalContent: |
## Related topics
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)
[Extract files from a compressed USMT migration store](usmt-extract-files-from-a-compressed-migration-store.md)
[Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md)
- [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md).
- [Extract files from a compressed USMT migration store](usmt-extract-files-from-a-compressed-migration-store.md).
- [Verify the condition of a compressed migration store](verify-the-condition-of-a-compressed-migration-store.md).

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

@ -63,7 +63,7 @@ USMT provides the following options to specify what files to migrate.
| Command-Line Option | Description |
|--- |--- |
| **/i**:[*Path*]*FileName* | **(include)**<br>Specifies an **.xml** file that contains rules that define what data to migrate. This option can be specified multiple times to include all of the **.xml** files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom **.xml** files that are created). *Path* can be either a relative or full path. If the *Path* variable isn't specified, then *FileName* must be located in the current directory.<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. |
| **/i**:[*Path*]*FileName* | **(include)**<br>Specifies an **.xml** file that contains rules that define what data to migrate. This option can be specified multiple times to include all of the **.xml** files (`MigApp.xml`, `MigSys.xml`, `MigDocs.xml` and any custom **.xml** files that are created). *Path* can be either a relative or full path. If the *Path* variable isn't specified, then *FileName* must be located in the current directory.<br><br>For more information about which files to specify, see the "XML files" section of the [Frequently Asked Questions](usmt-faq.yml) article. |
| **/config**:[*Path*]*FileName* | Specifies the `Config.xml` file that the `LoadState.exe` command should use. This option can't be specified more than once on the command line. *Path* can be either a relative or full path. If the *Path* variable isn't specified, 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 specifying the location of the default **.xml** files. If no path is specified, USMT uses the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. |

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

@ -51,7 +51,7 @@ The syntax for `/verify` is:
| Command-line Option | Description |
|-----|--------|
| *\<reportType\>* | Specifies whether to report on all files, corrupted files only, or the status of the catalog. <ul><li>**Summary**. Returns both the number of files that are intact and the number of files that are corrupted in the migration store. If no algorithm is specified, the summary report is displayed as a default.</li><li>**all**. Returns a tab-delimited list of all of the files in the compressed migration store and the status for each file. Each line contains the file name followed by a tab spacing, and either **CORRUPTED** or **OK** depending on the status of the file. The last entry reports the corruption status of the **CATALOG** of the store. A catalog file contains metadata for all files in a migration store. The **LoadState** tool requires a valid catalog file in order to open the migration store. Returns &quot;OK&quot; if the catalog file is intact and **LoadState** can open the migration store and &quot;CORRUPTED&quot; if the migration store is corrupted.</li><li>**failureonly**. Returns a tab-delimited list of only the files that are corrupted in the compressed migration store.</li><li>**Catalog**. Returns only the status of the catalog file.</li></ul> |
| *\<reportType\>* | Specifies whether to report on all files, corrupted files only, or the status of the catalog. <ul><li>**Summary**. Returns both the number of files that are intact and the number of files that are corrupted in the migration store. If no algorithm is specified, the summary report is displayed as a default.</li><li>**all**. Returns a tab-delimited list of all of the files in the compressed migration store and the status for each file. Each line contains the file name followed by a tab spacing, and either **CORRUPTED** or **OK** depending on the status of the file. The last entry reports the corruption status of the **CATALOG** of the store. A catalog file contains metadata for all files in a migration store. The **LoadState** tool requires a valid catalog file in order to open the migration store. Returns "OK" if the catalog file is intact and **LoadState** can open the migration store and "CORRUPTED" if the migration store is corrupted.</li><li>**failureonly**. Returns a tab-delimited list of only the files that are corrupted in the compressed migration store.</li><li>**Catalog**. Returns only the status of the catalog file.</li></ul> |
| **/l:**<br>*\<logfilePath\>* | Specifies the location and name of the log file. |
| **/v:** *\<VerbosityLevel\>* | **(Verbosity)**<br><br>Enables verbose output in the **UsmtUtils** log file. The default value is 0.<br><br>The *VerbosityLevel* can be set to one of the following levels:<br><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> |
| **/decrypt** *\<AlgID\>* **/**:*\<KeyString\>*<br>or<br>**/decrypt** *\<AlgID\>* **/**:*\<"Key String"\>*<br>or<br>**/decrypt:** *\<AlgID\>* **/keyfile**:*\<FileName\>* | Specifies that the `/encrypt` option was used to create the migration store with the **ScanState** tool. To decrypt the migration store, specify a `/key` or `/keyfile` option as follows:<br><ul><li>*\<AlgID\>* specifies the cryptographic algorithm that was used to create the migration store on the `ScanState.exe` command line. If no algorithm is specified, **ScanState** and **UsmtUtils** use the 3DES algorithm as a default.<br>*\<AlgID\>* valid values include: `AES_128`, `AES_192`, `AES_256`, `3DES`, or `3DES_112`.</li><li> `/key:` *\<KeyString\>* specifies the encryption key. If there's a space in *\<KeyString\>*, the argument must be surrounded with quotation marks.</li><li> `/keyfile`: *\<FileName\>* specifies the location and name of a text (.txt) file that contains the encryption key.</li></ul><br>For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). |