Partager via

Don’t mess about with USMT’s included manifests!

  • Article

Ned here. Today I talk about the importance of the included USMT component manifests and how things can get gross when they are not available to Scanstate and Loadstate.

Here’s you

  1. You are using USMT 4.0 to migrate from XP to Windows 7.
  2. You run scanstate on XP and it appears to work fine (no unexpected errors to console or logs).
  3. You run loadstate on Win7 and it appears to work fine (no unexpected errors to console or logs).
  4. A zillion system settings are not migrated, so the user does not get their mapped printers and drives, shell settings, RAS settings, favorites, regional settings, etc; all the stuff here:
  • Accessibility settings
  • Address book
  • Command-prompt settings
  • Desktop wallpaper
  • EFS files
  • Favorites
  • Folder options
  • Fonts
  • Group membership.
  • Windows Internet Explorer® settings
  • Microsoft® Open Database Connectivity (ODBC) settings
  • Mouse and keyboard settings
  • Network drive mapping
  • Network printer mapping
  • Offline files
  • Phone and modem options
  • RAS connection and phone book (.pbk) files
  • Regional settings
  • Remote Access
  • Taskbar settings
  • Windows Mail.
  • Microsoft Outlook Express Mail (.dbx) files are migrated from Windows XP.
  • Windows Media Player
  • Windows Rights Management

5.   Everyone runs around screaming.

What’s Up?

The problem is that USMT cannot locate the folder containing the migration manifest files. There are two of these included with USMT 4:

DlManifests
ReplacementManifests

clip_image002

Here’s what will happen if they are not present:

  • If running scanstate and loadstate with a full migration on XP and going to Vista/Windows 7 and you were missing the DLManifests folder, none of these settings I described earlier will migrate. Your log will show:

[0x000000] Downlevel Manifests folder is not present. System component settings will not be gathered.

  • If running scanstate /genconfig without the DlManifests or ReplacementManifests folders, your config.xml file will not have any WindowsComponents settings in it at all and will only contain the ErrorControl entries, like so:

<?xml version="1.0" encoding="UTF-8"?>

<Configuration>

  <Applications/>

  <Documents/>

  <WindowsComponents/>

  <Policies>

    <ErrorControl>

      <!--   Example:

 

          <fileError>

            <nonFatal errorCode="33">* [*]</nonFatal>

            <fatal errorCode="any">C:\Users\* [*]</fatal>

          </fileError>

          <registryError>

            <nonFatal errorCode="5">* [*]</nonFatal>

          </registryError>

      -->

    </ErrorControl>

    <HardLinkStoreControl>

      <!--   Example:

 

          <fileLocked>

            <createHardLink>c:\Users\* [*]</createHardLink>

            <errorHardLink>C:\* [*]</errorHardLink>

          </fileLocked>

      -->

    </HardLinkStoreControl>

  </Policies>

  <ProfileControl>

    <!--   Example (local group mapping):

 

          <localGroups>

            <mappings>

              <changeGroup from="Administrators" to="Users" appliesTo="MigratedUsers">

                <include>

                  <pattern>DomainName1\Username</pattern>

                </include>

                <exclude>

                  <pattern>DomainName2\Username</pattern>

                </exclude>

              </changeGroup>

            </mappings>

          </localGroups>

         

      -->

    <!--   Example (domain and user mapping):

 

          <domains>

            <domain from="Domain1" to="Domain2"/>

          </domains>

         

          <users>

            <user from="Domain1\User1" to="Domain2\User2"/>

          </users>

         

      -->

  </ProfileControl>

</Configuration>

  • If running scanstate and loadstate from Vista/7 to Vista/7, you may see various settings not work or other niggles not behaving as expected. Your log will show:

[0x000000] The ReplacementManifests folder used to service system component manifests is not present. OS settings migration will be done with system component manifests installed onto the system.

This is because these manifests are included by the component owners to handle special scenarios within migration, so you are falling back to using the manifests included in the OS for upgrades (which uses some of the same underlying USMT engine code). Your mileage may vary. A lot.

Nevermind that, what do I do?

The folders are often missing due to administrative misadventure – i.e. someone forgot to copy them and only copied the base files included in the USMT main folder. If you make sure they are present in the USMT working folder, you will be good to go. They were included for good reason reason and USMT is only tested with those files being included, so definitely do not intentionally discard them.

There are also a few reasons why they might not accidentally be found, based on how USMT was shelled. Both SCCM and MDT have bugs on this that are described and worked around:

  • MDT bug with workaround -
  • SCCM bug with workaround

I’m not sure if those folks have plans to fix these permanently or what, the KB’s don’t indicate.

Note: Micheal Niehaus let me know offline that MDT is fixed in MDT 2010 Update 1 and the KB just needs to be update to reflect this. Thanks Michael. :-)

That’s all for now.

- Ned “precious fontses!!!” Pyle