Something I’ve seen many forum posts of is people complaining “Exclude” and “UnconditionalExclude” rules don’t work as expected in in USMT’s scanstate.exe command. The answer is simply found by spending a couple of days reverse engineering scanstate.exe into 80×86 assembly, manually converting that to C code, then re-writing your own version from scratch to exclude the files you need. Or if that seems like a waste of time you might find the answer in the USMT help file under “Conflicts and Precedence”:
- If there are conflicting rules within a component, the most specific rule is applied. However, the <unconditionalExclude> rule is an exception because it takes precedence over all others. Directory names take precedence over file extensions.
- Only rules inside the same component can affect each other, depending on specificity. Rules that are in different components do not affect each other, except for the <unconditionalExclude> rule.
- If the rules are equally specific, <exclude> takes precedence over <include>. For example, if you use the <exclude> rule to exclude a file and use the <include> rule to include the same file, the file will be excluded.
- The ordering of components does not matter.It does not matter which components are listed in which .xml file, because each component is processed independently of the other components across all of the .xml files.
- The ordering of the <include> and <exclude> rules within a component does not matter.
- You can use the <unconditionalExclude> element to globally exclude data. This element excludes objects, regardless of any other <include> rules that are in the .xml files. For example, you can use the <unconditionalExclude> element to exclude all MP3 files on the computer or to exclude all files from C:\UserData.
To explain in other words:
- You can use as many Excludes or Unconditional Excludes as you like, but if you have another <rules> section in another <component> section or additional rules in the same component under a different context i.e. User & System which <include>s the file, it will still get included. This could be in any of the .xml files you pass to scan state. So if your CustomMig.xml file that you made EXCLUDED Downloads directory, but MigUser.xml included it, you would still get the downloads folder migrated.
- You can think of it as each time a registry or file is scanned on the system each <rules> section is checked – if any <rules> section gives it a positive match it will be included.
So in this sample custom XML file some important points:
- In the “User Data Rule” rule we “include” the profile and “exclude” user specific settings. Remember “exclude” only applies to what is “included” within the same rule
- In the “System Data Rule” we “exclude” the profile folder. If we had not done this, the excludes in “User Data” would have been ignored (assuming profile on C: drive) due to System Data rules’ “C:\* [*] inclusion
<?xml version=“1.0“ encoding=“utf-8“?>
<component type=“Documents“ context=“UserAndSystem“ defaultSupported=“Yes“>
<rules name=“User Data“ context=“User“>
<pattern type=“File“>%CSIDL_PROFILE%\* [*]</pattern>
<pattern type=“File“>%TEMP%\* [*]</pattern>
<pattern type=“File“>%CSIDL_INTERNET_CACHE%\* [*]</pattern>
<rules name=“System Data“ context=“System“>
<pattern type=“File“>C:\* [*]</pattern>
<pattern type=“File“>%PROFILESFOLDER%\* [*]</pattern>
To summarize – before using USMT 4.0 strongly recommend reading through the documentation