diff --git a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md index 6877961d15..e603c984d4 100644 --- a/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md +++ b/windows/deployment/usmt/getting-started-with-the-user-state-migration-tool.md @@ -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 `` 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® 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 `` 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. diff --git a/windows/deployment/usmt/migration-store-types-overview.md b/windows/deployment/usmt/migration-store-types-overview.md index d2cc3a4ec4..7bb4a37792 100644 --- a/windows/deployment/usmt/migration-store-types-overview.md +++ b/windows/deployment/usmt/migration-store-types-overview.md @@ -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 `\\\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 `\\\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. diff --git a/windows/deployment/usmt/offline-migration-reference.md b/windows/deployment/usmt/offline-migration-reference.md index b7ab0afb24..105327d3df 100644 --- a/windows/deployment/usmt/offline-migration-reference.md +++ b/windows/deployment/usmt/offline-migration-reference.md @@ -13,7 +13,7 @@ ms.technology: itpro-deploy # Offline Migration Reference -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: +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® 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:***<path to offline.xml>*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.| +|ScanState.exe|**/offline:***<path to Offline.xml>*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.| |ScanState.exe|**/offlineWinDir:***<Windows directory>*|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:***<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.| @@ -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: 
Set USMT_WORKING_DIR=[path to working directory]
| -|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: 
Set MIG_OFFLINE_PLATFORM_ARCH=32
| +|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: 
Set MIG_OFFLINE_PLATFORM_ARCH=32
| ## 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. ### <offline> diff --git a/windows/deployment/usmt/understanding-migration-xml-files.md b/windows/deployment/usmt/understanding-migration-xml-files.md index c27d2109d8..e5d168b840 100644 --- a/windows/deployment/usmt/understanding-migration-xml-files.md +++ b/windows/deployment/usmt/understanding-migration-xml-files.md @@ -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.
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.
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 /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml +ScanState.exe /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 - scanstate.exe /genmigxml: + ScanState.exe /genmigxml: ``` Where *<USMTpath>* is the location on your source computer where you've saved the USMT files and tools, and *<filepath.xml>* 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 diff --git a/windows/deployment/usmt/usmt-common-issues.md b/windows/deployment/usmt/usmt-common-issues.md index 23d35f65aa..3bc2e5875c 100644 --- a/windows/deployment/usmt/usmt-common-issues.md +++ b/windows/deployment/usmt/usmt-common-issues.md @@ -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 +UsmtUtils.exe /rd ``` You should also reboot the machine. diff --git a/windows/deployment/usmt/usmt-customize-xml-files.md b/windows/deployment/usmt/usmt-customize-xml-files.md index b56b14a8f1..b7345bd127 100644 --- a/windows/deployment/usmt/usmt-customize-xml-files.md +++ b/windows/deployment/usmt/usmt-customize-xml-files.md @@ -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 diff --git a/windows/deployment/usmt/usmt-exclude-files-and-settings.md b/windows/deployment/usmt/usmt-exclude-files-and-settings.md index 0c67fe8a1b..3821597500 100644 --- a/windows/deployment/usmt/usmt-exclude-files-and-settings.md +++ b/windows/deployment/usmt/usmt-exclude-files-and-settings.md @@ -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: diff --git a/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md b/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md index c1bb5f4ac4..20b48b006b 100644 --- a/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md +++ b/windows/deployment/usmt/usmt-extract-files-from-a-compressed-migration-store.md @@ -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 [/i:] [/e:] [/l:] [/decrypt[:] {/key: | /keyfile:}] [/o] +UsmtUtils.exe /extract [/i:] [/e:] [/l:] [/decrypt[:] {/key: | /keyfile:}] [/o] ``` Where the placeholders have the following values: @@ -45,7 +45,7 @@ Where the placeholders have the following values: - **<excludePattern>** specifies the pattern for the files to omit from the extraction. -- **<AlgID>** is the cryptographic algorithm that was used to create the migration store on the `scanstate.exe` command line. +- **<AlgID>** is the cryptographic algorithm that was used to create the migration store on the `ScanState.exe` command line. - **<logfile>** 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) diff --git a/windows/deployment/usmt/usmt-hard-link-migration-store.md b/windows/deployment/usmt/usmt-hard-link-migration-store.md index a43972cb9b..3ef9d3112b 100644 --- a/windows/deployment/usmt/usmt-hard-link-migration-store.md +++ b/windows/deployment/usmt/usmt-hard-link-migration-store.md @@ -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® 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 **<HardLinkStoreControl>** 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 **<HardLinkStoreControl>** 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 **<HardLinkStoreControl>** 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 diff --git a/windows/deployment/usmt/usmt-loadstate-syntax.md b/windows/deployment/usmt/usmt-loadstate-syntax.md index e70c3ef655..2571836634 100644 --- a/windows/deployment/usmt/usmt-loadstate-syntax.md +++ b/windows/deployment/usmt/usmt-loadstate-syntax.md @@ -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\] 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*
or
**/decrypt /key**:"*Key String*"
or
**/decrypt /keyfile**:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, you'll need to specify the encryption key in one of the following ways:
  • `/key`:*KeyString* specifies the encryption key. If there's a space in *KeyString*, you must surround the argument with quotation marks (`"`).
  • `/keyfile`:*FilePathAndName* specifies a text (`.txt`) file that contains the encryption key

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

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

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

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

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

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

`loadstate.exe \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log` | +| **/config**:[*Path*]*FileName* | Specifies the `Config.xml` file that the `LoadState.exe` command should use. You can't specify this option more than once on the command line. *Path* can be either a relative or full path. If you don't specify the *Path* variable, then the *FileName* must be located in the current directory.

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

`LoadState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:5 /l:LoadState.log` | | **/auto**:*"path to script files"* | This option enables you to specify the location of the default .xml files and then launch your migration. If no path is specified, USMT will use the directory where the USMT binaries are located. The `/auto` option has the same effect as using the following options: `/i:MigDocs.xml` `/i:MigApp.xml /v:5`. | ## 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.

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

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

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

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

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

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` | +| **/v**:*``* | **(Verbosity)**

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
` /progress:prog.log /l:load.log /md:contoso:fabrikam` | -| **/mu**:*OldDomain OldUserName*:[*NewDomain*]*NewUserName*
or
**/mu**:*OldLocalUserName*:*NewDomain NewUserName* | **(Move user)**

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

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1` | -| **/lac**:[*Password*] | **(Local account create)**

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

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

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

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`

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

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

For example:
`loadstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore`
`/progress:prog.log /l:load.log /lac:password /lae`

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | +| **/uel**:*``*
or
**/uel**:*``*
or
**/uel**:0 | **(User exclude based on last logon)**

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

For instructions, see [Migrate user accounts](usmt-migrate-user-accounts.md). | ### Examples for the /ui and /ue options diff --git a/windows/deployment/usmt/usmt-log-files.md b/windows/deployment/usmt/usmt-log-files.md index 9398cfb280..49cb9e9da6 100644 --- a/windows/deployment/usmt/usmt-log-files.md +++ b/windows/deployment/usmt/usmt-log-files.md @@ -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.| diff --git a/windows/deployment/usmt/usmt-migrate-user-accounts.md b/windows/deployment/usmt/usmt-migrate-user-accounts.md index 4a3750a1f2..148ccbacad 100644 --- a/windows/deployment/usmt/usmt-migrate-user-accounts.md +++ b/windows/deployment/usmt/usmt-migrate-user-accounts.md @@ -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 diff --git a/windows/deployment/usmt/usmt-migration-store-encryption.md b/windows/deployment/usmt/usmt-migration-store-encryption.md index bdbed437a0..b7896ba2dd 100644 --- a/windows/deployment/usmt/usmt-migration-store-encryption.md +++ b/windows/deployment/usmt/usmt-migration-store-encryption.md @@ -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. diff --git a/windows/deployment/usmt/usmt-requirements.md b/windows/deployment/usmt/usmt-requirements.md index 9fea9c01e5..d0f86bfc08 100644 --- a/windows/deployment/usmt/usmt-requirements.md +++ b/windows/deployment/usmt/usmt-requirements.md @@ -64,7 +64,7 @@ To open an elevated command prompt: ## Config.xml -### Specify the /c option and <ErrorControl> settings in the Config.xml file +### Specify the `/c` option and <ErrorControl> 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 **<ErrorControl>** 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). diff --git a/windows/deployment/usmt/usmt-return-codes.md b/windows/deployment/usmt/usmt-return-codes.md index a8904c9c4b..c2fbd59cd6 100644 --- a/windows/deployment/usmt/usmt-return-codes.md +++ b/windows/deployment/usmt/usmt-return-codes.md @@ -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 diff --git a/windows/deployment/usmt/usmt-scanstate-syntax.md b/windows/deployment/usmt/usmt-scanstate-syntax.md index 8598c81042..b6105d7f11 100644 --- a/windows/deployment/usmt/usmt-scanstate-syntax.md +++ b/windows/deployment/usmt/usmt-scanstate-syntax.md @@ -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 **<ErrorControl>** section.

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:** *<KeyString>* | **/keyfile**:*<file>*]} | 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:
  • `/key`: *KeyString* specifies the encryption key. If there's a space in *KeyString*, you'll need to surround *KeyString* with quotation marks (`"`).
  • `/keyfile`: *FilePathAndName* specifies a text (`.txt`) file that contains the encryption key.

*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.
**Important**
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.

The following example shows the `ScanState.exe` command and the `/key` option:
`scanstate.exe /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /encrypt /key:mykey` | +| **/encrypt** [{**/key:** *<KeyString>* | **/keyfile**:*<file>*]} | 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:
  • `/key`: *KeyString* specifies the encryption key. If there's a space in *KeyString*, you'll need to surround *KeyString* with quotation marks (`"`).
  • `/keyfile`: *FilePathAndName* specifies a text (`.txt`) file that contains the encryption key.

*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.
**Important**
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.

The following example shows the `ScanState.exe` command and the `/key` option:
`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \server\share\migration\mystore /encrypt /key:mykey` | | **/encrypt**:*<EncryptionStrength>* | 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 "File" 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.

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.

For example:
`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 "File" 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.

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.

For example:
`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)**

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 "XML Files" section of the [Frequently asked questions](usmt-faq.yml) article. | -| **/genconfig:**[*Path*]*FileName* | (Generate **Config.xml**)

Generates the optional `Config.xml` file, but doesn't create a migration store. To ensure that this file contains 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.

After you create this file, you'll need to make use of it with the `ScanState.exe` command using the **/config** option.

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.

Examples:
  • The following example creates a `Config.xml` file in the current directory:
    `scanstate.exe /i:migapp.xml /i:migdocs.xml /genconfig:config.xml /v:13`
| -| **/config:**[*Path*]*FileName* | Specifies the `Config.xml` file that the `ScanState.exe` command should use to create the store. 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.

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

The following example migrates the files and settings to the destination computer using the `Config.xml`, `MigDocs.xml`, and `MigApp.xml` files:
`loadstate.exe \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:13 /l:load.log` | +| **/genconfig:**[*Path*]*FileName* | (Generate **Config.xml**)

Generates the optional `Config.xml` file, but doesn't create a migration store. To ensure that this file contains 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.

After you create this file, you'll need to make use of it with the `ScanState.exe` command using the **/config** option.

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.

Examples:
  • The following example creates a `Config.xml` file in the current directory:
    `ScanState.exe /i:MigApp.xml /i:MigDocs.xml /genconfig:Config.xml /v:13`
| +| **/config:**[*Path*]*FileName* | Specifies the `Config.xml` file that the `ScanState.exe` command should use to create the store. 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.

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

The following example migrates the files and settings to the destination computer using the `Config.xml`, `MigDocs.xml`, and `MigApp.xml` files:
`LoadState.exe \server\share\migration\mystore /config:Config.xml /i:MigDocs.xml /i:MigApp.xml /v:13 /l:LoadState.log` | | **/auto:** *path to script files* | This option enables 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:
  • **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.
  • **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.
| @@ -119,12 +119,12 @@ USMT provides several options that you can use to analyze problems that occur du |-----|-----| | **/listfiles**:<FileName> | 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.

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.

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:

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

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

Enables verbose output in the **ScanState** log file. The default value is 0.

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

For example:
`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.

For example:
`scanstate.exe /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:scanlog.log` | +| **/v:***<VerbosityLevel>* | **(Verbosity)**

Enables verbose output in the **ScanState** log file. The default value is 0.

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

For example:
`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.

For example:
`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.

You can use the new <**ErrorControl**> section in the `Config.xml` file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This 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 <**ErrorControl**> section that is enabled by specifying error messages and desired behaviors in the `Config.xml` file. | | **/r:***<TimesToRetry>* | **(Retry)**

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

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:***<SecondsBeforeRetry>* | **(Wait)**

Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. | -| **/p:***<pathToFile>* | 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:
`Scanstate.exe C:\MigrationLocation [additional parameters]`
`/p:"C:\MigrationStoreSize.xml"`

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

To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the `/p` option, without specifying *"pathtoafile"*, 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:***<pathToFile>* | 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:
`ScanState.exe C:\MigrationLocation [additional parameters]`
`/p:"C:\MigrationStoreSize.xml"`

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

To preserve the functionality of existing applications or scripts that require the previous behavior of USMT, you can use the `/p` option, without specifying *"pathtoafile"*, 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.

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**:*<DomainName>*\*<UserName>*
or
**/ui**:*<ComputerName>*\*<LocalUserName>* | **(User include)**

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 (`"`).
**Note**
If a user is specified for inclusion with the `/ui` option and also specified to be excluded with either the `/ue` or `/uel` options, the user will be included in the migration.

For example:
  • To include only **User2** from the Fabrikam domain, enter:

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

  • 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:

    `/uel:30 /ui:fabrikam\*`

    In this example, a user account from the Contoso domain that was last modified two months ago won't be migrated.

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

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.

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.
**Note**
The `/uel` option isn't valid in offline migrations.
  • `/uel:0` migrates any users who are currently logged on.
  • `/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.
  • `/uel:1` migrates users whose account has been modified within the last 24 hours.
  • `/uel:2020/2/15` migrates users who have logged on or been modified February 15, 2020 or afterwards.

For example:
`scanstate.exe /i:migapp.xml /i:migdocs.xml \\server\share\migration\mystore /uel:0` | -| **/ue**:*<DomainName>*\*<UserName>*
-or-

**/ue**:*<ComputerName>*\*<LocalUserName>* | **(User exclude)**

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

For example:
`scanstate.exe /i:migdocs.xml /i:migapp.xml \\server\share\migration\mystore /ue:contoso\user1` | +| **/uel**:*<NumberOfDays>*
or
**/uel**:*<YYYY/MM/DD>*
or
**/uel:0** | **(User exclude based on last logon)**

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.

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.
**Note**
The `/uel` option isn't valid in offline migrations.
  • `/uel:0` migrates any users who are currently logged on.
  • `/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.
  • `/uel:1` migrates users whose account has been modified within the last 24 hours.
  • `/uel:2020/2/15` migrates users who have logged on or been modified February 15, 2020 or afterwards.

For example:
`ScanState.exe /i:MigApp.xml /i:MigDocs.xml \\server\share\migration\mystore /uel:0` | +| **/ue**:*<DomainName>*\*<UserName>*
-or-

**/ue**:*<ComputerName>*\*<LocalUserName>* | **(User exclude)**

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

For example:
`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.

For example:
`scanstate.exe /i:migdocs.xml /i:migapp.xml \server\share\migration\mystore /efs:copyraw`
**Important**
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).
| +| **/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.

For example:
`ScanState.exe /i:MigDocs.xml /i:MigApp.xml \server\share\migration\mystore /efs:copyraw`
**Important**
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).
| ## Incompatible command-line options diff --git a/windows/deployment/usmt/usmt-technical-reference.md b/windows/deployment/usmt/usmt-technical-reference.md index 2504eabb75..09ed7e6290 100644 --- a/windows/deployment/usmt/usmt-technical-reference.md +++ b/windows/deployment/usmt/usmt-technical-reference.md @@ -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 diff --git a/windows/deployment/usmt/usmt-xml-elements-library.md b/windows/deployment/usmt/usmt-xml-elements-library.md index 240033409e..e686dbb4b4 100644 --- a/windows/deployment/usmt/usmt-xml-elements-library.md +++ b/windows/deployment/usmt/usmt-xml-elements-library.md @@ -27,15 +27,15 @@ The following table describes the XML elements and helper functions you can use ## <addObjects> -The <addObjects> element emulates the existence of one or more objects on the source computer. The child <object> elements provide the details of the emulated objects. If the content is a <script> element, the result of the invocation will be an array of objects. +The **<addObjects>** element emulates the existence of one or more objects on the source computer. The child **<object>** elements provide the details of the emulated objects. If the content is a <script> element, the result of the invocation will be an array of objects. - **Number of occurrences:** unlimited - **Parent elements:** [<rules>](#rules) -- **Required child elements:** [<object>](#object) In addition, you must specify [<location>](#location) and [<attribute>](#attributes) as child elements of this <object> element. +- **Required child elements:** [<object>](#object) In addition, you must specify [<location>](#location) and [<attribute>](#attributes) as child elements of this **<object>** element. -- **Optional child elements:** [<conditions>](#conditions), <condition>, [<script>](#script) +- **Optional child elements:** [<conditions>](#conditions), [<condition>](#condition), [<script>](#script) Syntax: @@ -44,7 +44,7 @@ Syntax: ``` -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -63,9 +63,9 @@ The following example is from the MigApp.xml file: ## <attributes> -The <attributes> element defines the attributes for a registry key or file. +The **<attributes>** element defines the attributes for a registry key or file. -- **Number of occurrences:** once for each <object> +- **Number of occurrences:** once for each [<object>](#object) - **Parent elements:** [<object>](#object) @@ -81,7 +81,7 @@ Syntax: |------|-----|----| | *Content* | Yes | The content depends on the type of object specified.
  • For files, the content can be a string containing any of the following attributes separated by commas:
    • Archive
    • Read-only
    • System
    • Hidden
  • For registry keys, the content can be one of the following types:
    • None
    • String
    • ExpandString
    • Binary
    • Dword
    • REG_SZ
| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -93,7 +93,7 @@ The following example is from the MigApp.xml file: ## <bytes> -You must specify the <bytes> element only for files because, if <location> corresponds to a registry key or a directory, then <bytes> will be ignored. +You must specify the **<bytes>** element only for files because, if **<location>** corresponds to a registry key or a directory, then **<bytes>** will be ignored. - **Number of occurrences:** zero or one @@ -110,10 +110,10 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | |string|No, default is No|Determines whether *Content* should be interpreted as a string or as bytes.| -|expand|No (default = Yes|When the expand parameter is Yes, the content of the <bytes> element is first expanded in the context of the source computer and then interpreted.| -|*Content*|Yes|Depends on the value of the string.
  • When the string is Yes: the content of the <bytes> element is interpreted as a string.
  • When the string is No: the content of the <bytes> element is interpreted as bytes. Each two characters represent the hexadecimal value of a byte. For example, "616263" is the representation for the "abc" ANSI string. A complete representation of the UNICODE string "abc" including the string terminator would be: "6100620063000000".
| +|expand|No (default = Yes|When the expand parameter is **Yes**, the content of the **<bytes>** element is first expanded in the context of the source computer and then interpreted.| +|*Content*|Yes|Depends on the value of the string.
  • When the string is **Yes**: the content of the **<bytes>** element is interpreted as a string.
  • When the string is **No**: the content of the **<bytes>** element is interpreted as bytes. Each two characters represent the hexadecimal value of a byte. For example, `616263` is the representation for the `abc` ANSI string. A complete representation of the UNICODE string `abc` including the string terminator would be: `6100620063000000`.
| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -125,13 +125,13 @@ The following example is from the MigApp.xml file: ## <commandLine> -You might want to use the <commandLine> element if you want to start or stop a service or application before or after you run the ScanState and LoadState tools. +You might want to use the **<commandLine>** element if you want to start or stop a service or application before or after you run the **ScanState** and **LoadState** tools. - **Number of occurrences:** unlimited - **Parent elements:** [<externalProcess>](#externalprocess) -- **Child elements:** none**** +- **Child elements:** none Syntax: @@ -145,9 +145,12 @@ Syntax: ## <component> -The <component> element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the MigApp.xml file, "Microsoft® Office 2003" is a component that contains another component, "Microsoft Office Access® 2003". You can use the child elements to define the component. +The **<component>** element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the `MigApp.xml` file, "Microsoft Office 2003" is a component that contains another component, "Microsoft Office Access 2003". You can use the child elements to define the component. -A component can be nested inside another component; that is, the <component> element can be a child of the <role> element within the <component> element in two cases: 1) when the parent <component> element is a container or 2) if the child <component> element has the same role as the parent <component> element. +A component can be nested inside another component; that is, the **<component>** element can be a child of the **<role>** element within the **<component>** element in two cases: + +1. When the parent **<component>** element is a container +2. If the child **<component>** element has the same role as the parent **<component>** element. - **Number of occurrences:** Unlimited @@ -167,26 +170,26 @@ hidden="Yes|No"> |Setting|Required?|Value| |--- |--- |--- | -| type | Yes | You can use the following to group settings, and define the type of the component.
  • **System:** Operating system settings. All Windows® components are defined by this type.
    When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that is specified on the LoadState command line. For example, the default MigSys.xml file contains components with type="System" and defaultSupported="FALSE". If you specify this file on the ScanState command line, you must also specify the file on the LoadState command line for the settings to migrate. This is because the LoadState tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name. Otherwise, the LoadState tool will not migrate those settings from the store. This is helpful when the source computer is running Windows XP, and you are migrating to both Windows Vista and Windows XP because you can use the same store for both destination computers.
  • **Application:** Settings for an application.
  • **Device:** Settings for a device.
  • **Documents:** Specifies files.
| -| context | No
Default = UserAndSystem | Defines the scope of this parameter; that is, whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the <component> element. For example, if a <component> element has a context of User and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it has a context of User. If a <rules> element has a context of System, it would act as though the <rules> element is not there.
  • **User**. Evaluates the component for each user.
  • **System**. Evaluates the component only once for the system.
  • **UserAndSystem**. Evaluates the component for the entire operating system and each user.
| -| defaultSupported | No
(default = TRUE) | Can be any of TRUE, FALSE, YES, or NO. If this parameter is FALSE (or NO), the component will not be migrated unless there is an equivalent component on the destination computer.
When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that are specified on the LoadState command line. For example, the default MigSys.xml file contains components with type="System" and defaultSupported="FALSE". If you specify this file on the ScanState command line, you must also specify the file on the LoadState command line for the settings to migrate. This is because the LoadState tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name or the LoadState tool will not migrate those settings from the store. This is helpful when the source computer is running Windows XP, and you are migrating to both Windows Vista and Windows XP because you can use the same store for both destination computers. | +| type | Yes | You can use the following to group settings, and define the type of the component.
  • **System:** Operating system settings. All Windows components are defined by this type.
    When **type="System"** and **defaultSupported="FALSE"** the settings will not migrate unless there is an equivalent component in the .xml files that is specified on the `LoadState.exe` command line. For example, the default `MigSys.xml` file contains components with **type="System"** and **defaultSupported="FALSE"**. If you specify this file on the `ScanState.exe` command line, you must also specify the file on the `LoadState.exe` command line for the settings to migrate. This is because the `LoadState.exe` tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name. Otherwise, the **LoadState** tool will not migrate those settings from the store. This is helpful because you can use the same store for destination computers that are the same version of Windows and a different version of Windows as the source computer.
  • **Application:** Settings for an application.
  • **Device:** Settings for a device.
  • **Documents:** Specifies files.
| +| context | No
Default = UserAndSystem | Defines the scope of this parameter; that is, whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the **<component>** element. For example, if a **<component>** element has a context of **User** and a **<rules>** element had a context of **UserAndSystem**, then the **<rules>** element would act as though it has a context of **User**. If a **<rules>** element has a context of **System**, it would act as though the **<rules>** element is not there.
  • **User**: Evaluates the component for each user.
  • **System**: Evaluates the component only once for the system.
  • **UserAndSystem**: Evaluates the component for the entire operating system and each user.
| +| defaultSupported | No
(default = TRUE) | Can be any of **TRUE**, **FALSE**, **YES**, or **NO**. If this parameter is **FALSE** (or **NO**), the component will not be migrated unless there is an equivalent component on the destination computer.
When **type="System"** and **defaultSupported="FALSE"** the settings will not migrate unless there is an equivalent component in the .xml files that are specified on the `LoadState.exe` command line. For example, the default `MigSys.xml` file contains components with **type="System"** and **defaultSupported="FALSE"**. If you specify this file on the `ScanState.exe` command line, you must also specify the file on the `LoadState.exe` command line for the settings to migrate. This is because the **LoadState** tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name or the **LoadState** tool will not migrate those settings from the store. This is helpful because you can use the same store for destination computers that are the same version of Windows and a different version of Windows as the source computer. | | hidden | | This parameter is for internal USMT use only. | For an example, see any of the default migration .xml files. ## <condition> -Although the <condition> element under the <detect>, <objectSet>, and <addObjects> elements is supported, we recommend that you do not use it. This element might be deprecated in future versions of USMT, requiring you to rewrite your scripts. We recommend that, if you need to use a condition within the <objectSet> and <addObjects> elements, you use the more powerful [<conditions>](#conditions) element, which allows you to formulate complex Boolean statements. +Although the **<condition>** element under the **<detect>**, **<objectSet>**, and **<addObjects>** elements is still supported, it is recommend to no longer use the **<condition>** element because it may be deprecated in future versions of USMT. If the **<condition>** element were depecated, it would require a rewrite of any scripts that use the **<condition>** element. Instead, if you need to use a condition within the **<objectSet>** and **<addObjects>** elements, it is recommended to use the more powerful **[<conditions>](#conditions)** element. The **<conditions>** element allows for formulation of complex Boolean statements. -The <condition> element has a Boolean result. You can use this element to specify the conditions in which the parent element will be evaluated. If any of the present conditions return FALSE, the parent element will not be evaluated. +The **<condition>** element has a Boolean result. You can use this element to specify the conditions in which the parent element will be evaluated. If any of the present conditions return **FALSE**, the parent element will not be evaluated. - **Number of occurrences:** unlimited. -- **Parent elements:** [<conditions>](#conditions), <detect>, <objectSet>, <addObjects> +- **Parent elements:** [<conditions>](#conditions), [<detect>](#detect), [<objectSet>](#objectset), [<addObjects>](#addobjects) - **Child elements:** none -- **Helper functions:** You can use the following [<condition> functions](#condition-functions) with this element: DoesOSMatch, IsNative64Bit(), IsOSLaterThan, IsOSEarlierThan, DoesObjectExist, DoesFileVersionMatch, IsFileVersionAbove, IsFileVersionBelow, IsSystemContext, DoesStringContentEqual, DoesStringContentContain, IsSameObject, IsSameContent, and IsSameStringContent. +- **Helper functions:** You can use the following [<condition> functions](#condition-functions) with this element: `DoesOSMatch`, `IsNative64Bit()`, `IsOSLaterThan`, `IsOSEarlierThan`, `DoesObjectExist`, `DoesFileVersionMatch`, `IsFileVersionAbove`, `IsFileVersionBelow`, `IsSystemContext`, `DoesStringContentEqual`, `DoesStringContentContain`, `IsSameObject`, `IsSameContent`, and `IsSameStringContent`. Syntax: @@ -196,12 +199,12 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|negation|No
Default = No|"Yes" reverses the True/False value of the condition.| +|negation|No
Default = No|**"Yes"** reverses the True/False value of the condition.| |*ScriptName*|Yes|A script that has been defined within this migration section.| For example, -In the code sample below, the <condition> elements, A and B, are joined together by the AND operator because they are in separate <conditions> sections. For example: +In the code sample below, the **<condition>** elements, A and B, are joined together by the **AND** operator because they are in separate **<conditions>** sections. For example: ```xml @@ -214,7 +217,7 @@ In the code sample below, the <condition> elements, A and B, are joined to ``` -However, in the code sample below, the <condition> elements, A and B, are joined together by the OR operator because they are in the same <conditions> section. +However, in the code sample below, the **<condition>** elements, **A** and **B**, are joined together by the **OR** operator because they are in the same **<conditions>** section. ```xml @@ -227,7 +230,7 @@ However, in the code sample below, the <condition> elements, A and B, are ### <condition> functions -The <condition> functions return a Boolean value. You can use these elements in <addObjects> conditions. +The **<condition>** functions return a Boolean value. You can use these elements in **<addObjects>** conditions. - [Operating system version functions](#operating-system-version-functions) @@ -243,7 +246,7 @@ The <condition> functions return a Boolean value. You can use these elemen |Setting|Required?|Value| |--- |--- |--- | - |*OSType*|Yes|The only valid value for this setting is **NT**. Note, however, that you must set this setting for the <condition> functions to work correctly.| + |*OSType*|Yes|The only valid value for this setting is **NT**. Note, however, that you must set this setting for the **<condition>** functions to work correctly.| |*OSVersion*|Yes|The major version, minor version, build number and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version with a pattern. For example, `5.0.*`.| For example: @@ -254,7 +257,7 @@ The <condition> functions return a Boolean value. You can use these elemen - **IsNative64Bit** - The IsNative64Bit function returns TRUE if the migration process is running as a native 64-bit process; that is, a process running on a 64-bit system without Windows on Windows (WOW). Otherwise, it returns FALSE. + The **IsNative64Bit** function returns **TRUE** if the migration process is running as a native 64-bit process; that is, a process running on a 64-bit system without Windows on Windows (WOW). Otherwise, it returns **FALSE**. - **IsOSLaterThan** @@ -264,8 +267,8 @@ The <condition> functions return a Boolean value. You can use these elemen |Setting|Required?|Value| |--- |--- |--- | - |*OSType*|Yes|Can be **9x** or **NT**. If *OSType* does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and *OSType* is "9x", the result will be FALSE.| - |*OSVersion*|Yes|The major version, minor version, build number, and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version but no pattern is allowed. For example, `5.0`.

The IsOSLaterThan function returns TRUE if the current operating system is later than or equal to *OSVersion*.| + |*OSType*|Yes|Can be **9x** or **NT**. If *OSType* does not match the type of the current operating system, then it returns **FALSE**. For example, if the current operating system is Windows NT-based and *OSType* is **"9x"**, the result will be **FALSE**.| + |*OSVersion*|Yes|The major version, minor version, build number, and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version but no pattern is allowed. For example, `5.0`.

The **IsOSLaterThan** function returns **TRUE** if the current operating system is later than or equal to *OSVersion*.| For example: @@ -281,23 +284,23 @@ The <condition> functions return a Boolean value. You can use these elemen |Setting|Required?|Value| |--- |--- |--- | - |*OSType*|Yes|Can be **9x** or **NT**. If *OSType* does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and *OSType* is "9x" the result will be FALSE.| - |*OSVersion*|Yes|The major version, minor version, build number, and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version but no pattern is allowed. For example, `5.0`.

The IsOSEarlierThan function returns TRUE if the current operating system is earlier than *OSVersion*.| + |*OSType*|Yes|Can be **9x** or **NT**. If *OSType* does not match the type of the current operating system, then it returns **FALSE**. For example, if the current operating system is Windows NT-based and *OSType* is **"9x"** the result will be **FALSE**.| + |*OSVersion*|Yes|The major version, minor version, build number, and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version but no pattern is allowed. For example, `5.0`.

The **IsOSEarlierThan** function returns **TRUE** if the current operating system is earlier than *OSVersion*.| ### Object content functions - **DoesObjectExist** - The DoesObjectExist function returns TRUE if any object exists that matches the location pattern. Otherwise, it returns FALSE. The location pattern is expanded before attempting the enumeration. + The DoesObjectExist function returns **TRUE** if any object exists that matches the location pattern. Otherwise, it returns **FALSE**. The location pattern is expanded before attempting the enumeration. Syntax: `DoesObjectExist("ObjectType","EncodedLocationPattern")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType*|Yes|Defines the object type. Can be File or Registry.| - |*EncodedLocationPattern*|Yes|The [location pattern](#specifying-locations). Environment variables are allowed.| + |*EncodedLocationPattern*|Yes|The **[location pattern](#specifying-locations)**. Environment variables are allowed.| - For an example of this element, see the MigApp.xml file. + For an example of this element, see the `MigApp.xml` file. - **DoesFileVersionMatch** @@ -307,8 +310,8 @@ The <condition> functions return a Boolean value. You can use these elemen |Setting|Required?|Value| |--- |--- |--- | - |*EncodedFileLocation*|Yes|The [location pattern](#specifying-locations) for the file that will be checked. Environment variables are allowed.| - |*VersionTag*|Yes|The [version tag](#valid-version-tags) value that will be checked.| + |*EncodedFileLocation*|Yes|The **[location pattern](#specifying-locations)** for the file that will be checked. Environment variables are allowed.| + |*VersionTag*|Yes|The **[version tag](#valid-version-tags)** value that will be checked.| |*VersionValue*|Yes|A string pattern. For example, "Microsoft*".| For example: @@ -319,14 +322,14 @@ The <condition> functions return a Boolean value. You can use these elemen - **IsFileVersionAbove** - The IsFileVersionAbove function returns TRUE if the version of the file is higher than *VersionValue*. + The **IsFileVersionAbove** function returns **TRUE** if the version of the file is higher than *VersionValue*. Syntax: `IsFileVersionAbove("EncodedFileLocation","VersionTag","VersionValue")` |Setting|Required?|Value| |--- |--- |--- | - |*EncodedFileLocation*|Yes|The [location pattern](#specifying-locations) for the file that will be checked. Environment variables are allowed.| - |*VersionTag*|Yes|The [version tag](#valid-version-tags) value that will be checked.| + |*EncodedFileLocation*|Yes|The **[location pattern](#specifying-locations)** for the file that will be checked. Environment variables are allowed.| + |*VersionTag*|Yes|The **[version tag](#valid-version-tags)** value that will be checked.| |*VersionValue*|Yes|The value to compare to. You cannot specify a pattern.| - **IsFileVersionBelow** @@ -335,26 +338,26 @@ The <condition> functions return a Boolean value. You can use these elemen |Setting|Required?|Value| |--- |--- |--- | - |*EncodedFileLocation*|Yes|The [location pattern](#specifying-locations) for the file that will be checked. Environment variables are allowed.| - |*VersionTag*|Yes|The [version tag](#valid-version-tags) value that will be checked.| + |*EncodedFileLocation*|Yes|The **[location pattern](#specifying-locations)** for the file that will be checked. Environment variables are allowed.| + |*VersionTag*|Yes|The **[version tag](#valid-version-tags)** value that will be checked.| |*VersionValue*|Yes|The value to compare to. You cannot specify a pattern.| - **IsSystemContext** - The IsSystemContext function returns TRUE if the current context is "System". Otherwise, it returns FALSE. + The **IsSystemContext** function returns **TRUE** if the current context is **"System"**. Otherwise, it returns **FALSE**. Syntax: `IsSystemContext()` - **DoesStringContentEqual** - The DoesStringContentEqual function returns TRUE if the string representation of the given object is identical to `StringContent`. + The **DoesStringContentEqual** function returns **TRUE** if the string representation of the given object is identical to `StringContent`. Syntax: `DoesStringContentEqual("ObjectType","EncodedLocation","StringContent")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType*|Yes|Defines the type of object. Can be File or Registry.| - |*EncodedLocationPattern*|Yes|The [encoded location](#specifying-locations) for the object that will be examined. You can specify environment variables.| + |*EncodedLocationPattern*|Yes|The **[encoded location](#specifying-locations)** for the object that will be examined. You can specify environment variables.| |StringContent|Yes|The string that will be checked against.| For example: @@ -365,27 +368,27 @@ The <condition> functions return a Boolean value. You can use these elemen - **DoesStringContentContain** - The DoesStringContentContain function returns TRUE if there is at least one occurrence of *StrToFind* in the string representation of the object. + The **DoesStringContentContain** function returns **TRUE** if there is at least one occurrence of *StrToFind* in the string representation of the object. Syntax: `DoesStringContentContain("ObjectType","EncodedLocation","StrToFind")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType*|Yes|Defines the type of object. Can be File or Registry.| - |*EncodedLocationPattern*|Yes|The [encoded location](#specifying-locations) for the object that will be examined. You can specify environment variables.| + |*EncodedLocationPattern*|Yes|The **[encoded location](#specifying-locations)** for the object that will be examined. You can specify environment variables.| |*StrToFind*|Yes|A string that will be searched inside the content of the given object.| - **IsSameObject** - The IsSameObject function returns TRUE if the given encoded locations resolve to the same physical object. Otherwise, it returns FALSE. + The **IsSameObject** function returns **TRUE** if the given encoded locations resolve to the same physical object. Otherwise, it returns **FALSE**. Syntax: `IsSameObject("ObjectType","EncodedLocation1","EncodedLocation2")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType*|Yes|Defines the type of object. Can be File or Registry.| - |*EncodedLocation1*|Yes|The [encoded location](#specifying-locations) for the first object. You can specify environment variables.| - |*EncodedLocation2*|Yes|The [encoded location](#specifying-locations) for the second object. You can specify environment variables.| + |*EncodedLocation1*|Yes|The **[encoded location](#specifying-locations)** for the first object. You can specify environment variables.| + |*EncodedLocation2*|Yes|The **[encoded location](#specifying-locations)** for the second object. You can specify environment variables.| For example: @@ -398,35 +401,35 @@ The <condition> functions return a Boolean value. You can use these elemen - **IsSameContent** - The IsSameContent function returns TRUE if the given objects have the same content. Otherwise, it returns FALSE. The content will be compared byte by byte. + The **IsSameContent** function returns **TRUE** if the given objects have the same content. Otherwise, it returns **FALSE**. The content will be compared byte by byte. Syntax: `IsSameContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType1*|Yes|Defines the type of the first object. Can be File or Registry.| - |*EncodedLocation1*|Yes|The [encoded location](#specifying-locations) for the first object. You can specify environment variables.| + |*EncodedLocation1*|Yes|The **[encoded location](#specifying-locations)** for the first object. You can specify environment variables.| |*ObjectType2*|Yes|Defines the type of the second object. Can be File or Registry.| - |*EncodedLocation2*|Yes|The [encoded location](#specifying-locations) for the second object. You can specify environment variables.| + |*EncodedLocation2*|Yes|The **[encoded location](#specifying-locations)** for the second object. You can specify environment variables.| - **IsSameStringContent** - The IsSameStringContent function returns TRUE if the given objects have the same content. Otherwise, it returns FALSE. The content will be interpreted as a string. + The **IsSameStringContent** function returns **TRUE** if the given objects have the same content. Otherwise, it returns **FALSE**. The content will be interpreted as a string. Syntax: `IsSameStringContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")` |Setting|Required?|Value| |--- |--- |--- | |*ObjectType1*|Yes|Defines the type of the first object. Can be File or Registry.| - |*EncodedLocation1*|Yes|The [encoded location](#specifying-locations) for the first object. You can specify environment variables.| + |*EncodedLocation1*|Yes|The **[encoded location](#specifying-locations)** for the first object. You can specify environment variables.| |*ObjectType2*|Yes|Defines the type of the second object. Can be File or Registry.| - |*EncodedLocation2*|Yes|The [encoded location](#specifying-locations) for the second object. You can specify environment variables.| + |*EncodedLocation2*|Yes|The **[encoded location](#specifying-locations)** for the second object. You can specify environment variables.| ## <conditions> -The <conditions> element returns a Boolean result that is used to specify the conditions in which the parent element is evaluated. USMT evaluates the child elements, and then joins their results using the operators AND or OR according to the **operation** parameter. +The **<conditions>** element returns a Boolean result that is used to specify the conditions in which the parent element is evaluated. USMT evaluates the child elements, and then joins their results using the operators **AND** or **OR** according to the operation parameter. -- **Number of occurrences:** Unlimited inside another <conditions> element. Limited to one occurrence in [<detection>](#detection), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset) +- **Number of occurrences:** Unlimited inside another **<conditions>** element. Limited to one occurrence in [<detection>](#detection), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset) - **Parent elements:** [<conditions>](#conditions), [<detection>](#detection), [<environment>](#environment), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset) @@ -443,7 +446,7 @@ Syntax: |--- |--- |--- | |operation|No, default = AND|Defines the Boolean operation that is performed on the results that are obtained from the child elements.| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -458,7 +461,7 @@ The following example is from the MigApp.xml file: ## <content> -You can use the <content> element to specify a list of object patterns to obtain an object set from the source computer. Each <objectSet> within a <content> element is evaluated. For each resulting object pattern list, the objects that match it are enumerated and their content is filtered by the filter parameter. The resulting string array is the output for the <content> element. The filter script returns an array of locations. The parent <objectSet> element can contain multiple child <content> elements. +You can use the **<content>** element to specify a list of object patterns to obtain an object set from the source computer. Each **<objectSet>** within a **<content>** element is evaluated. For each resulting object pattern list, the objects that match it are enumerated and their content is filtered by the filter parameter. The resulting string array is the output for the **<content>** element. The filter script returns an array of locations. The parent **<objectSet>** element can contain multiple child **<content>** elements. - **Number of occurrences:** unlimited @@ -466,7 +469,7 @@ You can use the <content> element to specify a list of object patterns to - **Child elements:** [<objectSet>](#objectset) -- **Helper functions:** You can use the following [<content> functions](#content-functions) with this element: ExtractSingleFile, ExtractMultipleFiles, and ExtractDirectory. +- **Helper functions:** You can use the following [<content> functions](#content-functions) with this element: `ExtractSingleFile`, `ExtractMultipleFiles`, and `ExtractDirectory`. Syntax: @@ -477,22 +480,22 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|filter|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script is called for each object that is enumerated by the object sets in the <include> rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|filter|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script is called for each object that is enumerated by the object sets in the **<include>** rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| ### <content> functions -The following functions generate patterns out of the content of an object. These functions are called for every object that the parent <ObjectSet> element is enumerating. +The following functions generate patterns out of the content of an object. These functions are called for every object that the parent **<ObjectSet>** element is enumerating. - **ExtractSingleFile** - If the registry value is a MULTI-SZ, only the first segment is processed. The returned pattern is the encoded location for a file that must exist on the system. If the specification is correct in the registry value, but the file does not exist, this function returns NULL. + If the registry value is a **MULTI-SZ**, only the first segment is processed. The returned pattern is the encoded location for a file that must exist on the system. If the specification is correct in the registry value, but the file does not exist, this function returns **NULL**. Syntax: `ExtractSingleFile(Separators,PathHints)` |Setting|Required?|Value| |--- |--- |--- | - |*Separators*|Yes|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. You can specify NULL.| - |*PathHints*|Yes|A list of extra paths, separated by colons (;), where the function will look for a file matching the current content. For example, if the content is "Notepad.exe" and the path is the %Path% environment variable, the function will find Notepad.exe in %windir% and returns "c:\Windows [Notepad.exe]". You can specify NULL.| + |*Separators*|Yes|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is **"C:\Windows\Notepad.exe,-2"**, the separator is a comma. You can specify **NULL**.| + |*PathHints*|Yes|A list of extra paths, separated by colons (`;`), where the function will look for a file matching the current content. For example, if the content is **"Notepad.exe"** and the path is the **%Path%** environment variable, the function will find **Notepad.exe** in `%windir%` and returns **"c:\Windows [Notepad.exe]"**. You can specify **NULL**.| For example: @@ -508,7 +511,7 @@ The following functions generate patterns out of the content of an object. These - **ExtractMultipleFiles** - The ExtractMultipleFiles function returns multiple patterns, one for each file that is found in the content of the given registry value. If the registry value is a MULTI-SZ, the MULTI-SZ separator is considered a separator by default. therefore, for MULTI-SZ, the <Separators> argument must be NULL. + The **ExtractMultipleFiles** function returns multiple patterns, one for each file that is found in the content of the given registry value. If the registry value is a **MULTI-SZ**, the **MULTI-SZ** separator is considered a separator by default. therefore, for **MULTI-SZ**, the **<Separators>** argument must be **NULL**. The returned patterns are the encoded locations for files that must exist on the source computer. If the specification is correct in the registry value but the file does not exist, it will not be included in the resulting list. @@ -516,18 +519,18 @@ The following functions generate patterns out of the content of an object. These |Setting|Required?|Value| |--- |--- |--- | - |*Separators*|Yes|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. This parameter must be NULL when processing MULTI-SZ registry values.| - |*PathHints*|Yes|A list of extra paths, separated by colons (;), where the function will look for a file matching the current content. For example, if the content is "Notepad.exe" and the path is the %Path% environment variable, the function will find Notepad.exe in %windir% and returns "c:\Windows [Notepad.exe]". You can specify NULL.| + |*Separators*|Yes|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is **"C:\Windows\Notepad.exe,-2"**, the separator is a comma. This parameter must be NULL when processing **MULTI-SZ** registry values.| + |*PathHints*|Yes|A list of extra paths, separated by colons (`;`), where the function will look for a file matching the current content. For example, if the content is **"Notepad.exe"** and the path is the **%Path%** environment variable, the function will find **Notepad.exe** in `%windir%` and returns **"c:\Windows [Notepad.exe]"**. You can specify **NULL**.| - **ExtractDirectory** - The ExtractDirectory function returns a pattern that is the encoded location for a directory that must exist on the source computer. If the specification is correct in the registry value, but the directory does not exist, this function returns NULL. If it is processing a registry value that is a MULTI-SZ, only the first segment will be processed. + The **ExtractDirectory** function returns a pattern that is the encoded location for a directory that must exist on the source computer. If the specification is correct in the registry value, but the directory does not exist, this function returns **NULL**. If it is processing a registry value that is a **MULTI-SZ**, only the first segment will be processed. Syntax: `ExtractDirectory(Separators,LevelsToTrim,PatternSuffix)` |Setting|Required?|Value| |--- |--- |--- | - |*Separators*|No|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. You must specify NULL when processing MULTI-SZ registry values.| + |*Separators*|No|A list of possible separators that might follow the file specification in this registry value name. For example, if the content is **"C:\Windows\Notepad.exe,-2"**, the separator is a comma. You must specify **NULL** when processing **MULTI-SZ** registry values.| |*LevelsToTrim*|Yes|The number of levels to delete from the end of the directory specification. Use this function to extract a root directory when you have a registry value that points inside that root directory in a known location.| |*PatternSuffix*|Yes|The pattern to add to the directory specification. For example, `* [*]`.| @@ -545,7 +548,7 @@ The following functions generate patterns out of the content of an object. These ## <contentModify> -The <contentModify> element modifies the content of an object before it is written to the destination computer. For each <contentModify> element there can be multiple <objectSet> elements. This element returns the new content of the object that is being processed. +The **<contentModify>** element modifies the content of an object before it is written to the destination computer. For each **<contentModify>** element there can be multiple **<objectSet>** elements. This element returns the new content of the object that is being processed. - **Number of occurrences:** Unlimited @@ -553,7 +556,7 @@ The <contentModify> element modifies the content of an object before it is - **Required child elements:** [<objectSet>](#objectset) -- **Helper functions**: You can use the following [<contentModify> functions](#contentmodify-functions) with this element: ConvertToDWORD, ConvertToString, ConvertToBinary, KeepExisting, OffsetValue, SetValueByTable, MergeMultiSzContent, and MergeDelimitedContent. +- **Helper functions**: You can use the following [<contentModify> functions](#contentmodify-functions) with this element: **ConvertToDWORD**, **ConvertToString**, **ConvertToBinary**, **KeepExisting**, **OffsetValue**, **SetValueByTable**, **MergeMultiSzContent**, and **MergeDelimitedContent**. Syntax: @@ -564,31 +567,31 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2").`

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2").`

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| ### <contentModify> functions -The following functions change the content of objects as they are migrated. These functions are called for every object that the parent <ObjectSet> element is enumerating. +The following functions change the content of objects as they are migrated. These functions are called for every object that the parent **<ObjectSet>** element is enumerating. - **ConvertToDWORD** - The ConvertToDWORD function converts the content of registry values that are enumerated by the parent <ObjectSet> element to a DWORD. For example, ConvertToDWORD will convert the string "1" to the DWORD 0x00000001. If the conversion fails, then the value of DefaultValueOnError will be applied. + The **ConvertToDWORD** function converts the content of registry values that are enumerated by the parent **<ObjectSet>** element to a DWORD. For example, **ConvertToDWORD** will convert the string `"1"` to the DWORD `0x00000001`. If the conversion fails, then the value of **DefaultValueOnError** will be applied. Syntax: `ConvertToDWORD(DefaultValueOnError)` |Setting|Required?|Value| |--- |--- |--- | - |*DefaultValueOnError*|No|The value that will be written into the value name if the conversion fails. You can specify NULL, and 0 will be written if the conversion fails.| + |*DefaultValueOnError*|No|The value that will be written into the value name if the conversion fails. You can specify **NULL**, and `0` will be written if the conversion fails.| - **ConvertToString** - The ConvertToString function converts the content of registry values that match the parent <ObjectSet> element to a string. For example, it will convert the DWORD 0x00000001 to the string "1". If the conversion fails, then the value of DefaultValueOnError will be applied. + The **ConvertToString** function converts the content of registry values that match the parent **<ObjectSet>** element to a string. For example, it will convert the DWORD `0x00000001` to the string **"1"**. If the conversion fails, then the value of **DefaultValueOnError** will be applied. Syntax: `ConvertToString(DefaultValueOnError)` |Setting|Required?|Value| |--- |--- |--- | - |*DefaultValueOnError*|No|The value that will be written into the value name if the conversion fails. You can specify NULL, and 0 will be written if the conversion fails.| + |*DefaultValueOnError*|No|The value that will be written into the value name if the conversion fails. You can specify **NULL**, and `0` will be written if the conversion fails.| For example: @@ -602,13 +605,13 @@ The following functions change the content of objects as they are migrated. Thes - **ConvertToBinary** - The ConvertToBinary function converts the content of registry values that match the parent <ObjectSet> element to a binary type. + The **ConvertToBinary** function converts the content of registry values that match the parent **<ObjectSet>** element to a binary type. Syntax: `ConvertToBinary ()` - **OffsetValue** - The OffsetValue function adds or subtracts *Value* from the value of the migrated object, and then writes the result back into the registry value on the destination computer. For example, if the migrated object is a DWORD with a value of 14, and the *Value* is "-2", the registry value will be 12 on the destination computer. + The **OffsetValue** function adds or subtracts *Value* from the value of the migrated object, and then writes the result back into the registry value on the destination computer. For example, if the migrated object is a DWORD with a value of `14`, and the *Value* is **"-2"**, the registry value will be `12` on the destination computer. Syntax: `OffsetValue(Value)` @@ -618,7 +621,7 @@ The following functions change the content of objects as they are migrated. Thes - **SetValueByTable** - The SetValueByTable function matches the value from the source computer to the source table. If the value is there, the equivalent value in the destination table will be applied. If the value is not there, or if the destination table has no equivalent value, the *DefaultValueOnError* will be applied. + The **SetValueByTable** function matches the value from the source computer to the source table. If the value is there, the equivalent value in the destination table will be applied. If the value is not there, or if the destination table has no equivalent value, the *DefaultValueOnError* will be applied. Syntax: `SetValueByTable(SourceTable,DestinationTable,DefaultValueOnError)` @@ -626,21 +629,21 @@ The following functions change the content of objects as they are migrated. Thes |--- |--- |--- | |*SourceTable*|Yes|A list of values separated by commas that are possible for the source registry values.| |*DestinationTable*|No|A list of translated values separated by commas.| - |*DefaultValueOnError*|No|The value that will be applied to the destination computer if either 1) the value for the source computer does not match *SourceTable*, or 2) *DestinationTable* has no equivalent value.

If DefaultValueOnError is NULL, the value will not be changed on the destination computer.| + |*DefaultValueOnError*|No|The value that will be applied to the destination computer if either
  1. The value for the source computer does not match *SourceTable*
  2. *DestinationTable* has no equivalent value.

If **DefaultValueOnError** is **NULL**, the value will not be changed on the destination computer.| - **KeepExisting** - You can use the KeepExisting function when there are conflicts on the destination computer. This function will keep (not overwrite) the specified attributes for the object that is on the destination computer. + You can use the **KeepExisting** function when there are conflicts on the destination computer. This function will keep (not overwrite) the specified attributes for the object that is on the destination computer. Syntax: `KeepExisting("OptionString","OptionString","OptionString",…)` |Setting|Required?|Value| |--- |--- |--- | - | *OptionString* | Yes | *OptionString* can be **Security**, **TimeFields**, or **FileAttrib**:*Letter*. You can specify one of each type of *OptionStrings*. Do not specify multiple *OptionStrings* with the same value. If you do, the right-most option of that type will be kept. For example, do not specify **("FileAttrib:H", "FileAttrib:R")** because only Read-only will be evaluated. Instead specify **("FileAttrib:HR")** and both Hidden and Read-only attributes will be kept on the destination computer.
  • **Security**. Keeps the destination object's security descriptor if it exists.
  • **TimeFields**. Keeps the destination object's time stamps. This parameter is for files only.
  • **FileAttrib:** *Letter*. Keeps the destination object's attribute value, either On or OFF, for the specified set of file attributes. This parameter is for files only. The following are case-insensitive, but USMT will ignore any values that are invalid, repeated, or if there is a space after "FileAttrib:". You can specify any combination of the following attributes:
    • **A** = Archive
    • **C** = Compressed
    • **E** = Encrypted
    • **H** = Hidden
    • **I** = Not Content Indexed
    • **O** = Offline
    • **R** = Read-Only
    • **S** = System
    • **T** = Temporary
| + | *OptionString* | Yes | *OptionString* can be **Security**, **TimeFields**, or **FileAttrib**:*Letter*. You can specify one of each type of *OptionStrings*. Do not specify multiple *OptionStrings* with the same value. If you do, the right-most option of that type will be kept. For example, do not specify **("FileAttrib:H", "FileAttrib:R")** because only Read-only will be evaluated. Instead specify **("FileAttrib:HR")** and both Hidden and Read-only attributes will be kept on the destination computer.
  • **Security**: Keeps the destination object's security descriptor if it exists.
  • **TimeFields**: Keeps the destination object's time stamps. This parameter is for files only.
  • **FileAttrib:<Letter>**: Keeps the destination object's attribute value, either **ON** or **OFF**, for the specified set of file attributes. This parameter is for files only. The following are case-insensitive, but USMT will ignore any values that are invalid, repeated, or if there is a space after **FileAttrib:**. You can specify any combination of the following attributes:
    • **A** = Archive
    • **C** = Compressed
    • **E** = Encrypted
    • **H** = Hidden
    • **I** = Not Content Indexed
    • **O** = Offline
    • **R** = Read-Only
    • **S** = System
    • **T** = Temporary
| - **MergeMultiSzContent** - The MergeMultiSzContent function merges the MULTI-SZ content of the registry values that are enumerated by the parent <ObjectSet> element with the content of the equivalent registry values that already exist on the destination computer. `Instruction` and `String` either remove or add content to the resulting MULTI-SZ. Duplicate elements will be removed. + The **MergeMultiSzContent** function merges the **MULTI-SZ** content of the registry values that are enumerated by the parent **<ObjectSet>** element with the content of the equivalent registry values that already exist on the destination computer. `Instruction` and `String` either remove or add content to the resulting **MULTI-SZ**. Duplicate elements will be removed. Syntax: `MergeMultiSzContent (Instruction,String,Instruction,String,…)` @@ -651,19 +654,19 @@ The following functions change the content of objects as they are migrated. Thes - **MergeDelimitedContent** - The MergeDelimitedContent function merges the content of the registry values that are enumerated by the parent <ObjectSet> element with the content of the equivalent registry values that already exist on the destination computer. The content is considered a list of elements separated by one of the characters in the Delimiters parameter. Duplicate elements will be removed. + The **MergeDelimitedContent** function merges the content of the registry values that are enumerated by the parent **<ObjectSet>** element with the content of the equivalent registry values that already exist on the destination computer. The content is considered a list of elements separated by one of the characters in the Delimiters parameter. Duplicate elements will be removed. Syntax: `MergeDelimitedContent(Delimiters,Instruction,String,…)` |Setting|Required?|Value| |--- |--- |--- | - | *Delimiters* | Yes | A single character that will be used to separate the content of the object that is being processed. The content will be considered as a list of elements that is separated by the *Delimiters*.
For example, "." will separate the string based on a period. | - | *Instruction* | Yes | Can one of the following:
  • **Add.** Adds *String* to the resulting MULTI-SZ if it is not already there.
  • **Remove.** Removes *String* from the resulting MULTI-SZ.
| + | *Delimiters* | Yes | A single character that will be used to separate the content of the object that is being processed. The content will be considered as a list of elements that is separated by the *Delimiters*.
For example, `"."` will separate the string based on a period. | + | *Instruction* | Yes | Can be one of the following:
  • **Add**: Adds *String* to the resulting MULTI-SZ if it is not already there.
  • **Remove**: Removes *String* from the resulting MULTI-SZ.
| | *String* | Yes | The string to be added or removed. | ## <description> -The <description> element defines a description for the component but does not affect the migration. +The **<description>** element defines a description for the component but does not affect the migration. - **Number of occurrences:** zero or one @@ -689,12 +692,12 @@ The following code sample shows how the <description> element defines the ## <destinationCleanup> -The <destinationCleanup> element deletes objects, such as files and registry keys, from the destination computer before applying the objects from the source computer. This element is evaluated only when the LoadState tool is run on the destination computer. That is, this element is ignored by the ScanState tool. +The **<destinationCleanup>** element deletes objects, such as files and registry keys, from the destination computer before applying the objects from the source computer. This element is evaluated only when the **LoadState** tool is run on the destination computer. That is, this element is ignored by the **ScanState** tool. > [!IMPORTANT] > Use this option with extreme caution because it will delete objects from the destination computer. -For each <destinationCleanup> element there can be multiple <objectSet> elements. A common use for this element is if there is a missing registry key on the source computer and you want to ensure that a component is migrated. In this case, you can delete all of the component's registry keys before migrating the source registry keys. This will ensure that if there is a missing key on the source computer, it will also be missing on the destination computer. +For each **<destinationCleanup>** element there can be multiple **<objectSet>** elements. A common use for this element is if there is a missing registry key on the source computer and you want to ensure that a component is migrated. In this case, you can delete all of the component's registry keys before migrating the source registry keys. This will ensure that if there is a missing key on the source computer, it will also be missing on the destination computer. - **Number of occurrences:** Unlimited @@ -711,7 +714,7 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|filter|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|filter|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| For example: @@ -726,15 +729,15 @@ For example: ## <detect> -Although the <detect> element is still supported, we do not recommend using it because it may be deprecated in future versions of USMT. In that case, you would have to rewrite your scripts. Instead, we recommend that you use the [<detection>](#detection)**element.** +Although the **<detect>** element is still supported, it is recommend to no longer use the **<detect>** element because it may be deprecated in future versions of USMT. If the **<detect>** element were depecated, it would require a rewrite of any scripts that use the **<detect>** element. Instead, it is recommend to use the **[<detection>](#detection)** element. The **<detection>** element allows for more clearly formulated complex Boolean statements -You use the <detect> element to determine if the component is present on a system. If all child <detect> elements within a <detect> element resolve to TRUE, then the <detect> element resolves to TRUE. If any child <detect> elements resolve to FALSE, then their parent <detect> element resolves to FALSE. If there is no <detect> element section, then USMT will assume that the component is present. +The **<detect>** element can be used to determine if the component is present on a system. If all child **<detect>** elements within a **<detect>** element resolve to **TRUE**, then the **<detect>** element resolves to **TRUE**. If any child **<detect>** elements resolve to **FALSE**, then their parent **<detect>** element resolves to **FALSE**. If there is no **<detect>** element section, then USMT will assume that the component is present. -For each <detect> element there can be multiple child <condition> or <objectSet> elements, which will be logically joined by an OR operator. If at least one <condition> or <objectSet> element evaluates to TRUE, then the <detect> element evaluates to TRUE. +For each **<detect>** element there can be multiple child **<condition>** or **<objectSet>** elements, which will be logically joined by an **OR** operator. If at least one **<condition>** or **<objectSet>** element evaluates to **TRUE**, then the **<detect>** element evaluates to **TRUE**. - **Number of occurrences:** unlimited -- **Parent elements:** <detects>, [<namedElements>](#namedelements) +- **Parent elements:** [<detects>](#detects), [<namedElements>](#namedelements) - **Required child elements:** [<condition>](#condition) @@ -749,16 +752,16 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| name | Yes, when <detect> is a child to <namedElements>
No, when <detect> is a child to <detects> | When *ID* is specified, any child elements are not processed. Instead, any other <detect> elements with the same name that are declared within the <namedElements> element are processed. | -| context | No
(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the component element. For example, if a <component> element has a context of User, and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it had a context of User. If the <rules> element had a context of System, it would act as though the <rules> element were not there.
  • **User.** Evaluates the variables for each user.
  • **System.** Evaluates the variables only once for the system.
  • **UserAndSystem.** Evaluates the variables for the entire operating system and each user.
| +| name | Yes, when **<detect>** is a child to **<namedElements>**
No, when **<detect>** is a child to <detects> | When *ID* is specified, any child elements are not processed. Instead, any other **<detect>** elements with the same name that are declared within the **<namedElements>** element are processed. | +| context | No
(default = UserAndSystem) | Defines the scope of this parameter which are whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the component element. For example, if a **<component>** element has a context of **User**, and a **<rules>** element had a context of **UserAndSystem**, then the **<rules>** element would act as though it had a context of **User**. If the **<rules>** element had a context of **System**, it would act as though the **<rules>** element were not there.
  • **User**: Evaluates the variables for each user.
  • **System**: Evaluates the variables only once for the system.
  • **UserAndSystem**: Evaluates the variables for the entire operating system and each user.
| For examples, see the examples for [<detection>](#detection). ## <detects> -Although the <detects> element is still supported, we recommend that you do not use it because it may be deprecated in future versions of USMT, which would require you to rewrite your scripts. Instead, we recommend that you use the [<detection>](#detection) element if the parent element is <role> or <namedElements>, and we recommend that you use the <conditions> element if the parent element is <rules>. Using <detection> allows you to more clearly formulate complex Boolean statements. +Although the **<detects>** element is still supported, it is recommend to no longer use the **<detects>** element because it may be deprecated in future versions of USMT. If the **<detects>** element were deprecated, it would require a rewrite of any scripts that use the **<detects>** element. Instead, it is recommend to use the **[<detection>](#detection)** element if the parent element is **<role>** or **<namedElements>**, or use the **[<conditions>](#conditions)** element if the parent element is **<rules>**. The **<detection>** element allows for more clearly formulated complex Boolean statements and the **<conditions>** element allows for formulation of complex Boolean statements. -The <detects> element is a container for one or more <detect> elements. If all of the child <detect> elements within a <detects> element resolve to TRUE, then <detects> resolves to TRUE. If any of the child <detect> elements resolve to FALSE, then <detects> resolves to FALSE. If you do not want to write the <detects> elements within a component, then you can create the <detects> element under the <namedElements> element, and then refer to it. If there is no <detects> element section, then USMT will assume that the component is present. The results from each <detects> element are joined together by the OR operator to form the rule used to detect the parent element. +The **<detects>** element is a container for one or more **<detect>** elements. If all of the child **<detect>** elements within a **<detects>** element resolve to **TRUE**, then **<detects>** resolves to **TRUE**. If any of the child **<detect>** elements resolve to **FALSE**, then **<detects>** resolves to **FALSE**. If you do not want to write the **<detects>** elements within a component, then you can create the **<detects>** element under the **<namedElements>** element, and then refer to it. If there is no **<detects>** element section, then USMT will assume that the component is present. The results from each **<detects>** element are joined together by the **OR** operator to form the rule used to detect the parent element. Syntax: @@ -771,14 +774,14 @@ Syntax: - **Parent elements:** [<role>](#role), [<rules>](#rules), [<namedElements>](#namedelements) -- **Required child elements:** <detect> +- **Required child elements:** [<detect>](#detect) |Setting|Required?|Value| |--- |--- |--- | -| name | Yes, when <detects> is a child to <namedElements>
No, when <detects> is a child to <role> or <rules> | When *ID* is specified, no child <detect> elements are processed. Instead, any other <detects> elements with the same name that are declared within the <namedElements> element are processed. | -| context | No
(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the <component element>. For example, if a <component> element has a context of User and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it had a context of User. If the <rules> element had a context of System, it would act as though the <rules> element were not there.
  • **User.** Evaluates the variables for each user.
  • **System.** Evaluates the variables only once for the system.
  • **UserAndSystem.** Evaluates the variables for the entire operating system and each user.

The context parameter is ignored for <detects> elements that are inside <rules> elements. | +| name | Yes, when <detects> is a child to **<namedElements>**
No, when <detects> is a child to **<role>** or **<rules>** | When *ID* is specified, no child **<detect>** elements are processed. Instead, any other **<detects>** elements with the same name that are declared within the **<namedElements>** element are processed. | +| context | No
(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the **<component element>**. For example, if a **<component>** element has a context of **User** and a **<rules>** element had a context of **UserAndSystem**, then the **<rules>** element would act as though it had a context of **User**. If the **<rules>** element had a context of **System**, it would act as though the **<rules>** element were not there.
  • **User**: Evaluates the variables for each user.
  • **System**: Evaluates the variables only once for the system.
  • **UserAndSystem**: Evaluates the variables for the entire operating system and each user.

The context parameter is ignored for **<detects>** elements that are inside **<rules>** elements. | -The following example is from the MigApp.xml file. +The following example is from the `MigApp.xml` file. ```xml @@ -793,11 +796,11 @@ The following example is from the MigApp.xml file. ## <detection> -The <detection> element is a container for one <conditions> element. The result of the child <condition> elements, located underneath the <conditions> element, determines the result of this element. For example, if all of the child <conditions> elements within the <detection> element resolve to TRUE, then the <detection> element resolves to TRUE. If any of the child <conditions> elements resolve to FALSE, then the <detection> element resolves to FALSE. +The **<detection>** element is a container for one **<conditions>** element. The result of the child **<condition>** elements, located underneath the **<conditions>** element, determines the result of this element. For example, if all of the child **<conditions>** elements within the **<detection>** element resolve to **TRUE**, then the **<detection>** element resolves to **TRUE**. If any of the child **<conditions>** elements resolve to **FALSE**, then the **<detection>** element resolves to **FALSE**. -In addition, the results from each <detection> section within the <role> element are joined together by the OR operator to form the detection rule of the parent element. That is, if one of the <detection> sections resolves to TRUE, then the <role> element will be processed. Otherwise, the <role> element will not be processed. +In addition, the results from each **<detection>** section within the **<role>** element are joined together by the **OR** operator to form the detection rule of the parent element. That is, if one of the **<detection>** sections resolves to **TRUE**, then the **<role>** element will be processed. Otherwise, the **<role>** element will not be processed. -Use the <detection> element under the <namedElements> element if you do not want to write it within a component. Then include a matching <detection> section under the <role> element to control whether the component is migrated. If there is not a <detection> section for a component, then USMT will assume that the component is present. +Use the **<detection>** element under the **<namedElements>** element if you do not want to write it within a component. Then include a matching **<detection>** section under the **<role>** element to control whether the component is migrated. If there is not a **<detection>** section for a component, then USMT will assume that the component is present. - **Number of occurrences:** Unlimited. @@ -814,8 +817,8 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| name |
  • Yes, when <detection> is declared under <namedElements>
  • Optional, when declared under <role>
| If declared, the content of the <detection> element is ignored and the content of the <detection> element with the same name that is declared in the <namedElements> element will be evaluated. | -| context | No, default = UserAndSystem | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
  • **User.** Evaluates the component for each user.
  • **System.** Evaluates the component only once for the system.
  • **UserAndSystem.** Evaluates the component for the entire operating system and each user.
| +| name |
  • Yes, when **<detection>** is declared under **<namedElements>**
  • Optional, when declared under **<role>**
| If declared, the content of the **<detection>** element is ignored and the content of the **<detection>** element with the same name that is declared in the **<namedElements>** element will be evaluated. | +| context | No, default = UserAndSystem | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
  • **User**: Evaluates the component for each user.
  • **System**: Evaluates the component only once for the system.
  • **UserAndSystem**: Evaluates the component for the entire operating system and each user.
| For example: @@ -842,7 +845,7 @@ and ## <displayName> -The <displayName> element is a required field within each <component> element. +The **<displayName>** element is a required field within each **<component>** element. - **Number of occurrences:** once for each component @@ -869,7 +872,7 @@ For example: ## <environment> -The <environment> element is a container for <variable> elements in which you can define variables to use in your .xml file. All environment variables defined this way will be private. That is, they will be available only for their child components and the component in which they were defined. For two example scenarios, see [Examples](#examples). +The **<environment>** element is a container for **<variable>** elements in which you can define variables to use in your .xml file. All environment variables defined this way will be private. That is, they will be available only for their child components and the component in which they were defined. For two example scenarios, see [Examples](#examples). - **Number of occurrences:** unlimited @@ -877,7 +880,7 @@ The <environment> element is a container for <variable> elements in - **Required child elements:** [<variable>](#variable) -- **Optional child elements:** [conditions](#conditions) +- **Optional child elements:** [<conditions>](#conditions) Syntax: @@ -888,14 +891,14 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| name | Yes, when <environment> is a child of <namedElements>
No, when <environment> is a child of <role> or <component> | When declared as a child of the <role> or <component> elements, if *ID* is declared, USMT ignores the content of the <environment> element and the content of the <environment> element with the same name declared in the <namedElements> element is processed. | -| context | No
(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the <component> element. For example, if a <component> element has a context of User and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it had a context of User. If the <rules> element had a context of System, it would act as though <rules> were not there.
  • **User.** Evaluates the variables for each user.
  • **System.** Evaluates the variables only once for the system.
  • **UserAndSystem.** Evaluates the variables for the entire operating system and each user.
| +| name | Yes, when **<environment>** is a child of **<namedElements>**
No, when **<environment>** is a child of **<role>** or **<component>** | When declared as a child of the **<role>** or **<component>** elements, if *ID* is declared, USMT ignores the content of the **<environment>** element and the content of the **<environment>** element with the same name declared in the **<namedElements>** element is processed. | +| context | No
(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the **<component>** element. For example, if a **<component>** element has a context of **User** and a **<rules>** element had a context of **UserAndSystem**, then the **<rules>** element would act as though it had a context of **User**. If the **<rules>** element had a context of **System**, it would act as though **<rules>** were not there.
  • **User**: Evaluates the variables for each user.
  • **System**: Evaluates the variables only once for the system.
  • **UserAndSystem**: Evaluates the variables for the entire operating system and each user.
| ## Examples ### Example scenario 1 -In this scenario, you want to generate the location of objects at run time depending on the configuration of the destination computer. For example, you must do this if an application writes data in the directory where it is installed, and users can install the application anywhere on the computer. If the application writes a registry value hklm\\software\\companyname\\install \[path\] and then updates this value with the location where the application is installed, then the only way for you to migrate the required data correctly is to define an environment variable. For example: +In this scenario, you want to generate the location of objects at run time depending on the configuration of the destination computer. For example, you must do this if an application writes data in the directory where it is installed, and users can install the application anywhere on the computer. If the application writes a registry value `hklm\software\companyname\install [path\]` and then updates this value with the location where the application is installed, then the only way for you to migrate the required data correctly is to define an environment variable. For example: ```xml @@ -915,7 +918,7 @@ Then you can use an include rule as follows. You can use any of the [<script& ``` -Second, you can also filter registry values that contain data that you need. The following example extracts the first string (before the separator ",") in the value of the registry Hklm\\software\\companyname\\application\\ \[Path\]. +Second, you can also filter registry values that contain data that you need. The following example extracts the first string (before the separator "`,`") in the value of the registry `Hklm\software\companyname\application\ [Path\]`. ```xml @@ -933,7 +936,7 @@ Second, you can also filter registry values that contain data that you need. The ### Example scenario 2 -In this scenario, you want to migrate five files named File1.txt, File2.txt, and so on, from %SYSTEMDRIVE%\\data\\userdata\\dir1\\dir2\\. To do this you must have the following <include> rule in an .xml file: +In this scenario, you want to migrate five files named `File1.txt`, `File2.txt`, and so on, from `%SYSTEMDRIVE%\data\userdata\dir1\dir2\`. To do this you must have the following **<include>** rule in an .xml file: ```xml @@ -957,7 +960,7 @@ Instead of typing the path five times, you can create a variable for the locatio ``` -Then, you can specify the variable in an <include> rule as follows: +Then, you can specify the variable in an **<include>** rule as follows: ```xml @@ -973,7 +976,7 @@ Then, you can specify the variable in an <include> rule as follows: ## <exclude> -The <exclude> element determines what objects will not be migrated, unless there is a more specific <include> element that migrates an object. If there is an <include> and <exclude> element for the same object, the object will be included. For each <exclude> element there can be multiple child <objectSet> elements. +The **<exclude>** element determines what objects will not be migrated, unless there is a more specific **<include>** element that migrates an object. If there is an **<include>** and **<exclude>** element for the same object, the object will be included. For each **<exclude>** element there can be multiple child **<objectSet>** elements. - **Number of occurrences:** Unlimited @@ -981,7 +984,7 @@ The <exclude> element determines what objects will not be migrated, unless - **Child elements:** [<objectSet>](#objectset) -- **Helper functions:** You can use the following [<exclude> filter functions](#include-and-exclude-filter-functions) with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, NeverRestore, and SameRegContent. +- **Helper functions:** You can use the following [<exclude> filter functions](#include-and-exclude-filter-functions) with this element: `CompareStringContent`, `IgnoreIrrelevantLinks`, `AnswerNo`, `NeverRestore`, and `SameRegContent`. Syntax: @@ -992,7 +995,7 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|filter|No
(default = No)|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|filter|No
(default = No)|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| For example, from the MigUser.xml file: @@ -1008,7 +1011,7 @@ For example, from the MigUser.xml file: ## <excludeAttributes> -You can use the <excludeAttributes> element to determine which parameters associated with an object will not be migrated. If there are conflicts between the <includeAttributes> and <excludeAttributes> elements, the most specific pattern determines the patterns that will not be migrated. If an object does not have an <includeAttributes> or <excludeAttributes> element, then all of its parameters will be migrated. +You can use the **<excludeAttributes>** element to determine which parameters associated with an object will not be migrated. If there are conflicts between the **<includeAttributes>** and **<excludeAttributes>** elements, the most specific pattern determines the patterns that will not be migrated. If an object does not have an **<includeAttributes>** or **<excludeAttributes>** element, then all of its parameters will be migrated. - **Number of occurrences:** Unlimited @@ -1054,7 +1057,7 @@ Example: %SYSTEMDRIVE%\ [aa.txt] - + logoff @@ -1115,7 +1118,7 @@ Syntax: |--- |--- |--- | |*FilenameExtension*|Yes|A file name extension.| -For example, if you want to migrate all \*.doc files from the source computer, specifying the following code under the <component> element: +For example, if you want to migrate all \*.doc files from the source computer, specifying the following code under the **<component>** element: ```xml @@ -1123,7 +1126,7 @@ For example, if you want to migrate all \*.doc files from the source computer, s ``` -is the same as specifying the following code below the <rules> element: +is the same as specifying the following code below the **<rules>** element: ```xml @@ -1137,7 +1140,7 @@ For another example of how to use the <extension> element, see the example ## <externalProcess> -You can use the <externalProcess> element to run a command line during the migration process. For example, you may want to run a command after the LoadState process completes. +You can use the <externalProcess> element to run a command line during the migration process. For example, you may want to run a command after the **LoadState** process completes. - **Number of occurrences:** Unlimited @@ -1164,7 +1167,7 @@ This is an internal USMT element. Do not use this element. ## <include> -The <include> element determines what to migrate, unless there is a more specific [<exclude>](#exclude) rule. You can specify a script to be more specific to extend the definition of what you want to collect. For each <include> element there can be multiple <objectSet> elements. +The **<include>** element determines what to migrate, unless there is a more specific [<exclude>](#exclude) rule. You can specify a script to be more specific to extend the definition of what you want to collect. For each **<include>** element there can be multiple **<objectSet>** elements. - **Number of occurrences:** Unlimited @@ -1172,7 +1175,7 @@ The <include> element determines what to migrate, unless there is a more s - **Required child element:** [<objectSet>](#objectset) -- **Helper functions:** You can use the following [<include> filter functions](#include-and-exclude-filter-functions) with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, and NeverRestore. +- **Helper functions:** You can use the following [<include> filter functions](#include-and-exclude-filter-functions) with this element: `CompareStringContent`, `IgnoreIrrelevantLinks`, `AnswerNo`, and `NeverRestore`. Syntax: @@ -1183,7 +1186,7 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| filter | No.
If this parameter is not specified, then all patterns that are inside the child <ObjectSet> element will be processed. | A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script will be called for each object that is enumerated by the object sets in the <include> rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated. | +| filter | No.
If this parameter is not specified, then all patterns that are inside the child **<objectSet>** element will be processed. | A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script will be called for each object that is enumerated by the object sets in the **<include>** rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated. | The following example is from the MigUser.xml file: @@ -1215,13 +1218,13 @@ The following example is from the MigUser.xml file: ``` -### <include> and <exclude> filter functions +### <include> and **<exclude>** filter functions The following functions return a Boolean value. You can use them to migrate certain objects based on when certain conditions are met. - **AnswerNo** - This filter always returns FALSE. + This filter always returns **FALSE**. Syntax: `AnswerNo ()` @@ -1232,11 +1235,11 @@ The following functions return a Boolean value. You can use them to migrate cert |Setting|Required?|Value| |--- |--- |--- | | *StringContent* | Yes | The string to check against. | - | *CompareType* | Yes | A string. Use one of the following values:
  • **Equal** (case insensitive). The function returns TRUE if the string representation of the current object that is processed by the migration engine is identical to `StringContent`.
  • **NULL** **or any other value**. The function returns TRUE if the string representation of the current object that is processed by the migration engine does not match `StringContent`.
| + | *CompareType* | Yes | A string. Use one of the following values:
  • **Equal** (case insensitive). The function returns **TRUE** if the string representation of the current object that is processed by the migration engine is identical to `StringContent`.
  • **NULL** **or any other value**. The function returns **TRUE** if the string representation of the current object that is processed by the migration engine does not match `StringContent`.
| - **IgnoreIrrelevantLinks** - This filter screens out the .lnk files that point to an object that is not valid on the destination computer. Note that the screening takes place on the destination computer, so all .lnk files will be saved to the store during ScanState. Then they will be screened out when you run the LoadState tool. + This filter screens out the .lnk files that point to an object that is not valid on the destination computer. Note that the screening takes place on the destination computer, so all .lnk files will be saved to the store during **ScanState**. Then they will be screened out when you run the **LoadState** tool. Syntax: `IgnoreIrrelevantLinks ()` @@ -1252,7 +1255,7 @@ The following functions return a Boolean value. You can use them to migrate cert - **NeverRestore** - You can use this function to collect the specified objects from the source computer but then not migrate the objects to the destination computer. When run with the ScanState tool, this function evaluates to TRUE. When run with the LoadState tool, this function evaluates to FALSE. You may want to use this function when you want to check an object's value on the destination computer but do not intend to migrate the object to the destination. + You can use this function to collect the specified objects from the source computer but then not migrate the objects to the destination computer. When run with the **ScanState** tool, this function evaluates to **TRUE**. When run with the **LoadState** tool, this function evaluates to **FALSE**. You may want to use this function when you want to check an object's value on the destination computer but do not intend to migrate the object to the destination. Syntax: `NeverRestore()` @@ -1268,7 +1271,7 @@ The following functions return a Boolean value. You can use them to migrate cert ## <includeAttributes> -You can use the <includeAttributes> element to determine whether certain parameters associated with an object will be migrated along with the object itself. If there are conflicts between the <includeAttributes> and <excludeAttributes> elements, the most specific pattern will determine which parameters will be migrated. If an object does not have an <includeAttributes> or <excludeAttributes> element, then all of its parameters will be migrated. +You can use the **<includeAttributes>** element to determine whether certain parameters associated with an object will be migrated along with the object itself. If there are conflicts between the **<includeAttributes>** and **<excludeAttributes>** elements, the most specific pattern will determine which parameters will be migrated. If an object does not have an **<includeAttributes>** or **<excludeAttributes>** element, then all of its parameters will be migrated. - **Number of occurrences:** unlimited @@ -1285,9 +1288,9 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| attributes | Yes | Specifies the attributes to be included with a migrated object. You can specify one of the following, or both separated by quotes; for example, `"Security","TimeFields"`:
  • Security can be one of the following values:
    • **Owner.** The owner of the object (SID).
    • **Group.** The primary group for the object (SID).
    • **DACL** (discretionary access control list). An access control list that is controlled by the owner of an object and that specifies the access particular users or groups can have to the object.
    • **SACL** (system access control list). An ACL that controls the generation of audit messages for attempts to access a securable object. The ability to get or set an object's SACL is controlled by a privilege typically held only by system administrators.
  • TimeFields can be one of the following:
    • **CreationTime.** Specifies when the file or directory was created.
    • **LastAccessTime.** Specifies when the file is last read from, written to, or, in the case of executable files, run.
    • **LastWrittenTime.** Specifies when the file is last written to, truncated, or overwritten.
| +| attributes | Yes | Specifies the attributes to be included with a migrated object. You can specify one of the following, or both separated by quotes; for example, `"Security","TimeFields"`:
  • Security can be one of the following values:
    • **Owner**: The owner of the object (SID).
    • **Group**: The primary group for the object (SID).
    • **DACL** (discretionary access control list): An access control list that is controlled by the owner of an object and that specifies the access particular users or groups can have to the object.
    • **SACL** (system access control list): An ACL that controls the generation of audit messages for attempts to access a securable object. The ability to get or set an object's SACL is controlled by a privilege typically held only by system administrators.
  • TimeFields can be one of the following:
    • **CreationTime**: Specifies when the file or directory was created.
    • **LastAccessTime**: Specifies when the file is last read from, written to, or, in the case of executable files, run.
    • **LastWrittenTime**: Specifies when the file is last written to, truncated, or overwritten.
| -For an example of how to use the <includeAttributes> element, see the example for [<excludeAttributes>](#excludeattributes). +For an example of how to use the **<includeAttributes>** element, see the example for [<excludeAttributes>](#excludeattributes). ## <library> @@ -1295,9 +1298,9 @@ This is an internal USMT element. Do not use this element. ## <location> -The <location> element defines the location of the <object> element. +The **<location>** element defines the location of the **<object>** element. -- **Number of occurrences:** once for each <object> +- **Number of occurrences:** once for each **<object>** - **Parent elements:** [<object>](#object) @@ -1314,7 +1317,7 @@ Syntax: |type|Yes|*typeID* can be Registry or File.| |*ObjectLocation*|Yes|The location of the object.| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -1333,7 +1336,7 @@ The following example is from the MigApp.xml file: ## <locationModify> -You can use the <locationModify> element to change the location and name of an object before it is migrated to the destination computer. The <locationModify> element is processed only when the LoadState tool is run on the destination computer. In other words, this element is ignored by the ScanState tool. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist. +You can use the <locationModify> element to change the location and name of an object before it is migrated to the destination computer. The <locationModify> element is processed only when the **LoadState** tool is run on the destination computer. In other words, this element is ignored by the **ScanState** tool. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist. **Number of occurrences:** Unlimited @@ -1341,7 +1344,7 @@ You can use the <locationModify> element to change the location and name o - **Required child element:** [<objectSet>](#objectset) -- **Helper functions:** You can use the following [<locationModify> functions](#locationmodify-functions) with this element: ExactMove, RelativeMove, and Move. +- **Helper functions:** You can use the following [<locationModify> functions](#locationmodify-functions) with this element: `ExactMove`, `RelativeMove`, and `Move`. Syntax: @@ -1352,9 +1355,9 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -1366,11 +1369,11 @@ The following example is from the MigApp.xml file: ### <locationModify> functions -The following functions change the location of objects as they are migrated when using the <locationModify> element. These functions are called for every object that the parent <ObjectSet> element is enumerating. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist. +The following functions change the location of objects as they are migrated when using the <locationModify> element. These functions are called for every object that the parent **<objectSet>** element is enumerating. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist. - **ExactMove** - The ExactMove function moves all of the objects that are matched by the parent <ObjectSet> element into the given *ObjectEncodedLocation*. You can use this function when you want to move a single file to a different location on the destination computer. If the destination location is a node, all of the matching source objects will be written to the node without any subdirectories. If the destination location is a leaf, the migration engine will migrate all of the matching source objects to the same location. If a collision occurs, the normal collision algorithms will apply. + The ExactMove function moves all of the objects that are matched by the parent **<objectSet>** element into the given *ObjectEncodedLocation*. You can use this function when you want to move a single file to a different location on the destination computer. If the destination location is a node, all of the matching source objects will be written to the node without any subdirectories. If the destination location is a leaf, the migration engine will migrate all of the matching source objects to the same location. If a collision occurs, the normal collision algorithms will apply. Syntax: `ExactMove(ObjectEncodedLocation)` @@ -1406,7 +1409,7 @@ The following functions change the location of objects as they are migrated when |Setting|Required?|Value| |--- |--- |--- | - |*SourceRoot*|Yes|The location from where the objects will be moved. Any source objects that are enumerated by the parent <ObjectSet> element that are not in this location will not be moved.| + |*SourceRoot*|Yes|The location from where the objects will be moved. Any source objects that are enumerated by the parent **<objectSet>** element that are not in this location will not be moved.| |*DestinationRoot*|Yes|The location where the source objects will be moved to on the destination computer. If needed, this function will create any subdirectories that were above *SourceRoot*.| For example: @@ -1450,7 +1453,7 @@ Syntax: ## <merge> -The <merge> element determines what will happen when a collision occurs. A collision is when an object that is migrated is already present on the destination computer. If you do not specify this element, the default behavior for the registry is for the source object to overwrite the destination object. The default behavior for files is for the source file to be renamed to "OriginalFileName(1).OriginalExtension". This element specifies only what should be done when a collision occurs. It does not include objects. Therefore, for your objects to migrate, you must specify <include> rules along with the <merge> element. When an object is processed and a collision is detected, USMT will select the most specific merge rule and apply it to resolve the conflict. For example, if you have a <merge> rule `C:\* [*]` set to <sourcePriority> and a <merge> rule `C:\subfolder\* [*]` set to <destinationPriority>, then USMT would use the <destinationPriority> rule because it is the more specific. +The <merge> element determines what will happen when a collision occurs. A collision is when an object that is migrated is already present on the destination computer. If you do not specify this element, the default behavior for the registry is for the source object to overwrite the destination object. The default behavior for files is for the source file to be renamed to "OriginalFileName(1).OriginalExtension". This element specifies only what should be done when a collision occurs. It does not include objects. Therefore, for your objects to migrate, you must specify **<include>** rules along with the <merge> element. When an object is processed and a collision is detected, USMT will select the most specific merge rule and apply it to resolve the conflict. For example, if you have a <merge> rule `C:\* [*]` set to <sourcePriority> and a <merge> rule `C:\subfolder\* [*]` set to <destinationPriority>, then USMT would use the <destinationPriority> rule because it is the more specific. For an example of this element, see [Conflicts and precedence](usmt-conflicts-and-precedence.md). @@ -1460,7 +1463,7 @@ For an example of this element, see [Conflicts and precedence](usmt-conflicts-an - **Required child element:** [<objectSet>](#objectset) -- **Helper functions:** You can use the following [<merge> functions](#merge-functions) with this element: SourcePriority, DestinationPriority, FindFilePlaceByPattern, LeafPattern, NewestVersion, HigherValue(), and LowerValue(). +- **Helper functions:** You can use the following [<merge> functions](#merge-functions) with this element: `SourcePriority`, `DestinationPriority`, `FindFilePlaceByPattern`, `LeafPattern`, `NewestVersion`, `HigherValue()`, and `LowerValue()`. Syntax: @@ -1471,7 +1474,7 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the <include> rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.| +|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.

The script will be called for each object that is enumerated by the object sets in the **<include>** rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.| The following example is from the MigUser.xml file: @@ -1578,7 +1581,7 @@ Syntax: |urlid|Yes|*UrlID* is a string identifier that uniquely identifies this .xml file. This parameter must be a no-colon-name as defined by the XML Namespaces specification. Each migration .xml file must have a unique urlid. If two migration .xml files have the same urlid, the second .xml file that is specified on the command line will not be processed. For more information about XML Namespaces, see [Use XML Namespaces](/previous-versions/windows/desktop/ms754539(v=vs.85)).| |Name|No|Although not required, it is good practice to use the name of the .xml file.| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -1613,7 +1616,7 @@ This filter helper function can be used to filter the migration of files based o ## <namedElements> -You can use the **<namedElements>** element to define named elements. You can use these elements in any component throughout your .xml file. For an example of how to use this element, see the MigApp.xml file. +You can use the **<namedElements>** element to define named elements. You can use these elements in any component throughout your .xml file. For an example of how to use this element, see the `MigApp.xml` file. Syntax: @@ -1626,13 +1629,13 @@ Syntax: - **Parent elements:** [<migration>](#migration) -- **Child elements:** [<environment>](#environment), [<rules>](#rules), [<conditions>](#conditions), [<detection>](#detection), <detects>, <detect> +- **Child elements:** [<environment>](#environment), [<rules>](#rules), [<conditions>](#conditions), [<detection>](#detection), [<detects>](#detects), [<detect>](#detect) -For an example of this element, see the MigApp.xml file. +For an example of this element, see the `MigApp.xml` file. ## <object> -The <object> element represents a file or registry key. +The **<object>** element represents a file or registry key. - **Number of occurrences:** Unlimited @@ -1649,7 +1652,7 @@ Syntax: ``` -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml @@ -1668,15 +1671,15 @@ The following example is from the MigApp.xml file: ## <objectSet> -The <objectSet> element contains a list of object patterns ; for example, file paths, registry locations, and so on. Any child <conditions> elements will be evaluated first. If all child <conditions> elements return FALSE, the <objectSet> element will evaluate to an empty set. For each parent element, there can be only multiple <objectSet> elements. +The **<objectSet>** element contains a list of object patterns ; for example, file paths, registry locations, and so on. Any child **<conditions>** elements will be evaluated first. If all child **<conditions>** elements return **FALSE**, the **<objectSet>** element will evaluate to an empty set. For each parent element, there can be only multiple **<objectSet>** elements. - **Number of occurrences:** Unlimited -- **Parent elements:** [<variable>](#variable), [<content>](#content), [<include>](#include), [<exclude>](#exclude), [<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [<unconditionalExclude>](#unconditionalexclude), <detect> +- **Parent elements:** [<variable>](#variable), [<content>](#content), [<include>](#include), [<exclude>](#exclude), [<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [<unconditionalExclude>](#unconditionalexclude), [<detect>](#detect) - **Required child elements:** either [<script>](#script) or [<pattern>](#pattern) -- **Optional child elements:** [<content>](#content), [conditions](#conditions), <condition> +- **Optional child elements:** [<content>](#content), [<conditions>](#conditions), [<condition>](#condition) Syntax: @@ -1725,7 +1728,7 @@ This is an internal USMT element. Do not use this element. ## <pattern> -You can use this element to specify multiple objects. You can specify multiple <pattern> elements for each <objectSet> element and they will be combined. If you are specifying files, you may want to use GenerateDrivePatterns with <script> instead. GenerateDrivePatterns is basically the same as a <pattern> rule, without the drive letter specification. For example, the following two lines of code are similar: +You can use this element to specify multiple objects. You can specify multiple <pattern> elements for each **<objectSet>** element and they will be combined. If you are specifying files, you may want to use GenerateDrivePatterns with <script> instead. GenerateDrivePatterns is basically the same as a <pattern> rule, without the drive letter specification. For example, the following two lines of code are similar: ```xml C:\Folder\* [Sample.doc] @@ -1808,15 +1811,15 @@ This is an internal USMT element. Do not use this element. ## <role> -The <role> element is required in a custom .xml file. By specifying the <role> element, you can create a concrete component. The component will be defined by the parameters specified at the <component> level, and with the role that you specify here. +The **<role>** element is required in a custom .xml file. By specifying the **<role>** element, you can create a concrete component. The component will be defined by the parameters specified at the **<component>** level, and with the role that you specify here. -- **Number of occurrences:** Each <component> can have one, two or three child <role> elements. +- **Number of occurrences:** Each **<component>** can have one, two or three child **<role>** elements. - **Parent elements:** [<component>](#component), [<role>](#role) - **Required child elements:** [<rules>](#rules) -- **Optional child elements:** [<environment>](#environment), [<detection>](#detection), [<component>](#component), [<role>](#role), <detects>, <plugin>, +- **Optional child elements:** [<environment>](#environment), [<detection>](#detection), [<component>](#component), [<role>](#role), [<detects>](#detects), [<plugin>](#plugin) Syntax: @@ -1827,9 +1830,9 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| role | Yes | Defines the role for the component. Role can be one of:
  • **Container**
  • **Binaries**
  • **Settings**
  • **Data**
You can either:
  1. Specify up to three <role> elements within a <component> — one "Binaries" role element, one "Settings" role element and one "Data" role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these <role> elements, but each nested element must be of the same role parameter.
  2. Specify one "Container" <role> element within a <component> element. In this case, you cannot specify any child <rules> elements, only other <component> elements. And each child <component> element must have the same type as that of parent <component> element. For example:
<component context="UserAndSystem" type="Application"> 
  <displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName> 
  <environment name="GlobalEnv" /> 
  <role role="Container">
    <detection name="AnyOffice2003Version" /> 
    <detection name="FrontPage2003" /> 
    <!-- 
 Office 2003 Common Settings 
  --> 
     <component context="UserAndSystem" type="Application">
| +| role | Yes | Defines the role for the component. Role can be one of:
  • **Container**
  • **Binaries**
  • **Settings**
  • **Data**
You can either:
  1. Specify up to three **<role>** elements within a **<component>** — one "Binaries" role element, one "Settings" role element and one "Data" role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these **<role>** elements, but each nested element must be of the same role parameter.
  2. Specify one "Container" **<role>** element within a **<component>** element. In this case, you cannot specify any child **<rules>** elements, only other **<component>** elements. And each child **<component>** element must have the same type as that of parent **<component>** element. For example:
<component context="UserAndSystem" type="Application"> 
  <displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName> 
  <environment name="GlobalEnv" /> 
  <role role="Container">
    <detection name="AnyOffice2003Version" /> 
    <detection name="FrontPage2003" /> 
    <!-- 
 Office 2003 Common Settings 
  --> 
     <component context="UserAndSystem" type="Application">
| -The following example is from the MigUser.xml file. For more examples, see the MigApp.xml file: +The following example is from the MigUser.xml file. For more examples, see the `MigApp.xml` file: ```xml @@ -1862,7 +1865,7 @@ The following example is from the MigUser.xml file. For more examples, see the M ## <rules> -The <rules> element is required in a custom .xml file. This element contains rules that will run during the migration if the parent <component> element is selected, unless the child <conditions> element, if present, evaluates to FALSE. For each <rules> element there can be multiple child <rules> elements. +The **<rules>** element is required in a custom .xml file. This element contains rules that will run during the migration if the parent **<component>** element is selected, unless the child **<conditions>** element, if present, evaluates to **FALSE**. For each **<rules>** element there can be multiple child **<rules>** elements. - **Number of occurrences:** unlimited @@ -1870,7 +1873,7 @@ The <rules> element is required in a custom .xml file. This element contai - **Required child elements:** [<include>](#include) -- **Optional child elements:** [<rules>](#rules), [<exclude>](#exclude), [<unconditionalExclude>](#unconditionalexclude),[<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<addObjects>](#addobjects), [<externalProcess>](#externalprocess), [<processing>](#processing), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [conditions](#conditions), <detects> +- **Optional child elements:** [<rules>](#rules), [<exclude>](#exclude), [<unconditionalExclude>](#unconditionalexclude),[<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<addObjects>](#addobjects), [<externalProcess>](#externalprocess), [<processing>](#processing), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [conditions](#conditions), [<detects>](#detects) Syntax: @@ -1881,8 +1884,8 @@ Syntax: |Setting|Required?|Value| |--- |--- |--- | -| name | Yes, when <rules> is a child to <namedElements>
No, when <rules> is a child to any other element | When *ID* is specified, any child elements are not processed. Instead, any other <rules> elements with the same name that are declared within <namedElements> are processed. | -| context | No
(default = UserAndSystem) | Defines the scope of this parameter — whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the component element. For example, if a <component> element has a context of User and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it has a context of User. If <rules> had a context of System, it would act as though <rules> was not there.
  • **User.** Evaluates the variables for each user.
  • **System.** Evaluates the variables only once for the system.
  • **UserAndSystem.** Evaluates the variables for the entire operating system and each user.
| +| name | Yes, when **<rules>** is a child to **<namedElements>**
No, when **<rules>** is a child to any other element | When *ID* is specified, any child elements are not processed. Instead, any other **<rules>** elements with the same name that are declared within **<namedElements>** are processed. | +| context | No
(default = UserAndSystem) | Defines the scope of this parameter — whether to process this component in the context of the specific user, across the entire operating system, or both.
The largest possible scope is set by the component element. For example, if a **<component>** element has a context of **User** and a **<rules>** element had a context of **UserAndSystem**, then the **<rules>** element would act as though it has a context of **User**. If **<rules>** had a context of **System**, it would act as though **<rules>** was not there.
  • **User**: Evaluates the variables for each user.
  • **System**: Evaluates the variables only once for the system.
  • **UserAndSystem**: Evaluates the variables for the entire operating system and each user.
| The following example is from the MigUser.xml file: @@ -1928,19 +1931,19 @@ The return value that is required by <script> depends on the parent elemen - General Syntax: `` -- You can use [GetStringContent](#script-functions) when <script> is within <variable>. +- You can use [GetStringContent](#script-functions) when <script> is within **<variable>**. Syntax: `` Example: `` -- You can use [GenerateUserPatterns](#script-functions) when <script> is within <objectSet>. +- You can use [GenerateUserPatterns](#script-functions) when <script> is within **<objectSet>**. Syntax: `` Example: `` -- You can use [GenerateDrivePatterns](#script-functions) when <script> is within <objectSet>. +- You can use [GenerateDrivePatterns](#script-functions) when <script> is within **<objectSet>**. Syntax: `` @@ -1954,7 +1957,7 @@ The return value that is required by <script> depends on the parent elemen |Setting|Required?|Value| |--- |--- |--- | -| *ScriptWithArguments* | Yes | A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script will be called for each object that is enumerated by the object sets in the <include> rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.
The return value that is required by <script> depends on the parent element.
  • When used within <variable>, the return value must be a string.
  • When used within <objectSet>, the return value must be a two-dimensional array of strings.
  • When used within <location>, the return value must be a valid location that aligns with the type attribute of <location>. For example, if <location type="File">, the child script element, if specified, must be a valid file location.
    **Note**
    If you are migrating a file that has a bracket character ([ or ]) in the file name, insert the carrot (^) character directly before the bracket for it to be valid. For example, if there is a file named "file].txt", specify `c:\documents\mydocs [file^].txt]` instead of `c:\documents\mydocs [file].txt]`.
| +| *ScriptWithArguments* | Yes | A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`.
The script will be called for each object that is enumerated by the object sets in the **<include>** rule. The filter script returns a Boolean value. If the return value is **TRUE**, the object will be migrated. If it is **FALSE**, it will not be migrated.
The return value that is required by <script> depends on the parent element.
  • When used within **<variable>**, the return value must be a string.
  • When used within **<objectSet>**, the return value must be a two-dimensional array of strings.
  • When used within **<location>**, the return value must be a valid location that aligns with the type attribute of **<location>**. For example, if <location type="File">, the child script element, if specified, must be a valid file location.
    **Note**
    If you are migrating a file that has a bracket character ([ or ]) in the file name, insert the carrot (^) character directly before the bracket for it to be valid. For example, if there is a file named "file].txt", specify `c:\documents\mydocs [file^].txt]` instead of `c:\documents\mydocs [file].txt]`.
| Examples: @@ -1980,7 +1983,7 @@ These functions return either a string or a pattern. - **GetStringContent** - You can use GetStringContent with <script> elements that are within <variable> elements. If possible, this function returns the string representation of the given object. Otherwise, it returns NULL. For file objects this function always returns NULL. + You can use GetStringContent with <script> elements that are within **<variable>** elements. If possible, this function returns the string representation of the given object. Otherwise, it returns NULL. For file objects this function always returns NULL. Syntax: `GetStringContent("ObjectType","EncodedLocationPattern", "ExpandContent")` @@ -1988,7 +1991,7 @@ These functions return either a string or a pattern. |--- |--- |--- | | *ObjectType* | Yes | The type of object. Can be Registry or Ini (for an .ini file). | | *EncodedLocationPattern* | Yes |
  • If type of object is Registry, EncodedLocationPattern must be a valid registry path. For example, HKLM\SOFTWARE\MyKey[].
  • If the type of object is Ini, then EncodedLocationPattern must be in the following format:
    IniFilePath|SectionName[SettingName]
| - | *ExpandContent* | No (default=TRUE) | Can be TRUE or FALSE. If FALSE, then the given location will not be expanded before it is returned. | + | *ExpandContent* | No (default=TRUE) | Can be **TRUE** or **FALSE**. If **FALSE**, then the given location will not be expanded before it is returned. | For example: @@ -2000,7 +2003,7 @@ These functions return either a string or a pattern. - **GenerateDrivePatterns** - The GenerateDrivePatterns function will iterate all of the available drives and select the ones that match the requested drive type. It will then concatenate the selected drives with the end part of *PatternSegment* to form a full encoded file pattern. For example, if *PatternSegment* is `Path [file.txt]` and DriveType is `Fixed`, then the function will generate `C:\Path [file.txt]`, and other patterns if there are fixed drives other than C:. You cannot specify environment variables with this function. You can use GenerateDrivePatterns with <script> elements that are within [<objectSet>](#objectset) that are within <include>/<exclude>. + The GenerateDrivePatterns function will iterate all of the available drives and select the ones that match the requested drive type. It will then concatenate the selected drives with the end part of *PatternSegment* to form a full encoded file pattern. For example, if *PatternSegment* is `Path [file.txt]` and DriveType is `Fixed`, then the function will generate `C:\Path [file.txt]`, and other patterns if there are fixed drives other than C:. You cannot specify environment variables with this function. You can use GenerateDrivePatterns with <script> elements that are within [<objectSet>](#objectset) that are within **<include>**/<exclude>. Syntax: `GenerateDrivePatterns("PatternSegment","DriveType")` @@ -2013,7 +2016,7 @@ These functions return either a string or a pattern. - **GenerateUserPatterns** - The function will iterate through all users that are being migrated, excluding the currently processed user if <ProcessCurrentUser> is FALSE, and will expand the specified pattern in the context of each user. For example, if users A, B and C have profiles in C:\\Documents and Settings), by calling `GenerateUserPattens('File','%userprofile% [*.doc]','TRUE')`, the helper function will generate the following three patterns: + The function will iterate through all users that are being migrated, excluding the currently processed user if <ProcessCurrentUser> is **FALSE**, and will expand the specified pattern in the context of each user. For example, if users A, B and C have profiles in C:\\Documents and Settings), by calling `GenerateUserPattens('File','%userprofile% [*.doc]','TRUE')`, the helper function will generate the following three patterns: - "C:\\Documents and Settings\\A\\\* \[\*.doc\]" @@ -2027,13 +2030,13 @@ These functions return either a string or a pattern. |--- |--- |--- | |*ObjectType*|Yes|Defines the object type. Can be File or Registry.| |*EncodedLocationPattern*|Yes|The [location pattern](#specifying-locations). Environment variables are allowed.| - |*ProcessCurrentUser*|Yes|Can be TRUE or FALSE. Indicates if the patterns should be generated for the current user.| + |*ProcessCurrentUser*|Yes|Can be **TRUE** or **FALSE**. Indicates if the patterns should be generated for the current user.| **Example:** If GenerateUserPattens('File','%userprofile% \[\*.doc\]','FALSE') is called while USMT is processing user A, then this function will only generate patterns for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the source computer — but if user X is not migrated, then do not migrate any of the .doc files from user X's profile. -The following is example code for this scenario. The first <rules> element migrates all.doc files on the source computer with the exception of those inside C:\\Documents and Settings. The second <rules> elements will migrate all .doc files from C:\\Documents and Settings with the exception of the .doc files in the profiles of the other users. Because the second <rules> element will be processed in each migrated user context, the end result will be the desired behavior. The end result is the one we expected. +The following is example code for this scenario. The first **<rules>** element migrates all.doc files on the source computer with the exception of those inside C:\\Documents and Settings. The second **<rules>** elements will migrate all .doc files from C:\\Documents and Settings with the exception of the .doc files in the profiles of the other users. Because the second **<rules>** element will be processed in each migrated user context, the end result will be the desired behavior. The end result is the one we expected. ```xml @@ -2068,9 +2071,9 @@ This helper function invokes the document finder to scan the system for all file |Setting|Required?|Value| |--- |--- |--- | -|*ScanProgramFiles*|No (default = FALSE)|Can be TRUE or FALSE. The *ScanProgramFiles* parameter determines whether or not the document finder scans the **Program Files** directory to gather registered file extensions for known applications. For example, when set to TRUE it will discover and migrate .jpg files under the Photoshop directory, if .jpg is a file extension registered to Photoshop.| -|*IncludePatterns*|No (default = TRUE)|Can be TRUE or FALSE. TRUE will generate include patterns and can be added under the <include> element. FALSE will generate exclude patterns and can be added under the <exclude> element.| -|*SystemDrive*|No (default = FALSE)|Can be TRUE or FALSE. If TRUE, restricts all patterns to the system drive.| +|*ScanProgramFiles*|No (default = FALSE)|Can be **TRUE** or **FALSE**. The *ScanProgramFiles* parameter determines whether or not the document finder scans the **Program Files** directory to gather registered file extensions for known applications. For example, when set to **TRUE** it will discover and migrate .jpg files under the Photoshop directory, if .jpg is a file extension registered to Photoshop.| +|*IncludePatterns*|No (default = TRUE)|Can be **TRUE** or **FALSE**. **TRUE** will generate include patterns and can be added under the **<include>** element. **FALSE** will generate exclude patterns and can be added under the **<exclude>** element.| +|*SystemDrive*|No (default = FALSE)|Can be **TRUE** or **FALSE**. If **TRUE**, restricts all patterns to the system drive.| ```xml @@ -2169,7 +2172,7 @@ For example: ## <unconditionalExclude> -The <unconditionalExclude> element excludes the specified files and registry values from the migration, regardless of the other include rules in any of the migration .xml files or in the Config.xml file. The objects declared here will not be migrated because this element takes precedence over all other rules. For example, even if there are explicit <include> rules to include .mp3 files, if you specify to exclude them with this option, then they will not be migrated. +The <unconditionalExclude> element excludes the specified files and registry values from the migration, regardless of the other include rules in any of the migration .xml files or in the `Config.xml` file. The objects declared here will not be migrated because this element takes precedence over all other rules. For example, even if there are explicit **<include>** rules to include .mp3 files, if you specify to exclude them with this option, then they will not be migrated. Use this element if you want to exclude all .mp3 files from the source computer. Or, if you are backing up C:\\UserData using another method, you can exclude the entire folder from the migration. Use this element with caution, however, because if an application needs a file that you exclude, the application may not function properly on the destination computer. @@ -2206,13 +2209,13 @@ The following .xml file excludes all .mp3 files from migration. For additional e ## <variable> -The <variable> element is required in an <environment> element. For each <variable> element there must be one <objectSet>, <script>, or <text> element. The content of the <variable> element assigns a text value to the environment variable. This element has the following three options: +The **<variable>** element is required in an **<environment>** element. For each **<variable>** element there must be one **<objectSet>**, <script>, or <text> element. The content of the **<variable>** element assigns a text value to the environment variable. This element has the following three options: -1. If the <variable> element contains a <text> element, then the value of the variable element will be the value of the <text> element. +1. If the **<variable>** element contains a <text> element, then the value of the variable element will be the value of the <text> element. -2. If the <variable> element contains a <script> element and the invocation of the script produces a non-null string, then the value of the <variable> element will be the result of the script invocation. +2. If the **<variable>** element contains a <script> element and the invocation of the script produces a non-null string, then the value of the **<variable>** element will be the result of the script invocation. -3. If the <variable> element contains an <objectSet> element and the evaluation of the <objectSet> element produces at least one object pattern, then the value of the first object to match the resulting object pattern will be the value of the variable element. +3. If the **<variable>** element contains an **<objectSet>** element and the evaluation of the **<objectSet>** element produces at least one object pattern, then the value of the first object to match the resulting object pattern will be the value of the variable element. - **Number of occurrences:** Unlimited @@ -2232,7 +2235,7 @@ Syntax: |name|Yes|*ID* is a string value that is the name used to reference the environment variable. We recommend that *ID* start with the component's name to avoid namespace collisions. For example, if your component's name is MyComponent, and you want a variable that is your component's install path, you could specify `MyComponent.InstallPath`.| |remap|No, default = FALSE|Specifies whether to evaluate this environment variable as a remapping environment variable. Objects that are located in a path that is underneath this environment variable's value are automatically moved to where the environment variable points on the destination computer.| -The following example is from the MigApp.xml file: +The following example is from the `MigApp.xml` file: ```xml diff --git a/windows/deployment/usmt/usmt-xml-reference.md b/windows/deployment/usmt/usmt-xml-reference.md index e89befb18c..af25e49152 100644 --- a/windows/deployment/usmt/usmt-xml-reference.md +++ b/windows/deployment/usmt/usmt-xml-reference.md @@ -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.| diff --git a/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md b/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md index 38d39d3505..5bb2cf2322 100644 --- a/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md +++ b/windows/deployment/usmt/verify-the-condition-of-a-compressed-migration-store.md @@ -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\[:<*reportType*>\] <*filePath*> \[/l:<*logfile*>\] \[/decrypt \[:<*AlgID*>\] {/key:<*keystring*> | /keyfile:<*filename*>}\] +> UsmtUtils.exe /verify\[:<*reportType*>\] <*filePath*> \[/l:<*logfile*>\] \[/decrypt \[:<*AlgID*>\] {/key:<*keystring*> | /keyfile:<*filename*>}\] 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.