jump to navigation

Windows 7 Notification Area Automation – Falling Back Down the Binary Registry Rabbit Hole July 8, 2011

Posted by Micah Rowland in PowerShell, Windows 7.
6 comments

Once more unto the breach dear friends.

After countless hours of searching for a programmatic way to modify the notification settings of the task tray icons, I came to the conclusion that there are many questions and no answers out there. I embarked once again on the fun task of reverse engineering a binary registry setting to change a setting that should be pretty straight forward but, alas, is not. So let’s dive in shall we:

The notification settings for the task tray are stored in the registry at HKCU\Software\Classes\Local Settings\Microsoft\Windows\CurrentVersion\TrayNotify in the IconStreams value as a binary registry key. Luckly for us, the organization of the key is not nearly as hard to understand as the Favorites Bar. The binary stream begins with a 20 byte header followed by X number of 1640 byte items where X is the number of items that have notification settings. Each 1640 byte block is comprised of at least (one of the sections is not fully decoded so it may be made up of 2 or more sections) 5 fixed byte width sections as follows:

  • 528 bytes – Path to the executable
  • 4 bytes – Notification visibility setting
  • 512 bytes – Last visible tooltip
  • 592 bytes - Unknown (Seems to have a second tool-tip embeded in it but the starting position in the block changes)
  • 4 bytes – ID?

For the purposes of my automation, the first two blocks will serve very nicely.

param(
    [Parameter(Mandatory=$true,HelpMessage='The name of the program')][string]$ProgramName,
    [Parameter(Mandatory=$true,HelpMessage='The setting (2 = show icon and notifications 1 = hide icon and notifications, 0 = only show notifications')]
        [ValidateScript({if ($_ -lt 0 -or $_ -gt 2) { throw 'Invalid setting' } return $true})]
        [Int16]$Setting
    )

$encText = New-Object System.Text.UTF8Encoding
[byte[]] $bytRegKey = @()
$strRegKey = ""
$bytRegKey = $(Get-ItemProperty $(Get-Item 'HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify').PSPath).IconStreams
for($x=0; $x -le $bytRegKey.Count; $x++)
{
    $tempString = [Convert]::ToString($bytRegKey[$x], 16)
    switch($tempString.Length)
    {
        0 {$strRegKey += "00"}
        1 {$strRegKey += "0" + $tempString}
        2 {$strRegKey += $tempString}
    }
}
[byte[]] $bytTempAppPath = @()
$bytTempAppPath = $encText.GetBytes($ProgramName)
[byte[]] $bytAppPath = @()
$strAppPath = ""

Function Rot13($byteToRot)
{
    if($byteToRot -gt 64 -and $byteToRot -lt 91)
    {
        $bytRot = $($($byteToRot - 64 + 13) % 26 + 64)
        return $bytRot
    }
    elseif($byteToRot -gt 96 -and $byteToRot -lt 123)
    {
        $bytRot = $($($byteToRot - 96 + 13) % 26 + 96)
        return $bytRot
    }
    else
    {
        return $byteToRot
    }
}

for($x = 0; $x -lt $bytTempAppPath.Count * 2; $x++)
{
    If($x % 2 -eq 0)
    {
        $curbyte = $bytTempAppPath[$([Int]($x / 2))]
            $bytAppPath += Rot13($curbyte)

    }
    Else
    {
        $bytAppPath += 0
    }
}

for($x=0; $x -lt $bytAppPath.Count; $x++)
{
    $tempString = [Convert]::ToString($bytAppPath[$x], 16)
    switch($tempString.Length)
    {
        0 {$strAppPath += "00"}
        1 {$strAppPath += "0" + $tempString}
        2 {$strAppPath += $tempString}
    }
}
if(-not $strRegKey.Contains($strAppPath))
{
    Write-Host Program not found. Programs are case sensitive.
    break
}

[byte[]] $header = @()
$items = @{}
for($x=0; $x -lt 20; $x++)
{
    $header += $bytRegKey[$x]
}

for($x=0; $x -lt $(($bytRegKey.Count-20)/1640); $x++)
{
    [byte[]] $item=@()
    $startingByte = 20 + ($x*1640)
    $item += $bytRegKey[$($startingByte)..$($startingByte+1639)]
    $items.Add($startingByte.ToString(), $item)
}

foreach($key in $items.Keys)
{
$item = $items[$key]
    $strItem = ""
    $tempString = ""

    for($x=0; $x -le $item.Count; $x++)
    {
        $tempString = [Convert]::ToString($item[$x], 16)
        switch($tempString.Length)
        {
            0 {$strItem += "00"}
            1 {$strItem += "0" + $tempString}
            2 {$strItem += $tempString}
        }
    }
    if($strItem.Contains($strAppPath))
    {
        Write-Host Item Found with $ProgramName in item starting with byte $key
            $bytRegKey[$([Convert]::ToInt32($key)+528)] = $setting
            Set-ItemProperty $($(Get-Item 'HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\TrayNotify').PSPath) -name IconStreams -value $bytRegKey
    }
}

So what are we doing here. First we ask for two commandline arguments, the name of the program (normally the executable of the program) which is case sensitive, and the setting value. The possible settings values are:

  • 0 = only show notifications
  • 1 = hide icon and notifications
  • 2 = show icon and notifications

We then read in the current value from the registry and store it in a byte array, then create a string representation of the byte array to search for the application in.

We then encode the application name supplied in both a byte array and a string as with the registry value, then we search for the application in the registry key. If not found, we throw an error and drop out. Otherwise we continue.

We then store the header in its own byte array (we don’t use this header but if we need it in the future, we’ve already got the code to segregate it). After that, we loop through the remaining bytes, 1640 bytes at a time, and store each block in it’s own array which in turn is placed in a hash table using the begining byte position as its key.

Finally we loop through each key and search again for the application. If it is found, we set the 529th byte equal to the setting value passed in and then write the byte array back into the registry.

The astute script reader and novice cryptographer will notice our old friend ROT13. It turns out that Microsoft didn’t want us playing with this key so they used the unbreakable ROT13 algorithm on its contents. ROT13 is a mathematical substitution cypher (it’s much simpler than it sounds) which advances each alpha character 13 letters forward so A=N B=O C=P D=Q and so on. I’ve created a function that handles this in a case sensitive way and call it as needed.

So we have our script, but there’s one last wrinkle. The IconStreams registry value is read into memory by Explorer.exe when explorer loads and all changes to the notification area are stored in memory, then written to the registry on shutdown. This means that if we run our script, not only will we see no results right away, those results will be overwritten with the current settings when we restart the computer. Not good. It’s a simple fix though. We launch our script from a batch file and we execute taskkill /im explorer.exe /f then we execute our script, then we restart explorer.exe.

That’s pretty much it. No need for rainbow diagrams of nested dynamically sized items this time.

I will be cleaning up the script and updating this post later with additional information (default user hive info). Stay tuned!

New Tool: Advanced Format Drives April 29, 2011

Posted by keithga in Troubleshooting, Uncategorized, Windows 7.
3 comments

Been slacking lately (Working on MDT 2012).

Advanced format drives are coming!

http://en.wikipedia.org/wiki/Advanced_Format

This hasn’t been much of a problem until recently, now that most of the major hard drive manufacturers have started to switch over to full Advanced Format.

When you have an Advanced format drive, you should format with an operating system that can format the drive aligned on the advanced 4k sectors rather than the 512 byte sectors found on older drives.

If  you do not format an “Advanced Format” disk aligned on the 4k sectors, then you may experience performance degradation. Windows 7 SP1 has been updated to address Advanced Format Drives, and WinPE 3.1, contained in WAIK 3.1 has been updated as well.

But how do you know if you need WinPE 3.1?

I have just written a new tool: IsAdvancedFormat.exe, that can detect if there are *any* advanced format drives present on the local machine. It will return errorlevel 0 if there are no advanced format drives, and errorlevel 42 if there *are* advanced format drives.

Source code is included.

Sample Output!

C:\> IsAdvancedFormat.exe
Enumerate all detect all Advanced Format Drives.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: Maxtor 6L160M0
  Physical sector size is 512 bytes.
Enumerator: IDE Found: WDC WD10EADS-11M2B2
  Emulated sector size is 512 bytes.
  Physical sector size is 4096 bytes.
C:\> @echo %ErrorLevel%
42

Location!

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/IsAdvancedFormat.zip

Update! (7/24/2011)

It appears that Dell has taken this tool and enhanced it! Their new tool can detect if an Advanced Format drive was partitioned/formatted incorrectly.  Cool Stuff.

Since Dell’s tool is now a superset of my tool, I would recomend theirs first:  http://del.ly/afhdd 

I will continue to provide my tool here as a reference.

Thanks Dell! (and thanks Warren Byle)

Duplicate Driver Tool. January 10, 2011

Posted by keithga in MDT 2010, PowerShell, Troubleshooting.
comments closed

Overview

I just created a PowerShell script that can automatically detect duplicate drivers within a MDT Deployment share. For those of you who are not manually associating each driver to a specific Make and Model, this can help in trying to find drivers that are duplicates, or drivers that have been replaced by newer versions.

Typically having more than one driver in your MDT database won’t cause any errors during OS Installation, Windows will automatically determine the best driver out of all possible matches, and install only that one. However, as a Driver Database gets larger and larger, the MDT console may operate slower, and the installation process will also slow as MDT copies more possible driver matches.

This script is not a fully automated process. The output of the script is in text format, and the administrator must manually remove the drivers marked as duplicate/deprecated.

Syntax

…\DupeDriverTool.ps1 [[-SelectionProfile] <String>] [[-DPDrive] <String>] [[-DPShare] <String>] [-WhatIf] [-Confirm] [-Verbose]

DPShare – By default, the script will use the First Deployment share found on your local MDT Console. Override using this parameter.

SelectionProfile – By default the script will use the “Everything” Selection Profile Group, override using this parameter.

Verbose - Use Verbose to display more debugging information and to display a list of OK drivers at the end of the report.

Each driver package within the drivers.xml file looks something like:

<driver guid=”{1d30e8a3-f9ca-479f-bc89-9c929c9f647f}” enable=”True”>
   <Name>Intel System dmi_pci.inf 7.0.0.1011</Name>
<…>
   <Hash>0604A3D569DCBA7CC0EFEAE6ADB0D7A69DC40D2A</Hash>
   <Version>7.0.0.1011</Version>
   <Date>09/15/2006</Date>
   <WHQLSigned>True</WHQLSigned>
   <PNPId>*PNP0103</PNPId>
   <PNPId>PCI\VEN_8086&amp;DEV_244E</PNPId>
   <PNPId>PCI\VEN_8086&amp;DEV_2448</PNPId>
</driver>

Process Flow

The driver dupe tool runs as a PowerShell script, and must run on a machine with MDT 2010, or MDT 2010 Update 1 installed, as it uses some of the MDT PowerShell providers to manage the drivers.

The script will go through all driver packages and PnPID’s, looking for instances where two driver packages have matching PnPID’s. If we can do an intelligent job of determining which of the matching drivers contain the best version of the driver, we no longer need to maintain the drivers for the old drivers.

At the end of processing, the script will display a list of driver packages that are “safe” for removal. These are drivers where *all* PnPID’s are superseded by other “better/newer” drivers.

The Rules

  • Signed drivers are always preferred over unsigned drivers.
  • Signed driver dates are used to compare drivers, not driver versions.
  • Never modify any part of a Signed Driver, including the *.inf file. If you do so, the driver will no longer be signed.
  • It is always assumed that newer drivers are better than older drivers. If not, then you will need to manually keep track of which drivers are better.
  • Only driver packages where *all* PnPID’s are superdeded by better drivers are marked for removal.
  • Use the Verbose switch to see more detail while processing.

Future

  • Find Out of Box Drivers that exist within the OS as in-box drivers.
  • Find Out of Box Drivers that exist within WinPE.
  • Automatically delete the drivers on the machine if dupes are found.
  • No SCCM support now, only MDT 2010.

Location

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/DupeDriverTool.zip

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

Combining WIM files December 16, 2010

Posted by keithga in Uncategorized.
4 comments

I was at a customer site during the past few weeks, and the customer asked about merging WIM files. This company was a Lenovo shop, and they had three main platforms in their inventory, the Thinkpad T410, T410s, and the X201.

For technical reasons that I won’t get into here, we decided to create several Model Specific Fat images that could be deployed using SCCM as-is without loading additional Drivers. Unfortunately, when done we had about 8 images, including two base images that contained their common application suite, but did not contain any extra drivers.

When done we had the following x64 images:

  • WIN7ENTX64.base.wim
  • WIN7ENTX64.t410.wim
  • WIN7ENTX64.t410s.wim
  • WIN7ENTX64.x201.wim

Each wim was about 4-6 GB in size, all totaled about 21GB for x64.

WIM files

WIM files are containers that store other files, similar to the way that a *.zip file or a *.cab file stores other files. Microsoft Windows also provides the ability to “mount” Wim files into an existing File Folder, allowing one to Add/Delete/Modify files in the wim.  This causes problems since modifications of the WIM file can cause fragmentation, just like *.vhd files. Windows gets around this by supplying the imagex.exe /export command. This command will allow the administrator to move the content from one WIM file to another WIM file, and in doing so the new wim file will be de-fragmented!

We can use this imagex.exe /export command to move the contents of one Wim file *into* an existing wim file, the cool thing for us is that ImageX.exe will also check to see if the file already exists in the wim file, and will not add the file in order to save space!

Example

In the example case above with the three Lenovo machines and a base image, I decided to start with the base image, and to inject the three other platforms into the base *.wim image:

Imagex.exe /export WIN7ENTX64.t410.wim *   WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410″

Imagex.exe /export WIN7ENTX64.t410s.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.t410s”

Imagex.exe /export WIN7ENTX64.x201.wim * WIN7ENTX64.base.wim “WIN7ENTX64.DDrive.x201″

When I was finished the Base.wim file had increased in size by only 1.5GB, much better than trying to distribute 4 separate *.wim files totalling 20GB

-Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group

MDT Litetouch startup -Super Flow- help; November 11, 2010

Posted by keithga in MDT 2010, Troubleshooting, Windows 7.
3 comments

Someone posted a question on a MDT forum recently:

I´m courious about what is happening when you boot your client on the WinPE iso image that is generated when you update the deploymentshare in MDT.

So, does a “superflow” or other documentation like that exist ?

Interesting question, thought I’d write down some of the basics (Things that are interesting to people in the deployment field):

  •  The Computer starts up and the BIOS is responsible for selecting which device to boot from. This can be either:
    Network (PXE), Hard Disk, USB Flash Drive, or CD-ROM (El-Torito)
  • When booting off a hard disk or USB Flash Drive, the BIOS will look for an “Active” partition, and run the code in the Master Boot Record.
  • PXE Booting is a different topic…  :^)
  • When booting from the CD-ROM, the BIOS will kick off the EtfsBoot.com program running in El-Torito No-emulation mode. ETFSBoot.com does two things:
    • Runs the BootFix.bin program – This program will test for the existence of any “Active” hard disk partitions on the machine, if found, it will prompt the user to “Press Any Key to boot from CD or DVD.” If no “Active” partition is found, or the user presses a key, then the next “BootMgr” program is run.
    • Bootmgr – ( In windows XP it was ntldr) Is responsible for management of the other Operating Systems, it reads the \boot\bcd file (a registry hive), and displays a menu to the user. It can launch Windows, WinPE, other Real Mode programs, and even boot Windows from VHD files (for premium versions of windows like Windows Ultimate or Enterprise).
  • Once the OS has been selected, BootMgr then starts the process of loading all the OS components into memory, when ready it will pass control from Real Mode into the Windows Kernel. The OS will then take over the boot up process and continue loading the rest of the drivers and components. If at this point it can’t find the hard disk from where it came from, it will Stop BugCheckEx(), with error code 0x0000007B, typically this means the Storage Driver wasn’t loaded.
  • In WinPE the process continues by calling WinPEShl.exe. If WinPEShl.exe finds the file WinPEShl.ini, it will parse it. For MDT 2010, the WinPEShl.ini file looks like:
[LaunchApps]
%SYSTEMROOT%\System32\bddrun.exe,/bootstrap
  • BddRun.exe – Will launch wpeinit.exe. It will also remain in memory and monitor the keyboard for F8 (See: http://deployment.xtremeconsulting.com/2009/10/29/78/ )
  • WpeInit.exe will start up the network, and other services and parse the unattend.xml file for commands to run. For MDT 2010, the Unattend.xml file looks like:
<?xml version="1.0" encoding="utf-8"?>
…
<Path>wscript.exe X:\Deploy\Scripts\LiteTouch.wsf</Path>
  • Litetouch.wsf will then check to see if there are any Task Sequences in progress (is there a c:\minint and/or c:\_SMSTaskSequence\TSEnv.dat file present), and if so execute.
  • If Litetouch can’t find any in-progress Task Sequences (NewComputer), it will:
    • Parse the Bootstrap.ini file
    • Display the Welcome Wizard (unless SkipBDDWelcome is defined)
    • Parse the CustomSettings.ini file (Typically from the DeployRoot found in the Bootstrap.ini file).
    • Display the Deployment Wizard (Unless SkipWIzard is defined)
    • Run the full Task Sequence…

<whew>

New Tool: ZTIAppVerify.wsf – Logs the status of all installed applications. November 8, 2010

Posted by keithga in MDT 2010, Troubleshooting, VBscript.
comments closed

Someone posted this question on a E-Mail list today:

Subject: Applications log file

Hi all,

I am working on building a LTI solution for Win7. [… is] there […] a simple solution to create a log file at the end of the deployment phase. This log file must contains a list of all applications installed in the task sequence.

It’s possible?

It got me thinking, and I realized that I *had* created a script to perform this exact same problem early this year, yet never posted it here to my blog.

So without further delay:  Introducing new tool ZTIAppVerify.wsf!

Details:

This script performs two tasks:

  1. 1. It will enumerate through the Applications specified in the Wizard, the CustomSettings.ini, and/or MDT Database. In other words, it will parse the Applications and the MandatoryApplications list properties and attempt to see if the installation was successful.
    How does it determine if the installation was successful?  If you populated the “UninstallKey” when creating your Application in MDT, that Key must then exist in the uninstall registry. For MSI applications, that UnInstallKey is just the Product Key. An Error is generated if the Key is not found (meaning the install was not successful).
  2. The script will also enumerate through all the Uninstall Registry Keys on the local machine:
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\…
    This is the list that is populated when you go to the Control Panel to remove an application (and a lot more). Note that output will contain the “UninstalKey” for use later on.

Just place this script in your MDT 2010 Task Sequence, somewhere *after* the ZTIApplication.wsf script(s) are run.

Sample Output:

For example, in the 2nd case listed above, the script will display a list of installed programs, the “UninstallKey”, and a friendly name for the application:

…
INSTALLED:   {23170F69-40C1-2702-0465-000001000000} \ 7-Zip 4.65 (x64 edition)
INSTALLED:   {25097770-2B1F-49F6-AB9D-1C708B96262A} \ System Center Operations Manager 2007 R2 Agent
INSTALLED:   {26A24AE4-039D-4CA4-87B4-2F86416017FF} \ Java(TM) 6 Update 17 (64-bit)
INSTALLED:   {29C93182-34F6-3275-A18D-59326851CD57} \ Microsoft Windows SDK for Visual Studio 2008 .NET Framework Tools - enu
INSTALLED:   {2F14965D-567B-4E59-ADEB-0A2CC1E3ADDF} \ Sql Server Customer Experience Improvement Program
INSTALLED:   {31E8F586-4EF7-4500-844D-BA8756474FF1} \ Windows Automated Installation Kit
INSTALLED:   {347F1DAD-AFF5-4F68-84F5-69AEB3EE1D24} \ Microsoft Deployment Toolkit 2010 Update 1 (5.1.1642.01)
…

Link:

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/ZTIAppVerify.zip

New Tool: USB Boot Tool October 28, 2010

Posted by keithga in MDT 2010, Uncategorized, VBscript.
comments closed

Overview:

The purpose of the tool is to add/remove WinPE Boot.wim file(s) to a USB Flash Drive using a wizard. 

It is designed to integrate with the Microsoft Deployment Toolkit 2010.

Description:

It should be smart enough to find USB flash drives, find any local  MDT 2010 Litetouch.wim files, automatically mark the drive/partition active (if not already set), and it can add/remove multiple *.wim files to a single USB Flash drive if there is enough space.

This is ideal if you want multiple Litetouch WIMs, For example x86 *and* x64 litetouch.wim files on the same USB stick, or Litetouch WIMs from multiple Deployment shares (One production server, one test server)..

USBootTool.hta is a standalone *.hta file, and requires no other components/libraries.

Installation/Operation:

· Just copy this script to your %deploymentshare%\Boot\ directory.

· When the script starts up it will display the Litetouch.wim files present on that directory. If not present it will enumerate through the Deployment shares mounted in the MDT console.

Screen Shots:

clip_image001

· Note the tool found my Flash Drive, parsed the BCD file and found three entries.

· I click “add” to add a *.wim file.

clip_image002

· Note that the tool found several *.wim files in my deployment share.

· I can modify the description if required.

clip_image003

· The script will copy all the necessary files to the Flash Drive.

· It will also place the *.wim file in a separate folder. The folder name is a GUID to prevent conflicts.

· I can repeat the process to add other *.wim files to my USB flash drive

 Source

http://cid-5407b03614346a99.office.live.com/self.aspx/Blog/USBBootTool.zip

-k

Hard Link Migration using USMT October 12, 2010

Posted by Dave Field in USMT.
add a comment

Okay, so you’ve probably heard about how USMT can now migrate files without actually removing them from your computer…

You hadn’t? Well, let me be the first to tell you, and show you a short test you can do to prove this capability to yourself.

Hard Links

The NTFS file system supports a method of linking files that will be familiar to those with backgrounds in UNIX or Linux. These file system structures are called links. Essentially, they are aliases that point at a physical file stored somewhere else on a storage volume. The file can be accessed from either location, just as if it was stored there. The exact mechanism by which this is accomplished is different in NTFS, but the feature looks and acts the same.

How USMT uses Hard Links

When the User State Migration Tool (USMT) uses hard links, it creates a folder on the file system and writes links in it to files that are to be migrated to the new operating system. When the new operating system is installed, scripts can delete the original folders, clearing space on the disk for the new OS. As long as the folder created by USMT is not deleted, either directly or by formatting the volume, the files are preserved by the hard links. When the OS installation is completed, USMT runs again, restoring the original file links and removing the hard link folder.

Does this really work?

Try this short test. On a command prompt, issue the commands below and observe the output:

Create two folders for the test:

C:\>mkdir test1

C:\>mkdir test2

Now, write a file into the first folder:

C:\>Echo “Hello world!” > .\test1\test1.txt

Verify the file is readable:

C:\>type .\test1\test1.txt

“Hello world!”

Now make a hard link to a filename in the second folder:

C:\>mklink /H c:\test2\test2.txt c:\test1\test1.txt

Hardlink created for c:\test2\test2.txt <<===>> c:\test1\test1.txt

Verify that you can read the second “file”.

C:\>type test2\test2.txt

“Hello world!”

You are reading the original through a hard link!

Now delete the first file:

C:\>del test1\test1.txt

Is the file gone? Let’s check:

C:\>type .\test1\test1.txt

The system cannot find the file specified.

Looks gone to me…let’s check the second file:

C:\>type test2\test2.txt

“Hello world!”

More in using USMT to migrate users

Well, that’s about it. USMT preserves your data right on the disk even as the new operating system is installed. You’ve seen it with your own two eyes, so you know it works. Now take USMT for a spin. You can find out more about USMT in Tim Mintner’s post: Understanding USMT with MDT 2010

User Tiles in the Domain October 8, 2010

Posted by Micah Rowland in Uncategorized.
3 comments

In a previous post, I described a solution for handling user account tiles for local accounts. A reader recently emailed me inquiring about user tiles for domain users and I realized that I had failed to cover how Windows 7 handles this and how an IT department could leverage this functionality.

For those of you who have read the previous post, you’ll remember that Windows 7 (and Vista) stores the usertile picture that is displayed on login and on the start menu in the registry buried in the SAM hive. This article assumes you have read the previous one and will only briefly reiterate key points as necessary.

For domain accounts, the story is slightly different. Domain account usertiles are not in fact stored in the registry but in a much more accessible location, C:\ProgramData\Microsoft\User Account Pictures\ . If only local accounts were so easy. But don’t worry, we’ll still have a fun time. The usertile files for each user are saved as DOMAIN+username.dat. For example, John Doe at Contoso would be stored as CONTOSO+jdoe.dat. The contents of this dat file will look very familiar to any of you who have looked at local usertiles in the registry. In fact, the hex data stored in this file is EXACTLY the same as how it would be stored in the registry.

So lets get our plan of attack:

  1. Login to a domain account. Any will do.
  2. Set our usertile the old fashioned way.
  3. Retrieve the generated dat file.
  4. Use it!

WAY SIMPLER THAN LOCAL ACCOUNTS!

Let’s take the following scenario posed by one reader. Contoso would like users in each of 5 departments to have a department specific usertile. First we login using a domain account (for our example John Doe will do) and set its usertile to the first department’s desired tile. We then copy the C:\ProgramData\Microsoft\User Account Pictures\CONTOSO+jdoe.dat file to a holding area and rename it to departmentname.dat. We then repeat for the remaining 4 departments. Now that we have the proper dat files we can leverage them in a few different ways. Most users will go the route of the logon script: Check for group membership to ascertain the department of the user (or read an Active Directory attribute) and copy the proper department dat file into the local computer’s User Account Picture directory. We could also preload our OS deployment with a set of all user files for all members of the domain (probably only a good idea in an organization with a small number of users). Using a logon script will ensure that the proper department icon is used, even if a user changes it, though placing a complementing logoff script would be prudent to prevent any non-compliance.

Whatever way you cut it, it’s pretty much up to you at this point. Bon Appétit!

P2V Migration for Software Assurance Beta 2 Now Available – with System Center Configuration Manager 2007 integration September 26, 2010

Posted by keithga in Announcements, MDT 2010, System Center Configuration Manager, Troubleshooting, USMT, VBscript, Windows 7.
comments closed

 

We’ve been busy here at Xtreme Consulting Group, recently Keith worked as a Developer on the P2V Migration project with Microsoft.

For more information on P2V Migration, click here.

P2V Migration adds documentation and support of System Center Configuration Manager 2007 Zero Touch Installation! 

What is better than spending a moment to kick off a completely automated process to redeliver an existing operating system as a virtual machine within a new build of Windows 7?
Answer: Making the entire process “zero touch” without necessitating a visit to the target computer or manually initiating the migration!

P2V Migration for Software Assurance can now be implemented using System Center Configuration Manager 2007 Operating System Deployment as well as native Lite Touch Installation with the Microsoft Deployment Toolkit 2010 U1. Computer refresh, replace and restore task sequence templates for Configuration Manager are included and documented in this Beta release.

clip_image001 P2V Migration templates integrated with Microsoft Deployment Task Sequence options in System Center Configuration Manager. Can be created and advertised as with other task sequence options.

Additional optimizations beyond Configuration Manager functionality included in this release are:

1. Better flexibility for backing-up and restoring VHD files using default file locations

2. Support for PCs using system and boot volumes

3. Globalization of scripts to handle varying regional and locale formats

4. General bug fixes and improved documentation

These fixes reflect the feedback of our Connect community and MVPs – thanks to everyone for submitting feedback!

Download P2V Migration for Software Assurance Beta 2 now:

P2V Migration for Software Assurance

New to P2V Migration for Software Assurance?

 

This solution was built to help unblock OS deployments by redelivering blocking users’ old Windows environments, applications and browsers seamlessly in Windows 7 using automated physical-to-virtual migration

P2V Migration for Software Assurance uses the Microsoft Deployment Toolkit, Sysinternals Disk2VHD and optionally System Center Configuration Manager 2007 to convert a user’s existing Windows XP or newer client environment to a virtual hard disk then automates the delivery of an updated and personalized Windows 7 operating system containing a virtual machine with the user’s previous Windows environment, applications and Web browser. The user’s previous virtual desktop retains its existing management components, domain membership and policies. The process also publishes applications and the browser for the user to access them seamlessly within Windows 7’s start menu.

How it Works

clip_image002 Completely automated process enables the previous operating system to be a child virtual machine inside the Windows 7 host.
clip_image003 Standalone application and Internet Explorer links published from virtual machine to native Windows 7 start menu. These applications can be launched individually using RemoteApp integration – without showing the entire virtual machine’s desktop.

Keith

Keith Garner is a Deployment Specialist with Xtreme Consulting Group
Follow

Get every new post delivered to your Inbox.

Join 84 other followers