Get Shiny with USMT: Turning the Aero Theme on During XP to Windows 7 Migration

Get Shiny with USMT: Turning the Aero Theme on During XP to Windows 7 Migration

  • Comments 10
  • Likes

Ned here again. Today’s post is quick and dirty… and glossy! One thing users notice immediately about Windows 7 is the default Aero theme. Even if you‘re not a fan of eye candy, your users are – and in the end they run the show in most environments. Especially when their business card says “VP” on it.

Consider the following scenario:

1. Windows XP users have the default display theme of "Windows XP".
2. You use USMT 4.0 to migrate from Windows XP to Windows 7.
3. After migrating to Windows 7 with USMT – using online or offline migrations -- any migrated users that logon have the old and busted "Windows Classic" theme:


… instead of the new hotness:




Why this happens

By default, USMT tries to copy a user’s theme to the target computer. But XP did not have the Aero theme. Worse, XP’s default theme was “Windows XP” which does not exist in Windows 7. The closest possible match is “Windows Classic” so that’s what USMT uses.

Whether or not this default behavior is desirable is open for polite debate in our comments area. :-)

How to get Aero by blocking theme migration

To override the default theme migration, use the following steps:

1. On your reference XP source computer with USMT 4.0 installed, run:

SCANSTATE.EXE /genconfig:config.xml /o

This will create a new customization config.xml file in the scanstate working directory.

2. Open the config.xml in notepad.exe.
3. Locate the following line in the config.xml file (this is wrapped for readability):

<component displayname="Microsoft-Windows-themeui-DL" migrate="yes" ID=""/>

4. Change the "yes" to "no", so that the line now is:

<component displayname="Microsoft-Windows-themeui-DL" migrate="no" ID=""/>

5. Save the config.xml file.
6. Run your usual scanstate and loadstate syntax, making sure to also include your new config file on the scanstate:


Disabling this component prevents the following registry keys from migrating (under the covers):


And that’s it – now you have Aero.


Until next time.

- Ned “London Dungeon” Pyle

  • Hey Ned,

    Love the Zune screen shot. Long live ridiculous punk hair cuts :)

    Can you remove those Themes\LastTheme registry keys from user machines using the GP PowerShell cmdlet?  (Remove-GPRegistryKey...)

    - liliaG

     group policy PM

  • Shouldn't you be telling me, you invented that!


    I kid, I kid. There are nice theme controls for first user logon in GP on Win7 under:

    User Configuration\Policies\Administrative Templates\Control Panel\Personalization

    "Load a specific theme"

    "Specifies which theme file is applied to the computer the first time a user logs on.

    If you enable this setting, the theme that you specify will be applied when a new user logs on for the first time.  This policy does not prevent the user from changing the theme or any of the theme elements such as the desktop background, window color, sounds, or screen saver after the first logon."

    Seems like GP or Psh GP could handle that quite nicely. A nice get out of jail free card here...

    Thanks Lilia.

    - Ned

  • I must be being particularly slow today :(

    When I use the /genconfig command on an XP machine I get a pretty much empty XML, no components, just the error sections.  When I run it on W7 I get a nice set of components, but not the one you mention as being the culprit.

    Any suggestions?



  • I had never seen that before, but I took a guess in my repro and got it right:

    You do not have the DLManifests subfolder in the folder where you are running scanstate.exe

    When you copy the scanstate files onto the XL computer, make sure you copy *all* files from where USMT was installed from WAIK. If you leave behind the mnifests, XP will have no idea how to migrate system settings.

    Funny, this is the second symptom I've seen this week caused by people not copying that folder. Looks like I need to write something up.


  • On the money, THANKS!

    I have a related question if I may...

    Using MDT's REFRESH capability to rebuild machines and it appears (although I haven't seen it explicitly called out) that when migrating from XP you need to create the config file on an XP machine, and when migrating from W7 you would generate it on a W7 system.  Can the two files be merged and if not, how would you use the correct on in the correct scenario?



  • Cool, at least I got *something* right today. :)

    There's no way to merge the files as when they are generated they will use completely differnet manifests depending on the OS.

    For example, here's a snippet from a Win XP:

    <component displayname="Printers and Faxes" migrate="yes" ID="hardware\printers_and_faxes">

           <component displayname="Microsoft-Windows-Printing-Spooler-Networkclient-DL" migrate="yes" ID=">

           <component displayname="Microsoft-Windows-Printing-Spooler-Core-DL" migrate="yes" ID=">


    And here's a snippet from Win7:

    <component displayname="Printers and Faxes" migrate="yes" ID="hardware\printers_and_faxes">

           <component displayname="Microsoft-Windows-Printing-Spooler-Core" migrate="yes" ID=">

           <component displayname="Microsoft-Windows-Printing-Spooler-Networkclient" migrate="yes" ID=">

           <component displayname="Microsoft-Windows-Printing-Spooler-Core-Localspl" migrate="yes" ID=">


    Notice how they use different manifest names and schemas (the XP ones have DL for DownLevel and the Win7 one has extra goo altogether).

    I don't know much about MDT, that's actually supported by a whole other group here. I resume it has some ways to create 'packages' or 'jobs' or whatever based on OS? You would just give each of your 'things' their own copy of the config.XML, renamed to like confg7 an configxp, and change the paths used by MDT to reference the right one.

    Scott and Jeff probably know, you can ping them here:

    They support MDT and are a bunch of punks that need a firm hand.

  • I'm confused about why you would use config.xml over the included miguser migdocs and migapps.xml files? Can't I use those files and add a custom file for my additions?

    For example can't I just use something like this:

    (I haven't quite worked out the syntax yet for selecting a key and ingoring a subkey )



    <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\LastTheme\*[*]</pattern>

    <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes [*]</pattern>



  • Because the vast majority of people don't want to write or edit XML. So config.xml becomes a much easier way to do things, by just setting YES or NO. They don't want to work out the syntax, and that's fine.

    You are in that 1% that want to do things "just so", Joe. :)

  • Ok, so there's no advantage to doing it one way or another, other than simplicity? FYI I'm using XML Notepad 2007 and importing the MigXML.xsd. Seems to do the trick, much better than trying to do it by hand.

    Although I haven't really done anything involving logic yet, just simple copying of files and keys, I have collected all desktop shortcuts and redirected them to an "old shortcuts" folder.

  • In this case, no real difference. In other cases config.xml might do more or less than you wanted for some particular settings. It's never going to be as perfectly granualr as custom XML for most people, it mainly exists for the 99%.

    I use Visual Studio Express, myself :)

    Your way works well too. Whatever floats your boat.