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

Merge branch 'master' into v-smandalika-5494946-B3

Browse Source
This commit is contained in:
Daniel Simpson
2021-12-02 12:09:47 -08:00
committed by GitHub
parent 5f35d7f1d4 1735ee5c6b
commit dacaa74035
22 changed files with 530 additions and 2363 deletions
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 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.
@ -33,7 +32,6 @@ When you use User State Migration Tool (USMT) 10.0 to gather and restore user s
## In This topic
- [What Will Migrate Offline?](#bkmk-whatwillmigrate)
- [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?
The following user data and settings migrate offline, similar to an online migration:
- 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?
The following table defines the supported combination of online and offline operating systems in USMT.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</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>
|Running Operating System|Offline Operating System|
|--- |--- |
|WinPE 5.0 or greater, with the MSXML library|Windows Vista, Windows 7, Windows 8, Windows 10|
|Windows 7, Windows 8, Windows 10|Windows.old directory|
**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)).
## <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:
``` 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
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>
<colgroup>
<col width="33%" />
<col width="33%" />
<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>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>
|Component|Option|Description|
|--- |--- |--- |
|ScanState.exe|**/offline:***&lt;path to offline.xml&gt;*|This command-line option enables the offline-migration mode and requires a path to an Offline.xml configuration file.|
|ScanState.exe|**/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.|
|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.|
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
The following system environment variables are necessary in the scenarios outlined below.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<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>
|Variable|Value|Scenario|
|--- |--- |--- |
|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>|
|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>|
## <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.
### <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
[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
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.
## In This topic
[Overview of the Config.xml file](#bkmk-config)
[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
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
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**  
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.
> [!Important]
> 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
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:
@ -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
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 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 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
@ -166,7 +156,7 @@ The default MigUser.xml file migrates the following:
- 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:
@ -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.
**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.
> [!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 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
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>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<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>
|XML migration file|Modifies the following components:|
|--- |--- |
|Config.xml file|Operating-system components such as desktop wallpaper and background theme. <br/>You can also overload config.xml to include some application and document settings by generating the config.xml file with the other default XML files. For more information, see [Customize USMT XML Files](usmt-customize-xml-files.md) and [Config.xml File](usmt-configxml-file.md).|
|MigApps.xml file|Applications settings.|
|MigUser.xml or MigDocs.xml files|User files and profile settings.|
|Custom XML files|Application settings, user profile settings, or user files, beyond the rules contained in the other XML files.|
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
```
### <a href="" id="bkmk-userfiles"></a>XML rules for migrating user files
**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.
> [!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.
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
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**  
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.
> [!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.
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:
```
```console
cd /d <USMTpath>
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:
```
```console
cd /d c:\USMT
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.
<table>
<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>
- `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.
**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:**
```
```console
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
**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.
> [!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.
### <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
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>
<colgroup>
<col width="50%" />
<col width="50%" />
</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>
| Rule | Syntax |
|--- |--- |
|Rule 1|`<pattern type="File">d:\new folder[new text document.txt]</pattern>`|
|Rule 2|`<pattern type="File">d:\new folder[]</pattern>`|
To exclude the new text document.txt file as well as any .txt files in "new folder", you can do the following:
To exclude the new text document.txt file and any .txt files in "new folder", you can do the following:
**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).
**Note**  
For more information about the order of precedence for XML migration rules, see [Conflicts and Precedence](usmt-conflicts-and-precedence.md).
> [!NOTE]
> 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
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 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 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
[Exclude Files and Settings](usmt-exclude-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
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<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>
| Link | Description |
|--- |--- |
|[Migration Store Types Overview](migration-store-types-overview.md)|Choose the migration store type that works best for your needs and migration scenario.|
|[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.|
|[Hard-Link Migration Store](usmt-hard-link-migration-store.md)|Learn about hard-link migration stores and the scenarios in which they are used.|
|[Migration Store Encryption](usmt-migration-store-encryption.md)|Learn about the using migration store encryption to protect user data integrity during a migration.|
## Related topics
[Plan Your Migration](usmt-plan-your-migration.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
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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</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>
| Link | Description |
|--- |--- |
|[ScanState Syntax](usmt-scanstate-syntax.md)|Lists the command-line options for using the ScanState tool.|
|[LoadState Syntax](usmt-loadstate-syntax.md)|Lists the command-line options for using the LoadState tool.|
|[UsmtUtils Syntax](usmt-utilities.md)|Lists the command-line options for using the UsmtUtils tool.|

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

@ -16,10 +16,8 @@ ms.topic: article
# 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.
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**  
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 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)
@ -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;
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>`
## <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.
- **Number of occurrences**: Once for each component
@ -108,10 +101,8 @@ Additionally, the order in the **&lt;ErrorControl&gt;** section implies priority
</ErrorControl>
```
**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.
> [!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.
### <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>`
<table>
<colgroup>
<col width="33%" />
<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>
|Parameter|Required|Value|
|--- |--- |--- |
|errorCode|No|"any" or "*specify system error message here*"|
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;
The **&lt;fileError&gt;** element is not required.
- **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;
The **&lt;nonFatal&gt;** element is not required.
- **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>`
<table>
<colgroup>
<col width="33%" />
<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>
|Parameter|Required|Value|
|--- |--- |--- |
|**&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.|
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;
The <strong>&lt;registryError&gt;</strong>element is not required.
- **Number of occurrences**: Once for each component
@ -218,35 +166,14 @@ The <strong>&lt;registryError&gt;</strong>element is not required.
Syntax: `<registryError></registryError>`
<table>
<colgroup>
<col width="33%" />
<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>
|Parameter|Required|Value|
|--- |--- |--- |
|**&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.|
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;
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>`
@ -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.
**Important**  
The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file’s location.
> [!IMPORTANT]
> The **&lt;ErrorControl&gt;** section can be configured to conditionally ignore file access errors, based on the file’s location.
``` xml
<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;
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>`
## <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.
Syntax: `<createHardLink>`*&lt;pattern&gt;*`</createHardLink>`
## <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.
Syntax: `<errorHardLink>`*&lt;pattern&gt;*`</errorHardLink>`
## <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;**.
Syntax: &lt;`ProfileControl> </ProfileControl>`
## <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;**.
Syntax: `<localGroups> </localGroups>`
## <a href="" id="bkmk-mappings"></a>&lt;mappings&gt;
This element is used to contain other elements that establish mappings between groups.
Syntax: `<mappings> </mappings>`
## <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:
<table>
<colgroup>
<col width="33%" />
<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>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>
|Parameter|Required|Value|
|--- |--- |--- |
|From|Yes|A valid local group on the source machine that contains users selected for migration on the command line.|
|To|Yes|A local group that the users are to be moved to during the migration.|
|appliesTo|Yes|nonmigratedUsers, migratedUsers, AllUsers. This value defines which users the change group operation should apply to.|
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;
This element specifies that its required child, *&lt;pattern&gt;*, should be included in the migration.
Syntax: `<include>``</include>`
## <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.
Syntax: `<exclude>`` </exclude>`
## <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.
```xml
@ -577,14 +464,4 @@ Refer to the following sample Config.xml file for additional details about items
## Related topics
[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
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.
@ -33,7 +32,6 @@ When you include, exclude, and reroute files and settings, it is important to kn
## In this topic
**General**
- [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
### <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.
@ -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="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.
@ -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
<table>
<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 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 the same component | Resulting behavior | Explanation |
|-----|-----|-----|
| <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. |
| <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. |
| <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. |
| <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. |
| <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. |
| <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. |
<table>
<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: &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>
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|----|----|
| 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. |
| 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. |
| 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. |
### <a href="" id="regex"></a>Including and excluding registry objects
<table>
<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 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 the same component | Resulting behavior | Explanation |
|-----|-----|-----|
| <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. |
| <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. |
| <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. |
<table>
<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>
| If you have the following code in different components | Resulting behavior | Explanation |
|-----|-----|-----|
| 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. |
## 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.
@ -399,67 +218,49 @@ You have a custom .xml file that contains the following code:
</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>
<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>
**Example 1**
```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
[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
**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
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
@ -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
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>
<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>
`<condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>`
- **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 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
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>
<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>
`<pattern type="File">%ProgramFiles%\USMTTestFolder* [USMTTestFile.txt]</pattern>`
- **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
<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
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
<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>
<role role="Data">
<rules>
<include>
<include>
<objectSet>
<pattern type="File"> C:\UserDocuments\* [*]</pattern>
</objectSet>
</include>
<exclude>
<exclude>
<objectSet>
<pattern type="File"> C:\UserDocuments\ [Sample.doc]</pattern>
</objectSet>
@ -277,9 +229,9 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
<rules>
<include>
<objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("\Requests\* [*] ", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("*\Requests\* [*] ", "Fixed")</script>
</objectSet>
<script>MigXmlHelper.GenerateDrivePatterns ("\Requests\* [*] ", "Fixed")</script>
<script>MigXmlHelper.GenerateDrivePatterns ("*\Requests\* [*] ", "Fixed")</script>
</objectSet>
</include>
</rules>
</role>
@ -291,8 +243,8 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
<rules>
<include>
<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>
</include>
</rules>
@ -303,16 +255,6 @@ The behavior for this custom .xml file is described within the &lt;`displayName`
## Related topics
[USMT XML Reference](usmt-xml-reference.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
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<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>
| Link | Description |
|--- |--- |
|[Identify Users](usmt-identify-users.md)|Use command-line options to specify which users to migrate and how they should be migrated.|
|[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.|
|[Identify Operating System Settings](usmt-identify-operating-system-settings.md)|Use migration to create a new standard environment on each of the destination computers.|
|[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.|
## 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
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
[When to Use a Hard-Link Migration](#bkmk-when)
[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
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.
@ -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 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.
## <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.
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**  
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.
> [!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.
For more information about hard links, please see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
For more information about hard links, see [Hard Links and Junctions](/windows/win32/fileio/hard-links-and-junctions)
In most aspects, a hard-link migration store is identical to an uncompressed migration store. It 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.
**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.
> [!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.
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.
**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.
> [!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.
## <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.
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**  
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.
> [!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.
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]
> 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.
### <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
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
@ -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 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**  
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.
> [!IMPORTANT]
> There are some scenarios in which modifying the `<HardLinkStoreControl>` section in the Config.xml file makes it more difficult to delete a hard-link migration store. In these scenarios, you must use USMTutils.exe to schedule the migration store for deletion on the next restart.
## <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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<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>
| Element | Description |
|--- |--- |
| `<Policies>` | This element contains elements that describe the policies that USMT follows while creating a migration store. |
| `<HardLinkStoreControl>` | This element contains elements that describe how to handle files during the creation of a hard link migration store. |
| `<fileLocked>` | This element contains elements that describe how to handle files that are locked for editing. |
| `<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>` |
| `<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>` |
> [!IMPORTANT]
> You must use the **/nocompress** option with the **/HardLink** option.
**Important**  
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.
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.
``` xml
<Policies>
@ -226,8 +182,4 @@ The following XML sample specifies that files locked by an application under the
## Related topics
[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
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
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.
@ -55,7 +36,6 @@ Before you run the **LoadState** command, note the following:
## <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.
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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<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><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>
| Command-Line Option | Description |
|--- |--- |
| `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*. |
| `/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` |
| `/decrypt:`*"encryption strength"* | The `/decrypt` option accepts a command-line parameter to define the encryption strength specified for the migration store encryption. For more information about supported encryption algorithms, see [Migration Store Encryption](usmt-migration-store-encryption.md). |
| `/hardlink` | Enables user-state data to be restored from a hard-link migration store. The `/nocompress` parameter must be specified with `/hardlink` option. |
| `/nocompress` | Specifies that the store 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` |
## <a href="" id="bkmk-mig"></a>Migration Rule Options
USMT provides the following options to specify what files you want to migrate.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<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>
| Command-Line Option | Description |
|--- |--- |
| `/i`:[*Path*]*FileName* | **(include)** <br/>Specifies an .xml file that contains rules that define what state to migrate. You can specify this option multiple times to include all of your .xml files (MigApp.xml, MigSys.xml, MigDocs.xml and any custom .xml files that you create). *Path* can be either a relative or full path. If you 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. |
| `/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` |
| `/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`. |
## <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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<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>/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>
| Command-Line Option | Description |
|--- |--- |
| `/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. |
| `/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` |
| `/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` |
| `/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. |
| `/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. |
| `/w:`*`<SecondsBeforeRetry>`* | **(Wait)** <br/><br/>Specifies the time to wait, in seconds, before retrying a network file operation. The default is 1 second. |
| `/?` or `/help` | Displays Help on the command line. |
## <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).
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<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>/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>
| Command-Line Option | Description |
|--- |--- |
| `/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. |
| `/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. |
| `/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` |
| `/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. |
| `/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` |
| `/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` |
| `/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). |
| `/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). |
### 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Behavior</th>
<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>
| Behavior | Command |
|--- |--- |
| Exclude the user named User One in the Corporate domain. | `/ue:"corporate\user one"` |
| Exclude the user named User1 in the Corporate domain. | `/ue:corporate\user1` |
| Exclude the local user named User1. | `/ue:%computername%\user1` |
| Exclude all domain users. | `/ue:Domain` |
| Exclude all local users. | `/ue:%computername%` |
| Exclude users in all domains named User1, User2, and so on. | `/ue:\user` |
### 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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<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>
| Behavior | Command |
|--- |--- |
| Include only User2 from the Fabrikam domain and exclude all other users. | `/ue:* /ui:fabrikam\user2` |
| Include only the local user named User1 and exclude all other users. | `/ue:* /ui:user1` |
| 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> |
| Include only local (non-domain) users. | `/ue: /ui:%computername%*` |
## <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.
<table>
<colgroup>
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
<col width="20%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Command-Line Option</th>
<th align="left">/keyfile</th>
<th align="left">/nocompress</th>
<th align="left">/genconfig</th>
<th align="left">/all</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>/i</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>/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.
| Command-Line Option | /keyfile | /nocompress | /genconfig | /all |
|--- |--- |--- |--- |--- |
| **/i** | | | | |
| **/v** | | | | |
| **/nocompress** | | N/A | X | |
| **/key** | X | | X | |
| **/decrypt** | Required* | X | X | |
| **/keyfile** | N/A | | X | |
| **/l** | | | | |
| **/progress** | | | X | |
| **/r** | | | X | |
| **/w** | | | X | |
| **/c** | | | X | |
| **/p** | | | X | N/A |
| **/all** | | | X | |
| **/ui** | | | X | X |
| **/ue** | | | X | X |
| **/uel** | | | X | X |
| **/genconfig** | | | N/A | |
| **/config** | | | X | |
| *StorePath* | | | | |
| **/md** | | | | |
| **/mu** | | | | |
| **/lae** | | | | |
| **/lac** | | | | |
> [!NOTE]
> You must specify either the **/key** or **/keyfile** option with the **/encrypt** option.
## Related topics
[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
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)
@ -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
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>
<colgroup>
<col width="33%" />
<col width="33%" />
<col width="33%" />
</colgroup>
<thead>
<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>
|Command line Option|File Name|Description|
|--- |--- |--- |
|**/l** *[Path]FileName*|Scanstate.log or LoadState.log|Specifies the path and file name of the ScanState.log or LoadState log.|
|**/progress** *[Path]FileName*|Specifies the path and file name of the Progress log.|Provides information about the status of the migration, by percentage complete.|
|**/v** *[VerbosityLevel]*|Not applicable|See the "Monitoring Options" section in [ScanState Syntax](usmt-scanstate-syntax.md).|
|**/listfiles** *[Path]FileName*|Specifies the path and file name of the Listfiles log.|Provides a list of the files that were migrated.|
|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.|
**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
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
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.
@ -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.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Key</th>
<th align="left">Value</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p>program</p></td>
<td align="left"><p>ScanState.exe or LoadState.exe.</p></td>
</tr>
<tr class="even">
<td align="left"><p>productVersion</p></td>
<td align="left"><p>The full product version number of USMT.</p></td>
</tr>
<tr class="odd">
<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>
| Key | Value |
|-----|-------|
| program | ScanState.exe or LoadState.exe. |
| productVersion | The full product version number of USMT. |
| computerName | The name of the source or destination computer on which USMT was run. |
| commandLine | The full command used to run USMT. |
| 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> |
| 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> |
| includedInMigration | Defines whether the user profile/component is included for migration. Valid values are Yes or No. |
| 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> |
| 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> |
| totalSizeInMBToTransfer | Total size of the files and settings to migrate in megabytes (MB). |
| totalPercentageCompleted | Total percentage of the migration that has been completed by either ScanState or LoadState. |
| collectingUser | Specifies which user ScanState is collecting files and settings for. |
| totalMinutesRemaining | Time estimate, in minutes, for the migration to complete. |
| 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> |
| objectName | The name of the file or setting that caused the non-fatal error. |
| 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> |
| errorCode | The errorCode or return value. |
| numberOfIgnoredErrors | The total number of non-fatal errors that USMT ignored. |
| message | The message corresponding to the errorCode. |
## <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.
## <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.
The diagnostic log contains:
@ -244,7 +99,6 @@ The diagnostic log contains:
## 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 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:
```
```console
01/21/2009 10:08 PM <DIR> .
01/21/2009 10:08 PM <DIR> ..
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:
```
```console
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
@ -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:
``` xml
```xml
<MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<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:
``` xml
```xml
<pattern type="File">c:\data\* [*]</pattern>
```
When the migration is preformed again with the modified tag, the diagnostic log reveals the following:
``` xml
```xml
<MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<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:
```
```console
Directory of C:\Data
01/21/2009 10:08 PM <DIR> .
@ -360,7 +214,7 @@ Directory of C:\Data
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 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:
``` xml
```xml
<MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<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:
``` xml
```xml
<MigUnitList>
<MigUnit Name="&lt;System&gt;\DATA1 (CMXEAgent)" Context="System" ConfidenceLevel="100" Group="Applications" Role="UserData" Agent="CMXEAgent" Selected="true" Supported="true">
<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)

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

@ -16,62 +16,24 @@ ms.topic: article
# 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.
## 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.
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.
<table>
<colgroup>
<col width="33%" />
<col width="33%" />
<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>
|Component|Option|Description|
|--- |--- |--- |
|**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.|
|**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.|
**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)
## Related topics
[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
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.
@ -25,48 +24,14 @@ One of the most important requirements for migrating settings and data is restor
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<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>
| Link | Description |
|--- |--- |
|[Common Migration Scenarios](usmt-common-migration-scenarios.md)|Determine whether you will perform a refresh migration or a replace migration.|
|[What Does USMT Migrate?](usmt-what-does-usmt-migrate.md)|Learn which applications, user data, and operating system components USMT migrates.|
|[Choose a Migration Store Type](usmt-choose-migration-store-type.md)|Choose an uncompressed, compressed, or hard-link migration store.|
|[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.|
|[Test Your Migration](usmt-test-your-migration.md)|Test your migration before you deploy Windows to all users.|
## Related topics
[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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>ALLUSERSAPPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_COMMON_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>ALLUSERSPROFILE</strong></p></td>
<td align="left"><p>Refers to %<strong>PROFILESFOLDER</strong>%\Public or %<strong>PROFILESFOLDER</strong>%\all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_PROGRAM_FILES_COMMON</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>COMMONPROGRAMFILES</strong>(X86)</p></td>
<td align="left"><p>Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_ADMINTOOLS</strong></p></td>
<td align="left"><p>Version 10.0. The file-system directory that contains administrative tools for all users of the computer.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the non-localized Startup program group for all users.</p></td>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_APPDATA</strong></p></td>
<td align="left"><p>The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_DESKTOPDIRECTORY</strong></p></td>
<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>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_DOCUMENTS</strong></p></td>
<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>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_FAVORITES</strong></p></td>
<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>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_COMMON_MUSIC</strong></p></td>
<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>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_COMMON_PICTURES</strong></p></td>
<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>
 
|Variable|Explanation|
|--- |--- |
|**ALLUSERSAPPDATA**|Same as **CSIDL_COMMON_APPDATA**.|
|**ALLUSERSPROFILE**|Refers to %**PROFILESFOLDER**%\Public or %**PROFILESFOLDER**%\all users.|
|**COMMONPROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES_COMMON**.|
|**COMMONPROGRAMFILES**(X86)|Refers to the C:\Program Files (x86)\Common Files folder on 64-bit systems.|
|**CSIDL_COMMON_ADMINTOOLS**|Version 10.0. The file-system directory that contains administrative tools for all users of the computer.|
|**CSIDL_COMMON_ALTSTARTUP**|The file-system directory that corresponds to the non-localized Startup program group for all users.|
|**CSIDL_COMMON_APPDATA**|The file-system directory that contains application data for all users. A typical path Windows is C:\ProgramData.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**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.|
|**CSIDL_DEFAULT_APPDATA**|Refers to the Appdata folder inside %**DEFAULTUSERPROFILE**%.|
|C**SIDL_DEFAULT_LOCAL_APPDATA**|Refers to the local Appdata folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_COOKIES**|Refers to the Cookies folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_CONTACTS**|Refers to the Contacts folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_DESKTOP**|Refers to the Desktop folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_DOWNLOADS**|Refers to the Downloads folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_FAVORITES**|Refers to the Favorites folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_HISTORY**|Refers to the History folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_INTERNET_CACHE**|Refers to the Internet Cache folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_PERSONAL**|Refers to the Personal folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_MYDOCUMENTS**|Refers to the My Documents folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_MYPICTURES**|Refers to the My Pictures folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_MYMUSIC**|Refers to the My Music folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_MYVIDEO**|Refers to the My Videos folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_RECENT**|Refers to the Recent folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_SENDTO**|Refers to the Send To folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_STARTMENU**|Refers to the Start Menu folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_PROGRAMS**|Refers to the Programs folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_STARTUP**|Refers to the Startup folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_TEMPLATES**|Refers to the Templates folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_DEFAULT_QUICKLAUNCH**|Refers to the Quick Launch folder inside %**DEFAULTUSERPROFILE**%.|
|**CSIDL_FONTS**|A virtual folder containing fonts. A typical path is C:\Windows\Fonts.|
|**CSIDL_PROGRAM_FILESX86**|The Program Files folder on 64-bit systems. A typical path is C:\Program Files(86).|
|**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.|
|**CSIDL_PROGRAM_FILES**|The Program Files folder. A typical path is C:\Program Files.|
|**CSIDL_PROGRAM_FILES_COMMON**|A folder for components that are shared across applications. A typical path is C:\Program Files\Common.|
|**CSIDL_RESOURCES**|The file-system directory that contains resource data. A typical path is C:\Windows\Resources.|
|**CSIDL_SYSTEM**|The Windows System folder. A typical path is C:\Windows\System32.|
|**CSIDL_WINDOWS**|The Windows directory or system root. This corresponds to the %**WINDIR**% or %**SYSTEMROOT**% environment variables. A typical path is C:\Windows.|
|**DEFAULTUSERPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [DefaultUserProfile]**.|
|**PROFILESFOLDER**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList [ProfilesDirectory]**.|
|**PROGRAMFILES**|Same as **CSIDL_PROGRAM_FILES**.|
|**PROGRAMFILES(X86)**|Refers to the C:\Program Files (x86) folder on 64-bit systems.|
|**SYSTEM**|Refers to %**WINDIR**%\system32.|
|**SYSTEM16**|Refers to %**WINDIR**%\system.|
|**SYSTEM32**|Refers to %**WINDIR**%\system32.|
|**SYSTEMPROFILE**|Refers to the value in **HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\S-1-5-18 [ProfileImagePath]**.|
|**SYSTEMROOT**|Refers to the root of the system drive.|
|**WINDIR**|Refers to the Windows folder located on the system drive.|
## <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`.
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<thead>
<tr class="header">
<th align="left">Variable</th>
<th align="left">Explanation</th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td align="left"><p><strong>APPDATA</strong></p></td>
<td align="left"><p>Same as <strong>CSIDL_APPDATA</strong>.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_ADMINTOOLS</strong></p></td>
<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>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_ALTSTARTUP</strong></p></td>
<td align="left"><p>The file-system directory that corresponds to the user's non-localized Startup program group.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_APPDATA</strong></p></td>
<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>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_BITBUCKET</strong></p></td>
<td align="left"><p>The virtual folder that contains the objects in the user's Recycle Bin.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CDBURN_AREA</strong></p></td>
<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>
</tr>
<tr class="odd">
<td align="left"><p><strong>CSIDL_CONNECTIONS</strong></p></td>
<td align="left"><p>The virtual folder representing Network Connections that contains network and dial-up connections.</p></td>
</tr>
<tr class="even">
<td align="left"><p><strong>CSIDL_CONTACTS</strong></p></td>
<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>
 
|Variable|Explanation|
|--- |--- |
|**APPDATA**|Same as **CSIDL_APPDATA**.|
|**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.|
|**CSIDL_ALTSTARTUP**|The file-system directory that corresponds to the user's non-localized Startup program group.|
|**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.|
|**CSIDL_BITBUCKET**|The virtual folder that contains the objects in the user's Recycle Bin.|
|**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.|
|**CSIDL_CONNECTIONS**|The virtual folder representing Network Connections that contains network and dial-up connections.|
|**CSIDL_CONTACTS**|This refers to the Contacts folder in %**CSIDL_PROFILE**%.|
|**CSIDL_CONTROLS**|The virtual folder that contains icons for the Control Panel items.|
|**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.|
|**CSIDL_DESKTOP**|The virtual folder representing the Windows desktop.|
|**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.|
|**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.|
|**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.|
|**CSIDL_HISTORY**|The file-system directory that serves as a common repository for Internet history items.|
|**CSIDL_INTERNET**|A virtual folder for Internet Explorer.|
|**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|
|**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.|
|**CSIDL_MYDOCUMENTS**|The virtual folder representing My Documents.A typical path is C:\Users\Username\Documents.|
|**CSIDL_MYMUSIC**|The file-system directory that serves as a common repository for music files. A typical path is C:\Users\Username\Music.|
|**CSIDL_MYPICTURES**|The file-system directory that serves as a common repository for image files. A typical path is C:\Users\Username\Pictures.|
|**CSIDL_MYVIDEO**|The file-system directory that serves as a common repository for video files. A typical path is C:\Users\Username\Videos.|
|**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.|
|**CSIDL_NETWORK**|A virtual folder representing My Network Places, the root of the network namespace hierarchy.|
|**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.|
|**CSIDL_PLAYLISTS**|The virtual folder used to store play albums, typically C:\Users\username\My Music\Playlists.|
|**CSIDL_PRINTERS**|The virtual folder that contains installed printers.|
|**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.|
|**CSIDL_PROFILE**|The user's profile folder. A typical path is C:\Users\Username.|
|**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.|
|**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.|
|**CSIDL_SENDTO**|The file-system directory that contains **Send To** menu items. A typical path is C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo.|
|**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.|
|**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.|
|**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.|
|**HOMEPATH**|Same as the standard environment variable.|
|**TEMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.|
|**TMP**|The temporary folder on the computer. A typical path is %**USERPROFILE**%\AppData\Local\Temp.|
|**USERPROFILE**|Same as **CSIDL_PROFILE**.|
|**USERSID**|Represents the current user-account security identifier (SID). For example, <br/>S-1-5-21-1714567821-1326601894-715345443-1026.|
## Related topics
[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
## In This Section
<table>
<colgroup>
<col width="50%" />
<col width="50%" />
</colgroup>
<tbody>
<tr class="odd">
<td align="left"><p><a href="usmt-requirements.md" data-raw-source="[USMT Requirements](usmt-requirements.md)">USMT Requirements</a></p></td>
<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>
| Link | Description |
|--- |--- |
|[USMT Requirements](usmt-requirements.md)|Describes operating system, hardware, and software requirements, and user prerequisites.|
|[USMT Best Practices](usmt-best-practices.md)|Discusses general and security-related best practices when using USMT.|
|[How USMT Works](usmt-how-it-works.md)|Learn about the processes behind the ScanState and LoadState tools.|
|[Plan Your Migration](usmt-plan-your-migration.md)|Choose what to migrate and the best migration scenario for your enterprise.|
|[User State Migration Tool (USMT) Command-line Syntax](usmt-command-line-syntax.md)|Explore command-line options for the ScanState, LoadState, and UsmtUtils tools.|
|[USMT XML Reference](usmt-xml-reference.md)|Learn about customizing a migration with XML files.|
|[Offline Migration Reference](offline-migration-reference.md)|Find requirements, best practices, and other considerations for performing a migration offline.|
## Related topics
[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) Troubleshooting](usmt-troubleshooting.md)

2
windows/security/identity-protection/access-control/service-accounts.md
View File

@ -50,7 +50,7 @@ In addition to the enhanced security that is provided by having individual accou
- Unlike domain accounts in which administrators must manually reset passwords, the network passwords for these accounts are automatically reset.
- You do not have to complete complex SPN management tasks to use managed service accounts.
- You don't have to complete complex SPN management tasks to use managed service accounts.
- Administrative tasks for managed service accounts can be delegated to non-administrators.
### Software requirements

12
windows/security/threat-protection/intelligence/cybersecurity-industry-partners.md
View File

@ -1,8 +1,8 @@
---
title: Industry collaboration programs
ms.reviewer:
description: Microsoft industry-wide antimalware collaboration programs - Virus Information Alliance (VIA), Microsoft Virus Initiative (MVI), and Coordinated Malware Eradication (CME)
keywords: security, malware, antivirus industry, antimalware Industry, collaboration programs, alliances, Virus Information Alliance, Microsoft Virus Initiative, Coordinated Malware Eradication, WDSI, MMPC, Microsoft Malware Protection Center, partnerships
description: Microsoft industry-wide anti-malware collaboration programs - Virus Information Alliance (VIA), Microsoft Virus Initiative (MVI), and Coordinated Malware Eradication (CME)
keywords: security, malware, antivirus industry, anti-malware Industry, collaboration programs, alliances, Virus Information Alliance, Microsoft Virus Initiative, Coordinated Malware Eradication, WDSI, MMPC, Microsoft Malware Protection Center, partnerships
ms.prod: m365-security
ms.mktglfcycl: secure
ms.sitesec: library
@ -17,7 +17,7 @@ ms.technology: windows-sec
---
# Industry collaboration programs
Microsoft has several industry-wide collaboration programs with different objectives and requirements. Enrolling in the right program can help you protect your customers, gain more insight into the current threat landscape, or assist in disrupting the malware ecosystem.
Microsoft has several industry-wide collaboration programs with different objectives and requirements. Enrolling in the right program can help you protect your customers, gain more insight into the current threat landscape, or help disrupting the malware ecosystem.
## Virus Information Alliance (VIA)
@ -29,15 +29,15 @@ Go to the [VIA program page](virus-information-alliance-criteria.md) for more in
## Microsoft Virus Initiative (MVI)
MVI is open to organizations who build and own a Real Time Protection (RTP) antimalware product of their own design, or one developed using a third-party antivirus SDK.
MVI is open to organizations who build and own a Real Time Protection (RTP) anti-malware product of their own design, or one developed using a third-party Antivirus SDK.
Members get access to Microsoft client APIs for the Microsoft Defender Security Center, IOAV, AMSI, and Cloud Files, along with health data and other telemetry to help their customers stay protected. Antimalware products are submitted to Microsoft for performance testing on a regular basis.
Members get access to Microsoft client APIs for the Microsoft Defender Security Center, IOAV, AMSI, and Cloud Files, along with health data and other telemetry to help their customers stay protected. Anti-malware products are submitted to Microsoft for performance testing regularly.
Go to the [MVI program page](virus-initiative-criteria.md) for more information.
## Coordinated Malware Eradication (CME)
CME is open to organizations who are involved in cybersecurity and antimalware or interested in fighting cybercrime.
CME is open to organizations who are involved in cybersecurity and anti-malware or interested in fighting cybercrime.
The program aims to bring organizations in cybersecurity and other industries together to pool tools, information, and actions to drive coordinated campaigns against malware. The ultimate goal is to create efficient and long-lasting results for better protection of our communities, customers, and businesses.

12
windows/security/threat-protection/intelligence/virus-information-alliance-criteria.md
View File

@ -17,7 +17,7 @@ ms.technology: windows-sec
---
# Virus Information Alliance
The Virus Information Alliance (VIA) is a public antimalware collaboration program for security software providers, security service providers, antimalware testing organizations, and other organizations involved in fighting cybercrime.
The Virus Information Alliance (VIA) is a public anti-malware collaboration program for security software providers, security service providers, anti-malware testing organizations, and other organizations involved in fighting cyber crime.
Members of the VIA program collaborate by exchanging technical information on malicious software with Microsoft. The goal is to improve protection for Microsoft customers.
@ -25,7 +25,7 @@ Members of the VIA program collaborate by exchanging technical information on ma
The VIA program gives members access to information that will help them improve protection. For example, the program provides malware telemetry and samples to security teams so they can identify gaps and prioritize new threat coverage.
Malware prevalence data is provided to antimalware testers to assist them in selecting sample sets. The data also helps set scoring criteria that represent the real-world threat landscape. Service organizations, such as a CERT, can leverage our data to help assess the impact of policy changes or to help shut down malicious activity.
Malware prevalence data is provided to anti-malware testers to assist them in selecting sample sets. The data also helps set scoring criteria that represent the real-world threat landscape. Service organizations, such as a CERT, can leverage our data to help assess the impact of policy changes or to help shut down malicious activity.
Microsoft is committed to continuous improvement to help reduce the impact of malware on customers. By sharing malware-related information, Microsoft enables members of this community to work towards better protection for customers.
@ -37,10 +37,10 @@ The criteria is designed to ensure that Microsoft can work with the following gr
- Security software providers
- Security service providers
- Antimalware testing organizations
- Anti-malware testing organizations
- Other organizations involved in the fight against cybercrime
Members will receive information to facilitate effective malware detection, deterrence, and eradication. This information includes technical information on malware as well as metadata on malicious activity. Information shared through VIA is governed by the VIA membership agreement and a Microsoft non-disclosure agreement, where applicable.
Members will receive information to facilitate effective malware detection, deterrence, and eradication. This information includes technical information on malware and metadata on malicious activity. Information shared through VIA is governed by the VIA membership agreement and a Microsoft non-disclosure agreement, where applicable.
VIA has an open enrollment for potential members.
@ -52,9 +52,9 @@ To be eligible for VIA your organization must:
2. Fit into one of the following categories:
- Your organization develops antimalware technology that can run on Windows and your organization’s product is commercially available.
- Your organization develops anti-malware technology that can run on Windows and your organization’s product is commercially available.
- Your organization provides security services to Microsoft customers or for Microsoft products.
- Your organization publishes antimalware testing reports on a regular basis.
- Your organization publishes anti-malware testing reports regularly.
- Your organization has a research or response team dedicated to fighting malware to protect your organization, your customers, or the general public.
3. Be willing to sign and adhere to the VIA membership agreement.

62
windows/security/threat-protection/protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md
View File

@ -26,9 +26,9 @@ This article details an end-to-end solution that helps you protect high-value as
## Introduction
In Bring Your Own Device (BYOD) scenarios, employees bring commercially available devices to access both work-related resources and their personal data. Users want to use the device of their choice to access the organization’s applications, data, and resources not only from the internal network but also from anywhere. This phenomenon is also known as the consumerization of IT.
For Bring Your Own Device (BYOD) scenarios, employees bring commercially available devices to access both work-related resources and their personal data. Users want to use the device of their choice to access the organization’s applications, data, and resources not only from the internal network but also from anywhere. This phenomenon is also known as the consumerization of IT.
Users want to have the best productivity experience when accessing corporate applications and working on organization data from their devices. That means they will not tolerate being prompted to enter their work credentials each time they access an application or a file server. From a security perspective, it also means that users will manipulate corporate credentials and corporate data on unmanaged devices.
Users want to have the best productivity experience when accessing corporate applications and working on organization data from their devices. That means they won't tolerate being prompted to enter their work credentials each time they access an application or a file server. From a security perspective, it also means that users will manipulate corporate credentials and corporate data on unmanaged devices.
With the increased use of BYOD, there will be more unmanaged and potentially unhealthy systems accessing corporate services, internal resources, and cloud apps.
@ -46,7 +46,7 @@ During recent years, one particular category of threat has become prevalent: adv
With the BYOD phenomena, a poorly maintained device represents a target of choice. For an attacker, it’s an easy way to breach the security network perimeter, gain access to, and then steal high-value assets.
The attackers target individuals, not specifically because of who they are, but because of who they work for. An infected device will bring malware into an organization, even if the organization has hardened the perimeter of networks or has invested in its defensive posture. A defensive strategy is not sufficient against these threats.
The attackers target individuals, not specifically because of who they are, but because of who they work for. An infected device will bring malware into an organization, even if the organization has hardened the perimeter of networks or has invested in its defensive posture. A defensive strategy isn't sufficient against these threats.
### A different approach
@ -72,7 +72,7 @@ A device health attestation module can communicate measured boot data that is pr
Remote health attestation service performs a series of checks on the measurements. It validates security related data points, including boot state (Secure Boot, Debug Mode, and so on), and the state of components that manage security (BitLocker, Device Guard, and so on). It then conveys the health state of the device by sending a health encrypted blob back to the device.
An MDM solution typically applies configuration policies and deploys software to devices. MDM defines the security baseline and knows the level of compliance of the device with regular checks to see what software is installed and what configuration is enforced, as well as determining the health status of the device.
An MDM solution typically applies configuration policies and deploys software to devices. MDM defines the security baseline and knows the level of compliance of the device with regular checks to see what software is installed and what configuration is enforced, and determining the health status of the device.
An MDM solution asks the device to send device health information and forward the health encrypted blob to the remote health attestation service. The remote health attestation service verifies device health data, checks that MDM is communicating to the same device, and then issues a device health report back to the MDM solution.
@ -86,7 +86,7 @@ Depending on the requirements and the sensitivity of the managed asset, device h
In Windows 10, there are three pillars of investments:
- **Secure identities.** Microsoft is part of the FIDO Alliance that aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system and for services like on-premises resources and cloud resources.
- **Secure identities.** Microsoft is part of the FIDO alliance that aims to provide an interoperable method of secure authentication by moving away from the use of passwords for authentication, both on the local system and for services like on-premises resources and cloud resources.
- **Information protection.** Microsoft is making investments to allow organizations to have better control over who has access to important data and what they can do with that data. With Windows 10, organizations can take advantage of policies that specify which applications are considered to be corporate applications and can be trusted to access secure data.
- **Threat resistance.** Microsoft is helping organizations to better secure enterprise assets against the threats of malware and attacks by using security defenses relying on hardware.
@ -149,7 +149,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
- The TPM 1.2 specification allows vendors wide latitude when choosing implementation details
- TPM 2.0 standardizes much of this behavior
- **Secure Boot.** Devices with UEFI firmware can be configured to load only trusted operating system bootloaders. Secure Boot does not require a TPM.
- **Secure Boot.** Devices with UEFI firmware can be configured to load only trusted operating system bootloaders. Secure Boot doesn't require a TPM.
The most basic protection is the Secure Boot feature, which is a standard part of the UEFI 2.2+ architecture. On a PC with conventional BIOS, anyone who can take control of the boot process can boot by using an alternative OS loader, and potentially gain access to system resources. When Secure Boot is enabled, you can boot using only an OS loader that’s signed using a certificate stored in the UEFI Secure Boot DB. Naturally, the Microsoft certificate used to digitally sign the Windows 10 OS loaders are in that store, which allows UEFI to validate the certificate as part of its security policy. Secure Boot must be enabled by default on all computers that are certified for Windows 10 under the Windows Hardware Compatibility Program.
@ -182,7 +182,7 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
The ELAM driver is a small driver with a small policy database that has a very narrow scope, focused on drivers that are loaded early at system launch. The policy database is stored in a registry hive that is also measured to the TPM, to record the operational parameters of the ELAM driver. An ELAM driver must be signed by Microsoft and the associated certificate must contain the complementary EKU (1.3.6.1.4.1.311.61.4.1).
- **Virtualization-based security (Hyper-V + Secure Kernel).** Virtualization-based security is a completely new enforced security boundary that allows you to protect critical parts of Windows 10.
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate domain credentials from the rest of the Windows operating system. For more information, refer to the [Virtualization-based security](#virtual) section.
Virtualization-based security isolates sensitive code like Kernel Mode Code Integrity or sensitive corporate domain credentials from the rest of the Windows operating system. For more information, see [Virtualization-based security](#virtual) section.
- **Hypervisor-protected Code Integrity (HVCI).** Hypervisor-protected Code Integrity is a feature of Device Guard that ensures only drivers, executables, and DLLs that comply with the Device Guard Code Integrity policy are allowed to run.
@ -210,13 +210,13 @@ Windows 10 supports features to help prevent sophisticated low-level malware lik
During each subsequent boot, the same components are measured, which allows comparison of the measurements against an expected baseline. For more security, the values measured by the TPM can be signed and transmitted to a remote server, which can then perform the comparison. This process, called *remote device health attestation*, allows the server to verify health status of the Windows device.
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM vendor. Unlike Secure Boot, health attestation will not stop the boot process and enter remediation when a measurement does not work. But with conditional access control, health attestation will help to prevent access to high-value assets.
Although Secure Boot is a proactive form of protection, health attestation is a reactive form of boot protection. Health attestation ships disabled in Windows and is enabled by an antimalware or an MDM vendor. Unlike Secure Boot, health attestation won't stop the boot process and enter remediation when a measurement doesn't work. But with conditional access control, health attestation will help to prevent access to high-value assets.
### <a href="" id="virtual"></a>Virtualization-based security
Virtualization-based security provides a new trust boundary for Windows 10 and uses Hyper-V hypervisor technology to enhance platform security. Virtualization-based security provides a secure execution environment to run specific Windows trusted code (trustlet) and to protect sensitive data.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Virtualization-based security is not trying to protect against a physical attacker.
Virtualization-based security helps to protect against a compromised kernel or a malicious user with Administrator privileges. Virtualization-based security isn't trying to protect against a physical attacker.
The following Windows 10 services are protected with virtualization-based security:
@ -234,7 +234,7 @@ The schema below is a high-level view of Windows 10 with virtualization-based se
### Credential Guard
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs a sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This code execution helps ensure that protected data is not stolen and reused on
In Windows 10, when Credential Guard is enabled, Local Security Authority Subsystem Service (lsass.exe) runs a sensitive code in an Isolated user mode to help protect data from malware that may be running in the normal user mode. This code execution helps ensure that protected data isn't stolen and reused on
remote machines, which mitigates many PtH-style attacks.
Credential Guard helps protect credentials by encrypting them with either a per-boot or persistent key:
@ -255,16 +255,16 @@ Hyper-V Code Integrity is a feature that validates the integrity of a driver or
> [!NOTE]
> Independently of activation of Device Guard Policy, [Windows 10 by default raises the bar for what runs in the kernel](https://go.microsoft.com/fwlink/p/?LinkId=691613). Windows 10 drivers must be signed by Microsoft, and more specifically, by the WHQL (Windows Hardware Quality Labs) portal. Additionally, starting in October 2015, the WHQL portal will only accept driver submissions, including both kernel and user mode driver submissions, that have a valid Extended Validation (“EV”) Code Signing Certificate.
With Device Guard in Windows 10, organizations are now able to define their own Code Integrity policy for use on x64 systems running Windows 10 Enterprise. Organizations have the ability to configure the policy that determines what is trusted to run. These include drivers and system files, as well as traditional desktop applications and scripts. The system is then locked down to only run applications that the organization trusts.
With Device Guard in Windows 10, organizations are now able to define their own Code Integrity policy for use on x64 systems running Windows 10 Enterprise. Organizations have the ability to configure the policy that determines what is trusted to run. These include drivers and system files, and traditional desktop applications and scripts. The system is then locked down to only run applications that the organization trusts.
Device Guard is a built-in feature of Windows 10 Enterprise that prevents the execution of unwanted code and applications. Device Guard can be configured using two rule actions - allow and deny:
- **Allow** limits execution of applications to an allowed list of code or trusted publisher and blocks everything else.
- **Deny** completes the allow trusted publisher approach by blocking the execution of a specific application.
At the time of this writing, and according to Microsoft’s latest research, more than 90 percent of malware is unsigned completely. So implementing a basic Device Guard policy can simply and effectively help block the vast majority of malware. In fact, Device Guard has the potential to go further, and can also help block signed malware.
At the time of this writing, and according to Microsoft’s latest research, more than 90 percent of malware is unsigned completely. So implementing a basic Device Guard policy can simply and effectively help block malware. In fact, Device Guard has the potential to go further, and can also help block signed malware.
Device Guard needs to be planned and configured to be truly effective. It is not just a protection that is enabled or disabled. Device Guard is a combination of hardware security features and software security features that, when configured together, can lock down a computer to help ensure the most secure and resistant system possible.
Device Guard needs to be planned and configured to be truly effective. It isn't just a protection that is enabled or disabled. Device Guard is a combination of hardware security features and software security features that, when configured together, can lock down a computer to help ensure the most secure and resistant system possible.
There are three different parts that make up the Device Guard solution in Windows 10:
@ -276,18 +276,18 @@ For more information on how to deploy Device Guard in an enterprise, see the [De
### Device Guard scenarios
As previously described, Device Guard is a powerful way to lock down systems. Device Guard is not intended to be used broadly and it may not always be applicable, but there are some high-interest scenarios.
As previously described, Device Guard is a powerful way to lock down systems. Device Guard isn't intended to be used broadly and it may not always be applicable, but there are some high-interest scenarios.
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have very well-defined software that are expected to run and don’t change too frequently.
It could also help protect Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of applications is not going to change on a daily basis.
Device Guard is useful and applicable on fixed workloads systems like cash registers, kiosk machines, Secure Admin Workstations (SAWs), or well managed desktops. Device Guard is highly relevant on systems that have a well-defined software that are expected to run and don’t change too frequently.
It could also help protect Information Workers (IWs) beyond just SAWs, as long as what they need to run is known and the set of applications isn't going to change on a daily basis.
SAWs are computers that are built to help significantly reduce the risk of compromise from malware, phishing attacks, bogus websites, and PtH attacks, among other security risks. Although SAWs can’t be considered a “silver bullet” security solution to these attacks, these types of clients are helpful as part of a layered, defense-in-depth approach to security.
To protect high-value assets, SAWs are used to make secure connections to those assets.
Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool like Microsoft Endpoint Configuration Manager, Intune, or any third-party device management, then Device Guard is very applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
Similarly, on corporate fully-managed workstations, where applications are installed by using a distribution tool like Microsoft Endpoint Configuration Manager, Intune, or any third-party device management, then Device Guard is applicable. In that type of scenario, the organization has a good idea of the software that an average user is running.
It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s quite difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
It could be challenging to use Device Guard on corporate, lightly-managed workstations where the user is typically allowed to install software on their own. When an organization offers great flexibility, it’s difficult to run Device Guard in enforcement mode. Nevertheless, Device Guard can be run in Audit mode, and in that case, the event log will contain a record of any binaries that violated the Device Guard policy. When Device Guard is used in Audit mode, organizations can get rich data about drivers and applications that users install and run.
Before you can benefit from the protection included in Device Guard, Code Integrity policy must be created by using tools provided by Microsoft, but the policy can be deployed with common management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10, along with restrictions on Windows 10 script hosts. Device Guard Code Integrity policy restricts what code can run on a device.
@ -306,13 +306,13 @@ On computers with Device Guard, Microsoft proposes to move from a world where un
With Windows 10, organizations will make line-of-business (LOB) apps available to members of the organization through the Microsoft Store infrastructure. More specifically, LOB apps will be available in a private store within the public Microsoft Store. Microsoft Store signs and distributes Universal
Windows apps and Classic Windows apps. All apps downloaded from the Microsoft Store are signed.
In organizations today, the vast majority of LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
In organizations today, many LOB applications are unsigned. Code signing is frequently viewed as a tough problem to solve for a variety of reasons, like the lack of code signing expertise. Even if code signing is a best practice, a lot of internal applications are not signed.
Windows 10 includes tools that allow IT pros to take applications that have been already packaged and run them through a process to create additional signatures that can be distributed along with existing applications.
### Why are antimalware and device management solutions still necessary?
Although allow-list mechanisms are extremely efficient at ensuring that only trusted applications can be run, they cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
Although allow-list mechanisms are efficient at ensuring that only trusted applications can be run, they cannot prevent the compromise of a trusted (but vulnerable) application by malicious content designed to exploit a known vulnerability. Device Guard doesn’t protect against user mode malicious code run by exploiting vulnerabilities.
Vulnerabilities are weaknesses in software that could allow an attacker to compromise the integrity, availability, or confidentiality of the device. Some of the worst vulnerabilities allow attackers to exploit the compromised device by causing it to run malicious code without the user’s knowledge.
@ -384,7 +384,7 @@ This section presented information about several closely related controls in Win
## <a href="" id="detect-unhealthy"></a>Detect an unhealthy Windows 10-based device
As of today, many organizations only consider devices to be compliant with company policy after they’ve passed a variety of checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting is not entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
As of today, many organizations only consider devices to be compliant with company policy after they’ve passed a variety of checks that show, for example, that the operating system is in the correct state, properly configured, and has security protection enabled. Unfortunately, with today’s systems, this form of reporting isn't entirely reliable because malware can spoof a software statement about system health. A rootkit, or a similar low-level exploit, can report a false healthy state to traditional compliance tools.
The biggest challenge with rootkits is that they can be undetectable to the client. Because they start before antimalware, and they have system-level privileges, they can completely disguise themselves while continuing to access system resources. As a result, traditional computers infected with rootkits appear to be healthy, even with antimalware running.
@ -400,7 +400,7 @@ However, the use of traditional malware prevention technologies like antimalware
The definition of device compliance will vary based on an organization’s installed antimalware, device configuration settings, patch management baseline, and other security requirements. But health of the device is part of the overall device compliance policy.
The health of the device is not binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by leveraging trustworthy hardware TPM.
The health of the device isn't binary and depends on the organization’s security implementation. The Health Attestation Service provides information back to the MDM on which security features are enabled during the boot of the device by leveraging trustworthy hardware TPM.
But health attestation only provides information, which is why an MDM solution is needed to take and enforce a decision.
@ -501,7 +501,7 @@ For certain devices that use firmware-based TPM produced by Intel or Qualcomm, t
### Attestation Identity Keys
Because the endorsement certificate is unique for each device and does not change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
Because the endorsement certificate is unique for each device and doesn't change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows 10 issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service.
> [!NOTE]
> Before the device can report its health using the TPM attestation functions, an AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows 10 creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK.
@ -511,9 +511,9 @@ The AIK is an asymmetric (public/private) key pair that is used as a substitute
Windows 10 creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft is hosting a cloud service called Microsoft Cloud CA to establish cryptographically that it is communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft
Cloud CA service has established these facts, it will issue an AIK certificate to the Windows 10-based device.
Many existing devices that will upgrade to Windows 10 will not have a TPM, or the TPM will not contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this is not as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates are not issued by Microsoft Cloud CA. Note that this isn't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that is not backed by an endorsement certificate.
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be leveraged by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that isn't backed by an endorsement certificate.
### Storage root key
@ -527,7 +527,7 @@ The measurement of the boot sequence is based on the PCR and TCG log. To establi
PCRs are set to zero when the platform is booted, and it is the job of the firmware that boots the platform to measure components in the boot chain and to record the measurements in the PCRs. Typically, boot components take the hash of the next component that is to be run and record the measurements in the PCRs. The initial component that starts the measurement chain is implicitly trusted. This is the CRTM. Platform manufacturers are required to have a secure update process for the CRTM or not permit updates to it. The PCRs record a cumulative hash of the components that have been measured.
The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log has not been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
The value of a PCR on its own is hard to interpret (it is just a hash value), but platforms typically keep a log with details of what has been measured, and the PCRs merely ensure that the log hasn't been tampered with. The logs are referred as a TCG log. Each time a register PCR is extended, an entry is added to the TCG log. Thus, throughout the boot process, a trace of the executable code and configuration data is created in the TCG log.
### TPM provisioning
@ -539,7 +539,7 @@ During the provisioning process, the device may need to be restarted.
Note that the **Get-TpmEndorsementKeyInfo PowerShell** cmdlet can be used with administrative privilege to get information about the endorsement key and certificates of the TPM.
If the TPM ownership is not known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location:
If the TPM ownership isn't known but the EK exists, the client library will provision the TPM and will store the resulting **ownerAuth** value into the registry if the policy allows it will store the SRK public portion at the following location:
**HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\Admin\\SRKPub**
As part of the provisioning process, Windows 10 will create an AIK with the TPM. When this operation is performed, the resulting AIK public portion is stored in the registry at the following location: **HKLM\\SYSTEM\\CurrentControlSet\\Services\\TPM\\WMI\\WindowsAIKPub**
@ -701,7 +701,7 @@ For more information on how to manage Windows 10 security and system settings wi
On most platforms, the Azure Active Directory (Azure AD) device registration happens automatically during enrollment. The device states are written by the MDM solution into Azure AD, and then read by Office 365 (or by any authorized Windows app that interacts with Azure AD) the next time the client tries to access an Office 365 compatible workload.
If the device is not registered, the user will get a message with instructions on how to register (also known as enrolling). If the device is not compliant, the user will get a different message that redirects them to the MDM web portal where they can get more information on the compliance problem and how to resolve it.
If the device isn't registered, the user will get a message with instructions on how to register (also known as enrolling). If the device isn't compliant, the user will get a different message that redirects them to the MDM web portal where they can get more information on the compliance problem and how to resolve it.
**Azure AD** authenticates the user and the device, **MDM** manages the compliance and conditional access policies, and the **Health Attestation Service** reports about the health of the device in an attested way.
@ -721,7 +721,7 @@ When a user enrolls, the device is registered with Azure AD, and enrolled with a
When a user enrolls a device successfully, the device becomes trusted. Azure AD provides single-sign-on to access company applications and enforces conditional access policy to grant access to a service not only the first time the user requests access, but every time the user requests to renew access.
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the compliance policy is not met at the time of request for renewal.
The user will be denied access to services when sign-in credentials are changed, a device is lost/stolen, or the compliance policy isn't met at the time of request for renewal.
Depending on the type of email application that employees use to access Exchange online, the path to establish secured access to email can be slightly different. However, the key components: Azure AD, Office 365/Exchange Online, and Intune, are the same. The IT experience and end-user experience also are similar.
@ -779,7 +779,7 @@ The following process describes how Azure AD conditional access works:
For more information about Azure AD join, see [Azure AD & Windows 10: Better Together for Work or School](https://go.microsoft.com/fwlink/p/?LinkId=691619), a white paper.
Conditional access control is a topic that many organizations and IT pros may not know as well as they should. The different attributes that describe a user, a device, compliance, and context of access are very powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
Conditional access control is a topic that many organizations and IT pros may not know and they should. The different attributes that describe a user, a device, compliance, and context of access are very powerful when used with a conditional access engine. Conditional access control is an essential step that helps organizations secure their environment.
## Takeaways and summary
@ -819,7 +819,7 @@ The following list contains high-level key take-aways to improve the security po
- **Use AppLocker when it makes sense**
Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user or a group of users.
Although AppLocker isn't considered a new Device Guard feature, it complements Device Guard functionality for some scenarios like being able to deny a specific Universal Windows apps for a specific user or a group of users.
- **Lock down firmware and configuration**

22
windows/security/threat-protection/use-windows-event-forwarding-to-assist-in-intrusion-detection.md
View File

@ -41,7 +41,7 @@ Here's an approximate scaling guide for WEF events:
| 5,000 - 50,000 | SEM |
| 50,000+ | Hadoop/HDInsight/Data Lake |
Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This condition is because WEF is a passive system regarding the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling more event channels and expanding the size of event log files has not resulted in noticeable performance differences.
Event generation on a device must be enabled either separately or as part of the GPO for the baseline WEF implementation, including enabling of disabled event logs and setting channel permissions. For more info, see [Appendix C - Event channel settings (enable and channel access) methods](#bkmk-appendixc). This condition is because WEF is a passive system regarding the event log. It cannot change the size of event log files, enable disabled event channels, change channel permissions, or adjust a security audit policy. WEF only queries event channels for existing events. Additionally, having event generation already occurring on a device allows for more complete event collection building a complete history of system activity. Otherwise, you'll be limited to the speed of GPO and WEF subscription refresh cycles to make changes to what is being generated on the device. On modern devices, enabling additional event channels and expanding the size of event log files hasn't resulted in noticeable performance differences.
For the minimum recommended audit policy and registry system ACL settings, see [Appendix A - Minimum recommended minimum audit policy](#bkmk-appendixa) and [Appendix B - Recommended minimum registry system ACL policy](#bkmk-appendixb).
@ -66,7 +66,7 @@ This section addresses common questions from IT pros and customers.
The short answer is: No.
The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they will not notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there is an issue with the WEF subscription, there is no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel.
The longer answer is: The **Eventlog-forwardingPlugin/Operational** event channel logs the success, warning, and error events related to WEF subscriptions present on the device. Unless the user opens Event Viewer and navigates to that channel, they won't notice WEF either through resource consumption or Graphical User Interface pop-ups. Even if there is an issue with the WEF subscription, there is no user interaction or performance degradation. All success, warning, and failure events are logged to this operational event channel.
### Is WEF Push or Pull?
@ -91,13 +91,13 @@ In a domain setting, the connection used to transmit WEF events is encrypted usi
This authentication and encryption is performed regardless if HTTP or HTTPS is selected.
The HTTPS option is available if certificate based authentication is used, in cases where the Kerberos based mutual authentication is not an option. The SSL certificate and provisioned client certificates are used to provide mutual authentication.
The HTTPS option is available if certificate based authentication is used, in cases where the Kerberos based mutual authentication isn't an option. The SSL certificate and provisioned client certificates are used to provide mutual authentication.
### Do WEF Clients have a separate buffer for events?
The WEF client machines local event log is the buffer for WEF for when the connection to the WEC server is lost. To increase the “buffer size”, increase the maximum file size of the specific event log file where events are being selected. For more info, see [Appendix C – Event Channel Settings (enable and Channel Access) methods](#bkmk-appendixc).
When the event log overwrites existing events (resulting in data loss if the device is not connected to the Event Collector), there is no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.
When the event log overwrites existing events (resulting in data loss if the device isn't connected to the Event Collector), there is no notification sent to the WEF collector that events are lost from the client. Neither is there an indicator that there was a gap encountered in the event stream.
### What format is used for forwarded events?
@ -119,7 +119,7 @@ This table outlines the built-in delivery options:
| Event delivery optimization options | Description |
| - | - |
| Normal | This option ensures reliable delivery of events and does not attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. |
| Normal | This option ensures reliable delivery of events and doesn't attempt to conserve bandwidth. It is the appropriate choice unless you need tighter control over bandwidth usage or need forwarded events delivered as quickly as possible. It uses pull delivery mode, batches 5 items at a time and sets a batch timeout of 15 minutes. |
| Minimize bandwidth | This option ensures that the use of network bandwidth for event delivery is strictly controlled. It is an appropriate choice if you want to limit the frequency of network connections made to deliver events. It uses push delivery mode and sets a batch timeout of 6 hours. In addition, it uses a heartbeat interval of 6 hours. |
| Minimize latency | This option ensures that events are delivered with minimal delay. It is an appropriate choice if you are collecting alerts or critical events. It uses push delivery mode and sets a batch timeout of 30 seconds. |
@ -149,13 +149,13 @@ Yes. If you desire a High-Availability environment, simply configure multiple WE
There are three factors that limit the scalability of WEC servers. The general rule for a stable WEC server on commodity hardware is planning for a total of 3,000 events per second on average for all configured subscriptions.
- **Disk I/O**. The WEC server does not process or validate the received event, but rather buffers the received event and then logs it to a local event log file (EVTX file). The speed of logging to the EVTX file is limited by the disk write speed. Isolating the EVTX file to its own array or using high speed disks can increase the number of events per second that a single WEC server can receive.
- **Network Connections**. While a WEF source does not maintain a permanent, persistent connection to the WEC server, it does not immediately disconnect after sending its events. This means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server.
- **Registry size**. For each unique device that connects to a WEF subscription, there is a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this is not pruned to remove inactive clients this set of registry keys can grow to an unmanageable size over time.
- **Disk I/O**. The WEC server doesn't process or validate the received event, but rather buffers the received event and then logs it to a local event log file (EVTX file). The speed of logging to the EVTX file is limited by the disk write speed. Isolating the EVTX file to its own array or using high speed disks can increase the number of events per second that a single WEC server can receive.
- **Network Connections**. While a WEF source doesn't maintain a permanent, persistent connection to the WEC server, it doesn't immediately disconnect after sending its events. This means that the number of WEF sources that can simultaneously connect to the WEC server is limited to the open TCP ports available on the WEC server.
- **Registry size**. For each unique device that connects to a WEF subscription, there is a registry key (corresponding to the FQDN of the WEF Client) created to store bookmark and source heartbeat information. If this isn't pruned to remove inactive clients this set of registry keys can grow to an unmanageable size over time.
- When a subscription has &gt;1000 WEF sources connect to it over its operational lifetime, also known as lifetime WEF sources, Event Viewer can become unresponsive for a few minutes when selecting the **Subscriptions** node in the left-navigation, but will function normally afterwards.
- At &gt;50,000 lifetime WEF sources, Event Viewer is no longer an option and wecutil.exe (included with Windows) must be used to configure and manage subscriptions.
- At &gt;100,000 lifetime WEF sources, the registry will not be readable and the WEC server will likely have to be rebuilt.
- At &gt;100,000 lifetime WEF sources, the registry won't be readable and the WEC server will likely have to be rebuilt.
## Subscription information
@ -163,9 +163,9 @@ Below lists all of the items that each subscription collects, the actual subscri
### Baseline subscription
While this appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription does not require special configuration on client devices to enable event channels or modify channel permissions.
While this appears to be the largest subscription, it really is the lowest volume on a per-device basis. (Exceptions should be allowed for unusual devices – a device performing complex developer related tasks can be expected to create an unusually high volume of process create and AppLocker events.) This subscription doesn't require special configuration on client devices to enable event channels or modify channel permissions.
The subscription is essentially a collection of query statements applied to the Event Log. This means that it is modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements which filter out specific events, only apply within that query statement and are not to the entire subscription.
The subscription is essentially a collection of query statements applied to the Event Log. This means that it is modular in nature and a given query statement can be removed or changed without impacting other query statement in the subscription. Additionally, suppress statements which filter out specific events, only apply within that query statement and aren't to the entire subscription.
### Baseline subscription requirements

22
windows/security/threat-protection/windows-defender-system-guard/how-hardware-based-root-of-trust-helps-protect-windows.md
View File

@ -16,10 +16,9 @@ ms.date: 03/01/2019
ms.technology: windows-sec
---
# Windows Defender System Guard: How a hardware-based root of trust helps protect Windows 10
In order to protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy.
To protect critical resources such as the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module, a system's firmware and hardware must be trustworthy.
Windows Defender System Guard reorganizes the existing Windows 10 system integrity features under one roof and sets up the next set of investments in Windows security. It's designed to make these security guarantees:
@ -30,20 +29,21 @@ Windows Defender System Guard reorganizes the existing Windows 10 system integri
### Static Root of Trust for Measurement (SRTM)
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system.
With Windows 7, one of the means attackers would use to persist and evade detection was to install what is often referred to as a bootkit or rootkit on the system.
This malicious software would start before Windows started, or during the boot process itself, enabling it to start with the highest level of privilege.
With Windows 10 running on modern hardware (that is, Windows 8-certified or greater) a hardware-based root of trust helps ensure that no unauthorized firmware or software (such as a bootkit) can start before the Windows bootloader.
This hardware-based root of trust comes from the device’s Secure Boot feature, which is part of the Unified Extensible Firmware Interface (UEFI).
This technique of measuring the static early boot UEFI components is called the Static Root of Trust for Measurement (SRTM).
As there are thousands of PC vendors that produce numerous models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup.
Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a block list), or a list of known 'good' SRTM measurements (also known as an allow list).
As there are thousands of PC vendors that produce many models with different UEFI BIOS versions, there becomes an incredibly large number of SRTM measurements upon bootup.
Two techniques exist to establish trust here—either maintain a list of known 'bad' SRTM measurements (also known as a blocklist), or a list of known 'good' SRTM measurements (also known as an allowlist).
Each option has a drawback:
- A list of known 'bad' SRTM measurements allows a hacker to change just 1 bit in a component to create an entirely new SRTM hash that needs to be listed. This means that the SRTM flow is inherently brittle - a minor change can invalidate the entire chain of trust.
- A list of known 'good' SRTM measurements requires each new BIOS/PC combination measurement to be carefully added, which is slow.
In addition, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.
Also, a bug fix for UEFI code can take a long time to design, build, retest, validate, and redeploy.
### Secure Launch—the Dynamic Root of Trust for Measurement (DRTM)
@ -67,20 +67,18 @@ To defend against this, two techniques are used:
- Paging protection to prevent inappropriate access to code and data
- SMM hardware supervision and attestation
Paging protection can be implemented to lock certain code tables to be read-only to prevent tampering.
This prevents access to any memory that has not been specifically assigned.
Paging protection can be implemented to lock certain code tables to be read-only to prevent tampering. This prevents access to any memory that has not been assigned.
A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it does not access any part of the address space that it is not supposed to.
A hardware-enforced processor feature known as a supervisor SMI handler can monitor the SMM and make sure it doesn't access any part of the address space that it isn't supposed to.
SMM protection is built on top of the Secure Launch technology and requires it to function.
In the future, Windows 10 will also measure this SMI Handler’s behavior and attest that no OS-owned memory has been tampered with.
## Validating platform integrity after Windows is running (run time)
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We should be able to trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. When it comes to platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch will not support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data is not subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few.
While Windows Defender System Guard provides advanced protection that will help protect and maintain the integrity of the platform during boot and at run time, the reality is that we must apply an "assume breach" mentality to even our most sophisticated security technologies. We can trust that the technologies are successfully doing their jobs, but we also need the ability to verify that they were successful in achieving their goals. For platform integrity, we can’t just trust the platform, which potentially could be compromised, to self-attest to its security state. So Windows Defender System Guard includes a series of technologies that enable remote analysis of the device’s integrity.
As Windows 10 boots, a series of integrity measurements are taken by Windows Defender System Guard using the device’s Trusted Platform Module 2.0 (TPM 2.0). System Guard Secure Launch won't support earlier TPM versions, such as TPM 1.2. This process and data are hardware-isolated away from Windows to help ensure that the measurement data isn't subject to the type of tampering that could happen if the platform was compromised. From here, the measurements can be used to determine the integrity of the device’s firmware, hardware configuration state, and Windows boot-related components, just to name a few.
![Boot time integrity.](images/windows-defender-system-guard-boot-time-integrity.png)

10
windows/security/threat-protection/windows-defender-system-guard/system-guard-secure-launch-and-smm-protection.md
View File

@ -35,7 +35,7 @@ You can enable System Guard Secure Launch by using any of these options:
### Mobile Device Management
System Guard Secure Launch can be configured for Mobile Device Management (MDM) by using DeviceGuard policies in the Policy CSP, specifically [DeviceGuard/ConfigureSystemGuardLaunch](/windows/client-management/mdm/policy-csp-deviceguard#deviceguard-configuresystemguardlaunch).
System Guard Secure Launch can be configured for Mobile Device Management (MDM) by using DeviceGuard policies in the Policy CSP, [DeviceGuard/ConfigureSystemGuardLaunch](/windows/client-management/mdm/policy-csp-deviceguard#deviceguard-configuresystemguardlaunch).
### Group Policy
@ -79,10 +79,10 @@ To verify that Secure Launch is running, use System Information (MSInfo32). Clic
|For Intel&reg; vPro&trade; processors starting with Intel&reg; Coffeelake, Whiskeylake, or later silicon|Description|
|--------|-----------|
|64-bit CPU|A 64-bit computer with minimum four cores (logical processors) is required for hypervisor and virtualization-based security (VBS). For more info about Hyper-V, see [Hyper-V on Windows Server 2016](/windows-server/virtualization/hyper-v/hyper-v-on-windows-server) or [Introduction to Hyper-V on Windows 10](/virtualization/hyper-v-on-windows/about/). For more info about hypervisor, see [Hypervisor Specifications](/virtualization/hyper-v-on-windows/reference/tlfs).|
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, with the exception of Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.|
|Trusted Platform Module (TPM) 2.0|Platforms must support a discrete TPM 2.0. Integrated/firmware TPMs aren't supported, except Intel chips that support Platform Trust Technology (PTT), which is a type of integrated hardware TPM that meets the TPM 2.0 spec.|
|Windows DMA Protection|Platforms must meet the Windows DMA Protection Specification (all external DMA ports must be off by default until the OS explicitly powers them).|
|SMM communication buffers| All SMM communication buffers must be implemented in EfiRuntimeServicesData, EfiRuntimeServicesCode, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types. |
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example, no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType. <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|SMM Page Tables| Must NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory). <br/>Must NOT contain any mappings to code sections within EfiRuntimeServicesCode. <br/>Must NOT have execute and write permissions for the same page <br/>Must allow ONLY that TSEG pages can be marked executable and the memory map must report TSEG EfiReservedMemoryType. <br/>BIOS SMI handler must be implemented such that SMM page tables are locked on every SMM entry. |
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|TPM AUX Index|Platform must set up a AUX index with index, attributes, and policy that exactly corresponds to the AUX index specified in the TXT DG with a data size of exactly 104 bytes (for SHA256 AUX data). (NameAlg = SHA256) <br/> Platforms must set up a PS (Platform Supplier) index with: <ul><li> Exactly the "TXT PS2" style Attributes on creation as follows: <ul><li>AuthWrite</li><li>PolicyDelete</li><li>WriteLocked</li><li>WriteDefine</li><li>AuthRead</li><li>WriteDefine</li><li>NoDa</li><li>Written</li><li>PlatformCreate</li></ul> <li>A policy of exactly PolicyCommandCode(CC = TPM2_CC_UndefineSpaceSpecial) (SHA256 NameAlg and Policy)</li><li> Size of exactly 70 bytes </li><li> NameAlg = SHA256 </li><li> Also, it must have been initialized and locked (TPMA_NV_WRITTEN = 1, TPMA_NV_WRITELOCKED = 1) at time of OS launch. </li></ul> PS index data DataRevocationCounters, SINITMinVersion, and PolicyControl must all be 0x00 |
|AUX Policy|The required AUX policy must be as follows: <ul><li> A = TPM2_PolicyLocality (Locality 3 & Locality 4) </li><li>B = TPM2_PolicyCommandCode (TPM_CC_NV_UndefineSpecial)</li><li>authPolicy = \{A} OR {{A} AND \{B}}</li><li>authPolicy digest = 0xef, 0x9a, 0x26, 0xfc, 0x22, 0xd1, 0xae, 0x8c, 0xec, 0xff, 0x59, 0xe9, 0x48, 0x1a, 0xc1, 0xec, 0x53, 0x3d, 0xbe, 0x22, 0x8b, 0xec, 0x6d, 0x17, 0x93, 0x0f, 0x4c, 0xb2, 0xcc, 0x5b, 0x97, 0x24</li></ul>|
@ -93,9 +93,9 @@ To verify that Secure Launch is running, use System Information (MSInfo32). Clic
|For Qualcomm&reg; processors with SD850 or later chipsets|Description|
|--------|-----------|
|Monitor Mode Communication|All Monitor Mode communication buffers must be implemented in either EfiRuntimeServicesData (recommended), data sections of EfiRuntimeServicesCode as described by the Memory Attributes Table, EfiACPIMemoryNVS, or EfiReservedMemoryType memory types|
|Monitor Mode Page Tables|All Monitor Mode page tables must: <ul><li>NOT contain any mappings to EfiConventionalMemory (for example, no OS/VMM owned memory) </li><li>They must NOT have execute and write permissions for the same page </li><li>Platforms must only allow Monitor Mode pages marked as executable </li><li>The memory map must report Monitor Mode as EfiReservedMemoryType</li><li>Platforms must provide mechanism to protect the Monitor Mode page tables from modification</li></ul> |
|Monitor Mode Page Tables|All Monitor Mode page tables must: <ul><li>NOT contain any mappings to EfiConventionalMemory (for example no OS/VMM owned memory) </li><li>They must NOT have execute and write permissions for the same page </li><li>Platforms must only allow Monitor Mode pages marked as executable </li><li>The memory map must report Monitor Mode as EfiReservedMemoryType</li><li>Platforms must provide mechanism to protect the Monitor Mode page tables from modification</li></ul> |
|Modern/Connected Standby|Platforms must support Modern/Connected Standby.|
|Platform firmware|Platform firmware must carry all code required to perform a launch.|
|Platform firmware|Platform firmware must carry all code required to launch.|
|Platform firmware update|System firmware is recommended to be updated via UpdateCapsule in Windows Update. |
> [!NOTE]