Blocking Wallpaper Migration with USMT (or: you are a jerk)

Article
06/02/2011

Hi folks, Ned here again. Do you hate your users? Do you revel in removing the slightest joy they have in their day? Do you wish to crush their hope and dreams, to the point of removing the small shreds of humanity they see while walled into their bleak veal pens?

If so, this post is for you.

Today I talk about how to block wallpaper and theme migration from Vista or Windows 7 source computers when running USMT. The actual blocking part here is trivial, so if that's all you care about skip to the end. If you want to learn something, start at the beginning: this is part of an informal series that explains USMT reverse engineering. Once you get good at this, you can figure out any weird little corner-case on your own. Even blocking default behaviors. Like not letting people have pictures of their grandkids.

How do you live with yourself?

Understanding how wallpaper works

If you're migrating from Windows XP, you are already good to go - as you know from previous reading, wallpapers are not migrated automatically from that OS unless you write custom XML. However, if you are migrating from Windows Vista or Windows 7, user backgrounds do transfer over and work fine. It's tricky to turn off though, due to the shell's various personalization options. Let's walk through this.

Here for example, looking at a Windows Vista computer, you see that the desktop key (which contains a wallpaper registry value) is migrated using an OS built-in manifest:

C:\Windows\winsxs\Manifests>findstr /i "[wallpaper]" *.manifest

x86_ microsoft-windows-win32k-settings_31bf3856ad364e35 _6.0.6002.18005_none_b326fbadff7217f6.manifest:

<pattern type="Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

A quick Internet search seems to confirm that this is the right key data, as does looking at the registry:

If you set that Win32k manifest to NO in your config.xml (which is a bad idea, as that manifest migrates quite a few other settings and the users are going to be noticeably affected), then test a migration:

<component displayname="Microsoft-Windows-Win32k-Settings" migrate="no"

... the wallpaper customizations are still migrated.

This shows the danger of searching for references in the manifests without actually looking at the rules in the XML. Let's zoom out a bit:

< exclude > <objectSet>
<pattern type="Registry">HKCU\Control Panel\Desktop [Wallpaper]</pattern>

Examining that manifest closely shows that it actually already blocks migration of the wallpaper setting. But if you look at an actual user migration you will see that this wallpaper registry key does migrate even with this exclusion. You can search XML all you want for this one but you will only figure it out by the process of elimination: it's coming from:

x86_ microsoft-windows-shmig_31bf3856ad364e35 _6.0.6002.18005_none_6189f2a77440c81c.manifest

… which has no rules and only runs a "SHMIG.DLL" plugin that is completely opaque to you.

That manifest gets called by this guy in the config.xml:

<component displayname="Microsoft-Windows-shmig" migrate="yes"

Which is overruling the Win32K manifest. Gotta love the shell… turning that manifest off is definitely a bad idea, as it does a bazillion other things that you definitely want to migrate.

So what to do? It turns out there are two places in the user registry settings that control the wallpaper: the wallpaper registry value in the Desktop key, and the user's custom theme:

Ahhh Vista. We hardly knew ya.

The theme encapsulates the wallpaper settings as well. That does migrate over, thanks to this component manifest:

Which is the OS-supplied manifest:

x86_ microsoft-windows-themeui_31bf3856ad364e35 _6.0.6000.16386_none_82c7d4771e961867.manifest

Which only does this:

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

</objectSet>

</include>

</rules>

If you block the Themeui settings explicitly by using the config.xml, you block the wallpaper migration implicitly. This works because when the user first logs on and has blank theme settings, the default theme is set by the OS and voila: no customization happened, even if the Control Panel\Desktop\Wallpaper value is set. It sets the user to the default Windows theme. Sweet!

Nevermind all that, let's block some wallpaper!

Either of these works ion its own, pick one. The second one is the recommended one, the first one is the easier one:

1. Use the themeui config.xml (this can have unwanted side effects for various manifests, but in this case it's atomic to wallpaper and themes) to set only this change:

<component displayname="Microsoft-Windows-themeui" migrate="no"

2. Use custom XML (this is a best practice and generally recommended when blocking default migration behaviors):

scanstate c:\store /o /i:migapp.xml /i:miguser.xml /i:blockwallpaper.xml

<?xml version="1.0" encoding="UTF-8"?>
<migration urlid="https://www.microsoft.com/migration/1.0/migxmlext/blockwallpaperandthemes">
<component type="Documents" context="User">
<displayName>Block Wallpaper and Themes</displayName>
<role role="Data">
<rules>
<unconditionalExclude>
   <objectSet>
   
    <pattern type="Registry">HKCU\Control Panel\Desktop [WallPaper]</pattern>
    <pattern type="Registry">HKCU\Software\Microsoft\Windows\CurrentVersion\Themes\* [*]</pattern>
   </objectSet>
</unconditionalExclude>
</rules>
</role>
</component>
</migration>

And that's it. I hope you're happy with yourself, you made that nice user cry…

Ned "they probably had LOLCat pictures, no big loss" Pyle

Comments

Anonymous
June 06, 2011
...or for das Überjerk, just disable any ability to personalize the system via Group Policy in the first place. ;D
Anonymous
June 06, 2011
That's the Reichsmarschall of jerkiness.

Partager via

Blocking Wallpaper Migration with USMT (or: you are a jerk)

Understanding how wallpaper works

Nevermind all that, let's block some wallpaper!

Comments

Ressources supplémentaires