deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 13:57:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge pull request #6007 from MicrosoftDocs/aljupudi-5548201-htmltomdtable-batch20

Browse Source 
Updated-5548201-Batch-20
This commit is contained in:
Gary Moore 2021-12-01 21:47:42 -08:00 committed by GitHub
commit 72d0aad678
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
15 changed files with 460 additions and 2291 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -16,7 +16,6 @@ ms.topic: article
# Offline Migration Reference # 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. - **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.
@ -33,7 +32,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s
## In This topic ## In This topic
- [What Will Migrate Offline?](#bkmk-whatwillmigrate) - [What Will Migrate Offline?](#bkmk-whatwillmigrate)
- [What Offline Environments are Supported?](#bkmk-offlineenvironments) - [What Offline Environments are Supported?](#bkmk-offlineenvironments)
@ -48,7 +46,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s
## <a href="" id="bkmk-whatwillmigrate"></a>What Will Migrate Offline? ## <a href="" id="bkmk-whatwillmigrate"></a>What Will Migrate Offline?
The following user data and settings migrate offline, similar to an online migration: The following user data and settings migrate offline, similar to an online migration:
- Data and registry keys specified in MigXML - Data and registry keys specified in MigXML
@ -67,42 +64,18 @@ For exceptions to what you can migrate offline, see [What Does USMT Migrate?](us
## <a href="" id="bkmk-offlineenvironments"></a>What Offline Environments are Supported? ## <a href="" id="bkmk-offlineenvironments"></a>What Offline Environments are Supported?
The following table defines the supported combination of online and offline operating systems in USMT. The following table defines the supported combination of online and offline operating systems in USMT.
<table> |Running Operating System|Offline Operating System|
<colgroup> |--- |--- |
<col width="50%" /> |WinPE 5.0 or greater, with the MSXML library|Windows Vista, Windows 7, Windows 8, Windows 10|
<col width="50%" /> |Windows 7, Windows 8, Windows 10|Windows.old directory|
</colgroup>
<thead>
<tr class="header">
<th align="left">Running Operating System</th>
<th align="left">Offline Operating System</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>WinPE 5.0 or greater, with the MSXML library</p></td>
<td align="left"><p>Windows Vista, Windows 7, Windows 8, Windows 10</p></td>
</tr>
<tr class="even">
<td align="left"><p>Windows 7, Windows 8, Windows 10</p></td>
<td align="left"><p>Windows.old directory</p></td>
</tr>
</tbody>
</table>
**Note**   **Note**  
It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](/previous-versions/windows/it-pro/windows-7/ee424315(v=ws.10)). It is possible to run the ScanState tool while the drive remains encrypted by suspending Windows BitLocker Drive Encryption before booting into WinPE. For more information, see [this Microsoft site](/previous-versions/windows/it-pro/windows-7/ee424315(v=ws.10)).
## <a href="" id="bkmk-usergroupmembership"></a>User-Group Membership and Profile Control ## <a href="" id="bkmk-usergroupmembership"></a>User-Group Membership and Profile Control
User-group membership is not preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group: User-group membership is not preserved during offline migrations. You must configure a **&lt;ProfileControl&gt;** section in the Config.xml file to specify the groups that the migrated users should be made members of. The following example places all migrated users into the Users group:
``` xml ``` xml
@ -125,84 +98,27 @@ For information about the format of a Config.xml file, see [Config.xml File](usm
## <a href="" id="bkmk-commandlineoptions"></a>Command-Line Options ## <a href="" id="bkmk-commandlineoptions"></a>Command-Line Options
An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options: An offline migration can either be enabled by using a configuration file on the command line, or by using one of the following command line options:
<table> |Component|Option|Description|
<colgroup> |--- |--- |--- |
<col width="33%" /> |ScanState.exe|**/offline:***&lt;path to offline.xml&gt;*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.|
<col width="33%" /> |ScanState.exe|**/offlineWinDir:***&lt;Windows directory&gt;*|This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.|
<col width="33%" /> |ScanState.exe|**/OfflineWinOld:***&lt;Windows.old directory&gt;*|This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.|
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offline:</strong><em>&lt;path to offline.xml&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.</p></td>
</tr>
<tr class="even">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/offlineWinDir:</strong><em>&lt;Windows directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline-migration mode and starts the migration from the location specified. It is only for use in WinPE offline scenarios where the migration is occurring from a Windows directory.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>ScanState.exe</p></td>
<td align="left"><p><strong>/OfflineWinOld:</strong><em>&lt;Windows.old directory&gt;</em></p></td>
<td align="left"><p>This command-line option enables the offline migration mode and starts the migration from the location specified. It is only intended to be used in Windows.old migration scenarios, where the migration is occurring from a Windows.old directory.</p></td>
</tr>
</tbody>
</table>
You can use only one of the **/offline**, **/offlineWinDir**, or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
You can use only one of the **/offline**,**/offlineWinDir** , or **/OfflineWinOld** command-line options at a time; USMT does not support using more than one together.
## <a href="" id="bkmk-environmentvariables"></a>Environment Variables ## <a href="" id="bkmk-environmentvariables"></a>Environment Variables
The following system environment variables are necessary in the scenarios outlined below. The following system environment variables are necessary in the scenarios outlined below.
<table> |Variable|Value|Scenario|
<colgroup> |--- |--- |--- |
<col width="33%" /> |USMT_WORKING_DIR|Full path to a working directory|Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following: <br/><pre class="syntax"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre>|
<col width="33%" /> |MIG_OFFLINE_PLATFORM_ARCH|32 or 64|While operating offline, this environment variable defines the architecture of the offline system, if the system does not 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. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following: <br/><pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre>|
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Value</th>
<th align="left">Scenario</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>USMT_WORKING_DIR</p></td>
<td align="left"><p>Full path to a working directory</p></td>
<td align="left"><p>Required when USMT binaries are located on read-only media, which does not support the creation of log files or temporary storage. To set the system environment variable, at a command prompt type the following:</p>
<pre class="syntax"><code>Set USMT_WORKING_DIR=[path to working directory]</code></pre></td>
</tr>
<tr class="even">
<td align="left"><p>MIG_OFFLINE_PLATFORM_ARCH</p></td>
<td align="left"><p>32 or 64</p></td>
<td align="left"><p>While operating offline, this environment variable defines the architecture of the offline system, if the system does not 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. This is required when auto-detection of the offline architecture doesn't function properly, for example, when the source system is running a 64-bit version of Windows XP. For example, to set this system environment variable for a 32-bit architecture, at a command prompt type the following:</p>
<pre class="syntax"><code>Set MIG_OFFLINE_PLATFORM_ARCH=32</code></pre></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-offlinexml"></a>Offline.xml Elements ## <a href="" id="bkmk-offlinexml"></a>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.
### <a href="" id="-offline-"></a>&lt;offline&gt; ### <a href="" id="-offline-"></a>&lt;offline&gt;
@ -256,8 +172,4 @@ The following XML example illustrates some of the elements discussed earlier in
## Related topics ## Related topics
[Plan Your Migration](usmt-plan-your-migration.md) [Plan Your Migration](usmt-plan-your-migration.md)

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

@ -16,14 +16,12 @@ ms.topic: article
# Understanding Migration XML Files # Understanding Migration XML Files
You can modify the behavior of a basic User State Migration Tool (USMT) 10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the MigDocs.xml and MigUser.xml files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a Config.xml file to further customize your migration.
You can modify the behavior of a basic User State Migration Tool (USMT)10.0 migration by using XML files; these files provide instructions on where and how the USMT tools should gather and apply files and settings. USMT includes three XML files that you can use to customize a basic migration: the MigDocs.xml and MigUser.xml files, which modify how files are discovered on the source computer, and the MigApps.xml file, which is required in order to migrate supported application settings. You can also create and edit custom XML files and a Config.xml file to further customize your migration.
This topic 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. The MigDocs.xml file uses the new **GenerateDocPatterns** function available in USMT to automatically find user documents on a source computer. This topic 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. The MigDocs.xml file uses the new **GenerateDocPatterns** function available in USMT to automatically find user documents on a source computer.
## In This topic ## In This topic
[Overview of the Config.xml file](#bkmk-config) [Overview of the Config.xml file](#bkmk-config)
[Overview of the MigApp.xml file](#bkmk-migapp) [Overview of the MigApp.xml file](#bkmk-migapp)
@ -50,27 +48,20 @@ This topic provides an overview of the default and custom migration XML files an
## <a href="" id="bkmk-config"></a>Overview of the Config.xml file ## <a href="" id="bkmk-config"></a>Overview of the Config.xml file
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 /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).
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 in conjunction with other XML files, such as in the following example: `scanstate /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). > [!NOTE]
> When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files.
**Note**  
When modifying the XML elements in the Config.xml file, you should edit an element and set the **migrate** property to **no**, rather than deleting the element from the file. If you delete the element instead of setting the property, the component may still be migrated by rules in other XML files.
## <a href="" id="bkmk-migapp"></a>Overview of the MigApp.xml file ## <a href="" id="bkmk-migapp"></a>Overview of the MigApp.xml file
The MigApp.xml file installed with USMT includes instructions to migrate the settings for the applications listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md). You must include the MigApp.xml file when using the ScanState and LoadState tools, by using the `/i` option in order to migrate application settings. The MigDocs.xml and MigUser.xml files do not migrate application settings. You can create a custom XML file to include additional applications. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md). The MigApp.xml file installed with USMT includes instructions to migrate the settings for the applications listed in [What Does USMT Migrate?](usmt-what-does-usmt-migrate.md). You must include the MigApp.xml file when using the ScanState and LoadState tools, by using the `/i` option in order to migrate application settings. The MigDocs.xml and MigUser.xml files do not migrate application settings. You can create a custom XML file to include additional applications. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md).
**Important**   > [!Important]
The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. See the [Sample migration rules for customized versions of XML files](#bkmk-samples) section of this document for more information about migrating .pst files that are not linked to Outlook. > The MigApps.xml file will only detect and migrate .pst files that are linked to Microsoft Office Outlook. For more information about migrating .pst files that are not linked to Outlook, see the [Sample migration rules for customized versions of XML files](#bkmk-samples).
## <a href="" id="bkmk-migdocs"></a>Overview of the MigDocs.xml file ## <a href="" id="bkmk-migdocs"></a>Overview of the MigDocs.xml file
The MigDocs.xml file uses the new **GenerateDocPatterns** helper function to create instructions for USMT to migrate files from the source computer, based on the location of the files. You can use the MigDocs.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigDocs.xml file uses the new **GenerateDocPatterns** helper function to create instructions for USMT to migrate files from the source computer, based on the location of the files. You can use the MigDocs.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions.
The default MigDocs.xml file migrates the following: The default MigDocs.xml file migrates the following:
@ -141,12 +132,11 @@ You can also use the **/genmigxml** option with the ScanState tool to review and
## <a href="" id="bkmk-miguser"></a>Overview of the MigUser.xml file ## <a href="" id="bkmk-miguser"></a>Overview of the MigUser.xml file
The MigUser.xml file includes instructions for USMT to migrate user files based on file name extensions. You can use the MigUser.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigUser.xml file will gather all files from the standard user-profile folders, and any files on the computer with the specified file name extensions.
The MigUser.xml file includes instructions for USMT to migrate user files based on file name extensions. You can use the MigUser.xml file with the ScanState and LoadState tools to perform a more targeted migration than using USMT without XML instructions. The MigUser.xml file will gather all files from the standard user-profile folders, as well as any files on the computer with the specified file name extensions.
The default MigUser.xml file migrates the following: The default MigUser.xml file migrates the following:
- All files from the standard user-profile folders which are described as: - All files from the standard user-profile folders, which are described as:
- CSIDL\_MYVIDEO - CSIDL\_MYVIDEO
@ -166,7 +156,7 @@ The default MigUser.xml file migrates the following:
- Files with the following extensions: - Files with the following extensions:
.qdf, .qsd, .qel, .qph, .doc\*, .dot\*, .rtf, .mcw, .wps, .scd, .wri, .wpd, .xl\*, .csv, .iqy, .dqy, .oqy, .rqy, .wk\*, .wq1, .slk, .dif, .ppt\*, .pps\*, .pot\*, .sh3, .ch3, .pre, .ppa, .txt, .pst, .one\*, .vl\*, .vsd, .mpp, .or6, .accdb, .mdb, .pub `.qdf`, `.qsd`, `.qel`, `.qph`, `.doc\*`, `.dot\*`, `.rtf`, `.mcw`, `.wps`, `.scd`, `.wri`, `.wpd`, `.xl\*`, `.csv`, `.iqy`, `.dqy`, `.oqy`, `.rqy`, `.wk\*`, `.wq1`, `.slk`, `.dif`, `.ppt\*`, `.pps\*`, `.pot\*`, `.sh3`, `.ch3`, `.pre`, `.ppa`, `.txt`, `.pst`, `.one\*`, `.vl\*`, `.vsd`, `.mpp`, `.or6`, `.accdb`, `.mdb`, `.pub`
The default MigUser.xml file does not migrate the following: The default MigUser.xml file does not migrate the following:
@ -180,62 +170,30 @@ The default MigUser.xml file does not migrate the following:
You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer. You can make a copy of the MigUser.xml file and modify it to include or exclude standard user-profile folders and file name extensions. If you know all of the extensions for the files you want to migrate from the source computer, use the MigUser.xml file to move all of your relevant data, regardless of the location of the files. However, this may result in a migration that contains more files than intended. For example, if you choose to migrate all .jpg files, you may migrate image files such as thumbnails and logos from legacy applications that are installed on the source computer.
**Note**   > [!NOTE]
Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than three hundred file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document. > Each file name extension you include in the rules within the MigUser.xml file increases the amount of time needed for the ScanState tool to gather the files for the migration. If you are migrating more than 300 file types, you may experience a slow migration. For more information about other ways to organize the migration of your data, see the [Using multiple XML files](#bkmk-multiple) section of this document.
## <a href="" id="bkmk-multiple"></a>Using multiple XML files ## <a href="" id="bkmk-multiple"></a>Using multiple XML files
You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with additional migration rules. You can use multiple XML files with the ScanState and LoadState tools. Each of the default XML files included with or generated by USMT is configured for a specific component of the migration. You can also use custom XML files to supplement these default files with additional migration rules.
<table> |XML migration file|Modifies the following components:|
<colgroup> |--- |--- |
<col width="50%" /> |Config.xml file|Operating-system components such as desktop wallpaper and background theme. <br/>You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).|
<col width="50%" /> |MigApps.xml file|Applications settings.|
</colgroup> |MigUser.xml or MigDocs.xml files|User files and profile settings.|
<thead> |Custom XML files|Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.|
<tr class="header">
<th align="left">XML migration file</th>
<th align="left">Modifies the following components:</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Config.xml file</p></td>
<td align="left"><p>Operating-system components such as desktop wallpaper and background theme.</p>
<p>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 <a href="usmt-customize-xml-files.md" data-raw-source="[Customize USMT XML Files](usmt-customize-xml-files.md)">Customize USMT XML Files</a> and <a href="usmt-configxml-file.md" data-raw-source="[Config.xml File](usmt-configxml-file.md)">Config.xml File</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p>MigApps.xml file</p></td>
<td align="left"><p>Applications settings.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>MigUser.xml or MigDocs.xml files</p></td>
<td align="left"><p>User files and profile settings.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Custom XML files</p></td>
<td align="left"><p>Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.</p></td>
</tr>
</tbody>
</table>
For example, you can use all of the XML migration file types for a single migration, as in the following example: For example, you can use all of the XML migration file types for a single migration, as in the following example:
``` ```console
Scanstate <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml Scanstate <store> /config:c:\myFolder\config.xml /i:migapps.xml /i:migdocs.xml /i:customrules.xml
``` ```
### <a href="" id="bkmk-userfiles"></a>XML rules for migrating user files ### <a href="" id="bkmk-userfiles"></a>XML rules for migrating user files
**Important**   > [!IMPORTANT]
You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer. > You should not use the MigUser.xml and MigDocs.xml files together in the same command. Using both XML files can result in duplication of some migrated files. This occurs when conflicting target-location instructions are given in each XML file. The target file will be stored once during the migration, but will be applied by each XML file to a different location on the destination computer.
If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location. The MigUser.xml file migrates only the files with the specified file name extensions. If your data set is unknown or if many files are stored outside of the standard user-profile folders, the MigDocs.xml is a better choice than the MigUser.xml file, because the MigDocs.xml file will gather a broader scope of data. The MigDocs.xml file migrates folders of data based on location. The MigUser.xml file migrates only the files with the specified file name extensions.
@ -243,13 +201,10 @@ If you want more control over the migration, you can create custom XML files. Se
## <a href="" id="bkmk-createxml"></a>Creating and editing a custom XML file ## <a href="" id="bkmk-createxml"></a>Creating and editing a custom XML file
You can use the **/genmigxml** command-line option to determine which files will be included in your migration. The **/genmigxml** option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary. You can use the **/genmigxml** command-line option to determine which files will be included in your migration. The **/genmigxml** option creates a file in a location you specify, so that you can review the XML rules and make modifications as necessary.
**Note**   > [!NOTE]
If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location. > If you reinstall USMT, the default migration XML files will be overwritten and any customizations you make directly to these files will be lost. Consider creating separate XML files for your custom migration rules and saving them in a secure location.
To generate the XML migration rules file for a source computer: To generate the XML migration rules file for a source computer:
@ -259,14 +214,14 @@ To generate the XML migration rules file for a source computer:
3. At the command prompt, type: 3. At the command prompt, type:
``` ```console
cd /d <USMTpath> cd /d <USMTpath>
scanstate.exe /genmigxml: <filepath.xml> scanstate.exe /genmigxml: <filepath.xml>
``` ```
Where *&lt;USMTpath&gt;* is the location on your source computer where you have saved the USMT files and tools, and *&lt;filepath.xml&gt;* is the full path to a file where you can save the report. For example, type: Where *&lt;USMTpath&gt;* is the location on your source computer where you have saved the USMT files and tools, and *&lt;filepath.xml&gt;* is the full path to a file where you can save the report. For example, type:
``` ```console
cd /d c:\USMT 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"
``` ```
@ -275,46 +230,27 @@ To generate the XML migration rules file for a source computer:
The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes three Boolean values. You can change the settings to modify the way the MigDocs.xml file generates the XML rules for migration. The MigDocs.xml file calls the **GenerateDocPatterns** function, which takes three Boolean values. You can change the settings to modify the way the MigDocs.xml file generates the XML rules for migration.
<table> - `ScanProgramFiles`: This argument is valid only when the **GenerateDocPatterns** function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Setting</th>
<th align="left">Value</th>
<th align="left">Default Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>ScanProgramFiles</p></td>
<td align="left"><p>The <em>ScanProgramFiles</em> argument is valid only when the <strong>GenerateDocPatterns</strong> function is called in a system context. This argument determines whether or not to scan the Program Files directory to gather registered file name extensions for known applications.</p>
<p>For example, when set to <strong>TRUE</strong>, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The <strong>GenerateDocPatterns</strong> function generates this inclusion pattern for .doc files:</p>
<pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;C:\Program Files\Microsoft Office<em>[</em>.doc]&lt;/pattern&gt;</code></pre>
<p>If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions.</p></td>
<td align="left"><p>False</p></td>
</tr>
<tr class="even">
<td align="left"><p>IncludePatterns</p></td>
<td align="left"><p>The <em>IncludePatterns</em> argument determines whether to generate exclude or include patterns in the XML. When this argument is set to <strong>TRUE</strong>, the <strong>GenerateDocPatterns</strong> function generates include patterns and the function must be added under the &lt;include&gt; element. Changing this argument to <strong>FALSE</strong> generates exclude patterns and the function must be added under the &lt;exclude&gt; element.</p></td>
<td align="left"><p>True</p></td>
</tr>
<tr class="odd">
<td align="left"><p>SystemDrive</p></td>
<td align="left"><p>The <em>SystemDrive</em> argument determines whether to generate patterns for all fixed drives or only for the system drive. Changing this argument to <strong>TRUE</strong> restricts all patterns to the system drive.</p></td>
<td align="left"><p>False</p></td>
</tr>
</tbody>
</table>
**Default value**: False
For example, when set to **TRUE**, the function discovers and migrates .doc files under the Microsoft Office directory, because .doc is a file name extension registered to a Microsoft Office application. The **GenerateDocPatterns** function generates this inclusion pattern for `.doc` files:
`<pattern type="File">C:\Program Files\Microsoft Office[.doc]</pattern>`
If a child folder of an included folder contains an installed application, ScanProgramFiles will also create an exclusion rule for the child folder. All folders under the application folder will be scanned recursively for registered file name extensions.
- `IncludePatterns`: This argument determines whether to generate exclude or include patterns in the XML. When this argument is set to **TRUE**, the **GenerateDocPatterns** function generates include patterns and the function must be added under the `<include>` element. Changing this argument to **FALSE** generates exclude patterns and the function must be added under the `<exclude>` element.
**Default value**: True
- `SystemDrive`: This argument determines whether to generate patterns for all fixed drives or only for the system drive. Changing this argument to **TRUE** restricts all patterns to the system drive.
**Default value**: False
**Usage:** **Usage:**
``` ```console
MigXmlHelper.GenerateDocPatterns ("<ScanProgramFiles>", "<IncludePatterns>", "<SystemDrive>") MigXmlHelper.GenerateDocPatterns ("<ScanProgramFiles>", "<IncludePatterns>", "<SystemDrive>")
``` ```
@ -400,42 +336,24 @@ The user context includes rules for data in the User Profiles directory. When ca
- FOLDERID\_RecordedTV - FOLDERID\_RecordedTV
**Note**   > [!NOTE]
Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable. > Rules contained in a component that is assigned the user context will be run for each user profile on the computer. Files that are scanned multiple times by the MigDocs.xml files will only be copied to the migration store once; however, a large number of rules in the user context can slow down the migration. Use the system context when it is applicable.
### <a href="" id="bkmk-samples"></a>Sample migration rules for customized versions of XML files
### <a href="" id="bkmk-samples"></a>Sample migration rules for customized versions of XML files > [!NOTE]
> For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md).
**Note**  
For best practices and requirements for customized XML files in USMT, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [General Conventions](usmt-general-conventions.md).
### <a href="" id="bkmk-exclude"></a>Exclude rules usage examples ### <a href="" id="bkmk-exclude"></a>Exclude rules usage examples
In the examples below, the source computer has a .txt file called "new text document" in a directory called "new folder". The default MigDocs.xml behavior migrates the new text document.txt file and all files contained in the "new folder" directory. The rules generated by the function are: In the examples below, the source computer has a .txt file called "new text document" in a directory called "new folder". The default MigDocs.xml behavior migrates the new text document.txt file and all files contained in the "new folder" directory. The rules generated by the function are:
<table> | Rule | Syntax |
<colgroup> |--- |--- |
<col width="50%" /> |Rule 1|`<pattern type="File">d:\new folder[new text document.txt]</pattern>`|
<col width="50%" /> |Rule 2|`<pattern type="File">d:\new folder[]</pattern>`|
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p>Rule 1</p></td>
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;d:\new folder[new text document.txt]&lt;/pattern&gt;</code></pre></td>
</tr>
<tr class="even">
<td align="left"><p>Rule 2</p></td>
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;d:\new folder<em>[</em>]&lt;/pattern&gt;</code></pre></td>
</tr>
</tbody>
</table>
To exclude the new text document.txt file and any .txt files in "new folder", you can do the following:
To exclude the new text document.txt file as well as any .txt files in "new folder", you can do the following:
**Example 1: Exclude all .txt files in a folder** **Example 1: Exclude all .txt files in a folder**
@ -513,30 +431,17 @@ For locations outside the user profile, such as the Program Files folder, you ca
For more examples of include rules that you can use in custom migration XML files, see [Include Files and Settings](usmt-include-files-and-settings.md). For more examples of include rules that you can use in custom migration XML files, see [Include Files and Settings](usmt-include-files-and-settings.md).
**Note**   > [!NOTE]
For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md). > For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
## <a href="" id="bkmk-next"></a>Next steps ## <a href="" id="bkmk-next"></a>Next steps
You can include additional rules for the migration in the MigDocs.xml file or other XML migration files. For example, you can use the `<locationModify>` element to move files from the folder where they were gathered to a different folder, when they are applied to the destination computer.
You can include additional rules for the migration in the MigDocs.xml file or other XML migration files. For example, you can use the &lt;locationModify&gt; element to move files from the folder where they were gathered to a different folder, when they are applied to the destination computer.
You can use an XML schema (MigXML.xsd) file to validate the syntax of your customized XML files. For more information, see [USMT Resources](usmt-resources.md). You can use an XML schema (MigXML.xsd) file to validate the syntax of your customized XML files. For more information, see [USMT Resources](usmt-resources.md).
## Related topics ## Related topics
[Exclude Files and Settings](usmt-exclude-files-and-settings.md) [Exclude Files and Settings](usmt-exclude-files-and-settings.md)
[Include Files and Settings](usmt-include-files-and-settings.md) [Include Files and Settings](usmt-include-files-and-settings.md)

44
windows/deployment/usmt/usmt-choose-migration-store-type.md
View File

@ -16,51 +16,19 @@ ms.topic: article
# Choose a Migration Store Type # Choose a Migration Store Type
One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store. One of the main considerations for planning your migration is to determine which migration store type best meets your needs. As part of these considerations, determine how much space is required to run the User State Migration Tool (USMT) 10.0 components on your source and destination computers, and how much space is needed to create and host the migration store, whether you are using a local share, network share, or storage device. The final consideration is ensuring that user date integrity is maintained by encrypting the migration store.
## In This Section ## In This Section
| Link | Description |
<table> |--- |--- |
<colgroup> |[Migration Store Types Overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
<col width="50%" /> |[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)|Estimate the amount of disk space needed for computers in your organization based on information about your organization's infrastructure.|
<col width="50%" /> |[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they are used.|
</colgroup> |[Migration Store Encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
<tbody>
<tr class="odd">
<td align="left"><p><a href="migration-store-types-overview.md" data-raw-source="[Migration Store Types Overview](migration-store-types-overview.md)">Migration Store Types Overview</a></p></td>
<td align="left"><p>Choose the migration store type that works best for your needs and migration scenario.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-estimate-migration-store-size.md" data-raw-source="[Estimate Migration Store Size](usmt-estimate-migration-store-size.md)">Estimate Migration Store Size</a></p></td>
<td align="left"><p>Estimate the amount of disk space needed for computers in your organization based on information about your organization&#39;s infrastructure.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-hard-link-migration-store.md" data-raw-source="[Hard-Link Migration Store](usmt-hard-link-migration-store.md)">Hard-Link Migration Store</a></p></td>
<td align="left"><p>Learn about hard-link migration stores and the scenarios in which they are used.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a></p></td>
<td align="left"><p>Learn about the using migration store encryption to protect user data integrity during a migration.</p></td>
</tr>
</tbody>
</table>
## Related topics ## Related topics
[Plan Your Migration](usmt-plan-your-migration.md) [Plan Your Migration](usmt-plan-your-migration.md)
[User State Migration Tool (USMT) How-to topics](usmt-how-to.md) [User State Migration Tool (USMT) How-to topics](usmt-how-to.md)

38
windows/deployment/usmt/usmt-command-line-syntax.md
View File

@ -16,40 +16,12 @@ ms.topic: article
# User State Migration Tool (USMT) Command-line Syntax # User State Migration Tool (USMT) Command-line Syntax
The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation. The User State Migration Tool (USMT) 10.0 migrates user files and settings during large deployments of Windows. To improve and simplify the migration process, USMT captures desktop, network, and application settings in addition to a user's files. USMT then migrates these items to a new Windows installation.
## In This Section ## In This Section
| Link | Description |
<table> |--- |--- |
<colgroup> |[ScanState Syntax](usmt-scanstate-syntax.md)|Lists the command-line options for using the ScanState tool.|
<col width="50%" /> |[LoadState Syntax](usmt-loadstate-syntax.md)|Lists the command-line options for using the LoadState tool.|
<col width="50%" /> |[UsmtUtils Syntax](usmt-utilities.md)|Lists the command-line options for using the UsmtUtils tool.|
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the ScanState tool.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-loadstate-syntax.md" data-raw-source="[LoadState Syntax](usmt-loadstate-syntax.md)">LoadState Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the LoadState tool.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-utilities.md" data-raw-source="[UsmtUtils Syntax](usmt-utilities.md)">UsmtUtils Syntax</a></p></td>
<td align="left"><p>Lists the command-line options for using the UsmtUtils tool.</p></td>
</tr>
</tbody>
</table>

159
windows/deployment/usmt/usmt-configxml-file.md
View File

@ -16,10 +16,8 @@ ms.topic: article
# Config.xml File # Config.xml File
## Config.xml File ## Config.xml File
The Config.xml file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the **/genconfig** option with the ScanState.exe tool. If you want to include all of the default components, and do not want to change the default store-creation or profile-migration behavior, you do not need to create a Config.xml file. The Config.xml file is an optional User State Migration Tool (USMT) 10.0 file that you can create using the **/genconfig** option with the ScanState.exe tool. If you want to include all of the default components, and do not want to change the default store-creation or profile-migration behavior, you do not need to create a Config.xml file.
However, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigUser.xml and MigDocs.xml files, but you want to exclude certain components, you can create and modify a Config.xml file and leave the other .xml files unchanged. For example, you must create and modify the Config.xml file if you want to exclude any of the operating-system settings that are migrated. It is necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior. However, if you are satisfied with the default migration behavior defined in the MigApp.xml, MigUser.xml and MigDocs.xml files, but you want to exclude certain components, you can create and modify a Config.xml file and leave the other .xml files unchanged. For example, you must create and modify the Config.xml file if you want to exclude any of the operating-system settings that are migrated. It is necessary to create and modify this file if you want to change any of the default store-creation or profile-migration behavior.
@ -31,11 +29,8 @@ For more information about using the Config.xml file with other migration files,
**Note**   **Note**  
To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration. To exclude a component from the Config.xml file, set the **migrate** value to **"no"**. Deleting the XML tag for the component from the Config.xml file will not exclude the component from your migration.
## In this topic ## In this topic
In USMT there are new migration policies that can be configured in the Config.xml file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. The following elements and parameters are for use in the Config.xml file only. In USMT there are new migration policies that can be configured in the Config.xml file. For example, you can configure additional **&lt;ErrorControl&gt;**, **&lt;ProfileControl&gt;**, and **&lt;HardLinkStoreControl&gt;** options. The following elements and parameters are for use in the Config.xml file only.
[&lt;Policies&gt;](#bkmk-policies) [&lt;Policies&gt;](#bkmk-policies)
@ -74,14 +69,12 @@ In USMT there are new migration policies that can be configured in the Config.xm
## <a href="" id="bkmk-policies"></a>&lt;Policies&gt; ## <a href="" id="bkmk-policies"></a>&lt;Policies&gt;
The **&lt;Policies&gt;** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **&lt;Policies&gt;** element are **&lt;ErrorControl&gt;** and **&lt;HardLinkStoreControl&gt;**. The **&lt;Policies&gt;** element is a child of **&lt;Configuration&gt;**. The **&lt;Policies&gt;** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **&lt;Policies&gt;** element are **&lt;ErrorControl&gt;** and **&lt;HardLinkStoreControl&gt;**. The **&lt;Policies&gt;** element is a child of **&lt;Configuration&gt;**.
Syntax: `<Policies> </Policies>` Syntax: `<Policies> </Policies>`
## <a href="" id="bkmk-errorcontrol"></a>&lt;ErrorControl&gt; ## <a href="" id="bkmk-errorcontrol"></a>&lt;ErrorControl&gt;
The **&lt;ErrorControl&gt;** element is an optional element you can configure in the Config.xml file. The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. The **&lt;ErrorControl&gt;** element is an optional element you can configure in the Config.xml file. The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
- **Number of occurrences**: Once for each component - **Number of occurrences**: Once for each component
@ -108,10 +101,8 @@ Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority
</ErrorControl> </ErrorControl>
``` ```
**Important**   > [!IMPORTANT]
The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character. > The configurable **&lt;ErrorControl&gt;** rules support only the environment variables for the operating system that is running and the currently logged-on user. As a workaround, you can specify a path using the (\*) wildcard character.
### <a href="" id="bkmk-fatal"></a>&lt;fatal&gt; ### <a href="" id="bkmk-fatal"></a>&lt;fatal&gt;
@ -125,35 +116,14 @@ The **&lt;fatal&gt;** element is not required.
Syntax: `<fatal errorCode="any">`*&lt;pattern&gt;*`</fatal>` Syntax: `<fatal errorCode="any">`*&lt;pattern&gt;*`</fatal>`
<table> |Parameter|Required|Value|
<colgroup> |--- |--- |--- |
<col width="33%" /> |errorCode|No|"any" or "*specify system error message here*"|
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Parameter</th>
<th align="left">Required</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>errorCode</p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>&quot;any&quot; or &quot;<em>specify system error message here</em>&quot;</p></td>
</tr>
</tbody>
</table>
You use the **&lt;fatal&gt;** element to specify that errors matching a specific pattern should cause USMT to halt the migration. You use the **&lt;fatal&gt;** element to specify that errors matching a specific pattern should cause USMT to halt the migration.
## <a href="" id="bkmk-fileerror"></a>&lt;fileError&gt; ## <a href="" id="bkmk-fileerror"></a>&lt;fileError&gt;
The **&lt;fileError&gt;** element is not required. The **&lt;fileError&gt;** element is not required.
- **Number of occurrences**: Once for each component - **Number of occurrences**: Once for each component
@ -168,7 +138,6 @@ You use the **&lt;fileError&gt;** element to represent the behavior associated w
## <a href="" id="bkmk-nonfatal"></a>&lt;nonFatal&gt; ## <a href="" id="bkmk-nonfatal"></a>&lt;nonFatal&gt;
The **&lt;nonFatal&gt;** element is not required. The **&lt;nonFatal&gt;** element is not required.
- **Number of occurrences**: Once for each component - **Number of occurrences**: Once for each component
@ -179,35 +148,14 @@ The **&lt;nonFatal&gt;** element is not required.
Syntax: `<nonfatal errorCode="any">`*&lt;pattern&gt;*`</nonFatal>` Syntax: `<nonfatal errorCode="any">`*&lt;pattern&gt;*`</nonFatal>`
<table> |Parameter|Required|Value|
<colgroup> |--- |--- |--- |
<col width="33%" /> |**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.|
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Parameter</th>
<th align="left">Required</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>&lt;errorCode&gt;</strong></p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>&quot;any&quot; or &quot;<em>specify system error message here</em>&quot;. If system error messages are not specified, the default behavior applies the parameter to all system error messages.</p></td>
</tr>
</tbody>
</table>
You use the **&lt;nonFatal&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration. You use the **&lt;nonFatal&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
## <a href="" id="bkmk-registryerror"></a>&lt;registryError&gt; ## <a href="" id="bkmk-registryerror"></a>&lt;registryError&gt;
The <strong>&lt;registryError&gt;</strong>element is not required. The <strong>&lt;registryError&gt;</strong>element is not required.
- **Number of occurrences**: Once for each component - **Number of occurrences**: Once for each component
@ -218,35 +166,14 @@ The <strong>&lt;registryError&gt;</strong>element is not required.
Syntax: `<registryError></registryError>` Syntax: `<registryError></registryError>`
<table> |Parameter|Required|Value|
<colgroup> |--- |--- |--- |
<col width="33%" /> |**&lt;errorCode&gt;**|No|"any" or "*specify system error message here*". If system error messages are not specified, the default behavior applies the parameter to all system error messages.|
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Parameter</th>
<th align="left">Required</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>&lt;errorCode&gt;</strong></p></td>
<td align="left"><p>No</p></td>
<td align="left"><p>&quot;any&quot; or &quot;<em>specify system error message here</em>&quot;. If system error messages are not specified, the default behavior applies the parameter to all system error messages.</p></td>
</tr>
</tbody>
</table>
You use the **&lt;registryError&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration. You use the **&lt;registryError&gt;** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
## <a href="" id="bkmk-hardlinkstorecontrol"></a>&lt;HardLinkStoreControl&gt; ## <a href="" id="bkmk-hardlinkstorecontrol"></a>&lt;HardLinkStoreControl&gt;
The **&lt;HardLinkStoreControl&gt;** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **&lt;fileLocked&gt;**. The **&lt;HardLinkStoreControl&gt;** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **&lt;fileLocked&gt;**.
Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>` Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>`
@ -261,10 +188,8 @@ Syntax: `<HardLinkStoreControl></HardLinkStoreControl>`
The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that cannot be copied, even though is technically possible for the link to be created. The **&lt;HardLinkStoreControl&gt;** sample code below specifies that hard links can be created to locked files only if the locked file resides somewhere under C:\\Users\\. Otherwise, a file-access error occurs when a locked file is encountered that cannot be copied, even though is technically possible for the link to be created.
**Important**   > [!IMPORTANT]
The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file’s location. > The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file’s location.
``` xml ``` xml
<Policy> <Policy>
@ -282,84 +207,49 @@ The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore f
## <a href="" id="bkmk-filelock"></a>&lt;fileLocked&gt; ## <a href="" id="bkmk-filelock"></a>&lt;fileLocked&gt;
The **&lt;fileLocked&gt;** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **&lt;fileLocked&gt;** element are processed in the order in which they appear in the XML file. The **&lt;fileLocked&gt;** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **&lt;fileLocked&gt;** element are processed in the order in which they appear in the XML file.
Syntax: `<fileLocked></fileLocked>` Syntax: `<fileLocked></fileLocked>`
## <a href="" id="bkmk-createhardlink"></a>&lt;createHardLink&gt; ## <a href="" id="bkmk-createhardlink"></a>&lt;createHardLink&gt;
The **&lt;createHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application. The **&lt;createHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.
Syntax: `<createHardLink>`*&lt;pattern&gt;*`</createHardLink>` Syntax: `<createHardLink>`*&lt;pattern&gt;*`</createHardLink>`
## <a href="" id="bkmk-errorhardlink"></a>&lt;errorHardLink&gt; ## <a href="" id="bkmk-errorhardlink"></a>&lt;errorHardLink&gt;
The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should not be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that is not possible, **Error\_Locked** is thrown. This is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration. The **&lt;errorHardLink&gt;** element defines a standard MigXML pattern that describes file paths where hard links should not be created if the file is locked for editing by another application. USMT will attempt to copy files under these paths into the migration store. However, if that is not possible, **Error\_Locked** is thrown. This is a standard Windows application programming interface (API) error that can be captured by the **&lt;ErrorControl&gt;** section to either cause USMT to skip the file or abort the migration.
Syntax: `<errorHardLink>`*&lt;pattern&gt;*`</errorHardLink>` Syntax: `<errorHardLink>`*&lt;pattern&gt;*`</errorHardLink>`
## <a href="" id="bkmk-profilecontrol"></a>&lt;ProfileControl&gt; ## <a href="" id="bkmk-profilecontrol"></a>&lt;ProfileControl&gt;
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **&lt;ProfileMigration&gt;** is a child of **&lt;Configuration&gt;**. This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **&lt;ProfileMigration&gt;** is a child of **&lt;Configuration&gt;**.
Syntax: &lt;`ProfileControl> </ProfileControl>` Syntax: &lt;`ProfileControl> </ProfileControl>`
## <a href="" id="bkmk-localgroups"></a>&lt;localGroups&gt; ## <a href="" id="bkmk-localgroups"></a>&lt;localGroups&gt;
This element is used to contain other elements that establish rules for how to migrate local groups. **&lt;localGroups&gt;** is a child of **&lt;ProfileControl&gt;**. This element is used to contain other elements that establish rules for how to migrate local groups. **&lt;localGroups&gt;** is a child of **&lt;ProfileControl&gt;**.
Syntax: `<localGroups> </localGroups>` Syntax: `<localGroups> </localGroups>`
## <a href="" id="bkmk-mappings"></a>&lt;mappings&gt; ## <a href="" id="bkmk-mappings"></a>&lt;mappings&gt;
This element is used to contain other elements that establish mappings between groups. This element is used to contain other elements that establish mappings between groups.
Syntax: `<mappings> </mappings>` Syntax: `<mappings> </mappings>`
## <a href="" id="bkmk-changegrou"></a>&lt;changeGroup&gt; ## <a href="" id="bkmk-changegrou"></a>&lt;changeGroup&gt;
This element describes the source and destination groups for a local group membership change during the migration. It is a child of **&lt;localGroups&gt;**. The following parameters are defined: This element describes the source and destination groups for a local group membership change during the migration. It is a child of **&lt;localGroups&gt;**. The following parameters are defined:
<table> |Parameter|Required|Value|
<colgroup> |--- |--- |--- |
<col width="33%" /> |From|Yes|A valid local group on the source machine that contains users selected for migration on the command line.|
<col width="33%" /> |To|Yes|A local group that the users are to be moved to during the migration.|
<col width="33%" /> |appliesTo|Yes|nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.|
</colgroup>
<thead>
<tr class="header">
<th align="left">Parameter</th>
<th align="left">Required</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>From</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>A valid local group on the source machine that contains users selected for migration on the command line.</p></td>
</tr>
<tr class="even">
<td align="left"><p>To</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>A local group that the users are to be moved to during the migration.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>appliesTo</p></td>
<td align="left"><p>Yes</p></td>
<td align="left"><p>nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.</p></td>
</tr>
</tbody>
</table>
The valid and required children of **&lt;changeGroup&gt;** are **&lt;include&gt;** and **&lt;exclude&gt;**. Although both can be children at the same time, only one is required. The valid and required children of **&lt;changeGroup&gt;** are **&lt;include&gt;** and **&lt;exclude&gt;**. Although both can be children at the same time, only one is required.
@ -367,21 +257,18 @@ Syntax: `<changeGroup From="Group1" To= "Group2"> </changeGroup>`
## <a href="" id="bkmk-include"></a>&lt;include&gt; ## <a href="" id="bkmk-include"></a>&lt;include&gt;
This element specifies that its required child, *&lt;pattern&gt;*, should be included in the migration. This element specifies that its required child, *&lt;pattern&gt;*, should be included in the migration.
Syntax: `<include>``</include>` Syntax: `<include>``</include>`
## <a href="" id="bkmk-exclude"></a>&lt;exclude&gt; ## <a href="" id="bkmk-exclude"></a>&lt;exclude&gt;
This element specifies that its required child, *&lt;pattern&gt;*, should be excluded from the migration. This element specifies that its required child, *&lt;pattern&gt;*, should be excluded from the migration.
Syntax: `<exclude>`` </exclude>` Syntax: `<exclude>`` </exclude>`
## <a href="" id="bkmk-sampleconfigxjmlfile"></a>Sample Config.xml File ## <a href="" id="bkmk-sampleconfigxjmlfile"></a>Sample Config.xml File
Refer to the following sample Config.xml file for additional details about items you can choose to exclude from a migration. Refer to the following sample Config.xml file for additional details about items you can choose to exclude from a migration.
```xml ```xml
@ -577,14 +464,4 @@ Refer to the following sample Config.xml file for additional details about items
## Related topics ## Related topics
[USMT XML Reference](usmt-xml-reference.md) [USMT XML Reference](usmt-xml-reference.md)

321
windows/deployment/usmt/usmt-conflicts-and-precedence.md
View File

@ -16,7 +16,6 @@ ms.topic: article
# Conflicts and Precedence # Conflicts and Precedence
When you include, exclude, and reroute files and settings, it is important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind. When you include, exclude, and reroute files and settings, it is important to know how User State Migration Tool (USMT) 10.0 deals with conflicts and precedence. When working with USMT, the following are the most important conflicts and precedence guidelines to keep in mind.
- **If there are conflicting rules within a component, the most specific rule is applied.** However, the &lt;unconditionalExclude&gt; rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#bkmk1) and the first example in [Include and exclude precedence examples](#precexamples)****later in this topic. - **If there are conflicting rules within a component, the most specific rule is applied.** However, the &lt;unconditionalExclude&gt; rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions. For examples, see [What happens when there are conflicting include and exclude rules?](#bkmk1) and the first example in [Include and exclude precedence examples](#precexamples)****later in this topic.
@ -33,7 +32,6 @@ When you include, exclude, and reroute files and settings, it is important to kn
## In this topic ## In this topic
**General** **General**
- [What is the relationship between rules that are located within different components?](#bkmk2) - [What is the relationship between rules that are located within different components?](#bkmk2)
@ -60,7 +58,6 @@ When you include, exclude, and reroute files and settings, it is important to kn
## General ## General
### <a href="" id="bkmk2"></a>What is the relationship between rules that are located within different components? ### <a href="" id="bkmk2"></a>What is the relationship between rules that are located within different components?
Only rules inside the same component can affect each other, depending on specificity, except for the &lt;unconditionalExclude&gt; rule. Rules that are in different components do not affect each other. If there is an &lt;include&gt; rule in one component and an identical &lt;exclude&gt; rule in another component, the data will be migrated because the two rules are independent of each other. Only rules inside the same component can affect each other, depending on specificity, except for the &lt;unconditionalExclude&gt; rule. Rules that are in different components do not affect each other. If there is an &lt;include&gt; rule in one component and an identical &lt;exclude&gt; rule in another component, the data will be migrated because the two rules are independent of each other.
@ -129,7 +126,6 @@ USMT does not distinguish the .xml files based on their name or content. It proc
## <a href="" id="the--include--and--exclude--rules"></a>The &lt;include&gt; and &lt;exclude&gt; rules ## <a href="" id="the--include--and--exclude--rules"></a>The &lt;include&gt; and &lt;exclude&gt; rules
### <a href="" id="bkmk1"></a>What happens when there are conflicting &lt;include&gt; and &lt;exclude&gt; rules? ### <a href="" id="bkmk1"></a>What happens when there are conflicting &lt;include&gt; and &lt;exclude&gt; rules?
If there are conflicting rules within a component, the most specific rule is applied, except with the &lt;unconditionalExclude&gt; rule, which takes precedence over all other rules. If the rules are equally specific, then the data will be not be migrated. For example if you exclude a file, and include the same file, the file will not be migrated. If there are conflicting rules within different components, the rules do not affect each other because each component is processed independently. If there are conflicting rules within a component, the most specific rule is applied, except with the &lt;unconditionalExclude&gt; rule, which takes precedence over all other rules. If the rules are equally specific, then the data will be not be migrated. For example if you exclude a file, and include the same file, the file will not be migrated. If there are conflicting rules within different components, the rules do not affect each other because each component is processed independently.
@ -159,212 +155,35 @@ These examples explain how USMT deals with &lt;include&gt; and &lt;exclude&gt; r
### <a href="" id="filesex"></a>Including and excluding files ### <a href="" id="filesex"></a>Including and excluding files
<table> | If you have the following code in the same component | Resulting behavior | Explanation |
<colgroup> |-----|-----|-----|
<col width="33%" /> | <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:* [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in Dir1 (including all .txt files in C:). | The &lt;exclude&gt; rule does not affect the migration because the &lt;include&gt; rule is more specific. |
<col width="33%" /> | <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders. | Both rules are processed as intended. |
<col width="33%" /> | <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\ * [.txt]&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
</colgroup> | <ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> | Nothing will be migrated. | The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule. |
<thead> | <ul><li>Include rule: C:\Dir1* [.txt]</li><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> | Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2. <br/>No files are migrated from Dir2 or its subfolders. | Both rules are processed as intended. |
<tr class="header"> | <ul><li>Include rule: C:\Dir1\Dir2* []</li><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2). | Both rules are processed as intended. |
<th align="left">If you have the following code in the same component</th>
<th align="left">Resulting behavior</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* [<em>]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:* [</em>.txt]&lt;/pattern&gt;</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders in Dir1 (including all .txt files in C:).</p></td>
<td align="left"><p>The &lt;exclude&gt; rule does not affect the migration because the &lt;include&gt; rule is more specific.</p></td>
</tr>
<tr class="even">
<td align="left"><ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* [<em>]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [</em>.txt]&lt;/pattern&gt;</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1\Dir2 and its subfolders.</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
<tr class="odd">
<td align="left"><ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* [<em>]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\ * [</em>.txt]&lt;/pattern&gt;</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders in C:\Dir1, except the .txt files in C:\Dir1 and its subfolders.</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
<tr class="even">
<td align="left"><ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [<em>.txt]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [</em>.txt]&lt;/pattern&gt;</p></li>
</ul></td>
<td align="left"><p>Nothing will be migrated.</p></td>
<td align="left"><p>The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule.</p></td>
</tr>
<tr class="odd">
<td align="left"><ul>
<li><p>Include rule: C:\Dir1* [<em>.txt]</p></li>
<li><p>Exclude rule: C:\Dir1\Dir2* [</em>]</p></li>
</ul></td>
<td align="left"><p>Migrates the .txt files in Dir1 and the .txt files from subfolders other than Dir2.</p>
<p>No files are migrated from Dir2 or its subfolders.</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
<tr class="even">
<td align="left"><ul>
<li><p>Include rule: C:\Dir1\Dir2* [<em>]</p></li>
<li><p>Exclude rule: C:\Dir1* [</em>.txt]</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders of Dir2, except the .txt files from Dir1 and any subfolders of Dir1 (including Dir2).</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
</tbody>
</table>
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|----|----|
<table> | Component 1:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li></ul> <br/>Component 2:<ul><li>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [.txt]&lt;/pattern&gt;</li><li>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* []&lt;/pattern&gt;</li></ul> | Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2). | Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed. |
<colgroup> | Component 1:<ul><li>Include rule: C:\Dir1\Dir2* []</li></ul> <br/>Component 2:<ul><li>Exclude rule: C:\Dir1* [.txt]</li></ul> | Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders. | Both rules are processed as intended. |
<col width="33%" /> | Component 1:<ul><li>Exclude rule: C:\Dir1\Dir2* []</li></ul> <br/>Component 2:<ul><li>Include rule: C:\Dir1* [.txt]</li></ul> | Migrates all .txt files in Dir1 and any subfolders. | Component 1 does not contain an &lt;include&gt; rule, so the &lt;exclude&gt; rule is not processed. |
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">If you have the following code in different components</th>
<th align="left">Resulting behavior</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Component 1:</p>
<ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* [<em>]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [</em>.txt]&lt;/pattern&gt;</p></li>
</ul>
<p>Component 2:</p>
<ul>
<li><p>Include rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1\Dir2* [<em>.txt]&lt;/pattern&gt;</p></li>
<li><p>Exclude rule: &lt;pattern type=&quot;File&quot;&gt;C:\Dir1* [</em>]&lt;/pattern&gt;</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders of C:\Dir1\ (including C:\Dir1\Dir2).</p></td>
<td align="left"><p>Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, although some .txt files were excluded when Component 1 was processed, they were included when Component 2 was processed.</p></td>
</tr>
<tr class="even">
<td align="left"><p>Component 1:</p>
<ul>
<li><p>Include rule: C:\Dir1\Dir2* [<em>]</p></li>
</ul>
<p>Component 2:</p>
<ul>
<li><p>Exclude rule: C:\Dir1* [</em>.txt]</p></li>
</ul></td>
<td align="left"><p>Migrates all files and subfolders from Dir2 except the .txt files in C:\Dir1 and its subfolders.</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Component 1:</p>
<ul>
<li><p>Exclude rule: C:\Dir1\Dir2* [<em>]</p></li>
</ul>
<p>Component 2:</p>
<ul>
<li><p>Include rule: C:\Dir1* [</em>.txt]</p></li>
</ul></td>
<td align="left"><p>Migrates all .txt files in Dir1 and any subfolders.</p></td>
<td align="left"><p>Component 1 does not contain an &lt;include&gt; rule, so the &lt;exclude&gt; rule is not processed.</p></td>
</tr>
</tbody>
</table>
### <a href="" id="regex"></a>Including and excluding registry objects ### <a href="" id="regex"></a>Including and excluding registry objects
<table> | If you have the following code in the same component | Resulting behavior | Explanation |
<colgroup> |-----|-----|-----|
<col width="33%" /> | <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude Rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor. | Both rules are processed as intended. |
<col width="33%" /> | <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude Rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> | Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor. | DefaultColor is migrated because the &lt;include&gt; rule is more specific than the &lt;exclude&gt; rule. |
<col width="33%" /> | <ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Does not migrate DefaultColor. | The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule. |
</colgroup>
<thead>
<tr class="header">
<th align="left">If you have the following code in the same component</th>
<th align="left">Resulting behavior</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><ul>
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor* [<em>]</p></li>
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
</ul></td>
<td align="left"><p>Migrates all keys in HKLM\Software\Microsoft\Command Processor except DefaultColor.</p></td>
<td align="left"><p>Both rules are processed as intended.</p></td>
</tr>
<tr class="even">
<td align="left"><ul>
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
<li><p>Exclude Rule: HKLM\Software\Microsoft\Command Processor* [</em>]</p></li>
</ul></td>
<td align="left"><p>Migrates only DefaultColor in HKLM\Software\Microsoft\Command Processor.</p></td>
<td align="left"><p>DefaultColor is migrated because the &lt;include&gt; rule is more specific than the &lt;exclude&gt; rule.</p></td>
</tr>
<tr class="odd">
<td align="left"><ul>
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
</ul></td>
<td align="left"><p>Does not migrate DefaultColor.</p></td>
<td align="left"><p>The rules are equally specific, so the &lt;exclude&gt; rule takes precedence over the &lt;include&gt; rule.</p></td>
</tr>
</tbody>
</table>
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|-----|-----|
<table> | Component 1:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li></ul> <br/>Component 2:<ul><li>Include rule: <br/>HKLM\Software\Microsoft\Command Processor* []</li><li>Exclude rule: <br/>HKLM\Software\Microsoft\Command Processor [DefaultColor]</li></ul> | Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor. | Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed. |
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">If you have the following code in different components</th>
<th align="left">Resulting behavior</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Component 1:</p>
<ul>
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor* [<em>]</p></li>
</ul>
<p>Component 2:</p>
<ul>
<li><p>Include rule: HKLM\Software\Microsoft\Command Processor* [</em>]</p></li>
<li><p>Exclude rule: HKLM\Software\Microsoft\Command Processor [DefaultColor]</p></li>
</ul></td>
<td align="left"><p>Migrates all the keys/values under HKLM\Software\Microsoft\Command Processor.</p></td>
<td align="left"><p>Rules that are in different components do not affect each other, except for the &lt;unconditionalExclude&gt; rule. Therefore, in this example, the objects that were excluded when Component 1 was processed were included when Component 2 was processed.</p></td>
</tr>
</tbody>
</table>
## File collisions ## File collisions
### <a href="" id="collisions"></a>What is the default behavior when there are file collisions? ### <a href="" id="collisions"></a>What is the default behavior when there are file collisions?
If there is not a &lt;merge&gt; rule, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally: for example, OriginalFileName(1).OriginalExtension, OriginalFileName(2).OriginalExtension, and so on. If there is not a &lt;merge&gt; rule, the default behavior for the registry is for the source to overwrite the destination. The default behavior for files is for the source to be renamed incrementally: for example, OriginalFileName(1).OriginalExtension, OriginalFileName(2).OriginalExtension, and so on.
@ -399,67 +218,49 @@ You have a custom .xml file that contains the following code:
</include> </include>
``` ```
For this example, the following table describes the resulting behavior if you add the code in the first column to your custom .xml file. For this example, the following information describes the resulting behavior if you add the code to your custom .xml file.
<table> **Example 1**
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">If you specify the following code</th>
<th align="left">Resulting behavior</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;merge script=&quot;MigXmlHelper.DestinationPriority()&quot;&gt;
&lt;objectSet&gt;
&lt;pattern type=&quot;File&quot;&gt;c:\data* [<em>]&lt;/pattern&gt;
&lt;/objectSet&gt;
&lt;/merge&gt;</code></pre></td>
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
<p>During LoadState, only C:\Data\SampleA.txt will be restored.</p></td>
</tr>
<tr class="even">
<td align="left"><pre class="syntax"><code>&lt;merge script=&quot;MigXmlHelper.SourcePriority()&quot;&gt;
&lt;objectSet&gt;
&lt;pattern type=&quot;File&quot;&gt;c:\data* [</em>]&lt;/pattern&gt;
&lt;/objectSet&gt;
&lt;/merge&gt; </code></pre></td>
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
<p>During LoadState, all the files will be restored, overwriting the existing files on the destination computer.</p></td>
</tr>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;merge script=&quot;MigXmlHelper.SourcePriority()&quot;&gt;
&lt;objectSet&gt;
&lt;pattern type=&quot;File&quot;&gt;c:\data\ [*]&lt;/pattern&gt;
&lt;/objectSet&gt;
&lt;/merge&gt; </code></pre></td>
<td align="left"><p>During ScanState, all the files will be added to the store.</p>
<p>During LoadState, the following will occur:</p>
<ul>
<li><p>C:\Data\SampleA.txt will be restored.</p></li>
<li><p>C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer.</p></li>
<li><p>C:\Data\Folder\SampleB.txt will not be restored.</p></li>
</ul></td>
</tr>
</tbody>
</table>
```xml
<merge script="MigXmlHelper.DestinationPriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, only C:\Data\SampleA.txt will be restored.
**Example 2**
```xml
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data* []</pattern>
</objectSet>
</merge>
```
**Result**: During ScanState, all the files will be added to the store.
During LoadState, all the files will be restored, overwriting the existing files on the destination computer.
**Example 3**
```xml
<merge script="MigXmlHelper.SourcePriority()">
<objectSet>
<pattern type="File">c:\data\ [*]</pattern>
</objectSet>
</merge>
```
**Result**: During ScanState, all the files will be added to the store. During LoadState, the following will occur:
- C:\Data\SampleA.txt will be restored.
- C:\Data\SampleB.txt will be restored, overwriting the existing file on the destination computer.
- C:\Data\Folder\SampleB.txt will not be restored.
## Related topics ## Related topics
[USMT XML Reference](usmt-xml-reference.md) [USMT XML Reference](usmt-xml-reference.md)

134
windows/deployment/usmt/usmt-custom-xml-examples.md
View File

@ -15,26 +15,8 @@ ms.topic: article
# Custom XML Examples # Custom XML Examples
**Note**  
Because the tables in this topic are wide, you may need to adjust the width of its window.
## In This Topic:
- [Example 1: Migrating an Unsupported Application](#example)
- [Example 2: Migrating the My Videos Folder](#example2)
- [Example 3: Migrating Files and Registry Keys](#example3)
- [Example 4: Migrating Specific Folders from Various Locations](#example4)
## <a href="" id="example"></a>Example 1: Migrating an Unsupported Application ## <a href="" id="example"></a>Example 1: Migrating an Unsupported Application
The following is a template for the sections that you need to migrate your application. The template is not functional on its own, but you can use it to write your own .xml file. The following is a template for the sections that you need to migrate your application. The template is not functional on its own, but you can use it to write your own .xml file.
``` xml ``` xml
@ -103,37 +85,23 @@ The following is a template for the sections that you need to migrate your appli
## <a href="" id="example2"></a>Example 2: Migrating the My Videos Folder ## <a href="" id="example2"></a>Example 2: Migrating the My Videos Folder
The following sample is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer.
The following is a custom .xml file named CustomFile.xml that migrates My Videos for all users, if the folder exists on the source computer. - **Sample condition**: Verifies that My Videos exists on the source computer:
<table> `<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>`
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Code</th>
<th align="left">Behavior</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;condition&gt;MigXmlHelper.DoesObjectExist(&quot;File&quot;,&quot;%CSIDL_MYVIDEO%&quot;)&lt;/condition&gt;</code></pre></td>
<td align="left"><p>Verifies that My Videos exists on the source computer.</p></td>
</tr>
<tr class="even">
<td align="left"><pre class="syntax"><code>&lt;include filter=&#39;MigXmlHelper.IgnoreIrrelevantLinks()&#39;&gt;</code></pre></td>
<td align="left"><p>Filters out the shortcuts in My Videos that do not resolve on the destination computer. This has no effect on files that are not shortcuts. For example, if there is a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.</p></td>
</tr>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;%CSIDL_MYVIDEO%* [*]&lt;/pattern&gt;</code></pre></td>
<td align="left"><p>Migrates My Videos for all users.</p></td>
</tr>
</tbody>
</table>
- **Sample filter**: Filters out the shortcuts in My Videos that do not resolve on the destination computer:
`<include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>`
This has no effect on files that are not shortcuts. For example, if there is a shortcut in My Videos on the source computer that points to C:\Folder1, that shortcut will be migrated only if C:\Folder1 exists on the destination computer. However, all other files, such as .mp3 files, migrate without any filtering.
- **Sample pattern**: Migrates My Videos for all users:
`<pattern type="File">%CSIDL_MYVIDEO%* [*]</pattern>`
**XML file**
```xml ```xml
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
@ -160,41 +128,25 @@ The following is a custom .xml file named CustomFile.xml that migrates My Videos
## <a href="" id="example3"></a>Example 3: Migrating Files and Registry Keys ## <a href="" id="example3"></a>Example 3: Migrating Files and Registry Keys
The sample patterns describe the behavior in the following example .xml file.
This table describes the behavior in the following example .xml file. - **Sample pattern**: Migrates all instances of the file Usmttestfile.txt from all sub-directories under `%ProgramFiles%\USMTTestFolder`:
<table> `<pattern type="File">%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]</pattern>`
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Code</th>
<th align="left">Behavior</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]&lt;/pattern&gt;</code></pre></td>
<td align="left"><p>Migrates all instances of the file Usmttestfile.txt from all sub-directories under %ProgramFiles%\USMTTestFolder.</p></td>
</tr>
<tr class="even">
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;File&quot;&gt;%ProgramFiles%\USMTDIRTestFolder* [<em>]&lt;/pattern&gt;</code></pre></td>
<td align="left"><p>Migrates the whole directory under %ProgramFiles%\USMTDIRTestFolder.</p></td>
</tr>
<tr class="odd">
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;Registry&quot;&gt;HKCU\Software\USMTTESTKEY* [MyKey]&lt;/pattern&gt;</code></pre></td>
<td align="left"><p>Migrates all instances of MyKey under HKCU\Software\USMTTESTKEY.</p></td>
</tr>
<tr class="even">
<td align="left"><pre class="syntax"><code>&lt;pattern type=&quot;Registry&quot;&gt;HKLM\Software\USMTTESTKEY* [</em>]&lt;/pattern&gt;</code></pre></td>
<td align="left"><p>Migrates the entire registry hive under HKLM\Software\USMTTESTKEY.</p></td>
</tr>
</tbody>
</table>
- **Sample pattern**: Migrates the whole directory under `%ProgramFiles%\USMTDIRTestFolder`:
`<pattern type="File">%ProgramFiles%\USMTDIRTestFolder* []</pattern>`
- **Sample pattern**: Migrates all instances of MyKey under `HKCU\Software\USMTTESTKEY`:
`<pattern type="Registry">HKCU\Software\USMTTESTKEY* [MyKey]</pattern>`
- **Sample pattern**: Migrates the entire registry hive under `HKLM\Software\USMTTESTKEY`:
`<pattern type="Registry">HKLM\Software\USMTTESTKEY* []</pattern>`
**XML file**
``` xml ``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/testfilemig"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/testfilemig">
@ -230,7 +182,7 @@ This table describes the behavior in the following example .xml file.
## <a href="" id="example4"></a>Example 4: Migrating Specific Folders from Various Locations ## <a href="" id="example4"></a>Example 4: Migrating Specific Folders from Various Locations
The behavior for this custom .xml file is described within the &lt;`displayName`&gt; tags in the code. The behavior for this custom .xml file is described within the `<displayName>` tags in the code.
``` xml ``` xml
<migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test"> <migration urlid="http://www.microsoft.com/migration/1.0/migxmlext/test">
@ -257,12 +209,12 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
<displayName>Component to migrate all user documents except Sample.doc</displayName> <displayName>Component to migrate all user documents except Sample.doc</displayName>
<role role="Data"> <role role="Data">
<rules> <rules>
<include> <include>
<objectSet> <objectSet>
<pattern type="File"> C:\UserDocuments\* [*]</pattern> <pattern type="File"> C:\UserDocuments\* [*]</pattern>
</objectSet> </objectSet>
</include> </include>
<exclude> <exclude>
<objectSet> <objectSet>
<pattern type="File"> C:\UserDocuments\ [Sample.doc]</pattern> <pattern type="File"> C:\UserDocuments\ [Sample.doc]</pattern>
</objectSet> </objectSet>
@ -277,9 +229,9 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
<rules> <rules>
<include> <include>
<objectSet> <objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("\Requests\* [*] ", "Fixed")</script> <script>MigXmlHelper.GenerateDrivePatterns ("\Requests\* [*] ", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("*\Requests\* [*] ", "Fixed")</script> <script>MigXmlHelper.GenerateDrivePatterns ("*\Requests\* [*] ", "Fixed")</script>
</objectSet> </objectSet>
</include> </include>
</rules> </rules>
</role> </role>
@ -291,8 +243,8 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
<rules> <rules>
<include> <include>
<objectSet> <objectSet>
<pattern type="File"> C:\*\Presentations\* [*]</pattern> <pattern type="File"> C:\*\Presentations\* [*]</pattern>
<pattern type="File"> C:\Presentations\* [*]</pattern> <pattern type="File"> C:\Presentations\* [*]</pattern>
</objectSet> </objectSet>
</include> </include>
</rules> </rules>
@ -303,16 +255,6 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
## Related topics ## Related topics
[USMT XML Reference](usmt-xml-reference.md) [USMT XML Reference](usmt-xml-reference.md)
[Customize USMT XML Files](usmt-customize-xml-files.md) [Customize USMT XML Files](usmt-customize-xml-files.md)

30
windows/deployment/usmt/usmt-determine-what-to-migrate.md
View File

@ -24,30 +24,12 @@ To reduce complexity and increase standardization, your organization should cons
## In This Section ## In This Section
<table> | Link | Description |
<colgroup> |--- |--- |
<col width="50%" /> |[Identify Users](usmt-identify-users.md)|Use command-line options to specify which users to migrate and how they should be migrated.|
<col width="50%" /> |[Identify Applications Settings](usmt-identify-application-settings.md)|Determine which applications you want to migrate and prepare a list of application settings to be migrated.|
</colgroup> |[Identify Operating System Settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.|
<tbody> |[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)|Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.|
<tr class="odd">
<td align="left"><p><a href="usmt-identify-users.md" data-raw-source="[Identify Users](usmt-identify-users.md)">Identify Users</a></p></td>
<td align="left"><p>Use command-line options to specify which users to migrate and how they should be migrated.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-application-settings.md" data-raw-source="[Identify Applications Settings](usmt-identify-application-settings.md)">Identify Applications Settings</a></p></td>
<td align="left"><p>Determine which applications you want to migrate and prepare a list of application settings to be migrated.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-identify-operating-system-settings.md" data-raw-source="[Identify Operating System Settings](usmt-identify-operating-system-settings.md)">Identify Operating System Settings</a></p></td>
<td align="left"><p>Use migration to create a new standard environment on each of the destination computers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-identify-file-types-files-and-folders.md" data-raw-source="[Identify File Types, Files, and Folders](usmt-identify-file-types-files-and-folders.md)">Identify File Types, Files, and Folders</a></p></td>
<td align="left"><p>Determine and locate the standard, company-specified, and non-standard locations of the file types, files, folders, and settings that you want to migrate.</p></td>
</tr>
</tbody>
</table>
## Related topics ## Related topics

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

@ -16,12 +16,10 @@ ms.topic: article
# Hard-Link Migration Store # Hard-Link Migration Store
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs, and enables entirely new migration scenarios.
A *hard-link migration store* enables you to perform an in-place migration where all user state is maintained on the computer while the old operating system is removed and the new operating system is installed; this is why it is best suited for the computer-refresh scenario. Use of a hard-link migration store for a computer-refresh scenario drastically improves migration performance and significantly reduces hard-disk utilization, reduces deployment costs and enables entirely new migration scenarios.
## In this topic ## In this topic
[When to Use a Hard-Link Migration](#bkmk-when) [When to Use a Hard-Link Migration](#bkmk-when)
[Understanding a Hard-Link Migration](#bkmk-understandhardlinkmig) [Understanding a Hard-Link Migration](#bkmk-understandhardlinkmig)
@ -46,7 +44,6 @@ A *hard-link migration store* enables you to perform an in-place migration where
## <a href="" id="bkmk-when"></a>When to Use a Hard-Link Migration ## <a href="" id="bkmk-when"></a>When to Use a Hard-Link Migration
You can use a hard-link migration store when your planned migration meets both of the following criteria: You can use a hard-link migration store when your planned migration meets both of the following criteria:
- You are upgrading the operating system on existing hardware rather than migrating to new computers. - You are upgrading the operating system on existing hardware rather than migrating to new computers.
@ -57,32 +54,27 @@ You cannot use a hard-link migration store if your planned migration includes an
- You are migrating data from one computer to a second computer. - You are migrating data from one computer to a second computer.
- You are migrating data from one volume on a computer to another volume, for example from C: to D:. - You are migrating data from one volume on a computer to another volume, for example from `C:` to `D:`.
- You are formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store. - You are formatting or repartitioning the disk outside of Windows Setup, or specifying a disk format or repartition during Windows Setup that will remove the migration store.
## <a href="" id="bkmk-understandhardlinkmig"></a>Understanding a Hard-Link Migration ## <a href="" id="bkmk-understandhardlinkmig"></a>Understanding a Hard-Link Migration
The hard-link migration store is created using the command-line option, **/hardlink**, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario. The hard-link migration store is created using the command-line option, **/hardlink**, and is equivalent to other migration-store types. However, it differs in that hard links are utilized to keep files stored on the source computer during the migration. Keeping the files in place on the source computer eliminates the redundant work of duplicating files. It also enables the performance benefits and reduction in disk utilization that define this scenario.
When you create a hard link, you give an existing file an additional path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These are two paths to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file. When you create a hard link, you give an existing file an additional path. For instance, you could create a hard link to c:\\file1.txt called c:\\hard link\\myFile.txt. These are two paths to the same file. If you open c:\\file1.txt, make changes, and save the file, you will see those changes when you open c:\\hard link\\myFile.txt. If you delete c:\\file1.txt, the file still exists on your computer as c:\\hardlink\\myFile.txt. You must delete both references to the file in order to delete the file.
**Note**   > [!NOTE]
A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario. > A hard link can only be created for a file on the same volume. If you copy a hard-link migration store to another drive or external device, the files, and not the links, are copied, as in a non-compressed migration-store scenario.
For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
For more information about hard links, please 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 is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows&reg; Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place. In most aspects, a hard-link migration store is identical to an uncompressed migration store. It is located where specified by the Scanstate command-line tool and you can view the contents of the store by using Windows&reg; Explorer. Once created, it can be deleted or copied to another location without changing user state. Restoring a hard-link migration store is similar to restoring any other migration store; however, as with creating the store, the same hard-link functionality is used to keep files in-place.
As a best practice, we recommend 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 your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system. As a best practice, we recommend 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 your new installation of a Windows operating system, deleting the hard links in the migration store will only delete one path to the files and will not delete the actual files or the paths to them from your new operating system.
**Important**   > [!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 additional disk space being consumed or problems with some applications for the following reasons: Keeping the hard-link migration store can result in additional disk space being consumed or problems with some applications for the following reasons:
@ -92,22 +84,17 @@ Keeping the hard-link migration store can result in additional disk space being
- Editing the file by using different paths simultaneously may result in data corruption. - Editing the file by using different paths simultaneously may result in data corruption.
**Important**   > [!IMPORTANT]
The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links. > The read-only file attribute on migrated files is lost when the hard-link migration store is deleted. This is due to a limitation in NTFS file system hard links.
## <a href="" id="bkmk-scenario"></a>Hard-Link Migration Scenario ## <a href="" id="bkmk-scenario"></a>Hard-Link Migration Scenario
For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated. For example, a company has decided to deploy Windows 10 on all of their computers. Each employee will keep the same computer, but the operating system on each computer will be updated.
1. An administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink** command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances. 1. An administrator runs the ScanState command-line tool on each computer, specifying the **/hardlink** command-line option. The ScanState tool saves the user state to a hard-link migration store on each computer, improving performance by reducing file duplication, except in certain specific instances.
**Note**   > [!NOTE]
As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with Loadstate. > As a best practice, we recommend that you do not create your hard-link migration store until just before you perform the migration in order to migrate the latest versions of your files. You should not use your software applications on the computer after creating the migration store until you have finished migrating your files with Loadstate.
2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses. 2. On each computer, an administrator installs the company's standard operating environment (SOE), which includes Windows 7 and other applications the company currently uses.
@ -115,19 +102,18 @@ For example, a company has decided to deploy Windows 10 on all of their compute
> [!NOTE] > [!NOTE]
> During the update of a domain-joined computer, the profiles of users whose SID cannot be resolved will not be migrated. When using a hard-link migration store, it could cause a data loss. > During the update of a domain-joined computer, the profiles of users whose SID cannot be resolved will not be migrated. When using a hard-link migration store, it could cause a data loss.
## <a href="" id="bkmk-hardlinkstoredetails"></a>Hard-Link Migration Store Details
## <a href="" id="bkmk-hardlinkstoredetails"></a>Hard-Link Migration Store Details
This section provides details about hard-link migration stores. This section provides details about hard-link migration stores.
### <a href="" id="bkmk-harddiskspace"></a>Hard Disk Space ### <a href="" id="bkmk-harddiskspace"></a>Hard Disk Space
The **/hardlink** command-line option proceeds with creating the migration store only if there is 250 megabytes (MB) of free space on the hard disk. Provided that every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration. The **/hardlink** command-line option proceeds with creating the migration store only if there are 250 megabytes (MB) of free space on the hard disk. If every volume involved in the migration is formatted as NTFS, 250 MB should be enough space to ensure success for almost every hard-link migration, regardless on the size of the migration.
### <a href="" id="bkmk-hardlinkstoresizeest"></a>Hard-Link Store Size Estimation ### <a href="" id="bkmk-hardlinkstoresizeest"></a>Hard-Link Store Size Estimation
It is not 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 very 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 quite 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 is not 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.
### <a href="" id="bkmk-migstoremultvolumes"></a>Migration Store Path on Multiple Volumes ### <a href="" id="bkmk-migstoremultvolumes"></a>Migration Store Path on Multiple Volumes
@ -161,57 +147,27 @@ Files that are locked by an application or the operating system are handled diff
Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \\Windows directory, which minimizes performance-related issues. Files that are locked by the operating system cannot remain in place and must be copied into the hard-link migration store. As a result, selecting many operating-system files for migration significantly reduces performance during a hard-link migration. As a best practice, we recommend that you do not migrate any files out of the \\Windows directory, which minimizes performance-related issues.
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 is not being utilized. The volume shadow-copy service cannot be used in conjunction with hard-link migrations. However, by modifying the new **&lt;HardLinkStoreControl&gt;** section in the Config.xml file, it is possible to enable the migration of files locked by an application. 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 is not being utilized. The volume shadow-copy service cannot be used with hard-link migrations. However, by modifying the new `<HardLinkStoreControl>` section in the Config.xml file, it is possible to enable the migration of files locked by an application.
**Important**   > [!IMPORTANT]
There are some scenarios in which modifying the **&lt;HardLinkStoreControl&gt;** section in the Config.xml file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use USMTutils.exe to schedule the migration store for deletion on the next restart. > There are some scenarios in which modifying the `<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.
## <a href="" id="bkmk-xmlelementsinconfig"></a>XML Elements in the Config.xml File ## <a href="" id="bkmk-xmlelementsinconfig"></a>XML Elements in the Config.xml File
A new section in the Config.xml file allows optional configuration of some of the hard-link migration behavior introduced with the **/HardLink** option. A new section in the Config.xml file allows optional configuration of some of the hard-link migration behavior introduced with the **/HardLink** option.
<table> | Element | Description |
<colgroup> |--- |--- |
<col width="50%" /> | `<Policies>` | This element contains elements that describe the policies that USMT follows while creating a migration store. |
<col width="50%" /> | `<HardLinkStoreControl>` | This element contains elements that describe how to handle files during the creation of a hard link migration store. |
</colgroup> | `<fileLocked>` | This element contains elements that describe how to handle files that are locked for editing. |
<tbody> | `<createHardLink>` | This element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application. <br/><br/>Syntax: `<createHardLink>` [pattern] `</createHardLink>` |
<tr class="odd"> | `<errorHardLink>` | This element defines a standard MigXML pattern that describes file paths where hard links should not be created, if the file is locked for editing by another application. <br/><br/>`<errorHardLink>` [pattern] `</errorHardLink>` |
<td align="left"><p><strong>&lt;Policies&gt;</strong></p></td>
<td align="left"><p>This element contains elements that describe the policies that USMT follows while creating a migration store.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>&lt;HardLinkStoreControl&gt;</strong></p></td>
<td align="left"><p>This element contains elements that describe how to handle files during the creation of a hard link migration store.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>&lt;fileLocked&gt;</strong></p></td>
<td align="left"><p>This element contains elements that describe how to handle files that are locked for editing.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>&lt;createHardLink&gt;</strong></p></td>
<td align="left"><p>This element defines a standard MigXML pattern that describes file paths where hard links should be created, even if the file is locked for editing by another application.</p>
<p>Syntax: &lt;createHardLink&gt; [pattern] &lt;/createHardLink&gt;</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>&lt;errorHardLink&gt;</strong></p></td>
<td align="left"><p>This element defines a standard MigXML pattern that describes file paths where hard links should not be created, if the file is locked for editing by another application.</p>
<p>&lt;errorHardLink&gt; [pattern] &lt;/errorHardLink&gt;</p></td>
</tr>
</tbody>
</table>
> [!IMPORTANT]
> You must use the **/nocompress** option with the **/HardLink** option.
**Important**   The following XML sample specifies that files locked by an application under the \\Users directory can remain in place during the migration. It also specifies that locked files that are not located in the \\Users directory should result in the **File in Use** error. It is important to exercise caution when specifying the paths using the **File in Use`<createhardlink>`** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
You must use the **/nocompress** option with the **/HardLink** option.
The following XML sample specifies that files locked by an application under the \\Users directory can remain in place during the migration. It also specifies that locked files that are not located in the \\Users directory should result in the **File in Use** error. It is important to exercise caution when specifying the paths using the **File in Use&lt;createhardlink&gt;** tag in order to minimize scenarios that make the hard-link migration store more difficult to delete.
``` xml ``` xml
<Policies> <Policies>
@ -226,8 +182,4 @@ The following XML sample specifies that files locked by an application under the
## Related topics ## Related topics
[Plan Your Migration](usmt-plan-your-migration.md) [Plan Your Migration](usmt-plan-your-migration.md)

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

@ -16,29 +16,10 @@ ms.topic: article
# LoadState Syntax # LoadState Syntax
This topic discusses the **LoadState** command syntax and options available with it. This topic discusses the **LoadState** command syntax and options available with it.
## In this topic
[Before You Begin](#before)
[Syntax](#bkmk-s)
[Storage Options](#bkmk-st)
[Migration Rule Options](#bkmk-mig)
[Monitoring Options](#bkmk-mon)
[User Options](#bkmk-user)
[Incompatible Command-Line Options](#bkmk-cloi)
## <a href="" id="before"></a>Before You Begin ## <a href="" id="before"></a>Before You Begin
Before you run the **LoadState** command, note the following: Before you run the **LoadState** command, note the following:
- To ensure that all operating system settings migrate, we recommend that you run the **LoadState** commands in administrator mode from an account with administrative credentials. - To ensure that all operating system settings migrate, we recommend that you run the **LoadState** commands in administrator mode from an account with administrative credentials.
@ -55,7 +36,6 @@ Before you run the **LoadState** command, note the following:
## <a href="" id="bkmk-s"></a>Syntax ## <a href="" id="bkmk-s"></a>Syntax
This section explains the syntax and usage of the command-line options available when you use the **LoadState** command. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator. This section explains the syntax and usage of the command-line options available when you use the **LoadState** command. The options can be specified in any order. If the option contains a parameter, you can specify either a colon or space separator.
The **LoadState** command's syntax is: The **LoadState** command's syntax is:
@ -71,390 +51,66 @@ For example, to decrypt the store and migrate the files and settings to a comput
USMT provides the following options that you can use to specify how and where the migrated data is stored. USMT provides the following options that you can use to specify how and where the migrated data is stored.
<table> | Command-Line Option | Description |
<colgroup> |--- |--- |
<col width="50%" /> | `StorePath` | Indicates the folder where the files and settings data are stored. You must specify *StorePath* when using the **LoadState** command. You cannot specify more than one *StorePath*. |
<col width="50%" /> | `/decrypt /key`:*KeyString* <br/>or <br/>`/decrypt /key`:"*Key String*" <br/>or <br/>`/decrypt /keyfile`:[*Path*]*FileName* | Decrypts the store with the specified key. With this option, you will need to specify the encryption key in one of the following ways:<ul><li>`/key:`*KeyString* specifies the encryption key. If there is a space in *KeyString*, you must surround the argument with quotation marks.</li><li>`/keyfile:`*FilePathAndName* specifies a text (.txt) file that contains the encryption key</li></ul> <br/>*KeyString* cannot exceed 256 characters. <br/>The `/key` and `/keyfile` options cannot be used on the same command line. <br/>The `/decrypt` and `/nocompress` options cannot be used on the same command line. <br/><div class="alert">**Important** <br/> Use caution with this option, because anyone who has access to the **LoadState** command-line script will also have access to the encryption key.</div> <br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey` |
</colgroup> | `/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). |
<thead> | `/hardlink` | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. |
<tr class="header"> | `/nocompress` | Specifies that the store is not compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option cannot be used with the `/decrypt` option. <br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress` |
<th align="left">Command-Line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><em>StorePath</em></p></td>
<td align="left"><p>Indicates the folder where the files and settings data are stored. You must specify <em>StorePath</em> when using the <strong>LoadState</strong> command. You cannot specify more than one <em>StorePath</em>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/decrypt</strong> <strong>/key</strong>:<em>KeyString</em></p>
<p>or</p>
<p><strong>/decrypt</strong> <strong>/key</strong>:&quot;<em>Key String</em>&quot;</p>
<p>or</p>
<p><strong>/decrypt</strong> <strong>/keyfile</strong>:[<em>Path&lt;/em&gt;]<em>FileName</em></p></td>
<td align="left"><p>Decrypts the store with the specified key. With this option, you will need to specify the encryption key in one of the following ways:</p>
<ul>
<li><p><strong>/key:</strong><em>KeyString</em> specifies the encryption key. If there is a space in <em>KeyString</em>, you must surround the argument with quotation marks.</p></li>
<li><p><strong>/keyfile:</strong><em>FilePathAndName</em> specifies a text (.txt) file that contains the encryption key</p></li>
</ul>
<p><em>KeyString</em> cannot exceed 256 characters.</p>
<p>The <strong>/key</strong> and <strong>/keyfile</strong> options cannot be used on the same command line.</p>
<p>The <strong>/decrypt</strong> and <strong>/nocompress</strong> options cannot be used on the same command line.</p>
<div class="alert">
<strong>Important</strong><br/><p>Use caution with this option, because anyone who has access to the <strong>LoadState</strong> command-line script will also have access to the encryption key.</p>
</div>
<div>
</div>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /decrypt /key:mykey</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/decrypt:</strong><em>&quot;encryption strength&quot;</em></p></td>
<td align="left"><p>The <strong>/decrypt</strong> 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 <a href="usmt-migration-store-encryption.md" data-raw-source="[Migration Store Encryption](usmt-migration-store-encryption.md)">Migration Store Encryption</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/hardlink</strong></p></td>
<td align="left"><p>Enables user-state data to be restored from a hard-link migration store. The <strong>/nocompress</strong> parameter must be specified with <strong>/hardlink</strong> option.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/nocompress</strong></p></td>
<td align="left"><p>Specifies that the store is not compressed. You should only use this option in testing environments. We recommend that you use a compressed store during your actual migration. This option cannot be used with the <strong>/decrypt</strong> option.</p>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /nocompress</code></p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-mig"></a>Migration Rule Options ## <a href="" id="bkmk-mig"></a>Migration Rule Options
USMT provides the following options to specify what files you want to migrate. USMT provides the following options to specify what files you want to migrate.
<table> | Command-Line Option | Description |
<colgroup> |--- |--- |
<col width="50%" /> | `/i`:[*Path*]*FileName* | **(include)** <br/>Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* must be located in the current directory. <br/><br/>For more information about which files to specify, see the &quot;XML files&quot; section of the [Frequently Asked Questions](usmt-faq.yml) topic. |
<col width="50%" /> | `/config:`[*Path*]*FileName* | Specifies the Config.xml file that the **LoadState** command should use. You cannot specify this option more than once on the command line. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the *FileName* must be located in the current directory. <br/><br/>This example migrates the files and settings based on the rules in the Config.xml, MigDocs.xml, and MigApp.xml files: <br/><br/>`loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log` |
</colgroup> | `/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`. |
<thead>
<tr class="header">
<th align="left">Command-Line Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/i</strong>:[<em>Path</em>]<em>FileName</em></p></td>
<td align="left"><p><strong>(include)</strong></p>
<p>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). <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> must be located in the current directory.</p>
<p>For more information about which files to specify, see the &quot;XML files&quot; section of the <a href="usmt-faq.yml" data-raw-source="[Frequently Asked Questions](usmt-faq.yml)">Frequently Asked Questions</a> topic.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/config:</strong>[<em>Path</em>]<em>FileName</em></p></td>
<td align="left"><p>Specifies the Config.xml file that the <strong>LoadState</strong> command should use. You cannot specify this option more than once on the command line. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then the <em>FileName</em> must be located in the current directory.</p>
<p>This example migrates the files and settings based on the rules in the Config.xml, MigDocs.xml, and MigApp.xml files:</p>
<p><code>loadstate \server\share\migration\mystore /config:config.xml /i:migdocs.xml /i:migapp.xml /v:5 /l:loadstate.log</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/auto:</strong><em>&quot;path to script files&quot;</em></p></td>
<td align="left"><p>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 <strong>/auto</strong> option has the same effect as using the following options: <strong>/i:MigDocs.xml</strong> <strong>/i:MigApp.xml /v:5</strong>.</p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-mon"></a>Monitoring Options ## <a href="" id="bkmk-mon"></a>Monitoring Options
USMT provides several command-line options that you can use to analyze problems that occur during migration. USMT provides several command-line options that you can use to analyze problems that occur during migration.
<table> | Command-Line Option | Description |
<colgroup> |--- |--- |
<col width="50%" /> | `/l:`[*Path*]*FileName* | Specifies the location and name of the **LoadState** log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then the log will be created in the current directory. You can specify the **/v** option to adjust the amount of output. <br/><br/>If you run the **LoadState** command from a shared network resource, you must specify this option or USMT will fail with the error: &quot;USMT was unable to create the log file(s)&quot;. To fix this issue, use the **/l:load.log** option. |
<col width="50%" /> | `/v:`*`<VerbosityLevel>`* | **(Verbosity)** <br/><br/>Enables verbose output in the LoadState log file. The default value is 0. <br/>You can set the *VerbosityLevel* to one of the following levels:<ul><li>**0** - Only the default errors and warnings are enabled.</li><li>**1** - Enables verbose output.</li><li>**4** - Enables error and status output.</li><li>**5** - Enables verbose and status output.</li><li>**8** - Enables error output to a debugger.</li><li>**9** - Enables verbose output to a debugger.</li><li>**12** - Enables error and status output to a debugger.</li><li>**13** - Enables verbose, status, and debugger output.</li></ul><br/>For example: <br/>`loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml` |
</colgroup> | `/progress:`[*Path*]*FileName* | Creates the optional progress log. You cannot store any of the log files in *StorePath*. *Path* can be either a relative or full path. If you do not specify the *Path* variable, then *FileName* will be created in the current directory. <br/><br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log` |
<thead> | `/c` | When this option is specified, the **LoadState** 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 is a large file that will not fit on the computer, the **LoadState** command will log an error and continue with the migration. Without the **/c** option, the **LoadState** command will exit on the first error. You can use the new &lt;**ErrorControl**&gt; section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the **/c** command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the **/genconfig** option now generates a sample &lt;**ErrorControl**&gt; section that is enabled by specifying error messages and desired behaviors in the Config.xml file. |
<tr class="header"> | `/r:`*`<TimesToRetry>`* | **(Retry)** <br/><br/>Specifies the number of times to retry when an error occurs while migrating the user state from a server. The default is three times. This option is useful in environments where network connectivity is not reliable. <br/><br/>While restoring the user state, the **/r** option will not 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. |
<th align="left">Command-Line Option</th> | `/w:`*`<SecondsBeforeRetry>`* | **(Wait)** <br/><br/>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
<th align="left">Description</th> | `/?` or `/help` | Displays Help on the command line. |
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/l:</strong>[<em>Path</em>]<em>FileName</em></p></td>
<td align="left"><p>Specifies the location and name of the <strong>LoadState</strong> log. You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then the log will be created in the current directory. You can specify the <strong>/v</strong> option to adjust the amount of output.</p>
<p>If you run the <strong>LoadState</strong> command from a shared network resource, you must specify this option or USMT will fail with the error: &quot;USMT was unable to create the log file(s)&quot;. To fix this issue, use the <strong>/l:load.log</strong> option.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/v:</strong><em>&lt;VerbosityLevel&gt;</em></p></td>
<td align="left"><p><strong>(Verbosity)</strong></p>
<p>Enables verbose output in the LoadState log file. The default value is 0.</p>
<p>You can set the <em>VerbosityLevel</em> to one of the following levels:</p>
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Level</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>0</p></td>
<td align="left"><p>Only the default errors and warnings are enabled.</p></td>
</tr>
<tr class="even">
<td align="left"><p>1</p></td>
<td align="left"><p>Enables verbose output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>4</p></td>
<td align="left"><p>Enables error and status output.</p></td>
</tr>
<tr class="even">
<td align="left"><p>5</p></td>
<td align="left"><p>Enables verbose and status output.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>8</p></td>
<td align="left"><p>Enables error output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>9</p></td>
<td align="left"><p>Enables verbose output to a debugger.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>12</p></td>
<td align="left"><p>Enables error and status output to a debugger.</p></td>
</tr>
<tr class="even">
<td align="left"><p>13</p></td>
<td align="left"><p>Enables verbose, status, and debugger output.</p></td>
</tr>
</tbody>
</table>
<p> </p>
<p>For example:</p>
<p><code>loadstate \server\share\migration\mystore /v:5 /i:migdocs.xml /i:migapp.xml</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/progress:</strong>[<em>Path&lt;/em&gt;]<em>FileName</em></p></td>
<td align="left"><p>Creates the optional progress log. You cannot store any of the log files in <em>StorePath</em>. <em>Path</em> can be either a relative or full path. If you do not specify the <em>Path</em> variable, then <em>FileName</em> will be created in the current directory.</p>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /progress:prog.log /l:loadlog.log</code></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/c</strong></p></td>
<td align="left"><p>When this option is specified, the <strong>LoadState</strong> 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 is a large file that will not fit on the computer, the <strong>LoadState</strong> command will log an error and continue with the migration. Without the <strong>/c</strong> option, the <strong>LoadState</strong> command will exit on the first error. You can use the new &lt;<strong>ErrorControl</strong>&gt; section in the Config.xml file to specify which file or registry read/write errors can be safely ignored and which might cause the migration to fail. This enables the <strong>/c</strong> command-line option to safely skip all input/output (I/O) errors in your environment. In addition, the <strong>/genconfig</strong> option now generates a sample &lt;<strong>ErrorControl</strong>&gt; section that is enabled by specifying error messages and desired behaviors in the Config.xml file.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/r:</strong><em>&lt;TimesToRetry&gt;</em></p></td>
<td align="left"><p><strong>(Retry)</strong></p>
<p>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 is not reliable.</p>
<p>While restoring the user state, the <strong>/r</strong> option will not 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.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/w:</strong><em>&lt;SecondsBeforeRetry&gt;</em></p></td>
<td align="left"><p><strong>(Wait)</strong></p>
<p>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/?</strong> or <strong>/help</strong></p></td>
<td align="left"><p>Displays Help on the command line.</p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-user"></a>User Options ## <a href="" id="bkmk-user"></a>User Options
By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You cannot exclude users in the migration .xml files or by using the Config.xml file. For more information, see [Identify Users](usmt-identify-users.md). By default, all users are migrated. The only way to specify which users to include and exclude is by using the following options. You cannot exclude users in the migration .xml files or by using the Config.xml file. For more information, see [Identify Users](usmt-identify-users.md).
<table> | Command-Line Option | Description |
<colgroup> |--- |--- |
<col width="50%" /> | `/all` | Migrates all of the users on the computer. <br/><br/>USMT migrates all user accounts on the computer, unless you specifically exclude an account with the **/ue** or **/uel** options. For this reason, you do not need to specify this option on the command line. However, if you choose to use the **/all** option, you cannot also use the **/ui**, **/ue** or **/uel** options. |
<col width="50%" /> | `/ui:`*DomainName UserName* <br/>or <br/>`/ui:`*"DomainName User Name"* <br/>or <br/>`/ui:`*ComputerName LocalUserName* | **(User include)** <br/><br/>Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the **/ue** option. You can specify multiple **/ui** options, but you cannot 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 will need to surround it with quotations marks. <br/>For example:<ul><li>To include only User2 from the Corporate domain, type: <br/>`/ue:* /ui:corporate\user2`</li></ul> <div class="alert">**Note** <br/>If a user is specified for inclusion with the **/ui** option, and also is specified to be excluded with either the **/ue** or **/uel** options, the user will be included in the migration.</div> <br/> For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. |
</colgroup> | `/uel:`*`<NumberOfDays>`* <br/>or <br/>`/uel:`*`<YYYY/MM/DD>`* <br/>or <br/>`/uel:0` | **(User exclude based on last logon)** <br/><br/>Migrates only the users that logged onto the source computer within the specified time period, based on the **Last Modified** date of the Ntuser.dat file on the source computer. The **/uel** option acts as an include rule. For example, the **/uel:30** option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the **/all** option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT. <div class="alert">**Note** <br/>The **/uel** option is not valid in offline migrations.</div> <br/>Examples:<ul><li>`/uel:0` migrates accounts that were logged on to the source computer when the **ScanState** command was run.</li><li>`/uel:90` migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</li><li>`/uel:1` migrates users whose accounts have been modified within the last 24 hours.</li><li>`/uel:2002/1/15` migrates users who have logged on or whose accounts have been modified since January 15, 2002.</li></ul> <br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0` |
<thead> | `/ue`:*DomainName UserName* <br/>or <br/>`/ue`*"DomainName User Name"* <br/>or <br/>`/ue`:*ComputerName LocalUserName* | **(User exclude)** <br/><br/>Excludes the specified users from the migration. You can specify multiple **/ue** options but you cannot 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 will need to surround it with quotation marks. <br/><br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1` <br/>For more examples, see the descriptions of the **/uel**, **/ue**, and **/ui** options in this table. |
<tr class="header"> | `/md:`*OldDomain*:*NewDomain* <br/>or <br/>`/md:`*LocalComputerName:NewDomain* | **(move domain)** <br/>Specifies a new domain for the user. Use this option to change the domain for users on a computer or to migrate a local user to a domain account. *OldDomain* may contain the asterisk () wildcard character. <br/><br/>You can specify this option more than once. You may want to specify multiple **/md** options if you are consolidating users across multiple domains to a single domain. For example, you could specify the following to consolidate the users from the Corporate and FarNorth domains into the Fabrikam domain: `/md:corporate:fabrikam` and `/md:farnorth:fabrikam`. <br/><br/>If there are conflicts between two **/md** commands, the first rule that you specify is applied. For example, if you specify the `/md:corporate:fabrikam` and `/md:corporate:farnorth` commands, then Corporate users would be mapped to the Fabrikam domain. <div class="alert"> **Note** <br/>If you specify an *OldDomain* that did not exist on the source computer, the **LoadState** command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to *NewDomain* but will remain in their original domain. For example, if you misspell &quot;contoso&quot; and you specify &quot;/md:contso:fabrikam&quot;, the users will remain in contoso on the destination computer.</div> <br/> For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>` /progress:prog.log /l:load.log /md:contoso:fabrikam` |
<th align="left">Command-Line Option</th> | `/mu:`*OldDomain OldUserName*:[*NewDomain*]*NewUserName* <br/>or <br/>`/mu:`*OldLocalUserName*:*NewDomain NewUserName* | Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple **/mu** options. You cannot use wildcard characters with this option. <br/><br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>`/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1` |
<th align="left">Description</th> | `/lac:`[*Password*] | **(local account create)** <br/><br/>Specifies that if a user account is a local (non-domain) account, and it does not exist on the destination computer, USMT will create the account on the destination computer but it will be disabled. To enable the account, you must also use the **/lae** option. <br/><br/>If the **/lac** option is not specified, any local user accounts that do not already exist on the destination computer will not be migrated. <br/><br/>*Password* is the password for the newly created account. An empty password is used by default. <div class="alert"> **Caution** <br/>Use the *Password* variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the **LoadState** command. <br/>Also, if the computer has multiple users, all migrated users will have the same password.</div> <br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). |
</tr> | `/lae` | **(local account enable)** <br/><br/>Enables the account that was created with the **/lac** option. You must specify the **/lac** option with this option. <br/><br/>For example: <br/>`loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore` <br/>`/progress:prog.log /l:load.log /lac:password /lae` <br/><br/>For instructions, see [Migrate User Accounts](usmt-migrate-user-accounts.md). |
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/all</strong></p></td>
<td align="left"><p>Migrates all of the users on the computer.</p>
<p>USMT migrates all user accounts on the computer, unless you specifically exclude an account with the <strong>/ue</strong> or <strong>/uel</strong> options. For this reason, you do not need to specify this option on the command line. However, if you choose to use the <strong>/all</strong> option, you cannot also use the <strong>/ui</strong>, <strong>/ue</strong> or <strong>/uel</strong> options.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/ui:</strong><em>DomainName</em>&lt;em&gt;UserName</em></p>
<p>or</p>
<p><strong>/ui:</strong>&quot;<em>DomainName</em>&lt;em&gt;User Name</em>&quot;</p>
<p>or</p>
<p><strong>/ui:</strong><em>ComputerName</em>&lt;em&gt;LocalUserName</em></p></td>
<td align="left"><p><strong>(User include)</strong></p>
<p>Migrates the specified user. By default, all users are included in the migration. Therefore, this option is helpful only when used with the <strong>/ue</strong> option. You can specify multiple <strong>/ui</strong> options, but you cannot use the <strong>/ui</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (<em>) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotations marks.</p>
<p>For example:</p>
<ul>
<li><p>To include only User2 from the Corporate domain, type:</p>
<p><code>/ue:</em>* /ui:corporate\user2</code></p></li>
</ul>
<div class="alert">
<strong>Note</strong><br/><p>If a user is specified for inclusion with the <strong>/ui</strong> option, and also is specified to be excluded with either the <strong>/ue</strong> or <strong>/uel</strong> options, the user will be included in the migration.</p>
</div>
<div>
</div>
<p>For more examples, see the descriptions of the <strong>/uel</strong>, <strong>/ue</strong>, and <strong>/ui</strong> options in this table.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/uel</strong>:<em>&lt;NumberOfDays&gt;</em></p>
<p>or</p>
<p><strong>/uel</strong>:<em>&lt;YYYY/MM/DD&gt;</em></p>
<p>or</p>
<p><strong>/uel</strong>:0</p></td>
<td align="left"><p><strong>(User exclude based on last logon)</strong></p>
<p>Migrates only the users that logged onto the source computer within the specified time period, based on the <strong>Last Modified</strong> date of the Ntuser.dat file on the source computer. The <strong>/uel</strong> option acts as an include rule. For example, the <strong>/uel:30</strong> option migrates users who logged on, or whose user account was modified, within the last 30 days from the date when the ScanState command is run. You can specify a number of days or you can specify a date. You cannot use this option with the <strong>/all</strong> option. USMT retrieves the last logon information from the local computer, so the computer does not need to be connected to the network when you run this option. In addition, if a domain user has logged onto another computer, that logon instance is not considered by USMT.</p>
<div class="alert">
<strong>Note</strong><br/><p>The <strong>/uel</strong> option is not valid in offline migrations.</p>
</div>
<div>
</div>
<p>Examples:</p>
<ul>
<li><p><code>/uel:0</code> migrates accounts that were logged on to the source computer when the <strong>ScanState</strong> command was run.</p></li>
<li><p><code>/uel:90</code> migrates users who have logged on, or whose accounts have been otherwise modified, within the last 90 days.</p></li>
<li><p><code>/uel:1</code> migrates users whose accounts have been modified within the last 24 hours.</p></li>
<li><p><code>/uel:2002/1/15</code> migrates users who have logged on or whose accounts have been modified since January 15, 2002.</p></li>
</ul>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /uel:0</code></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/ue</strong>:<em>DomainName</em>&lt;em&gt;UserName</em></p>
<p>or</p>
<p><strong>/ue</strong>:&quot;<em>DomainName</em>&lt;em&gt;User Name</em>&quot;</p>
<p>or</p>
<p><strong>/ue</strong>:<em>ComputerName</em>&lt;em&gt;LocalUserName</em></p></td>
<td align="left"><p><strong>(User exclude)</strong></p>
<p>Excludes the specified users from the migration. You can specify multiple <strong>/ue</strong> options but you cannot use the <strong>/ue</strong> option with the <strong>/all</strong> option. <em>DomainName</em> and <em>UserName</em> can contain the asterisk (<em>) wildcard character. When you specify a user name that contains spaces, you will need to surround it with quotation marks.</p>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore /ue:contoso\user1</code></p>
<p>For more examples, see the descriptions of the <strong>/uel</strong>, <strong>/ue</strong>, and <strong>/ui</strong> options in this table.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/md:</strong><em>OldDomain</em>:<em>NewDomain</em></p>
<p>or</p>
<p><strong>/md:</strong><em>LocalComputerName:NewDomain</em></p></td>
<td align="left"><p><strong>(move domain)</strong></p>
<p>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. <em>OldDomain</em> may contain the asterisk (</em>) wildcard character.</p>
<p>You can specify this option more than once. You may want to specify multiple <strong>/md</strong> options if you are 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: <code>/md:corporate:fabrikam</code> and <code>/md:farnorth:fabrikam</code>.</p>
<p>If there are conflicts between two <strong>/md</strong> commands, the first rule that you specify is applied. For example, if you specify the <code>/md:corporate:fabrikam</code> and <code>/md:corporate:farnorth</code> commands, then Corporate users would be mapped to the Fabrikam domain.</p>
<div class="alert">
<strong>Note</strong><br/><p>If you specify an <em>OldDomain</em> that did not exist on the source computer, the <strong>LoadState</strong> command will appear to complete successfully, without an error or warning. However, in this case, users will not be moved to <em>NewDomain</em> but will remain in their original domain. For example, if you misspell &quot;contoso&quot; and you specify &quot;/md:contso:fabrikam&quot;, the users will remain in contoso on the destination computer.</p>
</div>
<div>
</div>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
<p><code> /progress:prog.log /l:load.log /md:contoso:fabrikam</code></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/mu:</strong><em>OldDomain</em>&lt;em&gt;OldUserName</em>:[<em>NewDomain</em>]<em>NewUserName</em></p>
<p>or</p>
<p><strong>/mu:</strong><em>OldLocalUserName</em>:<em>NewDomain</em>&lt;em&gt;NewUserName</em></p></td>
<td align="left"><p>Specifies a new user name for the specified user. If the store contains more than one user, you can specify multiple <strong>/mu</strong> options. You cannot use wildcard characters with this option.</p>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
<p><code>/progress:prog.log /l:load.log /mu:contoso\user1:fabrikam\user1</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/lac:</strong>[<em>Password</em>]</p></td>
<td align="left"><p><strong>(local account create)</strong></p>
<p>Specifies that if a user account is a local (non-domain) account, and it does not 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 <strong>/lae</strong> option.</p>
<p>If the <strong>/lac</strong> option is not specified, any local user accounts that do not already exist on the destination computer will not be migrated.</p>
<p><em>Password</em> is the password for the newly created account. An empty password is used by default.</p>
<div class="alert">
<strong>Caution</strong><br/><p>Use the <em>Password</em> variable with caution because it is provided in plain text and can be obtained by anyone with access to the computer that is running the <strong>LoadState</strong> command.</p>
<p>Also, if the computer has multiple users, all migrated users will have the same password.</p>
</div>
<div>
</div>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
<p>For instructions, see <a href="usmt-migrate-user-accounts.md" data-raw-source="[Migrate User Accounts](usmt-migrate-user-accounts.md)">Migrate User Accounts</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/lae</strong></p></td>
<td align="left"><p><strong>(local account enable)</strong></p>
<p>Enables the account that was created with the <strong>/lac</strong> option. You must specify the <strong>/lac</strong> option with this option.</p>
<p>For example:</p>
<p><code>loadstate /i:migapp.xml /i:migdocs.xml \server\share\migration\mystore</code></p>
<p><code>/progress:prog.log /l:load.log /lac:password /lae</code></p>
<p>For instructions, see <a href="usmt-migrate-user-accounts.md" data-raw-source="[Migrate User Accounts](usmt-migrate-user-accounts.md)">Migrate User Accounts</a>.</p></td>
</tr>
</tbody>
</table>
### Examples for the /ui and /ue options ### Examples for the /ui and /ue options
The following examples apply to both the **/ui** and **/ue** options. You can replace the **/ue** option with the **/ui** option to include, rather than exclude, the specified users. The following examples apply to both the **/ui** and **/ue** options. You can replace the **/ue** option with the **/ui** option to include, rather than exclude, the specified users.
<table> | Behavior | Command |
<colgroup> |--- |--- |
<col width="50%" /> | Exclude the user named User One in the Corporate domain. | `/ue:"corporate\user one"` |
<col width="50%" /> | Exclude the user named User1 in the Corporate domain. | `/ue:corporate\user1` |
</colgroup> | Exclude the local user named User1. | `/ue:%computername%\user1` |
<thead> | Exclude all domain users. | `/ue:Domain` |
<tr class="header"> | Exclude all local users. | `/ue:%computername%` |
<th align="left">Behavior</th> | Exclude users in all domains named User1, User2, and so on. | `/ue:\user` |
<th align="left">Command</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Exclude the user named User One in the Corporate domain.</p></td>
<td align="left"><p><code>/ue:&quot;corporate\user one&quot;</code></p></td>
</tr>
<tr class="even">
<td align="left"><p>Exclude the user named User1 in the Corporate domain.</p></td>
<td align="left"><p><code>/ue:corporate\user1</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Exclude the local user named User1.</p></td>
<td align="left"><p><code>/ue:%computername%\user1</code></p></td>
</tr>
<tr class="even">
<td align="left"><p>Exclude all domain users.</p></td>
<td align="left"><p><code>/ue:Domain<em></code></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Exclude all local users.</p></td>
<td align="left"><p><code>/ue:%computername%</em></code></p></td>
</tr>
<tr class="even">
<td align="left"><p>Exclude users in all domains named User1, User2, and so on.</p></td>
<td align="left"><p><code>/ue:<em>\user</em></code></p></td>
</tr>
</tbody>
</table>
### Using the Options Together ### Using the Options Together
@ -464,247 +120,46 @@ You can use the **/uel**, **/ue** and **/ui** options together to migrate only t
**The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user's profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days. **The /uel option takes precedence over the /ue option.** If a user has logged on within the specified time period set by the **/uel** option, that user's profile will be migrated even if they are excluded by using the **/ue** option. For example, if you specify `/ue:contoso\user1 /uel:14`, the User1 will be migrated if they have logged on to the computer within the last 14 days.
<table> | Behavior | Command |
<colgroup> |--- |--- |
<col width="50%" /> | Include only User2 from the Fabrikam domain and exclude all other users. | `/ue:* /ui:fabrikam\user2` |
<col width="50%" /> | Include only the local user named User1 and exclude all other users. | `/ue:* /ui:user1` |
</colgroup> | Include only the domain users from Contoso, except Contoso\User1. | This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:<ul><li>Using the **ScanState** command-line tool, type: `/ue:* /ui:contoso`</li><li>Using the **LoadState** command-line tool, type: `/ue:contoso\user1`</li></ul> |
<thead> | Include only local (non-domain) users. | `/ue: /ui:%computername%*` |
<tr class="header">
<th align="left">Behavior</th>
<th align="left">Command</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>Include only User2 from the Fabrikam domain and exclude all other users.</p></td>
<td align="left"><p><code>/ue:<em>* /ui:fabrikam\user2</code></p></td>
</tr>
<tr class="even">
<td align="left"><p>Include only the local user named User1 and exclude all other users.</p></td>
<td align="left"><p><code>/ue:</em>* /ui:user1</code></p></td>
</tr>
<tr class="odd">
<td align="left"><p>Include only the domain users from Contoso, except Contoso\User1.</p></td>
<td align="left"><p>This behavior cannot be completed using a single command. Instead, to migrate this set of users, you will need to specify the following:</p>
<ul>
<li><p>Using the <strong>ScanState</strong> command-line tool, type: <code>/ue:<em>* /ui:contoso<em></code></p></li>
<li><p>Using the <strong>LoadState</strong> command-line tool, type: <code>/ue:contoso\user1</code></p></li>
</ul></td>
</tr>
<tr class="even">
<td align="left"><p>Include only local (non-domain) users.</p></td>
<td align="left"><p><code>/ue:</em></em> /ui:%computername%*</code></p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-cloi"></a>Incompatible Command-Line Options ## <a href="" id="bkmk-cloi"></a>Incompatible Command-Line Options
The following table indicates which command-line options are not compatible with the **LoadState** command. If the table entry for a particular combination is blank, the options are compatible and you can use them together. The X symbol means that the options are not compatible. For example, you cannot use the **/nocompress** option with the **/encrypt** option. The following table indicates which command-line options are not compatible with the **LoadState** command. If the table entry for a particular combination is blank, the options are compatible and you can use them together. The X symbol means that the options are not compatible. For example, you cannot use the **/nocompress** option with the **/encrypt** option.
<table> | Command-Line Option | /keyfile | /nocompress | /genconfig | /all |
<colgroup> |--- |--- |--- |--- |--- |
<col width="20%" /> | **/i** | | | | |
<col width="20%" /> | **/v** | | | | |
<col width="20%" /> | **/nocompress** | | N/A | X | |
<col width="20%" /> | **/key** | X | | X | |
<col width="20%" /> | **/decrypt** | Required* | X | X | |
</colgroup> | **/keyfile** | N/A | | X | |
<thead> | **/l** | | | | |
<tr class="header"> | **/progress** | | | X | |
<th align="left">Command-Line Option</th> | **/r** | | | X | |
<th align="left">/keyfile</th> | **/w** | | | X | |
<th align="left">/nocompress</th> | **/c** | | | X | |
<th align="left">/genconfig</th> | **/p** | | | X | N/A |
<th align="left">/all</th> | **/all** | | | X | |
</tr> | **/ui** | | | X | X |
</thead> | **/ue** | | | X | X |
<tbody> | **/uel** | | | X | X |
<tr class="odd"> | **/genconfig** | | | N/A | |
<td align="left"><p><strong>/i</strong></p></td> | **/config** | | | X | |
<td align="left"><p></p></td> | *StorePath* | | | | |
<td align="left"><p></p></td> | **/md** | | | | |
<td align="left"><p></p></td> | **/mu** | | | | |
<td align="left"><p></p></td> | **/lae** | | | | |
</tr> | **/lac** | | | | |
<tr class="even">
<td align="left"><p><strong>/v</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/nocompress</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/key</strong></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/decrypt</strong></p></td>
<td align="left"><p>Required*</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/keyfile</strong></p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/l</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/progress</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/r</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/w</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/c</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/p</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>N/A</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/all</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/ui</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/ue</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/uel</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p>X</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/genconfig</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>N/A</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/config</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p>X</p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><em>StorePath</em></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/md</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/mu</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/lae</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/lac</strong></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
<td align="left"><p></p></td>
</tr>
</tbody>
</table>
**Note**
You must specify either the **/key** or **/keyfile** option with the **/encrypt** option.
> [!NOTE]
> You must specify either the **/key** or **/keyfile** option with the **/encrypt** option.
## Related topics ## Related topics
[XML Elements Library](usmt-xml-elements-library.md) [XML Elements Library](usmt-xml-elements-library.md)

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

@ -16,7 +16,6 @@ ms.topic: article
# Log Files # Log Files
You can use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. This topic describes the available command-line options to enable USMT logs, and new XML elements that configure which types of errors are fatal and should halt the migration, which types are non-fatal and should be skipped so that the migration can continue. You can use User State Migration Tool (USMT) 10.0 logs to monitor your migration and to troubleshoot errors and failed migrations. This topic describes the available command-line options to enable USMT logs, and new XML elements that configure which types of errors are fatal and should halt the migration, which types are non-fatal and should be skipped so that the migration can continue.
[Log Command-Line Options](#bkmk-commandlineoptions) [Log Command-Line Options](#bkmk-commandlineoptions)
@ -31,66 +30,25 @@ You can use User State Migration Tool (USMT) 10.0 logs to monitor your migratio
## <a href="" id="bkmk-commandlineoptions"></a>Log Command-Line Options ## <a href="" id="bkmk-commandlineoptions"></a>Log Command-Line Options
The following table describes each command-line option related to logs, and it provides the log name and a description of what type of information each log contains. The following table describes each command-line option related to logs, and it provides the log name and a description of what type of information each log contains.
<table> |Command line Option|File Name|Description|
<colgroup> |--- |--- |--- |
<col width="33%" /> |**/l** *[Path]FileName*|Scanstate.log or LoadState.log|Specifies the path and file name of the ScanState.log or LoadState log.|
<col width="33%" /> |**/progress** *[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.|
<col width="33%" /> |**/v** *[VerbosityLevel]*|Not applicable|See the "Monitoring Options" section in [ScanState Syntax](usmt-scanstate-syntax.md).|
</colgroup> |**/listfiles** *[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.|
<thead> |Set the environment variable MIG_ENABLE_DIAG to a path to an XML file.|USMTDiag.xml|The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.|
<tr class="header">
<th align="left">Command line Option</th>
<th align="left">File Name</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/l</strong><em>[Path]FileName</em></p></td>
<td align="left"><p>Scanstate.log or LoadState.log</p></td>
<td align="left"><p>Specifies the path and file name of the ScanState.log or LoadState log.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/progress</strong><em>[Path]FileName</em></p></td>
<td align="left"><p>Specifies the path and file name of the Progress log.</p></td>
<td align="left"><p>Provides information about the status of the migration, by percentage complete.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>/v</strong><em>[VerbosityLevel]</em></p></td>
<td align="left"><p>Not applicable</p></td>
<td align="left"><p>See the &quot;Monitoring Options&quot; section in <a href="usmt-scanstate-syntax.md" data-raw-source="[ScanState Syntax](usmt-scanstate-syntax.md)">ScanState Syntax</a>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>/listfiles</strong><em>[Path]FileName</em></p></td>
<td align="left"><p>Specifies the path and file name of the Listfiles log.</p></td>
<td align="left"><p>Provides a list of the files that were migrated.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>Set the environment variable MIG_ENABLE_DIAG to a path to an XML file.</p></td>
<td align="left"><p>USMTDiag.xml</p></td>
<td align="left"><p>The diagnostic log contains detailed system environment information, user environment information, and information about the migration units (migunits) being gathered and their contents.</p></td>
</tr>
</tbody>
</table>
> [!NOTE]
> You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run.
**Note**  
You cannot store any of the log files in *StorePath*. If you do, the log will be overwritten when USMT is run.
## <a href="" id="bkmk-scanloadstatelogs"></a>ScanState and LoadState Logs ## <a href="" id="bkmk-scanloadstatelogs"></a>ScanState and LoadState Logs
ScanState and LoadState logs are text files that are create when you run the ScanState and LoadState tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see Monitoring Options in [ScanState Syntax](usmt-scanstate-syntax.md). ScanState and LoadState logs are text files that are create when you run the ScanState and LoadState tools. You can use these logs to help monitor your migration. The content of the log depends on the command-line options that you use and the verbosity level that you specify. For more information about verbosity levels, see Monitoring Options in [ScanState Syntax](usmt-scanstate-syntax.md).
## <a href="" id="bkmk-progresslog"></a>Progress Log ## <a href="" id="bkmk-progresslog"></a>Progress Log
You can create a progress log using the **/progress** option. External tools, such as Microsoft System Center Operations Manager 2007, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows: You can create a progress log using the **/progress** option. External tools, such as Microsoft System Center Operations Manager 2007, can parse the progress log to update your monitoring systems. The first three fields in each line are fixed as follows:
- **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2006. - **Date:** Date, in the format of *day* *shortNameOfTheMonth* *year*. For example: 08 Jun 2006.
@ -101,137 +59,34 @@ You can create a progress log using the **/progress** option. External tools, su
The remaining fields are key/value pairs as indicated in the following table. The remaining fields are key/value pairs as indicated in the following table.
<table> | Key | Value |
<colgroup> |-----|-------|
<col width="50%" /> | program | ScanState.exe or LoadState.exe. |
<col width="50%" /> | productVersion | The full product version number of USMT. |
</colgroup> | computerName | The name of the source or destination computer on which USMT was run. |
<thead> | commandLine | The full command used to run USMT. |
<tr class="header"> | PHASE | Reports that a new phase in the migration is starting. This can be one of the following:<ul><li>Initializing</li><li>Scanning</li><li>Collecting</li><li>Saving</li><li>Estimating</li><li>Applying</li></ul> |
<th align="left">Key</th> | detectedUser | <ul><li>For the ScanState tool, these are the users USMT detected on the source computer that can be migrated.</li><li>For the LoadState tool, these are the users USMT detected in the store that can be migrated.</li></ul> |
<th align="left">Value</th> | includedInMigration | Defines whether the user profile/component is included for migration. Valid values are Yes or No. |
</tr> | forUser | Specifies either of the following:<ul><li>The user state being migrated.</li><li>*This Computer*, meaning files and settings that are not associated with a user.</li></ul> |
</thead> | detectedComponent | Specifies a component detected by USMT.<ul><li>For ScanState, this is a component or application that is installed on the source computer.</li><li>For LoadState, this is a component or application that was detected in the store.</li></ul> |
<tbody> | totalSizeInMBToTransfer | Total size of the files and settings to migrate in megabytes (MB). |
<tr class="odd"> | totalPercentageCompleted | Total percentage of the migration that has been completed by either ScanState or LoadState. |
<td align="left"><p>program</p></td> | collectingUser | Specifies which user ScanState is collecting files and settings for. |
<td align="left"><p>ScanState.exe or LoadState.exe.</p></td> | totalMinutesRemaining | Time estimate, in minutes, for the migration to complete. |
</tr> | error | Type of non-fatal error that occurred. This can be one of the following:<ul><li>**UnableToCopy**: Unable to copy to store because the disk on which the store is located is full.</li><li>**UnableToOpen**: Unable to open the file for migration because the file is opened in non-shared mode by another application or service.</li><li>**UnableToCopyCatalog**: Unable to copy because the store is corrupted.</li><li>**UnableToAccessDevice**: Unable to access the device.</li><li>**UnableToApply**: Unable to apply the setting to the destination computer.</li></ul> |
<tr class="even"> | objectName | The name of the file or setting that caused the non-fatal error. |
<td align="left"><p>productVersion</p></td> | action | Action taken by USMT for the non-fatal error. The values are:<ul><li>**Ignore**: Non-fatal error ignored and the migration continued because the **/c** option was specified on the command line.</li><li>**Abort**: Stopped the migration because the **/c** option was not specified.</li></ul> |
<td align="left"><p>The full product version number of USMT.</p></td> | errorCode | The errorCode or return value. |
</tr> | numberOfIgnoredErrors | The total number of non-fatal errors that USMT ignored. |
<tr class="odd"> | message | The message corresponding to the errorCode. |
<td align="left"><p>computerName</p></td>
<td align="left"><p>The name of the source or destination computer on which USMT was run.</p></td>
</tr>
<tr class="even">
<td align="left"><p>commandLine</p></td>
<td align="left"><p>The full command used to run USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>PHASE</p></td>
<td align="left"><p>Reports that a new phase in the migration is starting. This can be one of the following:</p>
<ul>
<li><p>Initializing</p></li>
<li><p>Scanning</p></li>
<li><p>Collecting</p></li>
<li><p>Saving</p></li>
<li><p>Estimating</p></li>
<li><p>Applying</p></li>
</ul></td>
</tr>
<tr class="even">
<td align="left"><p>detectedUser</p></td>
<td align="left"><ul>
<li><p>For the ScanState tool, these are the users USMT detected on the source computer that can be migrated.</p></li>
<li><p>For the LoadState tool, these are the users USMT detected in the store that can be migrated.</p></li>
</ul></td>
</tr>
<tr class="odd">
<td align="left"><p>includedInMigration</p></td>
<td align="left"><p>Defines whether the user profile/component is included for migration. Valid values are Yes or No.</p></td>
</tr>
<tr class="even">
<td align="left"><p>forUser</p></td>
<td align="left"><p>Specifies either of the following:</p>
<ul>
<li><p>The user state being migrated.</p></li>
<li><p><em>This Computer</em>, meaning files and settings that are not associated with a user.</p></li>
</ul></td>
</tr>
<tr class="odd">
<td align="left"><p>detectedComponent</p></td>
<td align="left"><p>Specifies a component detected by USMT.</p>
<ul>
<li><p>For ScanState, this is a component or application that is installed on the source computer.</p></li>
<li><p>For LoadState, this is a component or application that was detected in the store.</p></li>
</ul></td>
</tr>
<tr class="even">
<td align="left"><p>totalSizeInMBToTransfer</p></td>
<td align="left"><p>Total size of the files and settings to migrate in megabytes (MB).</p></td>
</tr>
<tr class="odd">
<td align="left"><p>totalPercentageCompleted</p></td>
<td align="left"><p>Total percentage of the migration that has been completed by either ScanState or LoadState.</p></td>
</tr>
<tr class="even">
<td align="left"><p>collectingUser</p></td>
<td align="left"><p>Specifies which user ScanState is collecting files and settings for.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>totalMinutesRemaining</p></td>
<td align="left"><p>Time estimate, in minutes, for the migration to complete.</p></td>
</tr>
<tr class="even">
<td align="left"><p>error</p></td>
<td align="left"><p>Type of non-fatal error that occurred. This can be one of the following:</p>
<ul>
<li><p><strong>UnableToCopy</strong>: Unable to copy to store because the disk on which the store is located is full.</p></li>
<li><p><strong>UnableToOpen</strong>: Unable to open the file for migration because the file is opened in non-shared mode by another application or service.</p></li>
<li><p><strong>UnableToCopyCatalog</strong>: Unable to copy because the store is corrupted.</p></li>
<li><p><strong>UnableToAccessDevice</strong>: Unable to access the device.</p></li>
<li><p><strong>UnableToApply</strong>: Unable to apply the setting to the destination computer.</p></li>
</ul></td>
</tr>
<tr class="odd">
<td align="left"><p>objectName</p></td>
<td align="left"><p>The name of the file or setting that caused the non-fatal error.</p></td>
</tr>
<tr class="even">
<td align="left"><p>action</p></td>
<td align="left"><p>Action taken by USMT for the non-fatal error. The values are:</p>
<ul>
<li><p><strong>Ignore</strong>: Non-fatal error ignored and the migration continued because the <strong>/c</strong> option was specified on the command line.</p></li>
<li><p><strong>Abort</strong>: Stopped the migration because the <strong>/c</strong> option was not specified.</p></li>
</ul></td>
</tr>
<tr class="odd">
<td align="left"><p>errorCode</p></td>
<td align="left"><p>The errorCode or return value.</p></td>
</tr>
<tr class="even">
<td align="left"><p>numberOfIgnoredErrors</p></td>
<td align="left"><p>The total number of non-fatal errors that USMT ignored.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>message</p></td>
<td align="left"><p>The message corresponding to the errorCode.</p></td>
</tr>
</tbody>
</table>
## <a href="" id="bkmk-listfileslog"></a>List Files Log ## <a href="" id="bkmk-listfileslog"></a>List Files Log
The List files log (Listfiles.txt) provides a list of the files that were migrated. This list can be used to troubleshoot XML issues or can be retained as a record of the files that were gathered into the migration store. The List Files log is only available for ScanState.exe. The List files log (Listfiles.txt) provides a list of the files that were migrated. This list can be used to troubleshoot XML issues or can be retained as a record of the files that were gathered into the migration store. The List Files log is only available for ScanState.exe.
## <a href="" id="bkmk-diagnosticlog"></a>Diagnostic Log ## <a href="" id="bkmk-diagnosticlog"></a>Diagnostic Log
You can obtain the diagnostic log by setting the environment variable MIG\_ENABLE\_DIAG to a path to an XML file. You can obtain the diagnostic log by setting the environment variable MIG\_ENABLE\_DIAG to a path to an XML file.
The diagnostic log contains: The diagnostic log contains:
@ -244,7 +99,6 @@ The diagnostic log contains:
## Using the Diagnostic Log ## Using the Diagnostic Log
The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data that is identified by the component it is associated with in the XML files. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files. The diagnostic log is essentially a report of all the migration units (migunits) included in the migration. A migunit is a collection of data that is identified by the component it is associated with in the XML files. The migration store is made up of all the migunits in the migration. The diagnostic log can be used to verify which migunits were included in the migration and can be used for troubleshooting while authoring migration XML files.
The following examples describe common scenarios in which you can use the diagnostic log. The following examples describe common scenarios in which you can use the diagnostic log.
@ -253,7 +107,7 @@ The following examples describe common scenarios in which you can use the diagno
Let's imagine that we have the following directory structure and that we want the "data" directory to be included in the migration along with the "New Text Document.txt" file in the "New Folder." The directory of **C:\\data** contains: Let's imagine that we have the following directory structure and that we want the "data" directory to be included in the migration along with the "New Text Document.txt" file in the "New Folder." The directory of **C:\\data** contains:
``` ```console
01/21/2009 10:08 PM <DIR> . 01/21/2009 10:08 PM <DIR> .
01/21/2009 10:08 PM <DIR> .. 01/21/2009 10:08 PM <DIR> ..
01/21/2009 10:08 PM <DIR> New Folder 01/21/2009 10:08 PM <DIR> New Folder
@ -264,7 +118,7 @@ Let's imagine that we have the following directory structure and that we want th
The directory of **C:\\data\\New Folder** contains: The directory of **C:\\data\\New Folder** contains:
``` ```console
01/21/2009 10:08 PM <DIR> . 01/21/2009 10:08 PM <DIR> .
01/21/2009 10:08 PM <DIR> .. 01/21/2009 10:08 PM <DIR> ..
01/21/2009 10:08 PM 0 New Text Document.txt 01/21/2009 10:08 PM 0 New Text Document.txt
@ -295,7 +149,7 @@ To migrate these files you author the following migration XML:
However, upon testing the migration you notice that the "New Text Document.txt" file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable MIG\_ENABLE\_DIAG set such that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: However, upon testing the migration you notice that the "New Text Document.txt" file isn't included in the migration. To troubleshoot this failure, the migration can be repeated with the environment variable MIG\_ENABLE\_DIAG set such that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered:
``` xml ```xml
<MigUnitList> <MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true"> <MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<Patterns Type="Include"> <Patterns Type="Include">
@ -316,13 +170,13 @@ Analysis of this XML section reveals the migunit that was created when the migra
An analysis of the XML elements reference topic reveals that the &lt;pattern&gt; tag needs to be modified as follows: An analysis of the XML elements reference topic reveals that the &lt;pattern&gt; tag needs to be modified as follows:
``` xml ```xml
<pattern type="File">c:\data\* [*]</pattern> <pattern type="File">c:\data\* [*]</pattern>
``` ```
When the migration is preformed again with the modified tag, the diagnostic log reveals the following: When the migration is preformed again with the modified tag, the diagnostic log reveals the following:
``` xml ```xml
<MigUnitList> <MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true"> <MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<Patterns Type="Include"> <Patterns Type="Include">
@ -347,7 +201,7 @@ This diagnostic log confirms that the modified &lt;pattern&gt; value enables the
In this scenario, you have the following directory structure and you want all files in the "data" directory to migrate, except for text files. The **C:\\Data** folder contains: In this scenario, you have the following directory structure and you want all files in the "data" directory to migrate, except for text files. The **C:\\Data** folder contains:
``` ```console
Directory of C:\Data Directory of C:\Data
01/21/2009 10:08 PM <DIR> . 01/21/2009 10:08 PM <DIR> .
@ -360,7 +214,7 @@ Directory of C:\Data
The **C:\\Data\\New Folder\\** contains: The **C:\\Data\\New Folder\\** contains:
``` ```console
01/21/2009 10:08 PM <DIR> . 01/21/2009 10:08 PM <DIR> .
01/21/2009 10:08 PM <DIR> .. 01/21/2009 10:08 PM <DIR> ..
01/21/2009 10:08 PM 0 New Text Document.txt 01/21/2009 10:08 PM 0 New Text Document.txt
@ -397,7 +251,7 @@ You author the following migration XML:
However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable MIG\_ENABLE\_DIAG set so that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered: However, upon testing the migration you notice that all the text files are still included in the migration. In order to troubleshoot this issue, the migration can be performed with the environment variable MIG\_ENABLE\_DIAG set so that the diagnostic log is generated. Upon searching the diagnostic log for the component "DATA1", the following XML section is discovered:
``` xml ```xml
<MigUnitList> <MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true"> <MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<Patterns Type="Include"> <Patterns Type="Include">
@ -454,7 +308,7 @@ Upon reviewing the diagnostic log, you confirm that the files are still migratin
Your revised migration XML script excludes the files from migrating, as confirmed in the diagnostic log: Your revised migration XML script excludes the files from migrating, as confirmed in the diagnostic log:
``` xml ```xml
<MigUnitList> <MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true"> <MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<Patterns Type="Include"> <Patterns Type="Include">
@ -484,11 +338,3 @@ Your revised migration XML script excludes the files from migrating, as confirme
[LoadState Syntax](usmt-loadstate-syntax.md) [LoadState Syntax](usmt-loadstate-syntax.md)

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

@ -16,62 +16,24 @@ ms.topic: article
# Migration Store Encryption # Migration Store Encryption
This topic discusses User State Migration Tool (USMT) 10.0 options for migration store encryption to protect the integrity of user data during a migration. This topic discusses User State Migration Tool (USMT) 10.0 options for migration store encryption to protect the integrity of user data during a migration.
## USMT Encryption Options ## USMT Encryption Options
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. 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** and the **LoadState** 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** and the **LoadState** 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** and the **LoadState** 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** and the **LoadState** 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. The following table describes the command-line encryption options in USMT.
<table> |Component|Option|Description|
<colgroup> |--- |--- |--- |
<col width="33%" /> |**ScanState**|**/encrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the **ScanState** tool employs the 3DES algorithm.|
<col width="33%" /> |**LoadState**|**/decrypt**<*AES, AES_128, AES_192, AES_256, 3DES, 3DES_112*>|This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the **LoadState** tool employs the 3DES algorithm.|
<col width="33%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Component</th>
<th align="left">Option</th>
<th align="left">Description</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ScanState</strong></p></td>
<td align="left"><p><strong>/encrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the migration store is encrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>ScanState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>LoadState</strong></p></td>
<td align="left"><p><strong>/decrypt</strong><em>&lt;AES, AES_128, AES_192, AES_256, 3DES, 3DES_112&gt;</em></p></td>
<td align="left"><p>This option and argument specify that the store must be decrypted and which algorithm to use. When the algorithm argument is not provided, the <strong>LoadState</strong> tool employs the 3DES algorithm.</p></td>
</tr>
</tbody>
</table>
**Important**   **Important**  
Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the UsmtUtils command with the **/ec** option. For more information see [UsmtUtils Syntax](usmt-utilities.md) Some encryption algorithms may not be available on your systems. You can verify which algorithms are available by running the UsmtUtils command with the **/ec** option. For more information see [UsmtUtils Syntax](usmt-utilities.md)
## Related topics ## Related topics
[Plan Your Migration](usmt-plan-your-migration.md) [Plan Your Migration](usmt-plan-your-migration.md)

49
windows/deployment/usmt/usmt-plan-your-migration.md
View File

@ -16,7 +16,6 @@ ms.topic: article
# Plan Your Migration # Plan Your Migration
Before you use the User State Migration Tool (USMT) 10.0 to perform your migration, we recommend that you plan your migration carefully. Planning can help your migration proceed smoothly and can reduce the risk of migration failure. Before you use the User State Migration Tool (USMT) 10.0 to perform your migration, we recommend that you plan your migration carefully. Planning can help your migration proceed smoothly and can reduce the risk of migration failure.
In migration planning, both organizations and individuals must first identify what to migrate, including user settings, applications and application settings, and personal data files and folders. Identifying the applications to migrate is especially important so that you can avoid capturing data about applications that may be phased out. In migration planning, both organizations and individuals must first identify what to migrate, including user settings, applications and application settings, and personal data files and folders. Identifying the applications to migrate is especially important so that you can avoid capturing data about applications that may be phased out.
@ -25,48 +24,14 @@ One of the most important requirements for migrating settings and data is restor
## In This Section ## In This Section
| Link | Description |
<table> |--- |--- |
<colgroup> |[Common Migration Scenarios](usmt-common-migration-scenarios.md)|Determine whether you will perform a refresh migration or a replace migration.|
<col width="50%" /> |[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)|Learn which applications, user data, and operating system components USMT migrates.|
<col width="50%" /> |[Choose a Migration Store Type](usmt-choose-migration-store-type.md)|Choose an uncompressed, compressed, or hard-link migration store.|
</colgroup> |[Determine What to Migrate](usmt-determine-what-to-migrate.md)|Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.|
<tbody> |[Test Your Migration](usmt-test-your-migration.md)|Test your migration before you deploy Windows to all users.|
<tr class="odd">
<td align="left"><p><a href="usmt-common-migration-scenarios.md" data-raw-source="[Common Migration Scenarios](usmt-common-migration-scenarios.md)">Common Migration Scenarios</a></p></td>
<td align="left"><p>Determine whether you will perform a refresh migration or a replace migration.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-what-does-usmt-migrate.md" data-raw-source="[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)">What Does USMT Migrate?</a></p></td>
<td align="left"><p>Learn which applications, user data, and operating system components USMT migrates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-choose-migration-store-type.md" data-raw-source="[Choose a Migration Store Type](usmt-choose-migration-store-type.md)">Choose a Migration Store Type</a></p></td>
<td align="left"><p>Choose an uncompressed, compressed, or hard-link migration store.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-determine-what-to-migrate.md" data-raw-source="[Determine What to Migrate](usmt-determine-what-to-migrate.md)">Determine What to Migrate</a></p></td>
<td align="left"><p>Identify user accounts, application settings, operating system settings, and files that you want to migrate inside your organization.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-test-your-migration.md" data-raw-source="[Test Your Migration](usmt-test-your-migration.md)">Test Your Migration</a></p></td>
<td align="left"><p>Test your migration before you deploy Windows to all users.</p></td>
</tr>
</tbody>
</table>
## Related topics ## Related topics
[USMT XML Reference](usmt-xml-reference.md) [USMT XML Reference](usmt-xml-reference.md)

529
windows/deployment/usmt/usmt-recognized-environment-variables.md
View File

@ -31,441 +31,112 @@ When using the XML files MigDocs.xml, MigApp.xml, and MigUser.xml, you can use e
You can use these variables within sections in the .xml files with `context=UserAndSystem`, `context=User`, and `context=System`. You can use these variables within sections in the .xml files with `context=UserAndSystem`, `context=User`, and `context=System`.
<table> |Variable|Explanation|
<colgroup> |--- |--- |
<col width="50%" /> |**ALLUSERSAPPDATA**|Same as **CSIDL_COMMON_APPDATA**.|
<col width="50%" /> |**ALLUSERSPROFILE**|Refers to %**PROFILESFOLDER**%\Public or %**PROFILESFOLDER**%\all users.|
</colgroup> |**COMMONPROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES_COMMON**.|
<thead> |**COMMONPROGRAMFILES**(X86)|Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.|
<tr class="header"> |**CSIDL_COMMON_ADMINTOOLS**|Version 10.0. The file-system directory that contains administrative tools for all users of the computer.|
<th align="left">Variable</th> |**CSIDL_COMMON_ALTSTARTUP**|The file-system directory that corresponds to the non-localized Startup program group for all users.|
<th align="left">Explanation</th> |**CSIDL_COMMON_APPDATA**|The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.|
</tr> |**CSIDL_COMMON_DESKTOPDIRECTORY**|The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop.|
</thead> |**CSIDL_COMMON_DOCUMENTS**|The file-system directory that contains documents that are common to all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Documents. A typical path is C:\Users\Public\Documents.|
<tbody> |**CSIDL_COMMON_FAVORITES**|The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.|
<tr class="odd"> |**CSIDL_COMMON_MUSIC**|The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.|
<td align="left"><p><strong>ALLUSERSAPPDATA</strong></p></td> |**CSIDL_COMMON_PICTURES**|The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.|
<td align="left"><p>Same as <strong>CSIDL_COMMON_APPDATA</strong>.</p></td> |**CSIDL_COMMON_PROGRAMS**|The file-system directory that contains the directories for the common program groups that appear on the **Start** menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.|
</tr> |**CSIDL_COMMON_STARTMENU**|The file-system directory that contains the programs and folders which appear on the **Start** menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.|
<tr class="even"> |**CSIDL_COMMON_STARTUP**|The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.|
<td align="left"><p><strong>ALLUSERSPROFILE</strong></p></td> |**CSIDL_COMMON_TEMPLATES**|The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.|
<td align="left"><p>Refers to %<strong>PROFILESFOLDER</strong>%\Public or %<strong>PROFILESFOLDER</strong>%\all users.</p></td> |**CSIDL_COMMON_VIDEO**|The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.|
</tr> |**CSIDL_DEFAULT_APPDATA**|Refers to the Appdata folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="odd"> |C**SIDL_DEFAULT_LOCAL_APPDATA**|Refers to the local Appdata folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p><strong>COMMONPROGRAMFILES</strong></p></td> |**CSIDL_DEFAULT_COOKIES**|Refers to the Cookies folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES_COMMON</strong>.</p></td> |**CSIDL_DEFAULT_CONTACTS**|Refers to the Contacts folder inside %**DEFAULTUSERPROFILE**%.|
</tr> |**CSIDL_DEFAULT_DESKTOP**|Refers to the Desktop folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="even"> |**CSIDL_DEFAULT_DOWNLOADS**|Refers to the Downloads folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p><strong>COMMONPROGRAMFILES</strong>(X86)</p></td> |**CSIDL_DEFAULT_FAVORITES**|Refers to the Favorites folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p>Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.</p></td> |**CSIDL_DEFAULT_HISTORY**|Refers to the History folder inside %**DEFAULTUSERPROFILE**%.|
</tr> |**CSIDL_DEFAULT_INTERNET_CACHE**|Refers to the Internet Cache folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="odd"> |**CSIDL_DEFAULT_PERSONAL**|Refers to the Personal folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p><strong>CSIDL_COMMON_ADMINTOOLS</strong></p></td> |**CSIDL_DEFAULT_MYDOCUMENTS**|Refers to the My Documents folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p>Version 10.0. The file-system directory that contains administrative tools for all users of the computer.</p></td> |**CSIDL_DEFAULT_MYPICTURES**|Refers to the My Pictures folder inside %**DEFAULTUSERPROFILE**%.|
</tr> |**CSIDL_DEFAULT_MYMUSIC**|Refers to the My Music folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="even"> |**CSIDL_DEFAULT_MYVIDEO**|Refers to the My Videos folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p><strong>CSIDL_COMMON_ALTSTARTUP</strong></p></td> |**CSIDL_DEFAULT_RECENT**|Refers to the Recent folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p>The file-system directory that corresponds to the non-localized Startup program group for all users.</p></td> |**CSIDL_DEFAULT_SENDTO**|Refers to the Send To folder inside %**DEFAULTUSERPROFILE**%.|
</tr> |**CSIDL_DEFAULT_STARTMENU**|Refers to the Start Menu folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="odd"> |**CSIDL_DEFAULT_PROGRAMS**|Refers to the Programs folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p><strong>CSIDL_COMMON_APPDATA</strong></p></td> |**CSIDL_DEFAULT_STARTUP**|Refers to the Startup folder inside %**DEFAULTUSERPROFILE**%.|
<td align="left"><p>The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.</p></td> |**CSIDL_DEFAULT_TEMPLATES**|Refers to the Templates folder inside %**DEFAULTUSERPROFILE**%.|
</tr> |**CSIDL_DEFAULT_QUICKLAUNCH**|Refers to the Quick Launch folder inside %**DEFAULTUSERPROFILE**%.|
<tr class="even"> |**CSIDL_FONTS**|A virtual folder containing fonts. A typical path is C:\Windows\Fonts.|
<td align="left"><p><strong>CSIDL_COMMON_DESKTOPDIRECTORY</strong></p></td> |**CSIDL_PROGRAM_FILESX86**|The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).|
<td align="left"><p>The file-system directory that contains files and folders that appear on the desktop for all users. A typical Windows® XP path is C:\Documents and Settings\All Users\Desktop. A typical path is C:\Users\Public\Desktop.</p></td> |**CSIDL_PROGRAM_FILES_COMMONX86**|A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.|
</tr> |**CSIDL_PROGRAM_FILES**|The Program Files folder. A typical path is C:\Program Files.|
<tr class="odd"> |**CSIDL_PROGRAM_FILES_COMMON**|A folder for components that are shared across applications. A typical path is C:\Program Files\Common.|
<td align="left"><p><strong>CSIDL_COMMON_DOCUMENTS</strong></p></td> |**CSIDL_RESOURCES**|The file-system directory that contains resource data. A typical path is C:\Windows\Resources.|
<td align="left"><p>The file-system directory that contains documents that are common to all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Documents. A typical path is C:\Users\Public\Documents.</p></td> |**CSIDL_SYSTEM**|The Windows System folder. A typical path is C:\Windows\System32.|
</tr> |**CSIDL_WINDOWS**|The Windows directory or system root. This corresponds to the %**WINDIR**% or %**SYSTEMROOT**% environment variables. A typical path is C:\Windows.|
<tr class="even"> |**DEFAULTUSERPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]**.|
<td align="left"><p><strong>CSIDL_COMMON_FAVORITES</strong></p></td> |**PROFILESFOLDER**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]**.|
<td align="left"><p>The file-system directory that serves as a common repository for favorites common to all users. A typical path is C:\Users\Public\Favorites.</p></td> |**PROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES**.|
</tr> |**PROGRAMFILES(X86)**|Refers to the C:\Program Files (x86) folder on 64-bit systems.|
<tr class="odd"> |**SYSTEM**|Refers to %**WINDIR**%\system32.|
<td align="left"><p><strong>CSIDL_COMMON_MUSIC</strong></p></td> |**SYSTEM16**|Refers to %**WINDIR**%\system.|
<td align="left"><p>The file-system directory that serves as a repository for music files common to all users. A typical path is C:\Users\Public\Music.</p></td> |**SYSTEM32**|Refers to %**WINDIR**%\system32.|
</tr> |**SYSTEMPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]**.|
<tr class="even"> |**SYSTEMROOT**|Refers to the root of the system drive.|
<td align="left"><p><strong>CSIDL_COMMON_PICTURES</strong></p></td> |**WINDIR**|Refers to the Windows folder located on the system drive.|
<td align="left"><p>The file-system directory that serves as a repository for image files common to all users. A typical path is C:\Users\Public\Pictures.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_PROGRAMS</strong></p></td>
<td align="left"><p>The file-system directory that contains the directories for the common program groups that appear on the <strong>Start</strong> menu for all users. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains the programs and folders which appear on the <strong>Start</strong> menu for all users. A typical path in Windows is C:\ProgramData\Microsoft\Windows\Start Menu.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_STARTUP</strong></p></td>
<td align="left"><p>The file-system directory that contains the programs that appear in the Startup folder for all users. A typical path in Windows XP is C:\Documents and Settings\All Users\Start Menu\Programs\Startup. A typical path is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_TEMPLATES</strong></p></td>
<td align="left"><p>The file-system directory that contains the templates that are available to all users. A typical path is C:\ProgramData\Microsoft\Windows\Templates.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_VIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a repository for video files common to all users. A typical path is C:\Users\Public\Videos.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_APPDATA</strong></p></td>
<td align="left"><p>Refers to the Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p>C<strong>SIDL_DEFAULT_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>Refers to the local Appdata folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_COOKIES</strong></p></td>
<td align="left"><p>Refers to the Cookies folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_CONTACTS</strong></p></td>
<td align="left"><p>Refers to the Contacts folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_DESKTOP</strong></p></td>
<td align="left"><p>Refers to the Desktop folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_DOWNLOADS</strong></p></td>
<td align="left"><p>Refers to the Downloads folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_FAVORITES</strong></p></td>
<td align="left"><p>Refers to the Favorites folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_HISTORY</strong></p></td>
<td align="left"><p>Refers to the History folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_INTERNET_CACHE</strong></p></td>
<td align="left"><p>Refers to the Internet Cache folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PERSONAL</strong></p></td>
<td align="left"><p>Refers to the Personal folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYDOCUMENTS</strong></p></td>
<td align="left"><p>Refers to the My Documents folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYPICTURES</strong></p></td>
<td align="left"><p>Refers to the My Pictures folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_MYMUSIC</strong></p></td>
<td align="left"><p>Refers to the My Music folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_MYVIDEO</strong></p></td>
<td align="left"><p>Refers to the My Videos folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_RECENT</strong></p></td>
<td align="left"><p>Refers to the Recent folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_SENDTO</strong></p></td>
<td align="left"><p>Refers to the Send To folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTMENU</strong></p></td>
<td align="left"><p>Refers to the Start Menu folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_PROGRAMS</strong></p></td>
<td align="left"><p>Refers to the Programs folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_STARTUP</strong></p></td>
<td align="left"><p>Refers to the Startup folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DEFAULT_TEMPLATES</strong></p></td>
<td align="left"><p>Refers to the Templates folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DEFAULT_QUICKLAUNCH</strong></p></td>
<td align="left"><p>Refers to the Quick Launch folder inside %<strong>DEFAULTUSERPROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_FONTS</strong></p></td>
<td align="left"><p>A virtual folder containing fonts. A typical path is C:\Windows\Fonts.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILESX86</strong></p></td>
<td align="left"><p>The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMONX86</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications on 64-bit systems. A typical path is C:\Program Files(86)\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES</strong></p></td>
<td align="left"><p>The Program Files folder. A typical path is C:\Program Files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROGRAM_FILES_COMMON</strong></p></td>
<td align="left"><p>A folder for components that are shared across applications. A typical path is C:\Program Files\Common.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_RESOURCES</strong></p></td>
<td align="left"><p>The file-system directory that contains resource data. A typical path is C:\Windows\Resources.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_SYSTEM</strong></p></td>
<td align="left"><p>The Windows System folder. A typical path is C:\Windows\System32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_WINDOWS</strong></p></td>
<td align="left"><p>The Windows directory or system root. This corresponds to the %<strong>WINDIR</strong>% or %<strong>SYSTEMROOT</strong>% environment variables. A typical path is C:\Windows.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>DEFAULTUSERPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROFILESFOLDER</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>PROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>PROGRAMFILES(X86)</strong></p></td>
<td align="left"><p>Refers to the C:\Program Files (x86) folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEM16</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEM32</strong></p></td>
<td align="left"><p>Refers to %<strong>WINDIR</strong>%\system32.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>SYSTEMPROFILE</strong></p></td>
<td align="left"><p>Refers to the value in <strong>HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]</strong>.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>SYSTEMROOT</strong></p></td>
<td align="left"><p>Refers to the root of the system drive.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>WINDIR</strong></p></td>
<td align="left"><p>Refers to the Windows folder located on the system drive.</p></td>
</tr>
</tbody>
</table>
 
## <a href="" id="bkmk-2"></a>Variables that are recognized only in the user context ## <a href="" id="bkmk-2"></a>Variables that are recognized only in the user context
You can use these variables in the .xml files within sections with `context=User` and `context=UserAndSystem`. You can use these variables in the .xml files within sections with `context=User` and `context=UserAndSystem`.
<table> |Variable|Explanation|
<colgroup> |--- |--- |
<col width="50%" /> |**APPDATA**|Same as **CSIDL_APPDATA**.|
<col width="50%" /> |**CSIDL_ADMINTOOLS**|The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile.|
</colgroup> |**CSIDL_ALTSTARTUP**|The file-system directory that corresponds to the user's non-localized Startup program group.|
<thead> |**CSIDL_APPDATA**|The file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.|
<tr class="header"> |**CSIDL_BITBUCKET**|The virtual folder that contains the objects in the user's Recycle Bin.|
<th align="left">Variable</th> |**CSIDL_CDBURN_AREA**|The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning.|
<th align="left">Explanation</th> |**CSIDL_CONNECTIONS**|The virtual folder representing Network Connections that contains network and dial-up connections.|
</tr> |**CSIDL_CONTACTS**|This refers to the Contacts folder in %**CSIDL_PROFILE**%.|
</thead> |**CSIDL_CONTROLS**|The virtual folder that contains icons for the Control Panel items.|
<tbody> |**CSIDL_COOKIES**|The file-system directory that serves as a common repository for Internet cookies. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies.|
<tr class="odd"> |**CSIDL_DESKTOP**|The virtual folder representing the Windows desktop.|
<td align="left"><p><strong>APPDATA</strong></p></td> |**CSIDL_DESKTOPDIRECTORY**|The file-system directory used to physically store file objects on the desktop, which should not be confused with the desktop folder itself. A typical path is C:\Users\username\Desktop.|
<td align="left"><p>Same as <strong>CSIDL_APPDATA</strong>.</p></td> |**CSIDL_DRIVES**|The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.|
</tr> |**CSIDL_FAVORITES**|The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.|
<tr class="even"> |**CSIDL_HISTORY**|The file-system directory that serves as a common repository for Internet history items.|
<td align="left"><p><strong>CSIDL_ADMINTOOLS</strong></p></td> |**CSIDL_INTERNET**|A virtual folder for Internet Explorer.|
<td align="left"><p>The file-system directory that is used to store administrative tools for an individual user. The Microsoft® Management Console (MMC) saves customized consoles to this directory, which roams with the user profile.</p></td> |**CSIDL_INTERNET_CACHE**|The file-system directory that serves as a common repository for temporary Internet files. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files|
</tr> |**CSIDL_LOCAL_APPDATA**|The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.|
<tr class="odd"> |**CSIDL_MYDOCUMENTS**|The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.|
<td align="left"><p><strong>CSIDL_ALTSTARTUP</strong></p></td> |**CSIDL_MYMUSIC**|The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.|
<td align="left"><p>The file-system directory that corresponds to the user's non-localized Startup program group.</p></td> |**CSIDL_MYPICTURES**|The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.|
</tr> |**CSIDL_MYVIDEO**|The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.|
<tr class="even"> |**CSIDL_NETHOOD**|A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.|
<td align="left"><p><strong>CSIDL_APPDATA</strong></p></td> |**CSIDL_NETWORK**|A virtual folder representing My Network Places, the root of the network namespace hierarchy.|
<td align="left"><p>The file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.</p></td> |**CSIDL_PERSONAL**|The virtual folder representing the My Documents desktop item. This is equivalent to **CSIDL_MYDOCUMENTS**. <br/>A typical path is C:\Documents and Settings\username\My Documents.|
</tr> |**CSIDL_PLAYLISTS**|The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.|
<tr class="odd"> |**CSIDL_PRINTERS**|The virtual folder that contains installed printers.|
<td align="left"><p><strong>CSIDL_BITBUCKET</strong></p></td> |**CSIDL_PRINTHOOD**|The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Printer Shortcuts.|
<td align="left"><p>The virtual folder that contains the objects in the user's Recycle Bin.</p></td> |**CSIDL_PROFILE**|The user's profile folder. A typical path is C:\Users\Username.|
</tr> |**CSIDL_PROGRAMS**|The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.|
<tr class="even"> |**CSIDL_RECENT**|The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent.|
<td align="left"><p><strong>CSIDL_CDBURN_AREA</strong></p></td> |**CSIDL_SENDTO**|The file-system directory that contains **Send To** menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.|
<td align="left"><p>The file-system directory acting as a staging area for files waiting to be written to CD. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\MasteredBurning\Disc Burning.</p></td> |**CSIDL_STARTMENU**|The file-system directory that contains **Start** menu items. A typical path in Windows XP is C:\Documents and Settings\username\Start Menu. A typical path in Windows Vista, Windows 7, or Windows 8 is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu.|
</tr> |**CSIDL_STARTUP**|The file-system directory that corresponds to the user's Startup program group. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.|
<tr class="odd"> |**CSIDL_TEMPLATES**|The file-system directory that serves as a common repository for document templates. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Templates.|
<td align="left"><p><strong>CSIDL_CONNECTIONS</strong></p></td> |**HOMEPATH**|Same as the standard environment variable.|
<td align="left"><p>The virtual folder representing Network Connections that contains network and dial-up connections.</p></td> |**TEMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.|
</tr> |**TMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.|
<tr class="even"> |**USERPROFILE**|Same as **CSIDL_PROFILE**.|
<td align="left"><p><strong>CSIDL_CONTACTS</strong></p></td> |**USERSID**|Represents the current user-account security identifier (SID). For example, <br/>S-1-5-21-1714567821-1326601894-715345443-1026.|
<td align="left"><p>This refers to the Contacts folder in %<strong>CSIDL_PROFILE</strong>%.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONTROLS</strong></p></td>
<td align="left"><p>The virtual folder that contains icons for the Control Panel items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COOKIES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for Internet cookies. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Cookies.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DESKTOP</strong></p></td>
<td align="left"><p>The virtual folder representing the Windows desktop.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_DESKTOPDIRECTORY</strong></p></td>
<td align="left"><p>The file-system directory used to physically store file objects on the desktop, which should not be confused with the desktop folder itself. A typical path is C:\Users\username\Desktop.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_DRIVES</strong></p></td>
<td align="left"><p>The virtual folder representing My Computer that contains everything on the local computer: storage devices, printers, and Control Panel. The folder may also contain mapped network drives.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_FAVORITES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for the user's favorites. A typical path is C:\Users\Username\Favorites.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_HISTORY</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for Internet history items.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_INTERNET</strong></p></td>
<td align="left"><p>A virtual folder for Internet Explorer.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_INTERNET_CACHE</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for temporary Internet files. A typical path is C:\Users\username\AppData\Local\Microsoft\Windows\Temporary Internet Files</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_LOCAL_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that serves as a data repository for local, non-roaming applications. A typical path is C:\Users\username\AppData\Local.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYDOCUMENTS</strong></p></td>
<td align="left"><p>The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYMUSIC</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_MYPICTURES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_MYVIDEO</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_NETHOOD</strong></p></td>
<td align="left"><p>A file-system directory that contains the link objects that may exist in the My Network Places virtual folder. It is not the same as CSIDL_NETWORK, which represents the network namespace root. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Network Shortcuts.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_NETWORK</strong></p></td>
<td align="left"><p>A virtual folder representing My Network Places, the root of the network namespace hierarchy.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PERSONAL</strong></p></td>
<td align="left"><p>The virtual folder representing the My Documents desktop item. This is equivalent to <strong>CSIDL_MYDOCUMENTS</strong>.</p>
<p>A typical path is C:\Documents and Settings\username\My Documents.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PLAYLISTS</strong></p></td>
<td align="left"><p>The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PRINTERS</strong></p></td>
<td align="left"><p>The virtual folder that contains installed printers.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PRINTHOOD</strong></p></td>
<td align="left"><p>The file-system directory that contains the link objects that can exist in the Printers virtual folder. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Printer Shortcuts.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_PROFILE</strong></p></td>
<td align="left"><p>The user's profile folder. A typical path is C:\Users\Username.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_PROGRAMS</strong></p></td>
<td align="left"><p>The file-system directory that contains the user's program groups, which are themselves file-system directories. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_RECENT</strong></p></td>
<td align="left"><p>The file-system directory that contains shortcuts to the user's most recently used documents. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Recent.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_SENDTO</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Send To</strong> menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_STARTMENU</strong></p></td>
<td align="left"><p>The file-system directory that contains <strong>Start</strong> menu items. A typical path in Windows XP is C:\Documents and Settings\username\Start Menu. A typical path in Windows Vista, Windows 7, or Windows 8 is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_STARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the user's Startup program group. A typical path is C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_TEMPLATES</strong></p></td>
<td align="left"><p>The file-system directory that serves as a common repository for document templates. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\Templates.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>HOMEPATH</strong></p></td>
<td align="left"><p>Same as the standard environment variable.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>TEMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>TMP</strong></p></td>
<td align="left"><p>The temporary folder on the computer. A typical path is %<strong>USERPROFILE</strong>%\AppData\Local\Temp.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>USERPROFILE</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROFILE</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>USERSID</strong></p></td>
<td align="left"><p>Represents the current user-account security identifier (SID). For example,</p>
<p>S-1-5-21-1714567821-1326601894-715345443-1026.</p></td>
</tr>
</tbody>
</table>
 
## Related topics ## Related topics
[USMT XML Reference](usmt-xml-reference.md) [USMT XML Reference](usmt-xml-reference.md)
 
 

59
windows/deployment/usmt/usmt-reference.md
View File

@ -16,63 +16,22 @@ ms.topic: article
# User State Migration Toolkit (USMT) Reference # User State Migration Toolkit (USMT) Reference
## In This Section ## In This Section
| Link | Description |
<table> |--- |--- |
<colgroup> |[USMT Requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.|
<col width="50%" /> |[USMT Best Practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.|
<col width="50%" /> |[How USMT Works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.|
</colgroup> |[Plan Your Migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.|
<tbody> |[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.|
<tr class="odd"> |[USMT XML Reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.|
<td align="left"><p><a href="usmt-requirements.md" data-raw-source="[USMT Requirements](usmt-requirements.md)">USMT Requirements</a></p></td> |[Offline Migration Reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.|
<td align="left"><p>Describes operating system, hardware, and software requirements, and user prerequisites.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-best-practices.md" data-raw-source="[USMT Best Practices](usmt-best-practices.md)">USMT Best Practices</a></p></td>
<td align="left"><p>Discusses general and security-related best practices when using USMT.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-how-it-works.md" data-raw-source="[How USMT Works](usmt-how-it-works.md)">How USMT Works</a></p></td>
<td align="left"><p>Learn about the processes behind the ScanState and LoadState tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-plan-your-migration.md" data-raw-source="[Plan Your Migration](usmt-plan-your-migration.md)">Plan Your Migration</a></p></td>
<td align="left"><p>Choose what to migrate and the best migration scenario for your enterprise.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="usmt-command-line-syntax.md" data-raw-source="[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)">User State Migration Tool (USMT) Command-line Syntax</a></p></td>
<td align="left"><p>Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.</p></td>
</tr>
<tr class="even">
<td align="left"><p><a href="usmt-xml-reference.md" data-raw-source="[USMT XML Reference](usmt-xml-reference.md)">USMT XML Reference</a></p></td>
<td align="left"><p>Learn about customizing a migration with XML files.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><a href="offline-migration-reference.md" data-raw-source="[Offline Migration Reference](offline-migration-reference.md)">Offline Migration Reference</a></p></td>
<td align="left"><p>Find requirements, best practices, and other considerations for performing a migration offline.</p></td>
</tr>
</tbody>
</table>
## Related topics ## Related topics
[User State Migration Tool (USMT) Overview Topics](usmt-topics.md) [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
[User State Migration Tool (USMT) How-to topics](usmt-how-to.md) [User State Migration Tool (USMT) How-to topics](usmt-how-to.md)
[User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md) [User State Migration Tool (USMT) Troubleshooting](usmt-troubleshooting.md)