mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-17 19:33:37 +00:00
Metadata update deployment/usmt 19
This commit is contained in:
Frank Rojas
@ -150,8 +150,10 @@ The following components are migrated by default using the manifest files:
|
||||
Even though it's not required for all applications, it's good practice to install all applications on the destination computer before restoring the user state. Installing applications before migrating settings helps to ensure that migrated settings aren't overwritten by the application installers.
|
||||
|
||||
> [!NOTE]
|
||||
> - The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.
|
||||
> - USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.
|
||||
> The versions of installed applications must match on the source and destination computers. USMT does not support migrating the settings of an earlier version of an application to a later version, except for Microsoft Office.
|
||||
|
||||
> [!NOTE]
|
||||
> USMT migrates only the settings that have been used or modified by the user. If there is an application setting on the source computer that was not touched by the user, the setting may not migrate.
|
||||
|
||||
When you specify the `MigApp.xml` file, USMT migrates the settings for the following applications:
|
||||
|
||||
|
||||
@ -15,21 +15,9 @@ ms.technology: itpro-deploy
|
||||
|
||||
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 addition to XML elements and helper functions, this article 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.
|
||||
|
||||
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.
|
||||
|
||||
- [Elements and helper functions](#elements)
|
||||
|
||||
- [Appendix](#appendix)
|
||||
|
||||
- [Specifying locations](#locations)
|
||||
|
||||
- [Internal USMT functions](#internalusmtfunctions)
|
||||
|
||||
- [Valid version tags](#allowed)
|
||||
|
||||
## <a href="" id="elements"></a>Elements and Helper Functions
|
||||
## Elements and helper functions
|
||||
|
||||
The following table describes the XML elements and helper functions you can use with USMT.
|
||||
|
||||
@ -37,17 +25,17 @@ The following table describes the XML elements and helper functions you can use
|
||||
|-----|----|-----|
|
||||
| [<addObjects>](#addobjects) <br/>[<attributes>](#attribute) <br/>[<bytes>](#bytes) <br/>[<commandLine>](#commandline) <br/>[<component>](#component) <br/>[<condition>](#condition) <br/>[<conditions>](#conditions) <br/>[<content>](#content) <br/>[<contentModify>](#contentmodify) <br/>[<description>](#description) <br/>[<destinationCleanup>](#destinationcleanup) <br/>[<detect>](#detect) <br/>[<detects>](#detects) <br/>[<detection>](#detection) <br/>[<displayName>](#displayname) <br/>[<environment>](#bkmk-environment) <br/>[<exclude>](#exclude) <br/>[<excludeAttributes>](#excludeattributes) <br/>[<extensions>](#extensions) <br/>[<extension>](#extension) <br/>[<externalProcess>](#externalprocess) <br/>[<icon>](#icon) <br/>[<include>](#include) <br/>[<includeAttribute>](#includeattributes) | [<library>](#library) <br/>[<location>](#location) <br/>[<locationModify>](#locationmodify) <br/>[<_locDefinition>](#locdefinition) <br/>[<manufacturer>](#manufacturer) <br/>[<merge>](#merge) <br/>[<migration>](#migration) <br/>[<namedElements>](#namedelements) <br/>[<object>](#object) <br/>[<objectSet>](#objectset) <br/>[<path>](#path) <br/>[<paths>](#paths) <br/>[<pattern>](#pattern) <br/>[<processing>](#processing) <br/>[<plugin>](#plugin) <br/>[<role>](#role) <br/>[<rules>](#rules) <br/>[<script>](#script) <br/>[<text>](#text) <br/>[<unconditionalExclude>](#unconditionalexclude) <br/>[<variable>](#variable) <br/>[<version>](#version) <br/>[<windowsObjects>](#windowsobjects) | [<condition> functions](#conditionfunctions) <br/>[<content> functions](#contentfunctions) <br/>[<contentModify> functions](#contentmodifyfunctions) <br/>[<include> and <exclude> filter functions](#persistfilterfunctions) <br/>[<locationModify> functions](#locationmodifyfunctions) <br/>[<merge> functions](#mergefunctions) <br/>[<script> functions](#scriptfunctions) <br/>[Internal USMT functions](#internalusmtfunctions) |
|
||||
|
||||
## <a href="" id="addobjects"></a><addObjects>
|
||||
## <addObjects>
|
||||
|
||||
The <addObjects> element emulates the existence of one or more objects on the source computer. The child <object> elements provide the details of the emulated objects. If the content is a <script> element, the result of the invocation will be an array of objects.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child elements:** [<object>](#object) In addition, you must specify [<location>](#location) and [<attribute>](#attribute) as child elements of this <object> element.
|
||||
|
||||
- **Optional child elements:**[<conditions>](#conditions), <condition>, [<script>](#script)
|
||||
- **Optional child elements:** [<conditions>](#conditions), <condition>, [<script>](#script)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -73,13 +61,13 @@ The following example is from the MigApp.xml file:
|
||||
</addObjects>
|
||||
```
|
||||
|
||||
## <a href="" id="attribute"></a><attributes>
|
||||
## <attributes>
|
||||
|
||||
The <attributes> element defines the attributes for a registry key or file.
|
||||
|
||||
- **Number of occurrences:** once for each <object>
|
||||
|
||||
- **Parent elements:**[<object>](#object)
|
||||
- **Parent elements:** [<object>](#object)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -103,13 +91,13 @@ The following example is from the MigApp.xml file:
|
||||
</object>
|
||||
```
|
||||
|
||||
## <a href="" id="bytes"></a><bytes>
|
||||
## <bytes>
|
||||
|
||||
You must specify the <bytes> element only for files because, if <location> corresponds to a registry key or a directory, then <bytes> will be ignored.
|
||||
|
||||
- **Number of occurrences:** zero or one
|
||||
|
||||
- **Parent elements:**[<object>](#object)
|
||||
- **Parent elements:** [<object>](#object)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -135,14 +123,13 @@ The following example is from the MigApp.xml file:
|
||||
</object>
|
||||
```
|
||||
|
||||
## <a href="" id="commandline"></a><commandLine>
|
||||
|
||||
## <commandLine>
|
||||
|
||||
You might want to use the <commandLine> element if you want to start or stop a service or application before or after you run the ScanState and LoadState tools.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<externalProcess>](#externalprocess)
|
||||
- **Parent elements:** [<externalProcess>](#externalprocess)
|
||||
|
||||
- **Child elements:** none****
|
||||
|
||||
@ -156,7 +143,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|*CommandLineString*|Yes|A valid command line.|
|
||||
|
||||
## <a href="" id="component"></a><component>
|
||||
## <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.
|
||||
|
||||
@ -164,11 +151,11 @@ A component can be nested inside another component; that is, the <component&g
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<migration>](#migration), [<role>](#role)
|
||||
- **Parent elements:** [<migration>](#migration), [<role>](#role)
|
||||
|
||||
- **Required child elements:**[<role>](#role), [<displayName>](#displayname)
|
||||
- **Required child elements:** [<role>](#role), [<displayName>](#displayname)
|
||||
|
||||
- **Optional child elements:**[<manufacturer>](#manufacturer), [<version>](#version), [<description>](#description), [<paths>](#paths), [<icon>](#icon), [<environment>](#bkmk-environment), [<extensions>](#extensions)
|
||||
- **Optional child elements:** [<manufacturer>](#manufacturer), [<version>](#version), [<description>](#description), [<paths>](#paths), [<icon>](#icon), [<environment>](#bkmk-environment), [<extensions>](#extensions)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -187,7 +174,7 @@ hidden="Yes|No">
|
||||
|
||||
For an example, see any of the default migration .xml files.
|
||||
|
||||
## <a href="" id="condition"></a><condition>
|
||||
## <condition>
|
||||
|
||||
Although the <condition> element under the <detect>, <objectSet>, and <addObjects> elements is supported, we recommend that you do not use it. This element might be deprecated in future versions of USMT, requiring you to rewrite your scripts. We recommend that, if you need to use a condition within the <objectSet> and <addObjects> elements, you use the more powerful [<conditions>](#conditions) element, which allows you to formulate complex Boolean statements.
|
||||
|
||||
@ -195,7 +182,7 @@ The <condition> element has a Boolean result. You can use this element to
|
||||
|
||||
- **Number of occurrences:** unlimited.
|
||||
|
||||
- **Parent elements:**[<conditions>](#conditions), <detect>, <objectSet>, <addObjects>
|
||||
- **Parent elements:** [<conditions>](#conditions), <detect>, <objectSet>, <addObjects>
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -238,15 +225,15 @@ However, in the code sample below, the <condition> elements, A and B, are
|
||||
</detection>
|
||||
```
|
||||
|
||||
### <a href="" id="conditionfunctions"></a><condition> functions
|
||||
### <condition> functions
|
||||
|
||||
The <condition> functions return a Boolean value. You can use these elements in <addObjects> conditions.
|
||||
|
||||
- [Operating system version functions](#operatingsystemfunctions)
|
||||
- [Operating system version functions](#operating-system-version-functions)
|
||||
|
||||
- [Object content functions](#objectcontentfunctions)
|
||||
- [Object content functions](#object-content-functions)
|
||||
|
||||
### <a href="" id="operatingsystemfunctions"></a>Operating system version functions
|
||||
### Operating system version functions
|
||||
|
||||
- **DoesOSMatch**
|
||||
|
||||
@ -297,8 +284,7 @@ The <condition> functions return a Boolean value. You can use these elemen
|
||||
|*OSType*|Yes|Can be **9x** or **NT**. If *OSType* does not match the type of the current operating system, then it returns FALSE. For example, if the current operating system is Windows NT-based and *OSType* is "9x" the result will be FALSE.|
|
||||
|*OSVersion*|Yes|The major version, minor version, build number, and corrected service diskette version separated by periods. For example, `5.0.2600.Service Pack 1`. You can also specify partial specification of the version but no pattern is allowed. For example, `5.0`. <br/><br/>The IsOSEarlierThan function returns TRUE if the current operating system is earlier than *OSVersion*.|
|
||||
|
||||
|
||||
### <a href="" id="objectcontentfunctions"></a>Object content functions
|
||||
### Object content functions
|
||||
|
||||
- **DoesObjectExist**
|
||||
|
||||
@ -436,15 +422,15 @@ The <condition> functions return a Boolean value. You can use these elemen
|
||||
|*ObjectType2*|Yes|Defines the type of the second object. Can be File or Registry.|
|
||||
|*EncodedLocation2*|Yes|The [encoded location](#locations) for the second object. You can specify environment variables.|
|
||||
|
||||
## <a href="" id="conditions"></a><conditions>
|
||||
## <conditions>
|
||||
|
||||
The <conditions> element returns a Boolean result that is used to specify the conditions in which the parent element is evaluated. USMT evaluates the child elements, and then joins their results using the operators AND or OR according to the **operation** parameter.
|
||||
|
||||
- **Number of occurrences:** Unlimited inside another <conditions> element. Limited to one occurrence in [<detection>](#detection), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset)
|
||||
|
||||
- **Parent elements:**[<conditions>](#conditions), [<detection>](#detection), [<environment>](#bkmk-environment), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset)
|
||||
- **Parent elements:** [<conditions>](#conditions), [<detection>](#detection), [<environment>](#bkmk-environment), [<rules>](#rules), [<addObjects>](#addobjects), and [<objectSet>](#objectset)
|
||||
|
||||
- **Child elements:**[<conditions>](#conditions), [<condition>](#condition)
|
||||
- **Child elements:** [<conditions>](#conditions), [<condition>](#condition)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -470,15 +456,15 @@ The following example is from the MigApp.xml file:
|
||||
</environment>
|
||||
```
|
||||
|
||||
## <a href="" id="content"></a><content>
|
||||
## <content>
|
||||
|
||||
You can use the <content> element to specify a list of object patterns to obtain an object set from the source computer. Each <objectSet> within a <content> element is evaluated. For each resulting object pattern list, the objects that match it are enumerated and their content is filtered by the filter parameter. The resulting string array is the output for the <content> element. The filter script returns an array of locations. The parent <objectSet> element can contain multiple child <content> elements.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<objectSet>](#objectset)
|
||||
- **Parent elements:** [<objectSet>](#objectset)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset)
|
||||
- **Child elements:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions:** You can use the following [<content> functions](#contentfunctions) with this element: ExtractSingleFile, ExtractMultipleFiles, and ExtractDirectory.
|
||||
|
||||
@ -493,7 +479,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|filter|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`. <br/>The script is called for each object that is enumerated by the object sets in the <include> rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.|
|
||||
|
||||
### <a href="" id="contentfunctions"></a><content> functions
|
||||
### <content> functions
|
||||
|
||||
The following functions generate patterns out of the content of an object. These functions are called for every object that the parent <ObjectSet> element is enumerating.
|
||||
|
||||
@ -557,15 +543,15 @@ The following functions generate patterns out of the content of an object. These
|
||||
</objectSet>
|
||||
```
|
||||
|
||||
## <a href="" id="contentmodify"></a><contentModify>
|
||||
## <contentModify>
|
||||
|
||||
The <contentModify> element modifies the content of an object before it is written to the destination computer. For each <contentModify> element there can be multiple <objectSet> elements. This element returns the new content of the object that is being processed.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child elements:**[<objectSet>](#objectset)
|
||||
- **Required child elements:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions**: You can use the following [<contentModify> functions](#contentmodifyfunctions) with this element: ConvertToDWORD, ConvertToString, ConvertToBinary, KeepExisting, OffsetValue, SetValueByTable, MergeMultiSzContent, and MergeDelimitedContent.
|
||||
|
||||
@ -580,7 +566,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|script|Yes|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2").` <br/><br/>The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.|
|
||||
|
||||
### <a href="" id="contentmodifyfunctions"></a><contentModify> functions
|
||||
### <contentModify> functions
|
||||
|
||||
The following functions change the content of objects as they are migrated. These functions are called for every object that the parent <ObjectSet> element is enumerating.
|
||||
|
||||
@ -675,13 +661,13 @@ The following functions change the content of objects as they are migrated. Thes
|
||||
| *Instruction* | Yes | Can one of the following: <ul><li>**Add.** Adds *String* to the resulting MULTI-SZ if it is not already there.</li><li>**Remove.** Removes *String* from the resulting MULTI-SZ.</li></ul> |
|
||||
| *String* | Yes | The string to be added or removed. |
|
||||
|
||||
## <a href="" id="description"></a><description>
|
||||
## <description>
|
||||
|
||||
The <description> element defines a description for the component but does not affect the migration.
|
||||
|
||||
- **Number of occurrences:** zero or one
|
||||
|
||||
- **Parent elements:**[<component>](#component)
|
||||
- **Parent elements:** [<component>](#component)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -701,22 +687,20 @@ The following code sample shows how the <description> element defines the
|
||||
<description>My custom component<description>
|
||||
```
|
||||
|
||||
## <a href="" id="destinationcleanup"></a><destinationCleanup>
|
||||
## <destinationCleanup>
|
||||
|
||||
The <destinationCleanup> element deletes objects, such as files and registry keys, from the destination computer before applying the objects from the source computer. This element is evaluated only when the LoadState tool is run on the destination computer. That is, this element is ignored by the ScanState tool.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Use this option with extreme caution because it will delete objects from the destination computer.
|
||||
|
||||
|
||||
|
||||
For each <destinationCleanup> element there can be multiple <objectSet> elements. A common use for this element is if there is a missing registry key on the source computer and you want to ensure that a component is migrated. In this case, you can delete all of the component's registry keys before migrating the source registry keys. This will ensure that if there is a missing key on the source computer, it will also be missing on the destination computer.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset) (Note that the destination computer will delete all child elements.)
|
||||
- **Child elements:** [<objectSet>](#objectset) (Note that the destination computer will delete all child elements.)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -740,7 +724,7 @@ For example:
|
||||
</destinationCleanup>
|
||||
```
|
||||
|
||||
## <a href="" id="detect"></a><detect>
|
||||
## <detect>
|
||||
|
||||
Although the <detect> element is still supported, we do not recommend using it because it may be deprecated in future versions of USMT. In that case, you would have to rewrite your scripts. Instead, we recommend that you use the [<detection>](#detection)**element.**
|
||||
|
||||
@ -752,9 +736,9 @@ For each <detect> element there can be multiple child <condition> or
|
||||
|
||||
- **Parent elements:** <detects>, [<namedElements>](#namedelements)
|
||||
|
||||
- **Required child elements:**[<condition>](#condition)
|
||||
- **Required child elements:** [<condition>](#condition)
|
||||
|
||||
- **Optional child elements:**[<objectSet>](#objectset)
|
||||
- **Optional child elements:** [<objectSet>](#objectset)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -770,7 +754,7 @@ Syntax:
|
||||
|
||||
For examples, see the examples for [<detection>](#detection).
|
||||
|
||||
## <a href="" id="detects"></a><detects>
|
||||
## <detects>
|
||||
|
||||
Although the <detects> element is still supported, we recommend that you do not use it because it may be deprecated in future versions of USMT, which would require you to rewrite your scripts. Instead, we recommend that you use the [<detection>](#detection) element if the parent element is <role> or <namedElements>, and we recommend that you use the <conditions> element if the parent element is <rules>. Using <detection> allows you to more clearly formulate complex Boolean statements.
|
||||
|
||||
@ -785,7 +769,7 @@ Syntax:
|
||||
|
||||
- **Number of occurrences:** Unlimited.
|
||||
|
||||
- **Parent elements:**[<role>](#role), [<rules>](#rules), [<namedElements>](#namedelements)
|
||||
- **Parent elements:** [<role>](#role), [<rules>](#rules), [<namedElements>](#namedelements)
|
||||
|
||||
- **Required child elements:** <detect>
|
||||
|
||||
@ -807,8 +791,7 @@ The following example is from the MigApp.xml file.
|
||||
</detects>
|
||||
```
|
||||
|
||||
## <a href="" id="detection"></a><detection>
|
||||
|
||||
## <detection>
|
||||
|
||||
The <detection> element is a container for one <conditions> element. The result of the child <condition> elements, located underneath the <conditions> element, determines the result of this element. For example, if all of the child <conditions> elements within the <detection> element resolve to TRUE, then the <detection> element resolves to TRUE. If any of the child <conditions> elements resolve to FALSE, then the <detection> element resolves to FALSE.
|
||||
|
||||
@ -818,9 +801,9 @@ Use the <detection> element under the <namedElements> element if you
|
||||
|
||||
- **Number of occurrences:** Unlimited.
|
||||
|
||||
- **Parent elements:**[<role>](#role), [<namedElements>](#namedelements)
|
||||
- **Parent elements:** [<role>](#role), [<namedElements>](#namedelements)
|
||||
|
||||
- **Child elements:**[<conditions>](#conditions)
|
||||
- **Child elements:** [<conditions>](#conditions)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -857,14 +840,13 @@ and
|
||||
</detection>
|
||||
```
|
||||
|
||||
## <a href="" id="displayname"></a><displayName>
|
||||
|
||||
## <displayName>
|
||||
|
||||
The <displayName> element is a required field within each <component> element.
|
||||
|
||||
- **Number of occurrences:** once for each component
|
||||
|
||||
- **Parent elements:**[<component>](#component)
|
||||
- **Parent elements:** [<component>](#component)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -885,17 +867,17 @@ For example:
|
||||
<displayName>Command Prompt settings</displayName>
|
||||
```
|
||||
|
||||
## <a href="" id="bkmk-environment"></a><environment>
|
||||
## <environment>
|
||||
|
||||
The <environment> element is a container for <variable> elements in which you can define variables to use in your .xml file. All environment variables defined this way will be private. That is, they will be available only for their child components and the component in which they were defined. For two example scenarios, see [Examples](#envex).
|
||||
The <environment> element is a container for <variable> elements in which you can define variables to use in your .xml file. All environment variables defined this way will be private. That is, they will be available only for their child components and the component in which they were defined. For two example scenarios, see [Examples](#examples).
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<role>](#role), [<component>](#component), [<namedElements>](#namedelements)
|
||||
- **Parent elements:** [<role>](#role), [<component>](#component), [<namedElements>](#namedelements)
|
||||
|
||||
- **Required child elements:**[<variable>](#variable)
|
||||
- **Required child elements:** [<variable>](#variable)
|
||||
|
||||
- **Optional child elements:**[conditions](#conditions)
|
||||
- **Optional child elements:** [conditions](#conditions)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -909,7 +891,7 @@ Syntax:
|
||||
| name | Yes, when <environment> is a child of <namedElements> <br/>No, when <environment> is a child of <role> or <component> | When declared as a child of the <role> or <component> elements, if *ID* is declared, USMT ignores the content of the <environment> element and the content of the <environment> element with the same name declared in the <namedElements> element is processed. |
|
||||
| context | No <br/>(default = UserAndSystem) | Defines the scope of this parameter: whether to process this component in the context of the specific user, across the entire operating system, or both. <br/>The largest possible scope is set by the <component> element. For example, if a <component> element has a context of User and a <rules> element had a context of UserAndSystem, then the <rules> element would act as though it had a context of User. If the <rules> element had a context of System, it would act as though <rules> were not there. <ul><li>**User.** Evaluates the variables for each user.</li><li>**System.** Evaluates the variables only once for the system.</li><li>**UserAndSystem.** Evaluates the variables for the entire operating system and each user.</li></ul> |
|
||||
|
||||
## <a href="" id="envex"></a>
|
||||
## Examples
|
||||
|
||||
### Example scenario 1
|
||||
|
||||
@ -989,16 +971,15 @@ Then, you can specify the variable in an <include> rule as follows:
|
||||
</include>
|
||||
```
|
||||
|
||||
## <a href="" id="exclude"></a><exclude>
|
||||
|
||||
## <exclude>
|
||||
|
||||
The <exclude> element determines what objects will not be migrated, unless there is a more specific <include> element that migrates an object. If there is an <include> and <exclude> element for the same object, the object will be included. For each <exclude> element there can be multiple child <objectSet> elements.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset)
|
||||
- **Child elements:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions:** You can use the following [<exclude> filter functions](#persistfilterfunctions) with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, NeverRestore, and SameRegContent.
|
||||
|
||||
@ -1013,7 +994,6 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|filter|No <br/>(default = No)|A script followed by any number of string arguments that are separated by a comma and enclosed in parenthesis. For example, `MyScripts.AScript ("Arg1","Arg2")`. <br/><br/>The script will be called for each object that is enumerated by the object sets in the include rule. The filter script returns a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.|
|
||||
|
||||
|
||||
For example, from the MigUser.xml file:
|
||||
|
||||
```xml
|
||||
@ -1026,16 +1006,15 @@ For example, from the MigUser.xml file:
|
||||
</exclude>
|
||||
```
|
||||
|
||||
## <a href="" id="excludeattributes"></a><excludeAttributes>
|
||||
|
||||
## <excludeAttributes>
|
||||
|
||||
You can use the <excludeAttributes> element to determine which parameters associated with an object will not be migrated. If there are conflicts between the <includeAttributes> and <excludeAttributes> elements, the most specific pattern determines the patterns that will not be migrated. If an object does not have an <includeAttributes> or <excludeAttributes> element, then all of its parameters will be migrated.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset)
|
||||
- **Child elements:** [<objectSet>](#objectset)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1099,16 +1078,15 @@ Example:
|
||||
</migration>
|
||||
```
|
||||
|
||||
## <a href="" id="extensions"></a><extensions>
|
||||
|
||||
## <extensions>
|
||||
|
||||
The <extensions> element is a container for one or more <extension> elements.
|
||||
|
||||
- **Number of occurrences:** zero or one
|
||||
|
||||
- **Parent elements:**[<component>](#component)
|
||||
- **Parent elements:** [<component>](#component)
|
||||
|
||||
- **Required child elements:**[<extension>](#extension)
|
||||
- **Required child elements:** [<extension>](#extension)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1117,14 +1095,13 @@ Syntax:
|
||||
</extensions>
|
||||
```
|
||||
|
||||
## <a href="" id="extension"></a><extension>
|
||||
|
||||
## <extension>
|
||||
|
||||
You can use the <extension> element to specify documents of a specific extension.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<extensions>](#extensions)
|
||||
- **Parent elements:** [<extensions>](#extensions)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -1158,16 +1135,15 @@ is the same as specifying the following code below the <rules> element:
|
||||
|
||||
For another example of how to use the <extension> element, see the example for [<excludeAttributes>](#excludeattributes).
|
||||
|
||||
## <a href="" id="externalprocess"></a><externalProcess>
|
||||
|
||||
## <externalProcess>
|
||||
|
||||
You can use the <externalProcess> element to run a command line during the migration process. For example, you may want to run a command after the LoadState process completes.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child elements:**[<commandLine>](#commandline)
|
||||
- **Required child elements:** [<commandLine>](#commandline)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1182,19 +1158,19 @@ Syntax:
|
||||
|
||||
For an example of how to use the <externalProcess> element, see the example for [<excludeAttributes>](#excludeattributes).
|
||||
|
||||
## <a href="" id="icon"></a><icon>
|
||||
## <icon>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <a href="" id="include"></a><include>
|
||||
## <include>
|
||||
|
||||
The <include> element determines what to migrate, unless there is a more specific [<exclude>](#exclude) rule. You can specify a script to be more specific to extend the definition of what you want to collect. For each <include> element there can be multiple <objectSet> elements.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child element:**[<objectSet>](#objectset)
|
||||
- **Required child element:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions:** You can use the following [<include> filter functions](#persistfilterfunctions) with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, and NeverRestore.
|
||||
|
||||
@ -1239,7 +1215,7 @@ The following example is from the MigUser.xml file:
|
||||
</component>
|
||||
```
|
||||
|
||||
### <a href="" id="persistfilterfunctions"></a><include> and <exclude> filter functions
|
||||
### <include> and <exclude> filter functions
|
||||
|
||||
The following functions return a Boolean value. You can use them to migrate certain objects based on when certain conditions are met.
|
||||
|
||||
@ -1290,16 +1266,15 @@ The following functions return a Boolean value. You can use them to migrate cert
|
||||
</include>
|
||||
```
|
||||
|
||||
## <a href="" id="includeattributes"></a><includeAttributes>
|
||||
|
||||
## <includeAttributes>
|
||||
|
||||
You can use the <includeAttributes> element to determine whether certain parameters associated with an object will be migrated along with the object itself. If there are conflicts between the <includeAttributes> and <excludeAttributes> elements, the most specific pattern will determine which parameters will be migrated. If an object does not have an <includeAttributes> or <excludeAttributes> element, then all of its parameters will be migrated.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset)
|
||||
- **Child elements:** [<objectSet>](#objectset)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1314,19 +1289,19 @@ Syntax:
|
||||
|
||||
For an example of how to use the <includeAttributes> element, see the example for [<excludeAttributes>](#excludeattributes).
|
||||
|
||||
## <a href="" id="library"></a><library>
|
||||
## <library>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <a href="" id="location"></a><location>
|
||||
## <location>
|
||||
|
||||
The <location> element defines the location of the <object> element.
|
||||
|
||||
- **Number of occurrences:** once for each <object>
|
||||
|
||||
- **Parent elements:**[<object>](#object)
|
||||
- **Parent elements:** [<object>](#object)
|
||||
|
||||
- **Child elements:**[<script>](#script)
|
||||
- **Child elements:** [<script>](#script)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1356,15 +1331,15 @@ The following example is from the MigApp.xml file:
|
||||
</addObjects>
|
||||
```
|
||||
|
||||
## <a href="" id="locationmodify"></a><locationModify>
|
||||
## <locationModify>
|
||||
|
||||
You can use the <locationModify> element to change the location and name of an object before it is migrated to the destination computer. The <locationModify> element is processed only when the LoadState tool is run on the destination computer. In other words, this element is ignored by the ScanState tool. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist.
|
||||
|
||||
**Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child element:**[<objectSet>](#objectset)
|
||||
- **Required child element:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions:** You can use the following [<locationModify> functions](#locationmodifyfunctions) with this element: ExactMove, RelativeMove, and Move.
|
||||
|
||||
@ -1389,7 +1364,7 @@ The following example is from the MigApp.xml file:
|
||||
</locationModify>
|
||||
```
|
||||
|
||||
### <a href="" id="locationmodifyfunctions"></a><locationModify> functions
|
||||
### <locationModify> functions
|
||||
|
||||
The following functions change the location of objects as they are migrated when using the <locationModify> element. These functions are called for every object that the parent <ObjectSet> element is enumerating. The <locationModify> element will create the appropriate folder on the destination computer if it does not already exist.
|
||||
|
||||
@ -1449,19 +1424,17 @@ For example:
|
||||
</locationModify>
|
||||
```
|
||||
|
||||
## <a href="" id="locdefinition"></a><\_locDefinition>
|
||||
|
||||
## <\_locDefinition>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <a href="" id="manufacturer"></a><manufacturer>
|
||||
|
||||
## <manufacturer>
|
||||
|
||||
The <manufacturer> element defines the manufacturer for the component, but does not affect the migration.
|
||||
|
||||
- **Number of occurrences:** zero or one
|
||||
|
||||
- **Parent elements:**[<component>](#component)
|
||||
- **Parent elements:** [<component>](#component)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -1475,7 +1448,7 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
|*Name*|Yes|The name of the manufacturer for the component.|
|
||||
|
||||
## <a href="" id="merge"></a><merge>
|
||||
## <merge>
|
||||
|
||||
The <merge> element determines what will happen when a collision occurs. A collision is when an object that is migrated is already present on the destination computer. If you do not specify this element, the default behavior for the registry is for the source object to overwrite the destination object. The default behavior for files is for the source file to be renamed to "OriginalFileName(1).OriginalExtension". This element specifies only what should be done when a collision occurs. It does not include objects. Therefore, for your objects to migrate, you must specify <include> rules along with the <merge> element. When an object is processed and a collision is detected, USMT will select the most specific merge rule and apply it to resolve the conflict. For example, if you have a <merge> rule C:\\\* \[\*\] set to <sourcePriority> and a <merge> rule C:\\subfolder\\\* \[\*\] set to <destinationPriority>, then USMT would use the <destinationPriority> rule because it is the more specific.
|
||||
|
||||
@ -1483,9 +1456,9 @@ For an example of this element, see [Conflicts and Precedence](usmt-conflicts-an
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child element:**[<objectSet>](#objectset)
|
||||
- **Required child element:** [<objectSet>](#objectset)
|
||||
|
||||
- **Helper functions:** You can use the following [<merge> functions](#mergefunctions) with this element: SourcePriority, DestinationPriority, FindFilePlaceByPattern, LeafPattern, NewestVersion, HigherValue(), and LowerValue().
|
||||
|
||||
@ -1517,7 +1490,7 @@ The following example is from the MigUser.xml file:
|
||||
</rules>
|
||||
```
|
||||
|
||||
### <a href="" id="mergefunctions"></a><merge> functions
|
||||
### <merge> functions
|
||||
|
||||
These functions control how collisions are resolved.
|
||||
|
||||
@ -1581,7 +1554,7 @@ These functions control how collisions are resolved.
|
||||
</merge>
|
||||
```
|
||||
|
||||
## <a href="" id="migration"></a><migration>
|
||||
## <migration>
|
||||
|
||||
The <migration> element is the single root element of a migration .xml file and is required. Each .xml file must have a unique migration urlid. The urlid of each file that you specify on the command line must be unique. This is because USMT uses the urlid to define the components within the file. For example, you must specify the following at the beginning of each file: <CustomFileName> is the name of the file; for example, "CustomApp".
|
||||
|
||||
@ -1589,9 +1562,9 @@ The <migration> element is the single root element of a migration .xml fil
|
||||
|
||||
- **Parent elements:** none
|
||||
|
||||
- **Required child elements:**[<component>](#component)
|
||||
- **Required child elements:** [<component>](#component)
|
||||
|
||||
- **Optional child elements:**[<library>](#library), [<namedElements>](#namedelements)
|
||||
- **Optional child elements:** [<library>](#library), [<namedElements>](#namedelements)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1638,7 +1611,7 @@ This filter helper function can be used to filter the migration of files based o
|
||||
</component>
|
||||
```
|
||||
|
||||
## <a href="" id="namedelements"></a><namedElements>
|
||||
## <namedElements>
|
||||
|
||||
You can use the **<namedElements>** element to define named elements. You can use these elements in any component throughout your .xml file. For an example of how to use this element, see the MigApp.xml file.
|
||||
|
||||
@ -1651,23 +1624,23 @@ Syntax:
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<migration>](#migration)
|
||||
- **Parent elements:** [<migration>](#migration)
|
||||
|
||||
- **Child elements:**[<environment>](#bkmk-environment), [<rules>](#rules), [<conditions>](#conditions), [<detection>](#detection), <detects>, <detect>
|
||||
- **Child elements:** [<environment>](#bkmk-environment), [<rules>](#rules), [<conditions>](#conditions), [<detection>](#detection), <detects>, <detect>
|
||||
|
||||
For an example of this element, see the MigApp.xml file.
|
||||
|
||||
## <a href="" id="object"></a><object>
|
||||
## <object>
|
||||
|
||||
The <object> element represents a file or registry key.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<addObjects>](#addobjects)
|
||||
- **Parent elements:** [<addObjects>](#addobjects)
|
||||
|
||||
- **Required child elements:**[<location>](#location), [<attributes>](#attribute)
|
||||
- **Required child elements:** [<location>](#location), [<attributes>](#attribute)
|
||||
|
||||
- **Optional child elements:**[<bytes>](#bytes)
|
||||
- **Optional child elements:** [<bytes>](#bytes)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1693,18 +1666,17 @@ The following example is from the MigApp.xml file:
|
||||
</addObjects>
|
||||
```
|
||||
|
||||
## <a href="" id="objectset"></a><objectSet>
|
||||
|
||||
## <objectSet>
|
||||
|
||||
The <objectSet> element contains a list of object patterns ; for example, file paths, registry locations, and so on. Any child <conditions> elements will be evaluated first. If all child <conditions> elements return FALSE, the <objectSet> element will evaluate to an empty set. For each parent element, there can be only multiple <objectSet> elements.
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<variable>](#variable), [<content>](#content), [<include>](#include), [<exclude>](#exclude), [<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [<unconditionalExclude>](#unconditionalexclude), <detect>
|
||||
- **Parent elements:** [<variable>](#variable), [<content>](#content), [<include>](#include), [<exclude>](#exclude), [<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [<unconditionalExclude>](#unconditionalexclude), <detect>
|
||||
|
||||
- **Required child elements:** either [<script>](#script) or [<pattern>](#pattern)
|
||||
|
||||
- **Optional child elements:**[<content>](#content), [conditions](#conditions), <condition>
|
||||
- **Optional child elements:** [<content>](#content), [conditions](#conditions), <condition>
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1743,19 +1715,16 @@ The following example is from the MigUser.xml file:
|
||||
</component>
|
||||
```
|
||||
|
||||
## <a href="" id="path"></a><path>
|
||||
|
||||
## <path>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <a href="" id="paths"></a><paths>
|
||||
|
||||
## <paths>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <pattern>
|
||||
|
||||
|
||||
You can use this element to specify multiple objects. You can specify multiple <pattern> elements for each <objectSet> element and they will be combined. If you are specifying files, you may want to use GenerateDrivePatterns with <script> instead. GenerateDrivePatterns is basically the same as a <pattern> rule, without the drive letter specification. For example, the following two lines of code are similar:
|
||||
|
||||
```xml
|
||||
@ -1765,7 +1734,7 @@ You can use this element to specify multiple objects. You can specify multiple &
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<objectSet>](#objectset)
|
||||
- **Parent elements:** [<objectSet>](#objectset)
|
||||
|
||||
- **Child elements:** none but *Path* \[*object*\] must be valid.
|
||||
|
||||
@ -1812,15 +1781,15 @@ For example:
|
||||
|
||||
- For more examples of how to use this element, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md), [Reroute Files and Settings](usmt-reroute-files-and-settings.md), [Include Files and Settings](usmt-include-files-and-settings.md), and [Custom XML Examples](usmt-custom-xml-examples.md).
|
||||
|
||||
## <a href="" id="processing"></a><processing>
|
||||
## <processing>
|
||||
|
||||
You can use this element to run a script during a specific point within the migration process. Return values are not expected from the scripts that you specify, and if there are return values, they will be ignored.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Required child element:**[<script>](#script)
|
||||
- **Required child element:** [<script>](#script)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1833,21 +1802,21 @@ Syntax:
|
||||
|--- |--- |--- |
|
||||
| when | Yes | Indicates when the script should be run. This value can be one of the following: <ul><li>**pre-scan** means before the scanning process begins.</li><li>**scan-success** means after the scanning process has finished successfully.</li><li>**post-scan** means after the scanning process has finished, whether it was successful or not.</li><li>**pre-apply** means before the apply process begins.</li><li>**apply-success** means after the apply process has finished successfully.</li><li>**post-apply** means after the apply process has finished, whether it was successful or not.</li></ul> |
|
||||
|
||||
## <a href="" id="plugin"></a><plugin>
|
||||
## <plugin>
|
||||
|
||||
This is an internal USMT element. Do not use this element.
|
||||
|
||||
## <a href="" id="role"></a><role>
|
||||
## <role>
|
||||
|
||||
The <role> element is required in a custom .xml file. By specifying the <role> element, you can create a concrete component. The component will be defined by the parameters specified at the <component> level, and with the role that you specify here.
|
||||
|
||||
- **Number of occurrences:** Each <component> can have one, two or three child <role> elements.
|
||||
|
||||
- **Parent elements:**[<component>](#component), [<role>](#role)
|
||||
- **Parent elements:** [<component>](#component), [<role>](#role)
|
||||
|
||||
- **Required child elements:**[<rules>](#rules)
|
||||
- **Required child elements:** [<rules>](#rules)
|
||||
|
||||
- **Optional child elements:**[<environment>](#bkmk-environment), [<detection>](#detection), [<component>](#component), [<role>](#role), <detects>, <plugin>,
|
||||
- **Optional child elements:** [<environment>](#bkmk-environment), [<detection>](#detection), [<component>](#component), [<role>](#role), <detects>, <plugin>,
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1891,18 +1860,17 @@ The following example is from the MigUser.xml file. For more examples, see the M
|
||||
</component>
|
||||
```
|
||||
|
||||
## <a href="" id="rules"></a><rules>
|
||||
|
||||
## <rules>
|
||||
|
||||
The <rules> element is required in a custom .xml file. This element contains rules that will run during the migration if the parent <component> element is selected, unless the child <conditions> element, if present, evaluates to FALSE. For each <rules> element there can be multiple child <rules> elements.
|
||||
|
||||
- **Number of occurrences:** unlimited
|
||||
|
||||
- **Parent elements:**[<role>](#role), [<rules>](#rules), [<namedElements>](#namedelements)
|
||||
- **Parent elements:** [<role>](#role), [<rules>](#rules), [<namedElements>](#namedelements)
|
||||
|
||||
- **Required child elements:**[<include>](#include)
|
||||
- **Required child elements:** [<include>](#include)
|
||||
|
||||
- **Optional child elements:**[<rules>](#rules), [<exclude>](#exclude), [<unconditionalExclude>](#unconditionalexclude),[<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<addObjects>](#addobjects), [<externalProcess>](#externalprocess), [<processing>](#processing), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [conditions](#conditions), <detects>
|
||||
- **Optional child elements:** [<rules>](#rules), [<exclude>](#exclude), [<unconditionalExclude>](#unconditionalexclude),[<merge>](#merge), [<contentModify>](#contentmodify), [<locationModify>](#locationmodify), [<destinationCleanup>](#destinationcleanup), [<addObjects>](#addobjects), [<externalProcess>](#externalprocess), [<processing>](#processing), [<includeAttributes>](#includeattributes), [<excludeAttributes>](#excludeattributes), [conditions](#conditions), <detects>
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -1946,14 +1914,13 @@ The following example is from the MigUser.xml file:
|
||||
</component>
|
||||
```
|
||||
|
||||
## <a href="" id="script"></a><script>
|
||||
|
||||
## <script>
|
||||
|
||||
The return value that is required by <script> depends on the parent element.
|
||||
|
||||
**Number of occurrences:** Once for [<variable>](#variable), unlimited for [<objectSet>](#objectset) and [<processing>](#processing)
|
||||
|
||||
**Parent elements:**[<objectSet>](#objectset), [<variable>](#variable), [<processing>](#processing)
|
||||
**Parent elements:** [<objectSet>](#objectset), [<variable>](#variable), [<processing>](#processing)
|
||||
|
||||
**Child elements:** none
|
||||
|
||||
@ -1999,7 +1966,7 @@ To migrate the Sample.doc file from any drive on the source computer, use <sc
|
||||
|
||||
For more examples of how to use this element, see [Exclude Files and Settings](usmt-exclude-files-and-settings.md), [Reroute Files and Settings](usmt-reroute-files-and-settings.md), and [Custom XML Examples](usmt-custom-xml-examples.md).
|
||||
|
||||
### <a href="" id="scriptfunctions"></a><script> functions
|
||||
### <script> functions
|
||||
|
||||
You can use the following functions with the <script> element
|
||||
|
||||
@ -2007,7 +1974,7 @@ You can use the following functions with the <script> element
|
||||
|
||||
- [Simple executing scripts](#simple)
|
||||
|
||||
### <a href="" id="stringgeneratingfunctions"></a>String and pattern generating functions
|
||||
### String and pattern generating functions
|
||||
|
||||
These functions return either a string or a pattern.
|
||||
|
||||
@ -2126,7 +2093,7 @@ This helper function invokes the document finder to scan the system for all file
|
||||
</component>
|
||||
```
|
||||
|
||||
### <a href="" id="simple"></a>Simple executing scripts
|
||||
### Simple executing scripts
|
||||
|
||||
The following scripts have no return value. You can use the following errors with <script> elements that are within <processing> elements
|
||||
|
||||
@ -2172,14 +2139,13 @@ The following scripts have no return value. You can use the following errors wit
|
||||
|
||||
- **SyncSCM(ServiceShortName).** Reads the Start type value from the registry (HKLM\\System\\CurrentControlSet\\Services\\ServiceShortName \[Start\]) after it is changed by the migration engine, and then synchronizes Service Control Manager (SCM) with the new value.
|
||||
|
||||
## <a href="" id="text"></a><text>
|
||||
|
||||
## <text>
|
||||
|
||||
You can use the <text> element to set a value for any environment variables that are inside one of the migration .xml files.
|
||||
|
||||
- **Number of occurrences:** Once in each [<variable>](#variable) element.
|
||||
|
||||
- **Parent elements:**[<variable>](#variable)
|
||||
- **Parent elements:** [<variable>](#variable)
|
||||
|
||||
- **Child elements:** None.
|
||||
|
||||
@ -2201,8 +2167,7 @@ For example:
|
||||
</variable>
|
||||
```
|
||||
|
||||
## <a href="" id="unconditionalexclude"></a><unconditionalExclude>
|
||||
|
||||
## <unconditionalExclude>
|
||||
|
||||
The <unconditionalExclude> element excludes the specified files and registry values from the migration, regardless of the other include rules in any of the migration .xml files or in the Config.xml file. The objects declared here will not be migrated because this element takes precedence over all other rules. For example, even if there are explicit <include> rules to include .mp3 files, if you specify to exclude them with this option, then they will not be migrated.
|
||||
|
||||
@ -2210,9 +2175,9 @@ Use this element if you want to exclude all .mp3 files from the source computer.
|
||||
|
||||
- **Number of occurrences:** Unlimited.
|
||||
|
||||
- **Parent elements:**[<rules>](#rules)
|
||||
- **Parent elements:** [<rules>](#rules)
|
||||
|
||||
- **Child elements:**[<objectSet>](#objectset)
|
||||
- **Child elements:** [<objectSet>](#objectset)
|
||||
|
||||
Syntax:
|
||||
|
||||
@ -2239,8 +2204,7 @@ The following .xml file excludes all .mp3 files from migration. For additional e
|
||||
</migration>
|
||||
```
|
||||
|
||||
## <a href="" id="variable"></a><variable>
|
||||
|
||||
## <variable>
|
||||
|
||||
The <variable> element is required in an <environment> element. For each <variable> element there must be one <objectSet>, <script>, or <text> element. The content of the <variable> element assigns a text value to the environment variable. This element has the following three options:
|
||||
|
||||
@ -2252,7 +2216,7 @@ The <variable> element is required in an <environment> element. For
|
||||
|
||||
- **Number of occurrences:** Unlimited
|
||||
|
||||
- **Parent elements:**[<environment>](#bkmk-environment)
|
||||
- **Parent elements:** [<environment>](#bkmk-environment)
|
||||
|
||||
- **Required child elements:** either [<text>](#text), or [<script>](#script), or [<objectSet>](#objectset)
|
||||
|
||||
@ -2281,14 +2245,13 @@ The following example is from the MigApp.xml file:
|
||||
</environment>
|
||||
```
|
||||
|
||||
## <a href="" id="version"></a><version>
|
||||
|
||||
## <version>
|
||||
|
||||
The <version> element defines the version for the component, but does not affect the migration.
|
||||
|
||||
- **Number of occurrences:** zero or one
|
||||
|
||||
- **Parent elements:**[<component>](#component)
|
||||
- **Parent elements:** [<component>](#component)
|
||||
|
||||
- **Child elements:** none
|
||||
|
||||
@ -2308,13 +2271,13 @@ For example:
|
||||
<version>4.*</version>
|
||||
```
|
||||
|
||||
## <a href="" id="windowsobjects"></a><windowsObjects>
|
||||
## <windowsObjects>
|
||||
|
||||
The <windowsObjects> element is for USMT internal use only. Do not use this element.
|
||||
|
||||
## Appendix
|
||||
|
||||
### <a href="" id="locations"></a>Specifying locations
|
||||
### Specifying locations
|
||||
|
||||
- **Specifying encoded locations**. The encoded location used in all of the helper functions is an unambiguous string representation for the name of an object. It is composed of the node part, optionally followed by the leaf enclosed in square brackets. This makes a clear distinction between nodes and leaves.
|
||||
|
||||
@ -2326,7 +2289,7 @@ The <windowsObjects> element is for USMT internal use only. Do not use thi
|
||||
|
||||
For example, the pattern `c:\Windows\*` will match the Windows directory and all subdirectories. But it will not match any of the files in those directories. To match the files as well, you must specify `c:\Windows\*[*]`.
|
||||
|
||||
### <a href="" id="internalusmtfunctions"></a>Internal USMT functions
|
||||
### Internal USMT functions
|
||||
|
||||
The following functions are for internal USMT use only. Do not use them in an .xml file.
|
||||
|
||||
@ -2356,7 +2319,7 @@ The following functions are for internal USMT use only. Do not use them in an .x
|
||||
|
||||
- SetPstPathInMapiStruc
|
||||
|
||||
### <a href="" id="allowed"></a>Valid version tags
|
||||
### Valid version tags
|
||||
|
||||
You can use the following version tags with various helper functions:
|
||||
|
||||
@ -2382,6 +2345,6 @@ The following version tags contain values that can be compared:
|
||||
|
||||
- "ProductVersion"
|
||||
|
||||
## Related topics
|
||||
## Related articles
|
||||
|
||||
[USMT XML Reference](usmt-xml-reference.md)
|
||||
[USMT XML reference](usmt-xml-reference.md)
|
||||
|
||||
Reference in New Issue
Block a user