XML Elements Reference

Overview

The following document describes the XML elements that you can use to author migration .xml files for use with USMT. It is assumed that readers of this document understand the basics of XML. You can download a .doc version of this file at https://go.microsoft.com/fwlink/?LinkId=73866.

Note

You may need to adjust the width of the sidebar on the left to view this topic. For example, if you have to scroll to read the text, move the sidebar to the left.

In this topic

• Elements and Helper Functions
• Appendix
  • Specifying Locations
  • Internal USMT functions
  • Valid version tags

Elements and helper functions

Elements A-K	Elements L-Z	Helper Functions
<addObjects> <attributes> <bytes> <commandLine> <component> <condition> <conditions> <content> <contentModify> <description> <destinationCleanup> <detect> <detects> <detection> <displayName> <environment> <exclude> <excludeAttributes> <extensions> <extension> <externalProcess> <icon> <include> <includeAttribute>	<library> <location> <locationModify> <_locDefinition> <manufacturer> <merge> <migration> <namedElements> <object> <objectSet> <path> <paths> <pattern> <processing> <plugin> <role> <rules> <script> <text> <unconditionalExclude> <variable> <version> <windowsObjects>	<condition> functions <content> functions <contentModify> functions <include> and <exclude> filter functions <locationModify> functions <merge> functions <script> functions Internal USMT functions

<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>
• Required child elements: <object> (In addition, you must specify <location> and <attribute> as child elements of this <object> element.)
• Optional child elements: <conditions>, <condition>, <script>,

Syntax:

<addObjects>

</addObjects>

The following example is from MigApp.xml:

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
   </object>
</addObjects>

<attributes>

This element defines the attributes for the registry key or file.

• Number of occurrences: once for each <object>
• Parent elements: <object>
• Child elements: none

Syntax:

<attributes>Content</attributes>

Parameter	Required?	Value
Content	Yes	The content depends on the type of object specified. For files, the content can be any string made out of the following attributes (separated by commas): Archive Read-only System Hidden For registry keys, the content can be one of the following types: None String ExpandString Binary Dword REG_SZ

The following example is from MigApp.xml:

<object>
   <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [Lang]</location>
   <attributes>DWORD</attributes>
   <bytes>00000000</bytes>
</object> 

<bytes>

You only need to specify this element 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>
• Child elements: none

Syntax:

<bytes string="Yes|No" expand="Yes|No">Content</bytes>

Parameter	Required?	Value
string	No, default is No	Determines whether Content should be interpreted as a string or as bytes.
expand	No, default is Yes	When this is Yes, the content of the <bytes> element will be first expanded in the context of the source computer and then interpreted.
Content	Yes	Depends on the value of the string. When the string is Yes: the content of the <bytes> element is interpreted as a string. When the string is No: the content of the <bytes> element is interpreted as bytes. Each two characters represent the hexadecimal value of a byte. For example, “616263” is the representation for “abc” ANSI string. A complete representation of the UNICODE string “abc” including the string terminator would be: “6100620063000000”.

The following example is from MigApp.xml:

<object>
   <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [Lang]</location>
   <attributes>DWORD</attributes>
   <bytes>00000000</bytes>
</object> 

<commandLine>

You might want to use this element if you need to start or stop a service or application before or after you run ScanState and LoadState.

• Number of occurrences: unlimited
• Parent elements: <externalProcess>
• Child elements: none

Syntax:

<commandLine>Content</commandLine>

Parameter	Required?	Value
Content	Yes	A valid command line.

<component>

This element is required in a custom .xml file. <component> defines the most basic construct of a migration .xml file. For example, in MigApp.xml, "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, <component> can be a child of <role> within <component>) in two cases: 1) when the parent component is a container or 2) if the child <component> has the same role as the parent <component>.

• Number of occurrences: Unlimited
• Parent elements: <migration>, <role>
• Required child elements:<role>, <displayName>
• Optional child elements: <manufacturer>, <version>, <description>, <paths>, <icon>, <environment>, <extensions>

Syntax:

<component type="System|Application|Device|Documents" context="User|System|UserAndSystem" defaultSupported="TRUE|FALSE|YES|NO"

hidden="Yes|No">

</component>

Parameter	Required?	Value
type	Yes	You can use the following to group settings, and define the type of the component. System: Operating system settings. All Windows components are defined by this type. When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that are specified with LoadState. 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 in order for the settings to migrate. This is because LoadState must detect an equivalent component (that is, the component must have the same migration urlid of the .xml file and an identical display name) or it 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. Application: Settings for an application. Device: Settings for a device. Documents: Specifies files.
context	No (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. 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 has a context of User. If <rules> had a context of System, it would act as though <rules> was not there. User. Evaluates the component for each user. System. Evaluates the component only once for the system. UserAndSystem. Evaluates the component for the entire operating system and each user.
defaultSupported	No (default = TRUE)	Can be any of TRUE, FALSE, YES or NO. If this parameter is FALSE (or NO), the component will not be migrated unless there is an equivalent component on the destination computer. When type="System" and defaultSupported="FALSE" the settings will not migrate unless there is an equivalent component in the .xml files that are specified with LoadState. 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 in order for the settings to migrate. This is because LoadState must detect an equivalent component (that is, the component must have the same migration urlid of the .xml file and an identical display name) or it 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.
hidden		This is for internal USMT use only.

For an example, see any of the default migration .xml files.

<condition>

Although using this element under the <detect>, <objectSet>, and <addObjects> elements is supported, we do not recommend it because this element may be deprecated in future versions of USMT (and then you would have to rewrite your scripts). You should only use this element within <conditions> — and you should use <conditions> within <objectSet> and <addObjects>.

This element has a Boolean result. You can use this element to specify the conditions in which the parent element will be evaluated. If any of the present conditions return FALSE, the parent element will not be evaluated.

• Number of occurrences: unlimited.
• Parent elements: <conditions>, <detect>, <objectSet>, <addObjects>
• Child elements: none
• Helper Functions: You can use the following <condition> functions with this element: DoesOSMatch, IsNative64Bit(), IsOSLaterThan, IsOSEarlierThan, DoesObjectExist, DoesFileVersionMatch, IsFileVersionAbove, IsFileVersionBelow, IsSystemContext, DoesStringContentEqual, DoesStringContentContain, IsSameObject, IsSameContent, IsSameStringContent

Syntax:

<condition negation="Yes|No">Content</condition>

Parameter	Required?	Value
negation	No (default = no)	"Yes" reverses the True/False value of the condition.
Content	Yes	A script that has been defined within this migration section.

For example,

A and B below will get ANDed together because they are in separate <conditions> sections. For example:

<detection>
   <conditions>
      <condition>A</condition>
   </conditions>
   <conditions operation="AND">
      <condition>B</condition>
   </conditions>
</detection>

However, A and B in the following example will get ORed together because they are in the same <conditions> section.

<detection>
   <conditions>
      <condition>A</condition>
      <condition>B</condition>
   </conditions>
</detection>

<condition> functions

These functions return a Boolean value. You can use these elements in <addObjects> conditions.

• Operating system version functions
• Object content functions

Operating system version functions

• DoesOSMatch
  All matches are case insensitive.
  Syntax: DoesOSMatch("OSType","OSVersion")

Parameter	Required?	Value
OSType	Yes	Can be 9x or NT.
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 with a pattern. For example 5.0.*.

For example: \

• IsNative64Bit
  This function will return TRUE if the migration process is running as a native 64-bit process (that is, a process running on a 64-bit system without Windows on Windows (WOW)). Otherwise, it will return FALSE.

• IsOSLaterThan
  All comparisons are case insensitive.
  Syntax: IsOSLaterThan("OSType","OSVersion")

Parameter	Required?	Value
OSType	Yes	Can be 9x or NT. If OSType does not match the type of the current operating system, then it will return 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. This function will return TRUE if the current operating system is later than OSVersion.

For example: \

• IsOSEarlierThan
  All comparisons are case insensitive.
  Syntax: IsOSEarlierThan("OSType","OSVersion")

Parameter	Required?	Value
OSType	Yes	Can be 9x or NT. If OSType does not match the type of the current operating system, then it will return 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. This function will return TRUE if the current operating system is earlier than OSVersion.

Object content functions

• DoesObjectExist
  This function will return TRUE if any object exists that matches the location pattern. Otherwise, it will return FALSE. The location pattern is expanded before attempting the enumeration.
  Syntax: DoesObjectExist("ObjectType","EncodedLocationPattern")

Parameter	Required?	Value
ObjectType	Yes	Defines the object type. Can be File or Registry.
EncodedLocationPattern	Yes	The location pattern. Environment variables are allowed.

For an example of this element, see the MigApp.xml file.

• DoesFileVersionMatch
  The pattern check is case insensitive.
  Syntax: DoesFileVersionMatch("EncodedFileLocation","VersionTag","VersionValue")

Parameter	Required?	Value
EncodedFileLocation	Yes	The location pattern for the file that will be checked. Environment variables are allowed.
VersionTag	Yes	The version tag value that will be checked.
VersionValue	Yes	A string pattern. For example "Microsoft*".

For example: \ \

• IsFileVersionAbove
  This function will return TRUE if the version of the file is higher than VersionValue.
  Syntax: IsFileVersionAbove("EncodedFileLocation","VersionTag","VersionValue")

Parameter	Required?	Value
EncodedFileLocation	Yes	The location pattern for the file that will be checked. Environment variables are allowed.
VersionTag	Yes	The version tag value that will be checked.
VersionValue	Yes	The value to compare to. You cannot specify a pattern.

• IsFileVersionBelow
  Syntax: IsFileVersionBelow("EncodedFileLocation","VersionTag","VersionValue")

Parameter	Required?	Value
EncodedFileLocation	Yes	The location pattern for the file that will be checked. Environment variables are allowed.
VersionTag	Yes	The version tag value that will be checked.
VersionValue	Yes	The value to compare to. You cannot specify a pattern.

• IsSystemContext
  This function returns TRUE if the current context is "System". Otherwise, it returns FALSE.
  Syntax: IsSystemContext()

• DoesStringContentEqual
  This function returns TRUE if the string representation of the given object is identical to StringContent.
  Syntax: DoesStringContentEqual("ObjectType","EncodedLocation","StringContent")

Parameter	Required?	Value
ObjectType	Yes	Defines the type of object. Can be File or Registry.
EncodedLocationPattern	Yes	The encoded location for the object that will be examined. You can specify environment variables.
StringContent	Yes	The string that will be checked against.

For example:

• DoesStringContentContain
  This function will return TRUE if there is at least one occurrence of StrToFind in the string representation of the object.
  Syntax: DoesStringContentContain("ObjectType","EncodedLocation","StrToFind")

Parameter	Required?	Value
ObjectType	Yes	Defines the type of object. Can be File or Registry.
EncodedLocationPattern	Yes	The encoded location for the object that will be examined. You can specify environmental variables.
StrToFind	Yes	A string that will be searched inside the content of the given object.

• IsSameObject
  This function will return TRUE if the given encoded locations resolve to the same physical object. Otherwise, it will return FALSE.
  Syntax: IsSameObject("ObjectType","EncodedLocation1","EncodedLocation2")

Parameter	Required?	Value
ObjectType	Yes	Defines the type of object. Can be File or Registry.
EncodedLocation1	Yes	The encoded location for the first object. You can specify environmental variables.
EncodedLocation2	Yes	The encoded location for the second object. You can specify environmental variables.

For example:

• IsSameContent
  This function returns TRUE if the given objects have the same content. Otherwise, it returns FALSE. The content will be compared byte by byte.
  Syntax: IsSameContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")

Parameter	Required?	Value
ObjectType1	Yes	Defines the type of the first object. Can be File or Registry.
EncodedLocation1	Yes	The encoded location for the first object. You can specify environmental variables.
ObjectType2	Yes	Defines the type of the second object. Can be File or Registry.
EncodedLocation2	Yes	The encoded location for the second object. You can specify environmental variables.

• IsSameStringContent
  This function will return TRUE if the given objects have the same content. Otherwise, it will return FALSE. The content will be interpreted as a string.
  Syntax: IsSameStringContent("ObjectType1","EncodedLocation1","ObjectType2","EncodedLocation2")

Parameter	Required?	Value
ObjectType1	Yes	Defines the type of the first object. Can be File or Registry.
EncodedLocation1	Yes	The encoded location for the first object. You can specify environmental variables.
ObjectType2	Yes	Defines the type of the second object. Can be File or Registry.
EncodedLocation2	Yes	The encoded location for the second object. You can specify environmental variables.

<conditions>

This element returns a Boolean result which is used to specify the conditions in which the parent element is evaluated. USMT evaluates the child elements and their results will be ANDed or ORed together according to the "operation" parameter.

• Number of occurrences: Unlimited inside another <conditions> element. Once in <detection>, <rules>, <addObjects>, and <objectSet>
• Parent elements: <conditions>, <detection>, <environment>, <rules>, <addObjects>,and <objectSet>
• Child elements: <conditions>, <condition>

Syntax:

<conditions operation="AND|OR">

</conditions>

Parameter	Required?	Value
operation	No, default is AND	Defines the Boolean operation that is performed on the results that are obtained from the child elements.

The following example is from MigApp.xml:

<environment name="GlobalEnv">
   <conditions>
      <condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
   </conditions>
   <variable name="HklmWowSoftware">
   <text>HKLM\Software</text>
   </variable>
</environment>

<content>

You can use this element to specify a list of object patterns in order to obtain an object set from the 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 will return an array of locations. The parent <objectSet> element can contain multiple child <content> elements.

• Number of occurrences: unlimited
• Parent elements: <objectSet>
• Child elements: <objectSet>
• Helper functions: You can use the following <content> functions with this element: ExtractSingleFile, ExtractMultipleFiles, ExtractDirectory

Syntax:

<content filter="ScriptInvocation">

</content>

Parameter	Required?	Value
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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.

The following example is from MigApp.xml:

<include>
   <objectSet>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [01020fff]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e0324]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6600]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6700]</pattern>
      <content filter="MigSysHelper.ExtractSingleFileAnsiBin()">
         <objectSet>
            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e0324]</pattern>
            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6600]</pattern>
            <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6700]</pattern>
         </objectSet>
      </content>
   </objectSet>
</include>

<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.

• ExtractSingleFile
  If the registry value is a MULTI-SZ, only the first segment is processed. The returned pattern is the encoded location for a file that must exist on the system. If the specification is correct in the registry value, but the file does not exist, this function will return NULL.
  Syntax: ExtractSingleFile(Separators,PathHints)

Parameter	Required?	Value
Separators	Yes	A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. You can specify NULL.
PathHints	Yes	A list of extra paths, separated by colons (;), where the function will look for a file matching the current content. For example, if the content is "Notepad.exe" and the path is the %Path% environment variable, the function will find Notepad.exe in %windir% and will return “c:\Windows [Notepad.exe]”. You can specify NULL.

For example:

• ExtractMultipleFiles
  This function returns multiple patterns, one for each file that is found in the content of the given registry value. If the registry value is a MULTI-SZ, the MULTI-SZ separator is considered a separator by default (therefore for MULTI-SZ, the <Separators> argument needs to be NULL).
  The returned patterns are the encoded locations for files that must exist on the computer. If the specification is correct in the registry value, but the file does not exist it will not be included in the resulting list.
  Syntax: ExtractMultipleFiles(Separators,PathHints)

Parameter	Required?	Value
Separators	Yes	A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. This parameter needs to be NULL when processing MULTI-SZ registry values.
PathHints	Yes	A list of extra paths, separated by colons (;), where the function will look for a file matching the current content. For example, if the content is "Notepad.exe" and the path is the %Path% environment variable, the function will find Notepad.exe in %windir% and will return “c:\Windows [Notepad.exe]”. You can specify NULL.

• ExtractDirectory
  This function returns a pattern that is the encoded location for a directory that must exist on the computer. If the specification is correct in the registry value, but the directory does not exist, this function will return NULL. If it is processing a registry value that is a MULTI-SZ, only the first segment will be processed.
  Syntax: ExtractDirectory(Separators,LevelsToTrim,PatternSuffix)

Parameter	Required?	Value
Separators	No	A list of possible separators that might follow the file specification in this registry value name. For example, if the content is "C:\Windows\Notepad.exe,-2", the separator is a comma. You must specify NULL when processing MULTI-SZ registry values.
LevelsToTrim	Yes	The number of levels to delete from the end of the directory specification. You should use this function to extract a root directory when you have a registry value that points inside that root directory in a known location.
PatternSuffix	Yes	The pattern to add to the directory specification. For example * [*].

For example:

<contentModify>

This 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>
• Required child elements: <objectSet>
• Helper functions: You can use the following <contentModify> functions with this element: ConvertToDWORD, ConvertToString, ConvertToBinary, KeepExisting, OffsetValue, SetValueByTable, MergeMultiSzContent, MergeDelimitedContent

Syntax:

<contentModify script="ScriptInvocation">

</contentModify>

Parameter	Required?	Value
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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.

The following example is from MigApp.xml.

<contentModify script='MigSysHelper.SetPstPathInMapiStruct ()'>
   <objectSet>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [0102*]</pattern>
   </objectSet>
</contentModify>

<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.

• ConvertToDWORD
  This function converts the content of registry values that are enumerated by the parent <ObjectSet> element to a DWORD. For example, ConvertToDWORD will convert the string "1" to the DWORD 0x00000001. If the conversion fails, then the value of DefaultValueOnError will be applied.
  Syntax: ConvertToDWORD(DefaultValueOnError)

Parameter	Required?	Value
DefaultValueOnError	No	The value that will be written into the value name if the conversion fails. You can specify NULL, and 0 will be written if the conversion fails.

• ConvertToString
  This function converts the content of registry values that match the parent <ObjectSet> element to a string. For example, it will convert the DWORD 0x00000001 to the string "1". If the conversion fails, then the value of DefaultValueOnError will be applied.
  Syntax: ConvertToString(DefaultValueOnError)

Parameter	Required?	Value
DefaultValueOnError	No	The value that will be written into the value name if the conversion fails. You can specify NULL, and 0 will be written if the conversion fails.

For example:

• ConvertToBinary
  This function converts the content of registry values that match the parent <ObjectSet> element to a binary type.
  Syntax: ConvertToBinary ()

• KeepExisting
  You can use this function when there are conflicts on the destination computer. This function will keep (not overwrite) the specified attributes for the object that is on the destination computer.
  Syntax: KeepExisting("OptionString","OptionString","OptionString",…)

Parameter	Required?	Value
OptionString	Yes	OptionString can be Security, TimeFields, or FileAttrib:Letter. You can specify one of each type of OptionStrings. You shouldnot specify multiple OptionStrings with the same value. If you do, the right-most option of that type will be kept. For example, do not specify ("FileAttrib:H", "FileAttrib:R") because only Read-only will be evaluated. Instead specify ("FileAttrib:HR") and both Hidden and Read-only attributes will be kept on the destination computer. Security. Keeps the destination object's security descriptor (if it exists). TimeFields. Keeps the destination object's time stamps. This is for files only. FileAttrib:Letter. Keeps the destination object's attribute value (either on or off) for the specified set of file attributes. This is for files only. The following are case-insensitive, but USMT will ignore any values that are invalid, repeated, or if there is a space after "FileAttrib:". You can specify any combination of the following attributes: A = Archive C = Compressed E = Encrypted H = Hidden I = Not Content Indexed O = Offline R = Read-Only S = System T = Temporary

• OffsetValue
  This function adds or subtracts Value from the value of the migrated object, and then writes the result back into the registry value on the destination computer. For example, if the migrated object is a DWORD with a value of 14, and the Value is "-2" the registry value will be 12 on the destination computer.
  Syntax: OffsetValue(Value)

Parameter	Required?	Value
Value	Yes	The string representation of a numeric value. It can be positive or negative. For example, OffsetValue(2).

• SetValueByTable
  This function matches the value from the source computer into the source table. If the value is there, the equivalent value in the destination table will be applied. If the value is not there, or if the destination table has no equivalent value, the DefaultValueOnError will be applied.
  Syntax: SetValueByTable(SourceTable,DestinationTable,DefaultValueOnError)

Parameter	Required?	Value
SourceTable	Yes	A list of values (separated by commas) that are possible for the source registry values.
DestinationTable	No	A list of translated values (separated by commas).
DefaultValueOnError	No	The value that will be applied to the destination computer if either 1) the value for the source computer does not match SourceTable, or 2) DestinationTable has no equivalent value. If DefaultValueOnError is NULL the value will not be changed on the destination computer.

• MergeMultiSzContent
  This function merges the MULTI-SZ content of the registry values (that are enumerated by the parent <ObjectSet> element) with the content of the equivalent registry values that already exist on the destination computer. Instruction and String either remove or add content to the resulting MULTI-SZ. Duplicate elements will be removed.
  Syntax: MergeMultiSzContent (Instruction,String,Instruction,String,…)

Parameter	Required?	Value
Instruction	Yes	Can one of the following: Add. Adds the corresponding String to the resulting MULTI-SZ if it is not already there. Remove. Removes the corresponding String from the resulting MULTI-SZ.
String	Yes	The string to be added or removed.

• MergeDelimitedContent
  This function merges the content of the registry values (that are enumerated by the parent <ObjectSet> element) with the content of the equivalent registry values that already exist on the destination computer. The content is considered a list of elements separated by one of the characters in Delimiters. Duplicate elements will be removed.
  Syntax: MergeDelimitedContent(Delimiters,Instruction,String,…)

Parameter	Required?	Value
Delimiters	Yes	A single character that will be used to separate the content of the object that is being processed. The content will be considered as a list of elements that is separated by the Delimiters. For example, "." will separate the string based on a period.
Instruction	Yes	Can one of the following: Add. Adds String to the resulting MULTI-SZ if it is not already there. Remove. Removes String from the resulting MULTI-SZ.
String	Yes	The string to be added or removed.

• SetPstPathInMapiStruct
  This is an internal USMT function. You should not use this function.

• ConvertToOfficeLangID
  This is an internal USMT function. You should not use this function.

<description>

This element defines a description for the component, but does not affect the migration.

• Number of occurrences: zero or one
• Parent elements: <component>
• Child elements: none

Syntax:

<description>Content</description>

Parameter	Required?	Value
Content	Yes	The description of the component.

For example:

<description>My custom component<description>

<destinationCleanup>

This element deletes objects (files and registry keys) from the destination computer before applying the objects from the source computer. This element is only evaluated when LoadState is run on the destination computer. That is, this element is ignored by ScanState.

Important

You should 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 was a missing key on the source computer, it will also be missing on the destination computer.

• Number of occurrences: Unlimited
• Parent elements: <rules>
• Child elements: <objectSet> (Note that all child elements will be deleted from the destination computer.)

Syntax:

<destinationCleanup filter=ScriptInvocation>

</destinationCleanup>

Parameter	Required?	Value
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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return 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:

<destinationCleanup>
   <objectSet>
      <pattern type="Registry">HKCU\Software\Lotus\123\99.0\DDE Preferences\* [*]</pattern>
      <pattern type="Registry">HKCU\Software\Lotus\123\99.0\Find Preferences\* [*]</pattern>
   </objectSet>
</destinationCleanup>

<detect>

Although this element is still supported, we recommend that you do not use it. This is because this element may be deprecated in future versions of USMT (and you would have to rewrite your scripts). Instead, we recommend that you use the<detection>element.

The <detect> element is used to determine if the component is present on a system. If all the child <detect> elements within <detects> resolve to true, then <detects> resolves to true. If any child <detect> elements resolve to false, then <detects> resolves to false. If there is no <detects> section, then USMT will assume that the component is present.

For each <detect> element there can be multiple child <condition> or <objectSet> elements, which will be logically ORed together. If at least one <condition> or <objectSet> element evaluates to TRUE, then the <detect> element evaluates to TRUE.

• Number of occurrences: unlimited
• Parent elements: <detects>, <namedElements>
• Required child elements: <condition>
• Optional child elements: <objectSet>

Syntax:

<detect name="ID" context="User|System|UserAndSystem">

</detect>

Parameter	Required?	Value
name	Yes, when <detect> is a child to <namedElements> No, when <detect> is a child to <detects>	When ID is specified, any child elements are not processed. Instead, any other <detect> elements with the same name that are declared within <namedElements> are processed.
context	No (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. 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 has a context of User. If <rules> had a context of System, it would act as though <rules> was not there. User. Evaluates the variables for each user. System. Evaluates the variables only once for the system. UserAndSystem. Evaluates the variables for the entire operating system and each user.

For examples, see the examples for <detection>.

<detects>

Although this element is still supported, we recommend that you do not use it. This is because this element may be deprecated in future versions of USMT (and you would have to rewrite your scripts). Instead, we recommend that you use the<detection>element if the parent element is <role> or <namedElements>, and we recommend that you use <conditions> if the parent is <rules>.

This is a container for one or more <detect> elements. If all the child <detect> elements within <detects> resolve to true, then <detects> resolves to true. If any child <detect> elements resolve to false, then <detects> resolves to false. If you do not want to write the <detects> elements within a component, then you can create the <detects> element under <namedElements> and then refer to it. If there is no <detects> section, then USMT will assume that the component is present. The results from each <detects> element will be ‘OR’ed together to form the detection of the parent element.

Syntax:

<detects name="ID" context="User|System|UserAndSystem">

</detects>

• Number of occurrences: Unlimited.
• Parent elements: <role>, <rules>, <namedElements>
• Required child elements: <detect>

Parameter	Required?	Value
name	Yes, when <detects> is a child to <namedElements> No, when <detects> is a child to <role> or <rules>	When ID is specified, any child <detect> elements are not processed. Instead, any other <detects> elements with the same name that are declared within <namedElements> are processed.
context	No (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. 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 has a context of User. If <rules> had a context of System, it would act as though <rules> was not there. User. Evaluates the variables for each user. System. Evaluates the variables only once for the system. UserAndSystem. Evaluates the variables for the entire operating system and each user. The context parameter is ignored for <detects> elements that are inside <rules> elements.

The following example is from MigApp.xml.

<detects>
   <detect>
      <condition>MigXmlHelper.DoesFileVersionMatch("%Lotus123InstPath%\123w.exe","ProductVersion","9.*")</condition>
   </detect>
   <detect>
      <condition>MigXmlHelper.DoesFileVersionMatch("%SmartSuiteInstPath%\smartctr.exe","ProductVersion","99.*")</condition>
   </detect>
</detects>

<detection>

This is a container for one <conditions> element. The result of the child <condition> elements (underneath <conditions>) determines the result of this element. For example, if all the child <conditions> elements within <detection> resolve to true, then <detection> resolves to true. If any child <conditions> elements resolve to false, then <detection> resolves to false.

In addition, the results from each <detection> section within <role> will be ‘OR’ed together to form the detection of the parent element. That is, if one of the <detection> sections resolves to true, then <role> will be processed. Otherwise, <role> will not be processed.

You should use this element under <namedElements> if you do not want to write it within a component. Then include a matching <detection> section under <role> to control whether the component is migrated or not. If there is not a <detection> section for a component, then USMT will assume that the component is present.

• Number of occurrences: Unlimited.
• Parent elements: <role>, <namedElements>
• Child elements: <conditions>

Syntax:

<detection name="ID" context="User|System|UserAndSystem">

</detection>

Parameter	Required?	Value
name	Yes, when <detection> is declared under <namedElements> element Optional, when declared under <role>	If declared, the content of the <detection> element is ignored and the content of the <detection> element with the same name that is declared in <namedElements> will be evaluated.
context	No, default is 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. User. Evaluates the component for each user. System. Evaluates the component only once for the system. UserAndSystem. Evaluates the component for the entire operating system and each user.

For example:

<detection name="AdobePhotoshopCS">
   <conditions>
      <condition>MigXmlHelper.DoesObjectExist("Registry","HKCU\Software\Adobe\Photoshop\8.0")</condition>
      <condition>MigXmlHelper.DoesFileVersionMatch("%PhotoshopSuite8Path%\Photoshop.exe","FileVersion","8.*")</condition>
   </conditions>
</detection>

and

<role role="Settings">
   <detection>
      <conditions>
         <condition>MigXmlHelper.DoesFileVersionMatch("%QuickTime5Exe%","ProductVersion","QuickTime 5.*")</condition>
         <condition>MigXmlHelper.DoesFileVersionMatch("%QuickTime5Exe%","ProductVersion","QuickTime 6.*")</condition>
      </conditions>
   </detection>

<displayName>

This is a required field within each <component> element.

• Number of occurrences: once for each component
• Parent elements: <component>
• Child elements: none

Syntax:

<displayName _locID="ID">Content</displayName>

Parameter	Required?	Value
locID	No	This is for internal USMT use. You should not use this parameter.
Content	Yes	The name for the component.

For example:

<displayName>Command Prompt settings</displayName>

<environment>

This element is a container for <variable> elements where you can define variables to use in your .xml file. All environment variables defined this way will be private — that is, they will only be available for their child components and the component in which they were defined. For two example scenarios, see Examples.

• Number of occurrences: unlimited
• Parent elements: <role>, <component>, <namedElements>
• Required child elements: <variable>
• Optional child elements: conditions

Syntax:

<environment name="ID" context="User|System|UserAndSystem">

</environment>

Parameter	Required?	Value
name	Yes, when <environment> is a child of <namedElements> No, when <environment> is a child of <role> or <component>	When declared as a child of <role> or <component>, 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 <namedElements> is processed.
context	No (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. 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 has a context of User. If <rules> had a context of System, it would act as though <rules> was not there. User. Evaluates the variables for each user. System. Evaluates the variables only once for the system. UserAndSystem. Evaluates the variables for the entire operating system and each user.

Example scenario 1

You might need to generate the location of objects at run time depending on the configuration of the destination computer. For example, you will need to do this if an application writes data in the directory where it is installed and users can install the application anywhere on the computer. If the application writes a registry value hklm\software\companyname\install [path] and then updates this value with the location where the application is installed, then the only way for you to correctly migrate the required data is to define an environment variable. For example:

<environment>
   <variable name=”INSTALLPATH”>
      <script>MigXmlHelper.GetStringContent("Registry","\software\companyname\install [path]")</script>
   </variable>
</environment>

Then you can use it an include rule as follows. You can use any of the <script> functions to perform similar tasks.

<include>
   <objectSet>
      <pattern type="File">%INSTALLPATH%\ [*.xyz]</pattern>
   </objectSet>
</include>

Secondly, you can also filter registry values which contain data that you need. The following example extracts the first string (before the separator “,”) in the value of the registry Hklm\software\companyname\application\ [Path].

<environment>
   <variable name="APPPATH">
        <objectSet>
           <content filter='MigXmlHelper.ExtractDirectory (“,”, "1")'>
             <objectSet>
                <pattern type="Registry">Hklm\software\companyname\application\ [Path]</pattern>
              </objectSet>
            </content>
        </objectSet>
    </variable>
</environment>

Example scenario 2:

If you want to migrate five files named File1.txt, File2.txt, and so on, from %SystemDrive%\data\userdata\dir1\dir2\, you need to have the following <include> rule in an .xml file:

<include>
   <objectSet>
      <pattern type="File">%SystemDrive%\data\userdata\dir1\dir2 [File1.txt]</pattern>
      <pattern type="File">%SystemDrive%\data\userdata\dir1\dir2 [File2.txt]</pattern>
      <pattern type="File">%SystemDrive%\data\userdata\dir1\dir2 [File3.txt]</pattern>
      <pattern type="File">%SystemDrive%\data\userdata\dir1\dir2 [File4.txt]</pattern>
      <pattern type="File">%SystemDrive%\data\userdata\dir1\dir2 [File5.txt]</pattern>
   </objectSet>
</include>

Instead of typing the path five times, you can create a variable for the location as follows:

<environment>
   <variable name=”DATAPATH”>
      <text>%SystemDrive%\data\userdata\dir1\dir2 </text>
      </variable>
</environment>

Then, you can specify the variable in an <include> rule as follows:

<include>
   <objectSet>
      <pattern type="File">%DATAPATH% [File1.txt]</pattern>
      <pattern type="File">%DATAPATH% [File2.txt]</pattern>
      <pattern type="File">%DATAPATH% [File3.txt]</pattern>
      <pattern type="File">%DATAPATH% [File4.txt]</pattern>
      <pattern type="File">%DATAPATH% [File5.txt]</pattern>
   </objectSet>
</include>

<exclude>

The <exclude> element determines what objects will not be migrated — unless there is a more specific <include> that migrates an object. If there is an <include> and <exclude> 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>
• Child elements: <objectSet>
• Helper Functions: You can use the following <exclude> filter functions with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, NeverRestore, SameRegContent

Syntax:

<exclude filter="ScriptInvocation">

</exclude>

Parameter	Required?	Value
filter	No (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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return 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 MigUser.xml:

<exclude>
   <objectSet>
      <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>
      <pattern type="File">%CSIDL_MYPICTURES%\* [*]</pattern>
      <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
   </objectSet>
</exclude>

<excludeAttributes>

You can use this element to determine which parameters associated with an object will not be migrated. If there are conflicts between <includeAttributes> and <excludeAttributes>, the most specific pattern will win. If an object does not have a <includeAttributes> or <excludeAttributes>, then all its parameters will be migrated.

• Number of occurrences: Unlimited
• Parent elements: <rules>
• Child elements: <objectSet>

Syntax:

<excludeAttributes attributes="Security|TimeFields|Security,TimeFields">

</excludeAttributes>

Parameter	Required?	Value
attributes	Yes	Specifies the attributes to be excluded. You can specify one of the following, or both separated by quotes (for example "Security","TimeFields"): Security can be one of Owner, Group, DACL, or SACL. TimeFields can be one of CreationTime, LastAccessTime and LastWrittenTime

Example:

<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/miguser">
<!-- This component migrates My Video files -->
   <component type="System" context="System">
      <displayName>System Data</displayName>
         <role role="Data">
            <rules>
<!-- Include all the text files, which are immediately in the drive where the operating system is installed -->
               <include>
                  <objectSet>
                     <pattern type="File">%systemdrive%\ [*.txt]</pattern>
                  </objectSet>
               </include>
<!-- Exclude the time stamps from the text file starting with the letter a -->
               <excludeAttributes attributes="TimeFields">
                  <objectSet>
                     <pattern type="File">%systemdrive%\ [a*.txt]</pattern>
                  </objectSet>
               </excludeAttributes>
<!-- include the time stamps from the text file aa.txt -->
               <includeAttributes attributes="TimeFields">
                  <objectSet>
                     <pattern type="File">%systemdrive%\ [aa.txt]</pattern>
                  </objectSet>
               </includeAttributes>
<!-- Logoff the user after loadstate successfully completed. -->
               <externalProcess when="post-apply">
                  <commandLine>
                     logoff
                  </commandLine>
               </externalProcess>
         </rules>
   </role>
<!-- Migrate 
   all doc files from the system
   all power point files
   all visio design files 
   all my c++ program files -->
   <extensions>
      <extension>DOC</extension>
      <extension>PPT</extension>
      <extension>VXD</extension>
      <extension>PST</extension>
      <extension>CPP</extension>
   </extensions>
</component>
</migration>

<extensions>

This is a container for one or more <extension> elements.

• Number of occurrences: zero or one
• Parent elements: <component>
• Required child elements: <extension>

Syntax:

<extensions>

</extensions>

<extension>

You can use this element to specify documents of a specific extension.

• Number of occurrences: unlimited
• Parent elements: <extensions>
• Child elements: none

Syntax:

<extension>Content</extension>

Parameter	Required?	Value
Content	Yes	A file name extension.

For example, if you want to migrate all *.doc files from the source computer, specifying the following code under <component>:

<extensions> 
        <extension>doc</extension> 
<extensions> 

Is the same as specifying the following underneath <rules>:

<include> 
        <objectSet> 
                <script>MigXmlHelper.GenerateDrivePatterns ("* [*.doc]", "Fixed")</script> 
        </objectSet> 
</include>

For another example of how to use this element, see the example for <excludeAttributes>.

<externalProcess>

You can use this element to run a command line during the migration process. For example, you may want to run a command after LoadState completes.

• Number of occurrences: Unlimited
• Parent elements: <rules>
• Required child elements: <commandLine>

Syntax:

<externalProcess when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">

</externalProcess>

Parameter	Required?	Value
when	Yes	Indicates when the command line should be run. This value can be one of the following: pre-scan means before the scanning process begins. scan-success means after the scanning process has finished successfully. post-scan means after the scanning process has finished, whether it was successful or not. pre-apply means before the apply process begins. apply-success means after the apply process has finished successfully. post-apply means after the apply process has finished, whether it was successful or not.

For an example of how to use this element, see the example for <excludeAttributes>.

<icon>

This is an internal USMT element. You should not use this element.

<include>

The <include> element determines what to migrate — unless there is a more specific <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>
• Required child element: <objectSet>
• Helper Functions: You can use the following <include> filter functions with this element: CompareStringContent, IgnoreIrrelevantLinks, AnswerNo, NeverRestore, SameRegContent

Syntax:

<include filter="ScriptInvocation">

</include>

Parameter	Required?	Value
filter	No. If this is not specified, then all patterns that are inside the child <ObjectSet> element will be processed.	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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.

The following example is from MigUser.xml:

<component type="Documents" context="User">
   <displayName _locID="miguser.myvideo">My Video</displayName>
      <paths>
         <path type="File">%CSIDL_MYVIDEO%</path>
      </paths>
      <role role="Data">
         <detects>           
            <detect>
               <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYVIDEO%")</condition>
            </detect>
         </detects>
         <rules>
               <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>                  <objectSet>                     <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>                  </objectSet>               </include>
               <merge script="MigXmlHelper.DestinationPriority()">
                  <objectSet>
                     <pattern type="File">%CSIDL_MYVIDEO% [desktop.ini]</pattern>
                  </objectSet>
            </merge>
         </rules>
      </role>
    </component>

The following example is from MigApp.xml:

<include>
   <objectSet>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [01020fff]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e0324]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6600]</pattern>
      <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6700]</pattern>
         <content filter="MigSysHelper.ExtractSingleFileAnsiBin()">
            <objectSet>
               <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e0324]</pattern>
               <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6600]</pattern>
               <pattern type="Registry">HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\* [001e6700]</pattern>
            </objectSet>
         </content>
   </objectSet>
</include>

<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.

• AnswerNo
  This filter always returns FALSE.
  Syntax: AnswerNo ()

• CompareStringContent
  Syntax: CompareStringContent("StringContent","CompareType")

Parameter	Required?	Value
StringContent	Yes	The string to check against.
CompareType	Yes	A string. Use one of: Equal (case insensitive). The function will return TRUE if the string representation of the current object that is processed by the migration engine is identical to StringContent. NULLor any other value. The function will return TRUE if the string representation of the current object that is processed by the migration engine does not match StringContent.

• IgnoreIrrelevantLinks
  This filter will screen out the .lnk files that point to an object that is not valid on the destination computer. Note that the screening takes place on the destination computer, so all .lnk files will be saved to the store during ScanState (and then screened out when you run LoadState).
  Syntax: IgnoreIrrelevantLinks ()
  For example:

  <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
       <objectSet>
            <pattern type="File">%CSIDL_COMMON_VIDEO%\* [*]</pattern>
       </objectSet>
  </include>
  

• NeverRestore
  You can use this function to collect the specified object(s) from the source computer, but then not migrate the objects to the destination computer. When run with ScanState, this function evaluates to true. When run with LoadState, this function evaluates to false. You may want to use this function when you want to check an object's value on the destination computer, but do not intend to migrate the object to the destination.
  Syntax: NeverRestore()
  In the following example, HKCU\Control Panel\International [Locale] will be included in the store, but it will not be migrated to the destination computer:

  <include filter="MigSysHelper.NeverRestore()">
     <objectSet>
        <pattern type="Registry">HKCU\Control Panel\International [Locale]</pattern>
     </objectSet>
  </include>
  

  You can also see the example of how this function is used in the "Regional settings" component of Migsys.xml.

• SameRegContent
  This function compares a registry value (SourceRegVal) of the source computer to a registry value of the destination computer (DestRegVal). On the source computer, this function always returns true, so the include rule is always evaluated. Then, on the destination computer, the two values are compared and if they match, the include rule is evaluated. You may want to use this function to check the value of a key on the destination computer and then apply it only if the value matches the value on the destination computer.
  Syntax: SameRegContent(SourceRegVal, DestRegVal)
  This example compares the values of both paths, and evaluates the include rule only if the value on the source computer matches the value on the destination computer.

  <include filter="MigSysHelper.SameRegContent('HKCU\Control Panel\International [Locale]','HKCU\Control Panel\International [Locale]')">
  

  You can also see the example of how this function is used in the "Regional settings" component of Migsys.xml.

<includeAttributes>

You can use this element to determine whether certain parameters associated with an object will be migrated, along with the object itself. If there are conflicts between <includeAttributes> and <excludeAttributes>, the most specific pattern will win. If an object does not have a <includeAttributes> or <excludeAttributes>, then all its parameters will be migrated.

• Number of occurrences: unlimited
• Parent elements: <rules>
• Child elements: <objectSet>

Syntax:

<includeAttributes attributes="Security|TimeFields|Security,TimeFields">

</includeAttributes>

Parameter	Required?	Value
attributes	Yes	Specifies the attributes to be included with a migrated object. You can specify one of the following, or both separated by quotes (for example "Security","TimeFields"): Security can be one of: Owner. The owner of the object (SID). Group. The primary group for the object (SID). DACL (discretionary access control list). An access control list that is controlled by the owner of an object and that specifies the access particular users or groups can have to the object. SACL (system access control list). An ACL that controls the generation of audit messages for attempts to access a securable object. The ability to get or set an object's SACL is controlled by a privilege typically held only by system administrators. TimeFields can be one of: CreationTime. Specifies when the file or directory was created. LastAccessTime. Specifies when the file is last read from, written to, or, in the case of executable files, run. LastWrittenTime. Specifies when the file is last written to, truncated, or overwritten.

For an example of how to use this element, see the example for <excludeAttributes>.

<library>

This is an internal USMT element. You should not use this element.

<location>

This element defines the location of <object>.

• Number of occurrences: once for each <object>
• Parent elements: <object>
• Child elements: <script>

Syntax:

<location type="typeID">Content</location>

Parameter	Required?	Value
type	Yes	typeID can be Registry or File.
Content	Yes	The location of the object.

The following example is from MigApp.xml:

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
   </object>
</addObjects>

<locationModify>

You can use this element to change the location and name of an object before it is migrated to the destination computer. This element is only processed when LoadState is run on the destination computer — that is, this element is ignored by ScanState. <locationModify> will create the folder on the destination computer if it does not already exist.

Number of occurrences: Unlimited

• Parent elements: <rules>
• Required child element: <objectSet>
• Helper functions: You can use the following <locationModify> functions with this element: ExactMove, RelativeMove, Move

Syntax:

<locationModify script="ScriptInvocation">

</locationModify>

Parameter	Required?	Value
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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.

The following example is from MigApp.xml:

<locationModify script="MigXmlHelper.RelativeMove('%CSIDL_APPDATA%\Microsoft\Office','%CSIDL_APPDATA%')">
   <objectSet>
      <pattern type="File">%CSIDL_APPDATA%\Microsoft\Office\ [Access10.pip]</pattern>
   </objectSet>
</locationModify>

<locationModify> functions

The following functions change the location of objects as they are migrated. These functions are called for every object that the parent <ObjectSet> element is enumerating. <locationModify> will create the folder on the destination computer if it does not already exist.

• ExactMove
  This function moves all the objects that are matched by the parent <ObjectSet> element into the given ObjectEncodedLocation. You can use this function when you want to move a single file to a different location on the destination computer. If the destination location is a node, all the matching source objects will be written to the node (without any subdirectories). If the destination location is a leaf, the migration engine will migrate all of them to the same location. If a collision occurs, the normal collision algorithms will apply.
  Syntax: ExactMove(ObjectEncodedLocation)

Parameter	Required?	Value
ObjectEncodedLocation	Yes	The destination location for all the source objects.

For example:

• Move
  This function moves objects to a different location on the destination computer. In addition, this function creates subdirectories that were above the longest CSIDL in the source object name.
  Syntax: Move(DestinationRoot)

Parameter	Required?	Value
DestinationRoot	Yes	The location where the source objects will be moved. If needed, this function will create any subdirectories that were above the longest CSIDL in the source object name.

• RelativeMove
  You can use this element to collect and move data. Note that you can use environment variables in source and destination roots, but they may be defined differently on the source and destination computers.
  Syntax: RelativeMove(SourceRoot,DestinationRoot)

Parameter	Required?	Value
SourceRoot	Yes	The location from where the objects will be moved. Any source objects that are enumerated by the parent <ObjectSet> element that are not in this location will not be moved.
DestinationRoot	Yes	The location where the source objects will be moved to on the destination computer. If needed, this function will create any subdirectories that were above SourceRoot.

For example:

<_locDefinition>

This is an internal USMT element. You should not use this element.

<manufacturer>

This element defines the manufacturer for the component, but does not affect the migration.

• Number of occurrences: zero or one
• Parent elements: <component>
• Child elements: none

Syntax:

<manufacturer>Name</manufacturer>

Parameter	Required?	Value
Name	Yes	The name of the manufacturer for the component.

<merge>

This 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 only specifies what should be done when a collision occurs — it does not include objects. Therefore, you need to specify <include> rules along with <merge> to make your objects migrate. 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 most specific.

For an example of this element, see How does <merge> work when there are conflicts on the destination computer?.

• Number of occurrences: Unlimited
• Parent elements: <rules>
• Required child element: <objectSet>
• Helper functions: You can use the following <merge> functions with this element: SourcePriority, DestinationPriority, FindFilePlaceByPattern, LeafPattern, NewestVersion, HigherValue(), LowerValue()

Syntax:

<merge script="ScriptInvocation">

</merge>

Parameter	Required?	Value
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"). The script will be called for each object that is enumerated by the object set(s) in the include rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated.

The following example is from MigUser.xml:

<rules>
   <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
      <objectSet>
         <pattern type="File">%CSIDL_MYVIDEO%\* [*]</pattern>
      </objectSet>
   </include>
   <merge script="MigXmlHelper.DestinationPriority()">
      <objectSet>
         <pattern type="File">%CSIDL_MYVIDEO% [desktop.ini]</pattern>
      </objectSet>
   </merge>
</rules>

<merge> functions

These functions control how collisions are resolved.

• DestinationPriority
  Specifies to keep the object that is on the destination computer and not migrate the object from the source computer.
  For example:

  <merge script="MigXmlHelper.DestinationPriority()">
       <objectSet>
            <pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\ [MyPictures]</pattern>
            <pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\Settings\ [PicturesPath]</pattern>
            <pattern type="Registry">HKCU\Software\Microsoft\Office\9.0\PhotoDraw\Settings\ [AdditionalPlugInPath]</pattern>
       </objectSet>
  </merge> 
  

• FindFilePlaceByPattern
  This function saves files with an incrementing counter when a collision occurs. It is a string that contains one of each constructs: <F>, <E>, <N> in any order.
  Syntax: FindFilePlaceByPattern(FilePattern)

Parameter	Required?	Value
FilePattern	Yes	<F> will be replaced by the original file name. <N> will be replaced by an incrementing counter until there is no collision with the objects on the destination computer. <E> will be replaced by the original file name extension. For example <F> (<N>).<E> will change the source file "MyDocument.DOC" into "MyDocument (1).DOC" on the destination computer.

• NewestVersion
  This function will resolve conflicts on the destination computer based on the version of the file.
  Syntax: NewestVersion(VersionTag)

Parameter	Required?	Value
VersionTag	Yes	The version field that will be checked. This can be "FileVersion" or "ProductVersion". The file with the highest VersionTag version wins. For example, if Myfile.txt contains FileVersion 1 and the same file on destination computer contains FileVersion 2, the file on destination will win and will remain.

• HigherValue()
  You can use this function for merging registry values. The registry values will be evaluated as numeric values and the one with the higher value will win.

• LowerValue()
  You can use this function for merging registry values. The registry values will be evaluated as numeric values and the one with the lower value will win.

• SourcePriority
  Specifies to migrate the object from the source computer, and delete the object that is on the destination computer.
  For example:

  <merge script="MigXmlHelper.SourcePriority()">
   <objectSet>
     <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
     <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\11.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
     <pattern type="Registry">%HklmWowSoftware%\Microsoft\Office\10.0\Common\Migration\Publisher [UpgradeVersion]</pattern>
   </objectSet>
  </merge>
  

<migration>

This 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 different. 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".

• Number of occurrences: one
• Parent elements: none
• Required child elements: <component>
• Optional child elements: <library>, <namedElements>

Syntax:

<migration urlid="*UrlID/*Name">

</migration>

Parameter	Required?	Value
urlid	Yes	UrlID is a string identifier that uniquely identifies this .xml file. This parameter must be a no-colon-name as defined by XML Namespaces specification. Each migration .xml file must have a unique urlid. If two migration .xml files have the same urlid, the second .xml file that is specified on the command line will not be processed. For more information about XML Namespaces, see Understanding XML Namespaces.
Name	No	Although not required, it is good practice to use the name of the .xml file.

The following example is from MigApp.xml:

<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/migapp">
</migration>

<namedElements>

You can use this 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 MigApp.xml.

Syntax:

<namedElements>

</namedElements>

• Number of occurrences: Unlimited
• Parent elements: <migration>
• Child elements: <environment>, <rules>, <conditions>, <detection>, <detects>, <detect>

For an example of this element, see MigApp.xml.

<object>

The <object> element represents a file or registry key.

• Number of occurrences: Unlimited
• Parent elements: <addObjects>
• Required child elements: <location>, <attributes>
• Optional child elements:<bytes>

Syntax:

<object>

</object>

The following example is from MigApp.xml:

<addObjects>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [UpgradeVersion]</location>
      <attributes>DWORD</attributes>
      <bytes>0B000000</bytes>
   </object>
   <object>
      <location type="Registry">%HklmWowSoftware%\Microsoft\Office\12.0\Common\Migration\Office [Lang]</location>
      <attributes>DWORD</attributes>
      <bytes>00000000</bytes>
      </object>
</addObjects>

<objectSet>

This 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>, <content>, <include>, <exclude>, <merge>, <contentModify>, <locationModify>, <destinationCleanup>, <includeAttributes>, <excludeAttributes>, <unconditionalExclude>, <detect>
• Required child elements: either <script> or <pattern>
• Optional child elements: <content>, conditions, <condition>

Syntax:

<objectSet>

</objectSet>

The following example is from MigUser.xml:

<component type="Documents" context="User">
   <displayName _locID="miguser.mymusic">My Music</displayName>
      <paths>
         <path type="File">%CSIDL_MYMUSIC%</path>
      </paths>
   <role role="Data">
      <detects>           
      <detect>
         <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYMUSIC%")</condition>
      </detect>
   </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>            <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>            <pattern type="File">%CSIDL_MYMUSIC%\ [desktop.ini]</pattern>         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<path>

This is an internal USMT element. You should not use this element.

<paths>

This is an internal USMT element. You should 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:

<pattern type="File">C:\Folder\* [Sample.doc]</pattern>
<script>MigXmlHelper.GenerateDrivePatterns("\Folder\* [Sample.doc]","Fixed"</script>

• Number of occurrences: Unlimited
• Parent elements: <objectSet>
• Child elements: none but Path [object] must be valid.

Syntax:

<pattern type="typeID">Path [object]</pattern>

Parameter	Required?	Value
type	Yes	typeID can be Registry, File, or Ini. If typeId is Ini, then you cannot have a space between Path and object. For example, the following is correct when type="Ini": <pattern type="Ini">%WinAmp5InstPath%\Winamp.ini|WinAmp[keeponscreen]</pattern>
Path [object]	Yes	A valid registry or file path pattern, followed by at least one space, followed by brackets [] that contain the object to be migrated. Path can contain the asterisk (*) wildcard character or can be an environment variable. You cannot use the question mark as a wildcard character.You can use HKCU and HKLM to refer to HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE respectively. Object can contain the asterisk (*) wildcard character. However, you cannot use the question mark as a wildcard character. For example: C:\Folder\ [*] enumerates all files in C:\Path but no subfolders of C:\Folder. C:\Folder\* [*] enumerates all files and subfolders of C:\Folder. C:\Folder\ [*.mp3] enumerates all .mp3 files in C:\Folder. C:\Folder\ [Sample.doc] enumerates only the Sample.doc located in C:\Folder. Note If you are migrating a file that has a bracket character ([ or ]) in the file name, you will need to insert the "^" character directly before the bracket in order for it to be valid. For example, if there is a file named "file].txt", you will need to specify <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> instead of <pattern type=”File”>c:\documents\mydocs [file].txt]</pattern>.

For example:

• To migrate a single registry key:

  <pattern type="Registry">HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Cache [Persistent]</pattern>
  

• To migrate the EngineeringDrafts folder and any subfolders from the C: drive:

  <pattern type="File">C:\EngineeringDrafts\* [*]</pattern>
  

• To migrate the only the EngineeringDrafts folder (excluding any subfolders) from the C: drive:

  <pattern type="File"> C:\EngineeringDrafts\ [*]</pattern>
  

• To migrate Sample.doc from C:\EngineeringDrafts:

  <pattern type="File"> C:\EngineeringDrafts\ [Sample.doc]</pattern>
  

• To migrate Sample.doc from where ever it exists on the C: drive use pattern in the following way. If multiple files exist with the same name on the C: drive, then all of these files will be migrated.

  <pattern type="File"> C:\* [Sample.doc] </pattern>
  

• For more examples of how to use this element, see How To Exclude Files and Settings, How To Reroute Files and Settings, How To Include Files and Settings, and XML Examples.

<processing>

You can use this element to execute 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>
• Required child element: <script>

Syntax:

<processing when="pre-scan|scan-success|post-scan|pre-apply|apply-success|post-apply">

</processing>

Parameter	Required?	Value
when	Yes	Indicates when the script should be run. This value can be one of the following: pre-scan means before the scanning process begins. scan-success means after the scanning process has finished successfully. post-scan means after the scanning process has finished, whether it was successful or not. pre-apply means before the apply process begins. apply-success means after the apply process has finished successfully. post-apply means after the apply process has finished, whether it was successful or not.

The following example is from MigSys.xml:

<rules>
   <processing when="pre-apply">
      <script>MigXmlHelper.KillExplorer()</script>
   </processing>
   <processing when="post-apply">
      <script>MigXmlHelper.RestartExplorer()</script>
   </processing>
</rules>

<plugin>

This is an internal USMT element. You should not use this element.

<role>

This 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>, <role>
• Required child elements: <rules>
• Optional child elements: <environment>, <detection>, <component>, <role>, <detects>, <plugin>,

Syntax:

<role role="Container|Binaries|Settings|Data">

</role>

Parameter	Required?	Value
role	Yes	Defines the role for the component. Role can be one of: Container Binaries Settings Data You can either: 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. Specify one “Container” <role> element within a <component>. In this case, you cannot specify any child <rules> elements (only other <component> elements). And each child <component> elements needs to have the same type as that of parent <component> element. For example: <component context="UserAndSystem" type="Application"> <displayName _locID="migapp.msoffice2003">Microsoft Office 2003</displayName> <environment name="GlobalEnv" /> <role role="Container"> <detection name="AnyOffice2003Version" /> <detection name="FrontPage2003" /> <!-- Office 2003 Common Settings   --> <component context="UserAndSystem" type="Application">

The following example is from MigUser.xml. For more examples, see MigApp.xml:

<component type="System" context="User">
   <displayName _locID="miguser.startmenu">Start Menu</displayName>
   <paths>
      <path type="File">%CSIDL_STARTMENU%</path>
   </paths>
   <role role="Settings">
      <detects>           
         <detect>
            <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_STARTMENU%")</condition>
         </detect>
      </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
            <pattern type="File">%CSIDL_STARTMENU%\* [*]</pattern>
         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
            <pattern type="File">%CSIDL_STARTMENU% [desktop.ini]</pattern>
            <pattern type="File">%CSIDL_STARTMENU%\* [*]</pattern>
         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<rules>

This element is required in a custom .xml file. This element contains rules that will be executed during the migration if the parent <component> element is selected, except if the child <conditions> element (if present) evaluate to FALSE. For each <rules> element there can be multiple child <rules> elements.

• Number of occurrences: unlimited
• Parent elements: <role>, <rules>, <namedElements>
• Required child elements: <include>
• Optional child elements: <rules>, <exclude>, <unconditionalExclude>, <merge>, <contentModify>, <locationModify>, <destinationCleanup>, <addObjects>, <externalProcess>, <processing>, <includeAttributes>, <excludeAttributes>, conditions, <detects>

Syntax:

<rules name="ID" context="User|System|UserAndSystem">

</rules>

Parameter	Required?	Value
name	Yes, when <rules> is a child to <namedElements> No, when <rules> is a child to any other element	When ID is specified, any child elements are not processed. Instead, any other <rules> elements with the same name that are declared within <namedElements> are processed.
context	No (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. 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 has a context of User. If <rules> had a context of System, it would act as though <rules> was not there. User. Evaluates the variables for each user. System. Evaluates the variables only once for the system. UserAndSystem. Evaluates the variables for the entire operating system and each user.

The following example is from MigUser.xml:

<component type="Documents" context="User">
   <displayName _locID="miguser.mymusic">My Music</displayName>
      <paths>
         <path type="File">%CSIDL_MYMUSIC%</path>
      </paths>
   <role role="Data">
      <detects>           
      <detect>
         <condition>MigXmlHelper.DoesObjectExist("File","%CSIDL_MYMUSIC%")</condition>
      </detect>
   </detects>           
   <rules>
      <include filter='MigXmlHelper.IgnoreIrrelevantLinks()'>
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\* [*]</pattern>
         </objectSet>
      </include>
      <merge script="MigXmlHelper.DestinationPriority()">
         <objectSet>
            <pattern type="File">%CSIDL_MYMUSIC%\ [desktop.ini]</pattern>
         </objectSet>
      </merge>
   </rules>
   </role>
</component>

<script>

The return value that is required by <script> depends on the parent element.

Number of occurrences: Once for <variable>, unlimited for <objectSet> and <processing>

Parent elements: <objectSet>, <variable>, <processing>

Child elements: none

Syntax and helper functions:

• General Syntax: <script>Content</script>
• You can use GetStringContent when <script> is within <variable>.
  Syntax: <script>MigXmlHelper.GetStringContent("ObjectType","EncodedLocationPattern", "ExpandContent")</script>
  Example: <script>MigXMLHelper.GetStringContent("Registry","HKLM\Software\MyApp\Installer [EXEPATH]")</script>
• You can use GenerateUserPatterns when <script> is within <objectSet>.
  Syntax: <script>MigXmlHelper.GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")</script>
  Example: <script>MigXmlHelper.GenerateUserPatterns ("File","%userprofile%\* [*.doc]", "FALSE")</script>
• You can use GenerateDrivePatterns when <script> is within <objectSet>.
  Syntax: <script>MigXmlHelper.GenerateDrivePatterns("PatternSegment","DriveType")</script>
  Example: <script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script>
• You can use the Simple executing scripts with <script> elements that are within <processing> elements: AskForLogoff, ConvertToShortFileName, KillExplorer, RemoveEmptyDirectories, RestartExplorer, RegisterFonts, StartService, StopService, SyncSCM.
  Syntax: <script>MigXmlHelper.ExecutingScript</script>
  Example: <script>MigXmlHelper.KillExplorer()</script>

Parameter	Required?	Value
Content	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"). The script will be called for each object that is enumerated by the object set(s) in the <include> rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be migrated. If it is FALSE, it will not be migrated. The return value that is required by <script> depends on the parent element. When used within <variable>, the return value needs to be a string. When used within <objectSet>, the return value needs to be a two-dimensional array of strings. When used within <location>, the return value needs to be a valid location which aligns with the type attribute of <location>. For example, if <location type="File">, the child script element (if specified) needs to be a valid file location. Note If you are migrating a file that has a bracket character ([ or ]) in the file name, you need to insert the "^" character directly before the bracket in order for it to be valid. For example, if there is a file named "file].txt", you need to specify <pattern type="File">c:\documents\mydocs [file^].txt]</pattern> instead of <pattern type=”File”>c:\documents\mydocs [file].txt]</pattern>.

Examples:

To migrate Sample.doc from any drive on the computer, use <script> as follows. If multiple files exist with the same name, all such files will get migrated.

<script>MigXmlHelper.GenerateDrivePatterns("* [sample.doc]", "Fixed")</script> 

For more examples of how to use this element, see How To Exclude Files and Settings, How To Reroute Files and Settings, How To Include Files and Settings, andXML Examples.

<script> functions

You can use the following functions with the <script> element

• String and pattern generating functions
• Simple executing scripts

String and pattern generating functions

These functions return either a string or a pattern.

• GetStringContent
  You can use GetStringContent with <script> elements that are within <variable> elements. If possible, this function returns the string representation of the given object. Otherwise, it returns NULL. For file objects this function always returns NULL.
  Syntax: GetStringContent("ObjectType","EncodedLocationPattern", "ExpandContent")

Parameter	Required?	Value
ObjectType	Yes	The type of object. Can be Registry or Ini (for an .ini file).
EncodedLocationPattern	Yes	If type of object is Registry, EncodedLocationPattern needs to be a valid registry path. For example, HKLM\SOFTWARE\MyKey[]. If the type of object is Ini, then EncodedLocationPattern needs to be in the following format: IniFilePath|SectionName[SettingName]
ExpandContent	No (default=TRUE)	Can be TRUE or FALSE. If FALSE, then the given location will not be expanded before it is returned.

For example:

• GenerateDrivePatterns
  This function will iterate all the available drives and select the ones that match the requested drive type. It will then concatenate the selected drive(s) with the end part of PatternSegment to form a full encoded file pattern. For example, if PatternSegment is Path [file.txt] and DriveType is Fixed, then the function will generate C:\Path [file.txt] (and other patterns if there are fixed drives other than C:). You cannot specify environmental variables with this function. You can use GenerateDrivePatterns with <script> elements that are within <objectSet> that are within <include>/<exclude>.
  Syntax: GenerateDrivePatterns("PatternSegment","DriveType")

Parameter	Required?	Value
PatternSegment	Yes	The suffix of an encoded pattern. It will be concatenated with a drive specification (like “c:\”) to form a complete encoded file pattern. For example, "* [*.doc]". PatternSegment cannot be an environmental variable.
DriveType	Yes	The drive type for which the patterns are to be generated. You can specify one of: Fixed CDROM Removable Remote

See the last component in MigUser.xml for an example of this element.

• GenerateUserPatterns
  The function will iterate through all users that are being migrated (excluding the currently processed user if <ProcessCurrentUser> is FALSE), and will expand the specified pattern in the context of each user. For example, if users A, B and C have profiles in C:\Documents and Settings), by calling GenerateUserPattens('File','%userprofile% [*.doc]','TRUE'), the helper function will generate the following three patterns:

  • “C:\Documents and Settings\A\* [*.doc]”
  • “C:\Documents and Settings\B\* [*.doc]”
  • “C:\Documents and Settings\C\* [*.doc]”

  Syntax: GenerateUserPatterns("ObjectType","EncodedLocationPattern","ProcessCurrentUser")

Parameter	Required?	Value
ObjectType	Yes	Defines the object type. Can be File or Registry.
EncodedLocationPattern	Yes	The location pattern. Environment variables are allowed.
ProcessCurrentUser	Yes	Can be TRUE or FALSE. Indicates if the patterns should be generated for the current user.

**Example:** If GenerateUserPattens('File','%userprofile% \[\*.doc\]','TRUE') is called while USMT is processing user A, then this function will only generate patters for users B and C. You can use this helper function to build complex rules. For example, to migrate all .doc files from the 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 \

Simple executing scripts

The following scripts have no return value. You can use the following errors with <script> elements that are within <processing> elements

• AskForLogoff(). Prompts the user to log off at the end of the migration. For example:

       <processing when="apply-success">
            <script>MigXmlHelper.AskForLogoff()</script>
       </processing>
  

• ConvertToShortFileName(RegistryEncodedLocation). If RegistryEncodedLocation is the full path of an existing file, this function will convert the file to its short file name and then it will update the registry value.

• KillExplorer(). Stops Explorer.exe for the current user context. This allows access to certain keys and files that are kept open when Explorer.exe is running. For example:

       <processing when="pre-apply">
            <script>MigXmlHelper.KillExplorer()</script>
       </processing>
  

• RegisterFonts(FileEncodedLocation). Registers the given font or all the fonts in the given directory. For example:

  <processing when="apply-success">
  <script>MigXmlHelper.RegisterFonts("%CSIDL_COMMON_FONTS%")</script>
  </processing>
  

• **RemoveEmptyDirectories (DirectoryEncodedPattern).**Deletes any empty directories that match DirectoryEncodedPattern on the destination computer.

• RestartExplorer(). Restarts Explorer.exe at the end of the migration. For example:

       <processing when="post-apply">
            <script>MigXmlHelper.RestartExplorer()</script>
       </processing>
  

• StartService (ServiceName, OptionalParam1, OptionalParam2,…). Starts the service identified by ServiceName. ServiceName is the subkey in HKLM\System\CurrentControlSet\Services that holds the data for the given service. The optional parameters (if any) will be passed to the StartService API. For more information, see StartService (https://go.microsoft.com/fwlink/?LinkId=74505).

• StopService (ServiceName). Stops the service that is identified by ServiceName. ServiceName is the subkey in HKLM\System\CurrentControlSet\Services that holds the data for the given service.

• 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.

<text>

You can use this 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> element.
• Parent elements: <variable>
• Child elements: None.

Syntax:

<text>Content</text>

Parameter	Value
Content	This will be interpreted as normal text.

For example:

<variable name="QuickTime5or6DataSys">
  <text>%CSIDL_COMMON_APPDATA%\QuickTime</text> 
</variable>

<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 Config.xml. 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.

You should use this element if you want to exclude all .mp3 files from the computer. Or, if you are backing up C:\UserData using another method, you can exclude the entire folder from the migration. You should use this element with caution because if an application needs a file that you exclude, the application may not function properly on the destination computer.

• Number of occurrences: Unlimited.
• Parent elements: <rules>
• Child elements: <objectSet>
• Helper functions: You can use the following <include> and <exclude> filter functions with this element: AnswerNo, CompareStringContent, IgnoreIrrelevantLinks, NeverRestore, SameRegContent.

Syntax:

<unconditionalExclude filter ="ScriptInvocation">

</unconditionalExclude>

Parameter	Required?	Value
filter	No (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"). The script will be called for each object that is enumerated by the object set(s) in the unconditionalExclude rule. The filter script will return a Boolean value. If the return value is TRUE, the object will be excluded from the migration. If it is FALSE, then unconditionalExclude will not apply to the object and therefore, the object will be migrated based on the other <include>, <exclude>, and <unconditionalExclude> rules. For example, if you would like to exclude all files that are older than a certain date, write a function in MigSys.xml that takes the file name and returns TRUE if the file is older than that date. Then use that function as a filter function with <unconditionalExclude>.

The following .xml file excludes all .mp3 files from migration. For additional examples of how to use this element, see the How To Exclude Files and Settings.

<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/excludefiles">
  <component context="System" type="Documents">
        <displayName>Test</displayName>
        <role role="Data">
            <rules>
             <unconditionalExclude>
                        <objectSet>
    <script>MigXmlHelper.GenerateDrivePatterns ("* [*.mp3]", "Fixed")</script>
                        </objectSet> 
             </unconditionalExclude>
            </rules>
        </role>
    </component>
</migration>

<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:

1. If <variable> contains a <text> element, then the value of the variable will be the value of the <text> element.
2. If <variable> contains a <script> element and the invocation of the script produces a non-null string, then the value of the variable will be the result of the script invocation.
3. If <variable> contains an <objectSet> element and the evaluation of the <objectSet> element produces at least one object pattern, then the value of the first object to match the resulting object pattern will be the value of the variable.

• Number of occurrences: Unlimited
• Parent elements: <environment>
• Required child elements: either <text>, or <script>, or <objectSet>

Syntax:

<variable name="ID" remap=TRUE|FALSE>

</variable>

Parameter	Required?	Value
name	Yes	ID is a string value that is the name used to reference the environment variable. We recommend that ID start with the component’s name in order to avoid namespace collisions. For example, if your component’s name is MyComponent, and you want a variable that was your component’s install path, you could specify MyComponent.InstallPath.
remap	No, default is FALSE	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 will automatically be moved to where the environment variable points on the destination computer.

The following example is from MigApp.xml:

<environment>
   <variable name="HklmWowSoftware">
      <text>HKLM\Software</text>
   </variable>
   <variable name="WinZip8or9or10Exe">
      <script>MigXmlHelper.GetStringContent("Registry","%HklmWowSoftware%\Microsoft\Windows\CurrentVersion\App Paths\winzip32.exe []")</script>
   </variable>
</environment>

<version>

This element defines the version for the component, but does not affect the migration.

• Number of occurrences: zero or one
• Parent elements: <component>
• Child elements: none

Syntax:

<version>Content</version>

Parameter	Required?	Value
Content	Yes	The version of the component, which can contain patterns.

For example:

<version>4.*</version>

<windowsObjects>

This element is for USMT internal use only. You should not use this element

Appendix

Specifying locations

• Specifying encoded locations. The encoded location used in all 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 way, there is a clear distinction between nodes and leaves.
  For example, you should specify the file C:\Windows\Notepad.exe like this: c:\Windows[Notepad.exe]. Similarly, you should specify the directory C:\Windows\System32 like this: c:\Windows\System32 (notice the absence of the [] construct).
  Representing the registry is very similar. The default value of a registry key is represented as an empty [] construct. For example, the default value for the HKLM\SOFTWARE\MyKey registry key will be HKLM\SOFTWARE\MyKey[].
• Specifying location patterns. You specify a location pattern in a similar way to how you specify an actual location. The exception is that both the node and leaf part accept patterns. However, a pattern from the node does not extend to the leaf.
  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. In order to match the files as well, you need to specify c:\Windows\*[*].

Internal USMT functions

The following functions are for internal USMT use only. You should not use them in an .xml file.

• AntiAlias
• ConvertScreenSaver
• ConvertShowIEOnDesktop
• ConvertToOfficeLangID
• MigrateActiveDesktop
• MigrateAppearanceUPM
• MigrateDisplayCS
• MigrateDisplaySS
• MigrateIEAutoSearch
• MigrateMouseUPM
• MigrateSoundSysTray
• MigrateTaskBarSS
• SetPstPathInMapiStruc

Valid version tags

The following are the valid version tags that you can use with various helper functions:

• “CompanyName”
• “FileDescription”
• “FileVersion”
• “InternalName”
• “LegalCopyright”
• “OriginalFilename”
• “ProductName”
• “ProductVersion”

The following are the version tags that contain values that can be compared:

• “FileVersion”
• “ProductVersion”