mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-21 05:13:40 +00:00
Updated-5548201
Converted HTML tables to Markdown tables in the following topics Offline Migration Reference Understanding Migration XML Files Choose a Migration Store Type User State Migration Tool (USMT) Command-line Syntax Config.xml File Conflicts and Precedence Custom XML Examples Determine What to Migrate Hard-Link Migration Store LoadState Syntax Log Files Migration Store Encryption Plan Your Migration Recognized Environment Variables User State Migration Toolkit (USMT) Reference
This commit is contained in:
Benzy Dharmanayagam
@ -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 **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. The following elements and parameters are for use in the Config.xml file only.
|
||||
|
||||
[<Policies>](#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><Policies>
|
||||
|
||||
|
||||
The **<Policies>** element contains elements that describe the policies that USMT follows while creating a migration store. Valid children of the **<Policies>** element are **<ErrorControl>** and **<HardLinkStoreControl>**. The **<Policies>** element is a child of **<Configuration>**.
|
||||
|
||||
Syntax: `<Policies> </Policies>`
|
||||
|
||||
## <a href="" id="bkmk-errorcontrol"></a><ErrorControl>
|
||||
|
||||
|
||||
The **<ErrorControl>** element is an optional element you can configure in the Config.xml file. The configurable **<ErrorControl>** 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
|
||||
@ -111,8 +104,6 @@ Additionally, the order in the **<ErrorControl>** section implies priority
|
||||
**Important**
|
||||
The configurable **<ErrorControl>** 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><fatal>
|
||||
|
||||
The **<fatal>** element is not required.
|
||||
@ -125,35 +116,14 @@ The **<fatal>** element is not required.
|
||||
|
||||
Syntax: `<fatal errorCode="any">`*<pattern>*`</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>"any" or "<em>specify system error message here</em>"</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
|
||||
|Parameter|Required|Value|
|
||||
|--- |--- |--- |
|
||||
|errorCode|No|"any" or "*specify system error message here*"|
|
||||
|
||||
You use the **<fatal>** element to specify that errors matching a specific pattern should cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-fileerror"></a><fileError>
|
||||
|
||||
|
||||
The **<fileError>** element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
@ -168,7 +138,6 @@ You use the **<fileError>** element to represent the behavior associated w
|
||||
|
||||
## <a href="" id="bkmk-nonfatal"></a><nonFatal>
|
||||
|
||||
|
||||
The **<nonFatal>** element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
@ -179,35 +148,14 @@ The **<nonFatal>** element is not required.
|
||||
|
||||
Syntax: `<nonfatal errorCode="any">`*<pattern>*`</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><errorCode></strong></p></td>
|
||||
<td align="left"><p>No</p></td>
|
||||
<td align="left"><p>"any" or "<em>specify system error message here</em>". 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|
|
||||
|--- |--- |--- |
|
||||
|**<errorCode>**|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 **<nonFatal>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-registryerror"></a><registryError>
|
||||
|
||||
|
||||
The <strong><registryError></strong>element is not required.
|
||||
|
||||
- **Number of occurrences**: Once for each component
|
||||
@ -218,35 +166,14 @@ The <strong><registryError></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><errorCode></strong></p></td>
|
||||
<td align="left"><p>No</p></td>
|
||||
<td align="left"><p>"any" or "<em>specify system error message here</em>". 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|
|
||||
|--- |--- |--- |
|
||||
|**<errorCode>**|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 **<registryError>** element to specify that errors matching a specific pattern should not cause USMT to halt the migration.
|
||||
|
||||
## <a href="" id="bkmk-hardlinkstorecontrol"></a><HardLinkStoreControl>
|
||||
|
||||
|
||||
The **<HardLinkStoreControl>** element contains elements that describe how to handle files during the creation of a hard-link migration store. Its only valid child is **<fileLocked>**.
|
||||
|
||||
Syntax: `<HardLinkStoreControl> </HardLinkStoreControl>`
|
||||
@ -264,8 +191,6 @@ The **<HardLinkStoreControl>** sample code below specifies that hard links
|
||||
**Important**
|
||||
The **<ErrorControl>** section can be configured to conditionally ignore file access errors, based on the file’s location.
|
||||
|
||||
|
||||
|
||||
``` xml
|
||||
<Policy>
|
||||
<HardLinkStoreControl>
|
||||
@ -282,84 +207,49 @@ The **<ErrorControl>** section can be configured to conditionally ignore f
|
||||
|
||||
## <a href="" id="bkmk-filelock"></a><fileLocked>
|
||||
|
||||
|
||||
The **<fileLocked>** element contains elements that describe how to handle files that are locked for editing. The rules defined by the **<fileLocked>** element are processed in the order in which they appear in the XML file.
|
||||
|
||||
Syntax: `<fileLocked></fileLocked>`
|
||||
|
||||
## <a href="" id="bkmk-createhardlink"></a><createHardLink>
|
||||
|
||||
|
||||
The **<createHardLink>** 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>`*<pattern>*`</createHardLink>`
|
||||
|
||||
## <a href="" id="bkmk-errorhardlink"></a><errorHardLink>
|
||||
|
||||
|
||||
The **<errorHardLink>** 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 **<ErrorControl>** section to either cause USMT to skip the file or abort the migration.
|
||||
|
||||
Syntax: `<errorHardLink>`*<pattern>*`</errorHardLink>`
|
||||
|
||||
## <a href="" id="bkmk-profilecontrol"></a><ProfileControl>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish rules for migrating profiles, users, and policies around local group membership during the migration. **<ProfileMigration>** is a child of **<Configuration>**.
|
||||
|
||||
Syntax: <`ProfileControl> </ProfileControl>`
|
||||
|
||||
## <a href="" id="bkmk-localgroups"></a><localGroups>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish rules for how to migrate local groups. **<localGroups>** is a child of **<ProfileControl>**.
|
||||
|
||||
Syntax: `<localGroups> </localGroups>`
|
||||
|
||||
## <a href="" id="bkmk-mappings"></a><mappings>
|
||||
|
||||
|
||||
This element is used to contain other elements that establish mappings between groups.
|
||||
|
||||
Syntax: `<mappings> </mappings>`
|
||||
|
||||
## <a href="" id="bkmk-changegrou"></a><changeGroup>
|
||||
|
||||
|
||||
This element describes the source and destination groups for a local group membership change during the migration. It is a child of **<localGroups>**. 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 **<changeGroup>** are **<include>** and **<exclude>**. 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><include>
|
||||
|
||||
|
||||
This element specifies that its required child, *<pattern>*, should be included in the migration.
|
||||
|
||||
Syntax: `<include>``</include>`
|
||||
|
||||
## <a href="" id="bkmk-exclude"></a><exclude>
|
||||
|
||||
|
||||
This element specifies that its required child, *<pattern>*, 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)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user