mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 10:23:37 +00:00
Update metadata seo marvel 4_24 2
This commit is contained in:
1justingilmore
@ -18,12 +18,10 @@ ms.topic: article
|
||||
# XML Elements Library
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
|
||||
This topic describes the XML elements and helper functions that you can employ to author migration .xml files to use with User State Migration Tool (USMT). It is assumed that you understand the basics of XML. .
|
||||
|
||||
## In This Topic
|
||||
## In this topic
|
||||
|
||||
|
||||
In addition to XML elements and helper functions, this topic describes how to specify encoded locations and locations patterns, functions that are for internal USMT use only, and the version tags that you can use with helper functions.
|
||||
@ -327,7 +325,7 @@ Syntax:
|
||||
## <a href="" id="component"></a><component>
|
||||
|
||||
|
||||
The <component> element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the MigApp.xml file, "Microsoft® Office 2003" is a component that contains another component, "Microsoft Office Access® 2003". You can use the child elements to define the component.
|
||||
The <component> element is required in a custom .xml file. This element defines the most basic construct of a migration .xml file. For example, in the MigApp.xml file, "Microsoft® Office 2003" is a component that contains another component, "Microsoft Office Access® 2003". You can use the child elements to define the component.
|
||||
|
||||
A component can be nested inside another component; that is, the <component> element can be a child of the <role> element within the <component> element in two cases: 1) when the parent <component> element is a container or 2) if the child <component> element has the same role as the parent <component> element.
|
||||
|
||||
@ -366,7 +364,7 @@ hidden="Yes|No">
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>You can use the following to group settings, and define the type of the component.</p>
|
||||
<ul>
|
||||
<li><p><strong>System:</strong> Operating system settings. All Windows® components are defined by this type.</p>
|
||||
<li><p><strong>System:</strong> Operating system settings. All Windows® components are defined by this type.</p>
|
||||
<p>When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that is specified on the LoadState command line. For example, the default MigSys.xml file contains components with type="System" and defaultSupported="FALSE". If you specify this file on the ScanState command line, you must also specify the file on the LoadState command line for the settings to migrate. This is because the LoadState tool must detect an equivalent component. That is, the component must have the same migration urlid of the .xml file and an identical display name. Otherwise, the LoadState tool will not migrate those settings from the store. This is helpful when the source computer is running Windows XP, and you are migrating to both Windows Vista and Windows XP because you can use the same store for both destination computers.</p></li>
|
||||
<li><p><strong>Application:</strong> Settings for an application.</p></li>
|
||||
<li><p><strong>Device:</strong> Settings for a device.</p></li>
|
||||
@ -557,7 +555,7 @@ For example:
|
||||
<tr class="odd">
|
||||
<td align="left"><p><em>OSType</em></p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>Can be <strong>9x</strong> or <strong>NT</strong>. If <em>OSType</em> does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and <em>OSType</em> is “9x”, the result will be FALSE.</p></td>
|
||||
<td align="left"><p>Can be <strong>9x</strong> or <strong>NT</strong>. If <em>OSType</em> does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and <em>OSType</em> is "9x", the result will be FALSE.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><em>OSVersion</em></p></td>
|
||||
@ -599,7 +597,7 @@ For example:
|
||||
<tr class="odd">
|
||||
<td align="left"><p><em>OSType</em></p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p>Can be <strong>9x</strong> or <strong>NT</strong>. If <em>OSType</em> does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and <em>OSType</em> is “9x” the result will be FALSE.</p></td>
|
||||
<td align="left"><p>Can be <strong>9x</strong> or <strong>NT</strong>. If <em>OSType</em> does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and <em>OSType</em> is "9x" the result will be FALSE.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p><em>OSVersion</em></p></td>
|
||||
@ -3132,8 +3130,8 @@ This filter helper function can be used to filter the migration of files based o
|
||||
<tr class="odd">
|
||||
<td align="left"><p>valueToCompare</p></td>
|
||||
<td align="left"><p>The value we are comparing. For example:</p>
|
||||
<p>Date: “2008/05/15-2005/05/17”, “2008/05/15”</p>
|
||||
<p>Size: A numeral with B, KB, MB, or GB at the end. “5GB”, “1KB-1MB”</p></td>
|
||||
<p>Date: "2008/05/15-2005/05/17", "2008/05/15"</p>
|
||||
<p>Size: A numeral with B, KB, MB, or GB at the end. "5GB", "1KB-1MB"</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -3465,8 +3463,8 @@ Syntax:
|
||||
</ul>
|
||||
<p>You can either:</p>
|
||||
<ol>
|
||||
<li><p>Specify up to three <role> elements within a <component> — one “Binaries” role element, one “Settings” role element and one “Data” role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these <role> elements, but each nested element must be of the same role parameter.</p></li>
|
||||
<li><p>Specify one “Container” <role> element within a <component> element. In this case, you cannot specify any child <rules> elements, only other <component> elements. And each child <component> element must have the same type as that of parent <component> element. For example:</p></li>
|
||||
<li><p>Specify up to three <role> elements within a <component> — one "Binaries" role element, one "Settings" role element and one "Data" role element. These parameters do not change the migration behavior — their only purpose is to help you categorize the settings that you are migrating. You can nest these <role> elements, but each nested element must be of the same role parameter.</p></li>
|
||||
<li><p>Specify one "Container" <role> element within a <component> element. In this case, you cannot specify any child <rules> elements, only other <component> elements. And each child <component> element must have the same type as that of parent <component> element. For example:</p></li>
|
||||
</ol>
|
||||
<pre class="syntax" space="preserve"><code><component context="UserAndSystem" type="Application">
|
||||
<displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName>
|
||||
@ -3847,7 +3845,7 @@ See the last component in the MigUser.xml file for an example of this element.
|
||||
~~~
|
||||
**Example:**
|
||||
|
||||
If GenerateUserPattens('File','%userprofile% \[\*.doc\]','FALSE') is called while USMT is processing user A, then this function will only generate patterns for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the source computer — but if user X is not migrated, then do not migrate any of the .doc files from user X’s profile.
|
||||
If GenerateUserPattens('File','%userprofile% \[\*.doc\]','FALSE') is called while USMT is processing user A, then this function will only generate patterns for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the source computer — but if user X is not migrated, then do not migrate any of the .doc files from user X's profile.
|
||||
|
||||
The following is example code for this scenario. The first <rules> element migrates all.doc files on the source computer with the exception of those inside C:\\Documents and Settings. The second <rules> elements will migrate all .doc files from C:\\Documents and Settings with the exception of the .doc files in the profiles of the other users. Because the second <rules> element will be processed in each migrated user context, the end result will be the desired behavior. The end result is the one we expected.
|
||||
|
||||
@ -4104,12 +4102,12 @@ Syntax:
|
||||
<tr class="odd">
|
||||
<td align="left"><p>name</p></td>
|
||||
<td align="left"><p>Yes</p></td>
|
||||
<td align="left"><p><em>ID</em> is a string value that is the name used to reference the environment variable. We recommend that <em>ID</em> start with the component’s name to avoid namespace collisions. For example, if your component’s name is MyComponent, and you want a variable that is your component’s install path, you could specify <code>MyComponent.InstallPath</code>.</p></td>
|
||||
<td align="left"><p><em>ID</em> is a string value that is the name used to reference the environment variable. We recommend that <em>ID</em> start with the component's name to avoid namespace collisions. For example, if your component's name is MyComponent, and you want a variable that is your component's install path, you could specify <code>MyComponent.InstallPath</code>.</p></td>
|
||||
</tr>
|
||||
<tr class="even">
|
||||
<td align="left"><p>remap</p></td>
|
||||
<td align="left"><p>No, default = FALSE</p></td>
|
||||
<td align="left"><p>Specifies whether to evaluate this environment variable as a remapping environment variable. Objects that are located in a path that is underneath this environment variable’s value are automatically moved to where the environment variable points on the destination computer.</p></td>
|
||||
<td align="left"><p>Specifies whether to evaluate this environment variable as a remapping environment variable. Objects that are located in a path that is underneath this environment variable's value are automatically moved to where the environment variable points on the destination computer.</p></td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@ -4228,27 +4226,27 @@ The following functions are for internal USMT use only. Do not use them in an .x
|
||||
|
||||
You can use the following version tags with various helper functions:
|
||||
|
||||
- “CompanyName”
|
||||
- "CompanyName"
|
||||
|
||||
- “FileDescription”
|
||||
- "FileDescription"
|
||||
|
||||
- “FileVersion”
|
||||
- "FileVersion"
|
||||
|
||||
- “InternalName”
|
||||
- "InternalName"
|
||||
|
||||
- “LegalCopyright”
|
||||
- "LegalCopyright"
|
||||
|
||||
- “OriginalFilename”
|
||||
- "OriginalFilename"
|
||||
|
||||
- “ProductName”
|
||||
- "ProductName"
|
||||
|
||||
- “ProductVersion”
|
||||
- "ProductVersion"
|
||||
|
||||
The following version tags contain values that can be compared:
|
||||
|
||||
- “FileVersion”
|
||||
- "FileVersion"
|
||||
|
||||
- “ProductVersion”
|
||||
- "ProductVersion"
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
Reference in New Issue
Block a user