The Quest

A customer recently decided to spruce up its tablet/slate fleet by including some simple third-party Silverlight applications. These applications are normally downloaded and installed using a web browser. So the question was raised, “Can we install this programatically as part of the imaging process?” My interest was piqued and I embarked on my foray into Silverlight deployment.

We’ll use the Fandango Windows Slate located (for now) at http://images.fandango.com/mobile/slate/ as our example.

Upon navigating to the above web address, the site checks to see if the application has already been installed. If not, the user is prompted to Tap to Install, a simple feat to accomplish if you have fingers.  After tapping the prompt, a security warning dialog box appears and after a short countdown allows the installation by clicking/tapping the Install button.

Breaking out Sysinternals Process Monitor and filtering the data reveals the Silverlight.Configuration.exe, a prime suspect. A quick right-click Properties action and a tap on the Process tab gives us a place to start. The command-line being executed is:

“C:\Program Files (x86)\Microsoft Silverlight\4.0.60831.0\Silverlight.Configuration.exe” -installtrustedApp 3835182041.images.fandango.com 231aa8

The next step was to see if this command alone would install the application. Uninstall, cmd, paste, enter. No error message… but no program in the start menu and nothing in Programs and Features. A dead end? What could I be missing?

Time to break out Sysinternals Process Explorer. Let’s watch the install happen real-time and see what other related parent and/or child processes may be involved. Processes launch and close relatively quickly in Process Explorer, so to give myself the extra time I may need, I accessed the Difference Highlighting Duration dialog from the Options menu. Unfortunately this value is limited from 0-9 so 9 will have to work. Uninstall, then, side by side, reinstall the app and watch.

Internet Explore launches a Silverlight.Configuration.exe child process, which launches a second Silverlight.Configuration.exe child process, which launches a sllauncher.exe child proces, which launches a second sllauncher.exe child process. A new suspect! Inspecting the properties of the child process reveals this command-line:

“C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe” 3835182041.images.fandango.com

Very similar to the above Silverlight.Configuration.exe command-line. Let’s search for this sllauncher.exe and see if it has some command line arguments we can use. A quick search reveals the perfect article: How to Install a Silverlight Out-of-Browser Applications (XAP) Silently

JACKPOT? A quick read reveals a sample scenario involving deploying your own in-house developed XAP… Not quite what we have in mind but it’s a great start. The sample command-line they use is:

“C:\Program Files\Microsoft Silverlight\sllauncher.exe” /install:”C:\MySilverlightApps\Silverlight4.OOB.ChromelessWindow.Demo.xap” /origin:http://www.kunal-chowdhury.com/private/apps/ClientBin/Silverlight4.OOB.ChromelessWindow.Demo.xap /shortcut:desktop+startmenu /overwrite

Not a bad start, but not perfect for our needs. We don’t have the xap file that the website is using nor do we know the origin of the file. Now what? Let’s pop back open Sysinternals Process Monitor and take a look at the file changes during install, maybe we can find a locally stored copy?  Pause and clear the capture, set the filters back to default, add a filter to include only sllauncher.exe processes, uninstall the app, start capture, install the app. Now filter only file operations and… nothing. Let’s try Silverlight.Configuration.exe… nope. Let’s try path contains xap… BINGO! An application.xap file in the folder 3835182041.images.fandango.com. We’ve seen that path before. The full path to that xap is:

C:\Users\Micah\AppData\Local\Microsoft\Silverlight\OutOfBrowser\3835182041.images.fandango.com

Ok, what have we got? Let’s see, we have an icon, a png of the icon, the application.xap file, an index.html file and 3 un-extensioned files: installstate, metadata, and state. Well it’s a good bet that the application.xap file is the source we need… what about the origin parameter? The installstate and state files are empty (probably flag files), but the metadata is the jackpot we’ve been waiting for:

ShortcutName=Fandango Slate Application
LaunchPath=C:\Users\Micah\AppData\Local\Microsoft\Silverlight\OutOfBrowser\3835182041.images.fandango.com\index.html
CustomIcon=1
TrimmedSourceDomain=images.fandango.com
TrimmedTitle=Fandango Slate Application
TrimmedName=Fandango Slate Application
ElevatedPermissions=2147483647
XapLastModified=Tue, 02 Aug 2011 23:16:17 GMT
EnableGPUAcceleration=True
WindowStartupLocation=0
WindowTop=0
WindowLeft=0
WindowWidth=1367
WindowStyle=1
WindowHeight=767
SourceDomain=images.fandango.com
OriginalSourceUri=http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap
FinalAppUri=http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap
RuntimeVersion=4.0.50826.0
AppID=3835182041.images.fandango.com
Description=Fandango Slate Application on your desktop; at home, at work or on the go.
Title=Fandango Slate Application
Name=Fandango Slate Application

OriginalSourceUri looks PERFECT. Just to make sure we really have the original XAP file, let’s download that XAP, maybe the xap file changes when downloaded and installed (ok maybe not, but we can’t be too safe). Copy pasting that address into IE gives us a downloaded copy!

As far as the remaining two parameters, shortcut and overwrite: The overwrite parameter is not needed for MDT deployments or if you are sure the app has never been deployed before. Adding overwrite prevents an error from being thrown if the application already is installed. The shortcut parameter can be left out or set to one of the following:

1. desktop
2. startmenu
3. desktop+startmenu

Let’s roll it all together: Place the xap file in a folder and our local command-line is as follows:

“C:\Program Files (x86)\Microsoft Silverlight\sllauncher.exe” /install:“Fandango.Slate.xap” /origin:http://images.fandango.com/mobile/slate/ClientBin/Fandango.Slate.xap /shortcut:startmenu /overwrite

Caveats

Silverlight 5 was released on December 9, 2011 and has a 64-bit installer. This means that if you are installing Silverlight 5, the path to sllauncher will always be C:\Program Files, regardless of the OS architecture, making our job simpler, one command-line for all

These applications are installed on a per-user basis, so for MDT deployment, make sure copyprofile=true.

Some Out-of-Browser Silverlight apps may require Native Extensions For Microsoft Silverlight which you can find here as an msi download. Install the extensions before deploying the apps to avoid dependency issues.

Summary

So, to summarize:

1. On a test machine, download and install the desired Silverlight Out-of-Browser application
2. Navigate to %LOCALAPPDATA%\Microsoft\Silverlight\OutOfBrowser and open the appropriate application folder.
3. Open the metadata file in notepad and copy the OriginalSourceUri path.
4. Paste the path the address bar of your browser and download the XAP file.
5. If using MDT, copy the XAP to a folder and import.
6. Use the command-line syntax as follows:
   • 64-bit OS: “%ProgramFiles(x86)%\Microsoft Silverlight\sllauncher.exe” /install:[XAP FILE] /origin:[ORIGINALSOURCEURI PATH] /shortcut:[DESIRED SETTING] /overwrite
   • 32-bit OS: “%ProgramFiles%\Microsoft Silverlight\sllauncher.exe” /install:[XAP FILE] /origin:[ORIGINALSOURCEURI PATH] /shortcut:[DESIRED SETTING] /overwrite

Credit: I ran across a great article on Tim Heuer’s blog while proofing this draft that I failed to locate when it was originally started and would be remiss not to mention. It’s a great echo of what I’ve covered here but doesn’t cover third-party apps.

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!

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)

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:

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

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

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>

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

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:

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

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

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

· I can modify the description if required.

· 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

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

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!

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. 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

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

	Completely automated process enables the previous operating system to be a child virtual machine inside the Windows 7 host.
	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

Initially I attempted to delete the contents of the %USERPROFILE%\Favorites\ folder and add a task sequence to copy a captured Favorites folder’s contents in. Unfortunately, this only partially worked. The links were required to have their respective icons cached and copying in a new set caused all of the links to revert to the default link icon. In addition, the Favorites Bar was empty and the Favorites menu had an additional folder named Favorites Bar that contained the links that should have been on the Favorites Bar itself. Time to dig in.

On the surface it appears that Favorites Bar links are stored at %USERPROFILE%\Favorites\Favorites Bar. Looking at the properites window, the Read-only check box is blacked out, a good indication that the folder is a “special folder”. Digging a bit deeper, I found that the “Favorites Bar” folder is a special folder whose actual folder path is %USERPROFILE%\Favorites\Links (even though it displays as “Favorites Bar”). When Internet Explorer launches, it checks for the Links folder, not the Favorites Bar folder. If the Links folder does not exist, one is created as a special folder that displays in Windows as “Favorites Bar”.

I’m always a fan of letting Windows do what it’s best at instead of trying to reverse engineer everything. So, to start I included the base set of favorites in the image. I then wrote a PowerShell script that determined the location based on the computers default gateway, opened the links that required customization, read through the lnk file and replace the FeedUrl and URL properties with the correct values, and rename the url files that required custom names reflecting the location. Here’s a brief script that illustrates the one used. Lets assume the link is named Link.url and the customer has 5 sites with different gateways. This script determines the gateway, maps it to a static list (you could use a environmental variable set by MDT), and then replaces the CITY in the link http://www.contoso.com/CITY/site.html and renames the favorites file.

#Get Gateway (assuming only one active network connection)
$strComputer = "."
$Nics = Get-wmiobject win32_NetworkAdapter -comp $strComputer
foreach ($Nic in $Nics)
{     $Config = Get-Wmiobject win32_NetworkAdapterConfiguration | where {$_.index -eq $Nic.index}     if ($config.IPAddress -ne $null)     {         $VGateway = $config.DefaultIPGateway     }
}
#Setup hash table and set urlLocation and city variables
$GatewayList = @{"10.0.0.1" = "urlfolder1";"10.0.1.1"  = "urlfolder2";"10.0.2.1" = "urlfolder3";"10.0.3.1"  = "urlfolder4";"10.0.4.1"    = "urlfolder5"}
$CityList = @{"10.0.0.1" = "City1, CA";"10.0.1.1"  = "City2, CO";"10.0.2.1" = "City3, WI";"10.0.3.1" = "City4, IA";"10.0.4.1" = "City5, NY"}
$urlLocation = $GatewayList[$VGateway]
$city = $CityList[$VGateway]
#Repeat for each file that needs customization
$file = get-item 'c:\users\USERNAME\favorites\links\CustomizedLinkFolder\Link.url'
$newcontents = ""
$reader = $file.opentext()
while ($reader.EndOfStream -eq $FALSE)
{     $curline = $reader.ReadLine()     if ($curline.contains("BASEURL="))     {         $newcontents += "BASEURL=<a href="http://www.contoso.com/"">http://www.contoso.com/"</a> + $urlLocation[0] + "/site.html`n"     }     elseif ($curline.contains("URL="))     {         $newcontents += "URL=<a href="http://www.contoso.com/"">http://www.contoso.com/"</a> + $urlLocation[0] + "/site.html`n"     }     else     {         $newcontents += $curline + "`n"     }
}
$reader.close()
out-file -filepath $file -InputObject $newcontents
#After all are edited, rename webslices to city
get-childItem C:\users\USERNAME\Favorites\Links\*.url | rename-item -newname { $_.name -replace 'CITYHERE', $city }

Ok, that’s not too bad, just cracking open the URL files and editing inline… So now I have the right links, on to the Favorites Bar!

Using Sysinternals Process Monitor, IE was monitored and the first time Internet Explorer opens, process monitor showed it writing to a  the contents of the Favorites Bar and stores it in the registry in a key named Order located at:

HKCU:\Software\Microsoft\Windows\Currentversion\Explorer\Menuorder\Favorites\Links

So let’s open up the registry and take a look…

Oh boy!

A half hour later and a few well crafted web searches later (A needle in a haystack search… got lucky) landed me at a website that described the format of this key for Windows XP and Windows Vista.

http://www.codeproject.com/KB/shell/iefavdecon.aspx

After comparing the binary format as described at this site with the stored values, something didn’t quite line up so I loaded the hex into excel and started reverse engineering the data using the provided binary format information as a starting point.

The information from Code Project was invaluable at deconstructing this (and I learned a lot about how Microsoft stores data in binary registry values). The Subrecord1 header in Windows XP is 18 bytes long, in Windows Vista is 36 bytes long, and, as I found, in Windows 7 is now 40 bytes long. There may be other changes to each field, but the main change is the size of that header. A side point: the length field of the header is stored in 2 bytes which as you read the hex need to be reversed…. so a length of 1C0 (448 bytes) is stored as C0 01.

Code Project does a  good job of describing the format, once you understand it… I’ll try to briefly explain and diagram it, I hope it clears it up a bit.

The data is stored much like a TCP IP packet with encapsulation (stay with me here). Think of it as a giant envelope that has a bunch of envelopes inside, and each envelope inside has an envelope in it that contains a letter. The binary data starts with a header that is 20 bytes long. This header tells us how many bytes long the payload is and how many items are in it. After we read the header, the first payload (envelope) follows. This envelope has an 8-byte header as well that tells you how long (how many bytes) its payload is as well as *TADA* the order it is to appear in the Favorites Bar. The length is how we know where one favorites bar item ends and the next begins. We then grab that many bytes and we have the item envelope. The item envelope has a 28-byte header that tells us what type of item it is (link or folder). Finally we have the “letter”, the actual data about the favorites bar item. The data contains such information as the file name of the item, the type of the item (link or folder)

After rereading that explanation above, I’ll be honest, it’s a complex topic and trying to explain it may have just made some readers’ nose bleed.

Sufficed to say, the above information allowed me to craft a PowerShell script that reads the data, scans each item and checks it’s longname property for a specific set of strings, and sets the order value in the purple header as desired.

And here’s the PowerShell script to reorder:

$key = get-item HKCU:\software\microsoft\windows\currentversion\explorer\menuorder\Favorites\Links
$value = $key.getvalue("Order")
write-host Original Size: $value.count
[byte[]] $newvalue = @()
$newvalue = $value[0..19]
$payload =  $value[20..$value.GetUpperBound(0)]
$list = @{}
[int] $i = 0
$remPayload = $payload.Clone()
write-host Payload Size: $remPayload.Count
while ($remPayload.Count -gt 8)
{     [byte[]] $currentrecord = @()     $length = $remPayload[3]*65536+$remPayload[2]*4096+$remPayload[1]*256+$remPayload[0]     $currentrecord = $remPayload[0..($length-1)]     write-host Record $i Size = $length     $list.add($i, $currentrecord)     $remPayload = $remPayload[$length..$remPayload.GetUpperBound(0)]     $i++
}
#$list.add($i.tostring(), $remPayload)
$order = 6
write-host Begining For list is $list.count members
for ($i = 0; $i -lt $list.count; $i++)
{     write-host Processing list item $i order $list[$i][4]     if ($list[$i].count -gt 8)     {          $startposition = $list[$i][-8] + 49          $teststring = ""          for ($y=1; $y -le 14; $y++)          {             $teststring += [char] $list[$i][$startposition + $y]          }          #$teststring          $n = [char](0)          if ($teststring.Contains("D"+$n+"o"+$n+"w"))          {             $list[$i][4]=0          }          elseif ($teststring.Contains("W"+$n+"e"+$n+"a"+$n+"t"+$n+"h"+$n+"e"+$n+"r"))          {             $list[$i][4]=1          }          elseif ($teststring.Contains("T"+$n+"r"+$n+"a"+$n+"f"+$n+"f"+$n+"i"+$n+"c"))          {             $list[$i][4]=2          }          elseif ($teststring.Contains("N"+$n+"e"+$n+"w"+$n+"s"))          {             $list[$i][4]=3          }          elseif ($teststring.Contains("W"+$n+"e"+$n+"b"))          {             $list[$i][4]=4          }          elseif ($teststring.Contains("C"+$n+"o"+$n+"n"+$n+"t"+$n+"o"+$n+"s"+$n+"o"))          {             $list[$i][4]=5          }          else          {             $list[$i][4]=$order             $order++          }     }
}    for ($i = 0; $i -lt $list.count; $i++)
{     if ($list[$i].count -gt 8)     {         write-host List item $i byte 10 = $list[$i][10] order = $list[$i][4]             $newvalue += $list[$i]     }
}        $value.count
$newvalue.count
set-itemproperty HKCU:\software\microsoft\windows\currentversion\explorer\menuorder\Favorites\Links Order $newvalue
write-host Total List Items: $list.count

As you can see, the script is very static, it’s looking for a link that has Dow, Weather, News, Web, or Contoso and puts those in positions 0 through 5, any other links are put afterwards.

Theoretically this script could be executed as part of a logon script so that the favorites bar gets reorganized everytime the user logs on and places any user added links at the end of the favorites bar.

Well that’s it. Wish this was stored in a much easier format like XML. C’est la vie.

The first step in automating any process is to do it manually first and watch what happens. I rely on the Sysinternals tool Process Monitor as well as Process Explorer for most of my research. Launching Process Explorer as an administrator led me down a few dead ends. It was only after running Process Explorer in the System context using PSExec with the -s and -i switches that I was able to locate the location that Windows 7 uses to store the user tile.

The User Tiles configuration information is stored in Windows registry at HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\########, where ######## is a unique 8 digit hexadecimal ID, in as a binary value named UserTile. But how can we cross reference a username to this 8-digit ID? Glad you asked!

Taking a further look at the registry key, you’ll notice that beneath the user ids, there is another key called Names. If you expand this key you’ll see a list of all local user accounts on the system. Upon opening any of the user keys you’ll notices that only a default value exists. However, take a look at the value type… It is not a standard type, but a hexidecimal number 0x### where the ### id crossreferences nicely with the list of user ids above. In our script we need only pad this value with leading 0′s until it reaches the desired 8-digits. Trying to retrieve this hexidecimal “type” throws exceptions in nearly every method I tried. Exporting the key to a .reg file gave me the output I needed to be able to search for a specific username and retrieve its id.

The SAM Hive of the registry is not generally accessible to any user accounts and is configured, by default, to only be accessed by the System account. To maintain security, both the read and the write operations necessary to modify the UserTiles programmatically are accomplished by executing the operations in the System context. Execution in the system context is accomplished by utilizing the PSExec tool.

When a user interactively changes the UserTile by means of the User Account control panel, Windows resizes the image specified by the user to 128×128 and saves new image as a 24-bit bitmap file in the C:\ProgramData\Microsoft\User Account Pictures\ folder as USERNAME.bmp. The bitmap is then stored in the registry in the SAM and the user’s contact card is updated.

The binary data is composed of a header followed by a payload containing the binary graphic used for the UserTile and closed with a footer that contains the path to the file used as the UserTile. The header is 16 bytes long.

1. 12-bytes (seem to be constant at 01 00 00 00 03 00 00 00 01 00 00 00)
2. 4-byte field representing the size of the payload

The payload data reveals that the image stored in the registry is 126×126 pixels, presumably to make up for the 1 pixel wide border around the image when displayed on the logon screen and on the start menu. Further, the image is stored in 16-bit color depth using BI_BITFIELDS compression.

The footer contains the type of image file used and the location of the file used using Unicode (2-bytes per character). The format is as follows:

1. 4-byte field (purpose unknown, possibly the length of the following field)
2. A null-terminated Unicode string representing the file type
   1. Eg. “bmp” = 62 00 6D 00 70 00 00 00
3. 4-byte field (purpose unknown, always 02 00 00 00)
4. 4-byte field representing the payload (bitmap) size in bytes
5. A null-terminated Unicode string representing the file location padded to the nearest 4 bytes.

Phew! Needless to say, this level of detail is not necessary for part 1 of this post, however in crafting a truely dynamic programmatic approach to changing the uer tile, we will need this information.

Solution:

It should be possible to engineer an application that accepts a username and a bitmap file to use. However, for part 1, it is simpler to export the registry keys from a sample machine using either the reg.exe or the regedit.exe utility under the System context using PSExec.

When scripting this automation, we must be aware that the first time PSExec is run, a EULA must be accepted. To avoid this, the following registry file is imported (AcceptPSExecEULA.reg):

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Sysinternals\PsExec]
"EulaAccepted"=dword:00000001

The following script was created to accomplish the goal of changing the UserTiles:

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'   Title:   User Tile Change Script
'   Author:  Micah Rowland (Xtreme Consulting)
'   Date:    07/14/2010
'   Desc:    This script is designed to programatically replace
'            a single local user's User Tile on Windows Vista
'            and above.
'   Prereq:  This script requires the use of PSExec available
'            from http://live.sysinternals.com/psexec.exe
'   Usage:   UserTile.vbs USERNAME USERTILEFILE
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
CONST FORREADING = 1
CONST FORWRITING = 2

set objShell = CreateObject("Wscript.Shell")
set objFSO = CreateObject("Scripting.FileSystemObject")
set objArgs = Wscript.Arguments
set objShell = CreateObject("Wscript.shell")
if CheckArgs() <> "" then
     Wscript.echo Checkargs() & vbcrlf
     wscript.echo "Arguments Invalid. Usage: ChangeUserPicture.vbs USERNAME UserTileFile"
     wscript.quit()
end if

strUsername = objArgs(0)
strUserTileFile = objArgs(1)
strUserIndex = GetUserIndex()
set objFile = objFSO.GetFile(strUserTileFile)
set objTS = objFile.OpenAsTextStream(1)
strUserTile = objTS.ReadAll
wscript.echo strUserTile
strRegFile = objShell.ExpandEnvironmentStrings("%temp%") & "\UserIndexes2.reg"
set objRegFile = objFSO.OpenTextFile(strRegFile, ForWriting, true)
contents = "Windows Registry Editor Version 5.00" & vbcrlf & vbcrlf & "[HKEY_LOCAL_MACHINE\SAM\SAM\Domains\Account\Users\" & strUserIndex & "]" & vbcrlf & strUserTile
objRegFile.Write contents
objRegFile.Close

strImport = "PSEXEC -S -I reg import " & strRegFile
objShell.Run strImport

Function GetUserIndex

     ' This function exports the Names key of the SAM from the registry to determine a match between the user account provided
     ' and its hex ID for use in creating the new registry file for import. Because the .reg file is exported in Unicode format
     ' we use the type command to pipe it from stdout to a new text file.

     strUsername = objArgs(0)
     strUserTileFile = objArgs(1)
     objShell.run "cmd /c reg export HKLM\SAM\SAM\Domains\Account\Users\Names %temp%\UserIndexes.reg /y"
     wscript.sleep(500)
     objShell.run "CMD /C type %temp%\userindexes.reg > %temp%\userindexes.txt"
     wscript.sleep(500)
     set objFile = objFSO.GetFile(objShell.ExpandEnvironmentStrings("%temp%") & "\userindexes.txt")
     set objRegExport = objFile.OpenAsTextStream(FORREADING)
     curLine = objRegExport.ReadLine()
     do until instr(lcase(curLine), lcase(strUserName)) or objRegExport.atendofStream
          curLine = objRegExport.ReadLine
     loop
     if objRegExport.AtEndOfStream then
          wscript.echo "Username not found."
          wscript.quit()
     else
          curLine = ObjRegExport.ReadLine
          tmpGetUserIndex = mid(curLine, instr(curLine, "(") + 1, len(curline) - instr(curline, "(") - (len(curLine) - instr(curline, ")")+1))
          do until len(tmpGetUserIndex) = 8
               tmpGetUserIndex = "0" & tmpGetUserIndex
          loop
          GetUserIndex = tmpGetUserIndex
     end if
End Function

Function CheckArgs()
     ' This function makes sure that 2 arguments were provided and that the filename provided exists
     if objArgs.Count <> 2 then
          CheckArgs = "Exactly 2 arguments must be specified."
     elseif not objFSO.FileExists(objArgs(1)) then
          CheckArgs = "File not found."
     else
          CheckArgs = ""
     end if
 End Function

The script syntax is: SetUserTile.vbs USERNAME FILE

The file used by this script consists of only the UserTile value from a registry export of a preconfigured UserTile. This can be accomplished by setting a local user account’s picture, opening regedit using the psexec -s -i regedit.exe command, navigating to the SAM key mentioned above, determining the correct user account as detailed above, and exporting the key. Then remove all data in the .reg file except the “UserTile=hex:…” entry.

To leverage this script, a command-script file was created and added to the Software Installation task sequence.

reg import AcceptPSExecEULA.reg
cscript SetUserTile.vbs "USERNAME" DATAFILE.txt

I hope to have a commandline based program developed in the future to tackle this which will accept any sized bitmap image as it’s input as opposed to using a captured registry value. I hope you have enjoyed this post. If you have any questions feel free to ask!

We have Speakers, Consultants, and Technical Professionals there to assist with Hands on Labs (Fun stuff).

Microsoft Deployment Toolkit Developer/Gurus Tim Mintner and Keith Garner will be there too. Get the inner workings of MDT 2010, and find out what’s going to be in MDT 2010 Update 1!

See you there!

Two “Birds-of-a-Feather” sessions you can count on us to be at:

OE01 Ask the Experts: Microsoft Deployment Toolkit (MDT) 2010

Tuesday, April 20 5:30 PM – 6:30 PM, Marco Polo 702 

Speaker(s): Michael Niehaus

Track(s): Client Management Technologies, Solution Accelerators, Systems Management

Session Type(s): Birds-of-a-Feather

Products(s): Configuration Manager 2007, Microsoft Deployment Toolkit, Windows Client

Here’s your chance to sit down with the team who are building MDT 2010, troubleshooting customer scenarios, blogging about the latest and greatest solutions and planning the next generation of deployment tools. Bring your questions about MDT 2010 to this Birds-of-a-feather session and find out how to apply the latest solutions to your specific scenarios.

OE31 Open Forum Discussion: Microsoft Deployment Toolkit 2010 (MDT) and Configuration Manager 2007 OSD

Tuesday, April 20 6:45 PM – 7:45 PM, Marco Polo 702 

Speaker(s): Chris Nackers

Track(s): Client Management Technologies, Solution Accelerators, Systems Management

Session Type(s): Birds-of-a-Feather

Products(s): Configuration Manager 2007, Microsoft Deployment Toolkit, Windows Client

Time to sit down with fellow OSD/MDT users and share your experiences around OSD/MDT in the real world. Come join Chris Nackers and others to discuss lessons learned around MDT and OSD in general in an Open Forum discussion.

Make/Model Match

Historically, if you had different hardware platforms, and you wanted to install drivers on each type, you would create separate packages for each Make and Model. Then you could query the Make and Model information from the BIOS to determine which package to install.

For example here are four Make+Model examples:

The disadvantage of this method is that you have to update the driver packages when new Models come along, and it’s also possible that you might keep multiple instances of the same driver package across many Make and Model repositories. 

PnP-ID Match

With MDT, ZTIDrivers.wsf was designed to do things in a different manner. Instead of downloading drivers and grouping them based on Make/Model, you would import the driver directly into MDT, MDT would parse the driver package, and MDT would install the driver package on the machine if the Plug and Play ID matched.

For example, Windows might search for Plug and Play ID’s that look like:

PCI\VEN_1099&DEV_0242&SUBSYS_02429005&REV_01
PCI\VEN_1099&DEV_0242&SUBSYS_02429005
PCI\VEN_1099&DEV_0242&CC_010401
PCI\VEN_1099&DEV_0242&CC_0104
PCI\VEN_1099&DEV_0242&REV_01
PCI\VEN_1099&DEV_0242
PCI\VEN_1099&CC_010401
PCI\VEN_1099&CC_0104
PCI\VEN_1099
PCI\CC_010401
PCI\CC_0104

Generally this system works better than copying based on Make and Model except for a few points:

• You must import the drivers in a correct fashion so MDT can parse the INF files, and so each driver package is a seperate entry (more on importing drivers later…)
• Some PC Makers only certify (support?) a subset of driver versions, so it is possible that MDT may give Windows the latest non-certified version of a driver.
• There also may be compatibility problems with specific drivers. When placed on some other platforms. (However IMHO, if a driver *can* be installed on a machine, but crashes the machine, then that is a bug of the driver).

Hybrid Make-Model + PnPID Match Solution

For my MDT environments, I don’t want to place all drivers into Make/Model groupings by default, since I loose the advantages of ZTIDrivers.wsf where it copy by PnPID. For example, I have the drivers for my Dell D620 integrated now, but it’s good to know that I probably have good coverage for any D820′s out there since they share mostly the same components.

I’ve seen some MDT implementations that totally throw away the ZTIDrivers.wsf PnPID style in favor of maintaining a manual mapping of drivers to Make+Model. However, I do concede, that there are some drivers out there that “… do not play nicely with others…”, and need to be quarantined somehow, and according to a make+model works well.

Create a Folder Structure in MDT Workbench:

Then in your CustomSettings.ini file, you can add the following: 

DriverGroups001=Common

DriverGroups002=%Make%\Common

DriverGroups003=%Make%\%Model%

DriverSelectionProfile=Nothing

(Note that DriverSelectionProfile=nothing is required if using DriverGroups).

%Make% and %Model% will be auto-expanded in the customsettings.ini file with the Make and Model values from the system BIOS.

• If you have a driver that will work for all Makes and Models, then place it under \Common.
• If you have a driver that is only supported for a single Manufacturer, then place it under \%Make%\Common.
• If you have a driver that only works on a specific Make and Model, then place it under \%Make%\%Model%.

This should allow you to use generic drivers by default, moving drivers to specific makes and models when required.

Keith

Keith was interviewed on the PowerScripting Podcast last week!

MDT 2010 uses Powershell quite extensively for Server Management, and Xtreme Deployment has been developing custom scripts for MDT 2010.

You can hear the podcast here.

- Keith

In MDT deployment I have Bitlocker set to save the recovery key to AD.  However, I am noticing that it is also copying the recovery key to either C: root or the USB flash drive.  How do I control this behavior?

In MDT 2010, the ZTIBDE.wsf script will perform most nasty administrative tasks in the background automatically. That is the beauty of MDT. However, some administrators may wish to control this Recovery File in a manner other than the default, which is to save the file to the C: drive or to a USB Key.

MDT Saves the recovery key even though the administrator told MDT to save the Password into Active Directory, as a backup process, just in case AD was *not* able to save the data to AD.

Disable Key Save

There are two ways to prevent ZTIBDE.wsf from saving the Administrator password in Active Directory.

Either:

Comment out lines 722 – 724 in the ZTIBDE.wsf script. (MDT 2010 Only).

or:

Set the variable in your customsettings.ini file to point to a location that is cleaned at the end of the Task Sequence process:

BDEKeyLocation=%SystemDrive%\minint\

If you don’t save the Password, and the AD backup of the recovery key fails for some reason, you will have no record of the recovery key.

Keith

So, what makes an application installation compatible with MDT (or other scripted installation methods, for that matter)?

Good question.

Microsoft Installer (MSI)

The good!

More and more products are being released lately as MSI packages. Most MSI Packages are easy to automate. For example, I typically use the following parameters:

Msiexec.exe /qb- /l*vx  %LogPath%\<file>.log REBOOT=ReallySuppress UILevel=67 ALLUSERS=2 /i <File>.msi

MDT will easily handle this installation script, and install properly for most MSI packages. Yea!

Non-MSI Packages

However, it is possible that you are working with a custom installation package, or perhaps developing your own. What are the rules necessary to make the package work in MDT?

Rule 1: Provide unattended installs

The install program should have a way to install in a unattended manner. Typically this is done by some sort of command line switch to the installer program or script: /quiet /silent /q whatever. MDT 2010 is a fully automated installation system, and the automation will break if there are any user prompts blocking installation.

For example, if you have a MSI installer package, you can call MSIExec.exe with the /q[bn][-] parameter.

This also equally important for errors. If the install package generates errors, it should provide a method to log the errors to a file for analysis later, rather than prompting the user for interaction with a blocking Error Message Box.

Rule 2: Do not exit until done

The install programs should not exit until all setup tasks have finished. If the setup program returns, yet there are still installation tasks being performed in the background, MDT has no way to determine this. So MDT may continue with the next installation, or perhaps a reboot thus causing conflicts with the installation running in the background.

For example, say you have two installation packages, A.Exe and B.Msi. A.Exe is just a Self Extracting Executable that expands A.MSI to the %temp% folder, and kicks off msiexec.exe. However, A.Exe calls msiexec.exe and doesn’t wait, instead A.Exe promptly exits. MDT does not know what is running in the background, and instead continues installing the next package in the list B.Msi. However since A.Msi is running in the backgound, and MSIExec only allows one installation at a time, B.Msi will fail.

Instead A.Exe should wait until Msiexec.exe /i A.msi has finished.

Rule 3: No rebooting

Sometimes an install package will need to reboot to complete the installation. Reboots, for example, are required to update any file that is already open and in use. It’s a common misconception that you need to reboot to install a device driver, you don’t (unless the driver is in use).

However problems arise if the setup program, when running in an unattended matter, decides to reboot on it’s own, without letting the calling script (in this case MDT), know before hand. It may be a couple of seconds before all processes have a chance to shutdown. It’s possible that MDT may try to continue installing the next program in the order or other cleanup tasks, when it shouldn’t.

Instead, a program should return Windows.h Error Code: 3010 ( ERROR_SUCCESS_REBOOT_REQUIRED ).

This will let MDT know that a reboot is required, reboot the machine, and *then* continue with the rest of the installation packages.

Other Notes

There are a few other notes that I wish I could mention to the authors of installation packages:

• Be aware that the installation may be performed under one user account, but the program may be used under another account. When calling MSIExec.exe, I usually call it with the ALLUSERS=2 property.
• Please make it easy to determine what the unattended/silent installation procedures are. It’s not always easy to determine what the command line parameters are.
• If you have a Self Extracting Executable that calls msiexec.exe, please provide a way to pass logging and other properties (see above) to msiexec.exe.
• Speaking of Self Extracting Exe files that call *.msi packages. Please just provide the *.msi install package, it’s much easier.
• On your web site, please provide direct access to your install packages, rather than going through some web logic. Several populat sites, for example will attempt to offer you *only* the x86 or x64 binaries depending on which platform you are running on, even though I may need both for packaging.
• Please keep the desktop free from links/icons, or provide a property in MSI to disable shortcuts creation on the desktop (I’m talking to you Adobe Reader). I like keeping my desktop clean.
• Speaking of options, please provide ways on the command line to enable/disable most common features.

Keith

Deploying Windows 7 from A to Z.doc
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=dfafb346-97dd-4fca-947e-3d9149834da6

It’s a good introductory reference to MDT, SCCM, and Deployment in general.

Keith

There has been several items posted in the OS Deployment community this week that you should definitely know about:

New KB Article published on USMT and MDT 2010.  This will fix issues when migrating items such as Operating System specific settings like network shares, printers, and EFS certificates.  This is a must have fix for MDT 2010!

The Deployment Guys also posted two great stories this week:

802.1x Security for Windows PE!  This has been a much requested feature to add 802.1x security to Windows PE. 

They also posted a great article on how to migrate time zone settings from an existing computer during an installation:

http://blogs.technet.com/deploymentguys/archive/2010/01/11/setting-mdt-time-zone-variables-from-the-source-os-time-zone.aspx

Enjoy and have a great week!

Luckily, this year, we found most Team Members, and we were disconnecting machines from power before the flood waters came. And were also able to get critical machines out before the moving crews came to cart the equipment out to an undisclosed location during repairs.

For example, here is what the office of Mike Niehaus looked like yesterday.

His entire office is now completely bare, and cleaning crews are doing their thing.

It’s been a crazy start to 2010! Hopefully things will calm down and I’ll start posting more soon.

Keith

http://social.technet.microsoft.com/Forums/en-US/mdt/threads

See ya there!

- Tim

In MDT 2010 when I am in the Deployment Wizard I can select the option to join a domain, enter in my domain and near the bottom I have the option to select my OU with a dropdown menu.
Within my control folder of my deployment share I have a file called DomainOUList.xml that has a long list of all the OUs I want our techs to be able to select from. The structure of the file looks something like this:

<DomainOUs>
<DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
…

How can I make it look like this:
Laptops / Accounting / Calgary / MYDOMAIN
…

I did some investigation, and discovered that MDT lacks the ability to display Friendly names in the Domain OU selection on the dialog box. This is a problem all the way back to BDD 2007.

Something I forgot to do.

Updated change

It s quick change to DeployWiz_Initialization.vbs to make the wizard display friendly names rather than the OU style.

First we introduce a new set of functions:

Function AddItemToMachineObjectOUOpt(item)   AddItemToMachineObjectOUOptEx item, itemEnd function

Function AddItemToMachineObjectOUOptEx(item,value)  Dim oOption

  set oOption = document.createElement("OPTION")  oOption.Value = value  oOption.Text = item  MachineObjectOUOptional.Add oOption  MachineObjectOUOptionalBtn.style.display = "inline"End function

I personally like to add *EX style function like this, it means that we can reduce the number of changed lines in the code, and keep the old version of the function around for compatibility.

Then later on we modify the code to read the DomainOUList.xml:

iRetVal = oUtility.FindFile( "DomainOUList.xml" , sFoundFile)
if iRetVal = SUCCESS then     For each oItem in oUtility.CreateXMLDOMObjectEx( sFoundFile ).selectNodes("//DomainOUs/DomainOU")

        if oItem.Attributes.getNamedItem("value") is nothing then             AddItemToMachineObjectOUOpt oItem.text         else
            AddItemToMachineObjectOUOptEx oItem.text, oItem.Attributes.getNamedItem("value").value         end if     Next
End if

If the DomainOUList.xml file contains a value attribute in the XML file, it will use that for the value, and the node for the Friendly Name:

<DomainOUs>
 <DomainOU>OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD</DomainOU>
 <DomainOU value="OU=Desktops,OU=Accounting,OU=Calgary,DC=MYDOMAIN,DC=AD" > DomainCalgaryAccountingDesktops </DomainOU>
</DomainOUs>

Full sample can be found at:

DeployWiz_Initialization.vbs

Keith

Are you bored? Might be a good utility to build. The PowerShell script [..] posted at http://blogs.technet.com/mniehaus/archive/2009/09/09/sorting-the-contents-of-an-mdt-2010-deployment-share.aspx shows how to rearrange the items in a folder – basically, it just reorders the GUIDs in the group and then saves the modified GUID list. The script only does alphabetical sorting, but some might want to manually rearrange – not terribly easy to do in PowerShell, so it would require a real UI.

For most scenarios, I recommend using Application Dependencies to ensure that applications install in the correct order.

I really didn’t think much of it until recently. When I had some applications that could install stand alone, by themselves, however when both were installed, they needed to be installed in a specific order. If I were creating a CustomSettings.ini file, I would manually ensure that the Applications were placed in order. However, if the user selected the applications from the wizard, then there was no way to ensure the order of the apps unless we modified the order within the ApplicationGroups.xml manually. <yuck>

The blog above shows how application ordering can be done. Simply create a temporary sub-folder, an move the items *in order* to the temporary subfolder and then move everything back.

Solution

This solution should work for sorting both Folders and Application Items within MDT 2010. The application is a simple wrapper around the MDT 2010 Powershell provider, and simply makes calls to move Applications and/or folders using Powershell.

User Interface

The wizard will prompt you for the correct MDT 2010 Deployment Share to use. The deployment share must be visible within the MDT 2010 console on the same machine and using the same user account. If you have not opened any MDT 2010 Deployment shares on this computer and this account, please run the MDT 2010 console, and open your Deployment Share.

When selected, the wizard will display a list of all applications and application folders present on the MDT 2010 Deployment share. You may highlight the Application you wish to move, and use the “Move Up” and “Move Down” buttons to rearrange the order of the application. 

When you are done, press the “Commit” button to run the Powershell script that performs the re-ordering. The applications will not be sorted until the script has finished running.

The MDT 2010 Powershell Provider will do all the necessary work to ApplicaitonGroups.xml on the back end.

You can view the script by saving the results to a txt file.

Restrictions and Limitations

It is recommended that you backup your MDT 2010 deployment periodically,

You can sort the contents of only one folder at a time.

You can not sort Folders within Application entries. Folders are always displayed first.

Link

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

License

This tool is provided “as-is”, with no warranties.
You agree not to hold the author, Keith Garner liable for any damages.
This tool is provided “Free of Charge” for “Evaluation” purposes only.
This tool is copyrighted by the author, Keith Garner, and he retains all
ownership, this tool is not public domain.
You are not permitted to redistribute this tool without the express written
consent of the author, Keith Garner.
The license for this tool can be revoked and/or superseded at any time, by the author, Keith Garner.
Of course, you should backup your critical files before running any 3rd party program downloaded off the internet.

By Keith Garner ( http://keithga.com ) – Deployment Consultant – Dec, 2009
Xtreme Consulting Group ( http://deployment.xtremeconsulting.com )
Microsoft Deployment Toolkit 2010 ( http://microsoft.com/deployment )
Copyright Keith Garner (keithga.com), All Rights Reserved.

Normal Process

Before MDT 2010, the variables collected in the wizard for joining the domain were placed directly into the unattend.xml or unattend.txt file. The OS would then perform the join to the domain during (OOBE) Setup.

This tool came about because of several scenarios that could prevent the machine from successfully joining the domain during Windows Setup. For example. If the network did not have DHCP available, Windows Setup is not programmed with the correct Static IP address settings necessary for the Join Domain feature to contact the domain controller. Later on in the Task Sequence Steps, the ZTINICConfig.wsf script would correctly configure the Network Cards, however it was too late for joining the domain.

So we developed a new script ZTIDomainJoin.wsf as a thin wrapper around the WMI call Win32_ComputerSystem:JoinDomainOrWorkgroup(). If the script sees that the machine is already joined to the correct domain, no problem, it continues on, without any errors. However, if the script sees that a request was made to join the domain, and the machine is *not* in that correct domain, then it will attempt to join the domain and reboot. If there is a failure joining the domain, the script will retry up to 3 times before logging a failure and continuing.

Domain Policies that break MDT

Another scenario where this script works well is when a Domain has a Policy that blocks automation. For example a Legal disclaimer at login, or a rename of the local Administrator Account. Either one of these changes will break MDT.

One possible work around in these scenarios is to *remove* the domain join entries in the unattend.xml and unattend.txt templates on your MDT server, or remove the entries in the ZTIConfigure.xml script. Once removed, the ZTIConfigure.wsf script won’t populate the unattend.txt with the correct variables gathered form the CustomSettings.ini file and/or Deployment Wizard.

Then add the ZTIDomainJoin.wsf script near the *end* of the Deployment Task Sequence. Most of the automation will be complete by that point.

Variables

It takes the following variables:

• JoinDomain – Name of domain to join
• DomainAdmin – User Account used to Join Domain (must have permissions to perform Domain Join)
• DomainAdminDomain – Domain of User account used to Join Domain
• DomainAdminPassword – Password used to Join Domain
• MachineObjectOU – Domain OU to join
• DomainErrorRecovery – [Auto|MANUAL|FAIL]
  • Auto – Automatically try to Join to the domain, reboot and retry if there is a failure.
  • Manual – Stop processing the Task Sequence, and wait for the user to manually join the domain.
  • Fail – Stop the Task Sequence if the machine has not joined the domain.

Notes

Fail could be useful if you have applications that *require* the machine to be part of the domain. If for any reason, the machine failed to join the domain, you could call the ZTIDomainJoin.wsf script with the “Fail” Parameter to crash the installation process if the machine is not joined to the domain.

Manual style is a new feature in MDT 2010, where MDT can “Halt” the execution of the Task Sequence, and allow the user the ability to perform manual steps (without the pesky Task Sequence progress bar, which insists that it remain on “top”). Just follow the instructions to restart the task sequence.

Keith

http://blogs.technet.com/mniehaus/archive/2009/12/06/ris-style-naming-with-mdt-2010-use-a-web-service.aspx

Just wanted to wish everyone a very Happy Thanksgiving!  We thank you so much for following our blog entries and really appreciate all of your feedback so far.

- Tim Mintner

Configuration Manager SP2 updates all of the executables that ConfigMgr uses for an OS Deployment.  One of the files that is used during a USMT migration is called OSDMigrateUserState.exe.  During an OS Deployment this file will be in one of two places.  For a New Computer deployment the file will be on Windows PE.  If you are doing a Refresh from an existing operating system the file will reside in the client’s local CCM directory.  If you just upgraded your site servers to SP2 the client machines won’t have the upgrade OSDMigrateUserState executable.  Prior to SP2, that executable had no knowledge of USMT 4 and the directory structure change of USMT.  So if you want to use USMT 4 in your ConfigMgr deployments you are going to need to upgrade all of your clients to ConfigMgr Sp2 as well!

This is just one example where mismatched SP1 and SP2 versions on your client machines will cause issues with Windows 7 deployments.  As a best practice always make sure you have SP2 fully deployed to all of your site systems AND all of your client computers before starting a Windows 7 deployment.

-Tim Mintner

Dynamic Deployment

The entire purpose of the MDT Configuration Database is make your deployments dynamic.  Now dynamic means many different things to many different people so lets define that a bit.  MDT’s goal is to reduce administrative overhead as much as possible.  There has been a lot of advancements in the past few years to allow you to reduce the number of images in your environment in many cases down to two images, one for X86 and one for X64, for your client and server operating systems.  Reducing the number of images of just one aspect to reducing the overall administrative overhead with a deployment.  With both MDT Lite Touch and System Center Configuration Manager OSD, the number of task sequences in many environments have expanded or the number of steps in the task sequence have increased as administrators add conditional statements in the task sequence for installing specific applications or installing drivers.  The MDT Configuration Database is meant to not only reduce the number of images but allow you to use a single task sequence and have that task sequence change dynamically during the deployment based on information retrieved from the database.

Understanding MDT Variables

Before we delve too deeply into the details of the database, we first need to understand how variables work inside of MDT.  Everything that is configured inside of the task sequence in MDT matches a variable that can be configured with a value.  Let’s take a look at the Validate step in the task sequence:

In this step you can see that you can configure the minimum memory, minimum processor speed, the minimum hard drive space required, and whether or not to deploy the image based on if the existing system is running a Client or Server Operating System.  Each one of these configuration items can be configured as variables.  Respectively for these items the variables are:

• ImageMemory
• ImageProcessorSpeed
• ImageSize
• VerifyOS

So how was I able to determine which variable to use?  The MDT documentation does good job of listing all of the variables that can be set as well as limited descriptions of each of the variables.  However if you just want to get a quick list of a specific step in the task sequence you can open up your configured task sequence XML file and look at that specific step.  For example the validate step looks like the following in the XML file:

<step type=”BDD_Validate” name=”Validate” successCodeList=”0 3010″ description=”" startIn=”" disable=”false” continueOnError=”false”>
  <defaultVarList>
    <variable name=”ImageSize” property=”ImageSize”>0</variable>
    <variable name=”ImageProcessorSpeed” property=”ImageProcessorSpeed”>800</variable>
    <variable name=”ImageMemory” property=”ImageMemory”>512</variable>
    <variable name=”VerifyOS” property=”VerifyOS”>CLIENT</variable>
  </defaultVarList>
  <action>cscript.exe “%SCRIPTROOT%\ZTIValidate.wsf”</action>
</step>

Here you can see in the XML file all of the variables that are associated with the Validate Step.

So now that you have the variables how would you use them?  One possible way of using the variables would be to set them in the customsettings.ini file.  This is configured by going to the Rules tab in the properties of the Deployment Share or you can just edit the file using notepad by going to the Control directory in the DeploymentShare.

Let’s say that you wanted to set the minimum memory to 1 GB instead of 512 MB.  To do that you could edit the task sequence or you could add the following line to the customettings.ini file:

Properties = ImageMemory

ImageMemory = 1024

“Note – to see a full list of variables that MDT can configure open up the ztigather.xml file in the DeploymentShare\Scripts folder.  In this case ImageMemory is not defined in ztigather.xml so you can add it by adding ImageMemory to the Properties line in the customsettings.ini”

Now when the validate step runs it will use the value specified in the customsettings.ini instead of the value in the task sequence.  In most cases the first value for a variable that gets set will take precedence over any other value. 

Adding variables directly to the customsettings.ini is a good start to doing dynamic deployments but if you add in all of the variables you need for every scenario directly into the customsettings.ini you will quickly replace the administrative overhead of managing a huge task sequence with lots of conditional steps with the administrative overhead of managing a huge customsettings.ini file.  You also now have to worry about replicating the customsettings.ini out to many different sites, locations, or USB drives.  To simplify both the management of the task sequence and the customsettings.ini file you should use the MDT Configuration Database to store your variables.  So lets now look at how to set up the database.

Creating the MDT Configuration Database

To create the database you need to navigate to the Database node under the Advanced Configuration node in the Deployment Workbench.  Note if you are using ConfigMgr 2007 you will still need to create and manage the database using the Deployment Workbench.  MDT can use any Microsoft SQL Server from SQL Server 2000 – SQL Server 2008 including SQL Server Express.  To create the database right click on the Database and choose New Database.  You will be prompted for the following:

• SQL Server Name – name of your SQL server
• Instance – only needed if you installed SQL without using the default instance or you are using SQL Server Express
• Port – only needed if you are using TCP/IP sockets (not recommended)
• Network Library – Named Pipes or TCP/IP sockets

Let’s talk a little bit about the Network Library.  It is HIGHLY recommended that you use Named Pipes over TCP/IP sockets.  Unfortunately Windows PE does not have the ability to use integrated security with TCP/IP sockets.  That is if you want to use an Active Directory or Windows username and password to connect to the database you must be using Named Pipes.  If you use TCP/IP sockets you would need a SQL user account and password. 

The next item you will need to provide is the SQL Share.  That is a share that MDT uses to authenticate to the server so that integrated security can be used.  The share does not need to contain anything, it just needs to exist on the SQL Server. 

Now that you have created your database by completing the wizard.  You need to configure the CustomSettings.ini to use the database.  To do so again right click on the Database node and choose Configure Database Rules.  This will start another wizard. For right now just click on Next until you have completed the wizard and your customsettings.ini file will be fully configured to query the database during your deployment. Note if you are using ConfigMgr 2007 with MDT integration, you will need to take the customsettings.ini and place it in your settings package.

Add items to the Database

So now that you have created the database and configured the customsettings.ini to query the database.  Expand the Database node and you should see a screen like the following:

MDT allows you to configure settings based on the following:

• Computers – identified by MacAddress, UUID, or Serial Number
• Roles – arbitrary grouping computers (Accounting, Finance, IT, etc.)
• Locations – defined by default gateways
• Make and Model – Computer manufacturer and model specific settings

So lets configure a setting in the database that states for all Dell Latitude E5500 computers the Display Resolution should be 1440 X 900.  To do that we would add an entry under Make and Model.  Right click on Make and Model and choose New.  Enter the following:

• Make – Dell Inc.
• Model – Latitude E5500

Click on the Details Pane and you should see a screen like the following:

Find Xresolution and set the value to 1440.  Also set the Yresolution to 900.  By clicking on Apply the values will be set and now when the deployment occurs all Dell Latitude E5500 laptops will automatically get the display resolution set.  There is nothing to configure in the task sequence or in the customsettings.ini because we already configured the customsettings.ini to query the database earlier.

This is a very simple example of one particular setting.  In future posts I will cover more scenarios such as Make and Model application selection, driver selection and Location, Role, and computer specific settings.

Updating your Boot Image

The only thing left for you to do is verify that your boot image contains ADO (Active-X Data Objects).  ADO is needed to query a database.  In Lite Touch, ADO is configured by default.  To verify this go to the properties of your Deployment Share and click on either Windows PE X86 Components or Windows PE x64 Components and verify that ADO is selected under Feature Packs.  If it is not, select it and Update your Deployment Share.

For ConfigMgr you will need to create a custom boot image using the MDT provided wizard.  Right click on Boot Images and choose Create Boot Image using Microsoft Deployment and walk through the wizard making sure you choose ADO under Feature Packs.

Summary

This post just explained the very basics of why you would want to use the database and how you can set your database up very quickly.  There is a lot more that the MDT Configuration Database can provide and automate to make your deployments truly dynamic.  Make sure you check back for more posts in the future on some intermediate and advanced posts on the MDT Database.

-Tim Mintner

Lite Touch Installation

USMT 4.0

In order to user MDT 2010, you must install the Windows AIK for Windows 7.  The Windows AIK now includes USMT 4.0 as a feature of the AIK so there is no longer a separate download required for USMT.  When you create your Deployment Share inside of the Deployment Workbench, MDT will create a folder at the root of the deployment share called USMT and copy the USMT files into that folder. 

Refresh Scenario

A refresh scenario means that you are deploying an Operating System to a computer that already has an existing Operating System using a task sequence created with the Standard Client Task Sequence.  The process is started from within the current Operating System.  In a Refresh scenario, the disk is not formatted or partitioned so in most cases, the user data can be saved locally on disk saving time and network bandwidth.  During a Lite Touch Installation there are only two steps in the task sequence step that uses USMT.  The first step is called Capture User State and the second step is called Restore User State.  This step will run a script called ztiuserstate.wsf.  The actions that ztiuserstate will be performed are determined by the following factors:

• The Operating System being deployed
• The values provided in CustomSettings.ini for UserDataLocation and UDDIR and UDShare
• The values provided in the Client Deployment Wizard used to start the Task Sequence

If ZTIUserState determines that you are deploying Windows XP it will not be able to use USMT 4.0 and will try to use USMT 3 for the user state migration (more on that later).  If you have specified that UserDataLocation = Network and you have also specified a UDDIR and UDShare in the customsettings.ini then USMT will migrate all of the files to a compressed file at the network location you specify.  Also if you provide a network location in the Client Deployment Wizard, USMT will migrate the user data to a compressed file at the network location you specify.  If UserDataLocation = AUTO and you are not deploying Windows XP, the ztiuserstate script will keep the data local in the MININT folder using hard-link migration.  There is no need to do an estimate because the hard-link migration process only requires 250 MB of space on the disk and if you didn’t have that much the process would fail in the validate step.

Replace Scenario

A Replace scenario is made up of two task sequences.  The first task sequence is based upon the Standard Client Replace template and the second task sequence is based on the Standard Client task sequence template.  The first task sequence is initiated from within the existing Operating System like in a Refresh scenario.  The USMT capture process in a Replace scenario works just like a Refresh scenario with one exception, in a Replace scenario the user data can not be stored locally so you must provide a network location to store the User Data.

The second task sequence is started by booting into the Lite Touch boot image and doing a New Computer deployment.  The Client Deployment Wizard will ask if you want to restore user state and where the user state is stored.  The Restore User State step in the task sequence would then use USMT to restore the user state to the computer being deployed.

USMT 3.01

So if USMT 4 has all these new cool features, why would you ever still want to use USMT 3?  Well USMT 4.0 cannot restore user data onto Windows XP.  Loadstate.exe from USMT 4.0 will not run on Windows XP.  So if you plan on migrating user data to Windows XP you will still need to use USMT 3.01.  To use USMT 3.01 you will need to download it from Microsoft.  The Deployment Workbench has direct links to both the 32 bit and 64 bit versions of USMT 3.01 in the Components section.  After downloading the installation files you will need to place those installations files in the Tools\X86 folder in your Deployment Share for 32 bit installs and Tools\X64 for 64 bit installs.

Refresh Scenario

In a Refresh scenario,the Lite Touch Installation process will be able to determine if the Operating System being deployed is Windows XP.  The same factors mentioned above are applicable for USMT 3.01.  If the Operating System is Windows XP, the ztiuserstate script will install USMT 3.01 on the computer and then do an estimate to determine how much user data is on the computer.  If the amount of user data is less than the amount of disk space needed then ztiuserstate will store the user data on the local disk in the MININT folder.  If there is not enough space then the user data will be stored in the UDSHARE and UDDIR locations.

Replace Scenario

A Replace scenario is a little trickier.  The Lite Touch Installation process won’t be able to automatically determine what Operating System you are going to be deploying because the Operating System is going to be deployed with a separate task sequence potentially even on a different computer.  In a Replace scenario ztiuserstate will use USMT 4.0 by default, however there is one problem with that.  User Data backed up with USMT 4 cannot be restored with USMT 3 and USMT 4 cannot be run on Windows XP!  So if you are replacing a Windows XP computer with another Windows XP computer, how can you make sure that USMT 3.01 is used?  To handle that scenario, MDT has a variable called USMT3.  To force the Replace scenario to use USMT 3 you would enter the following into your customsettings.ini:

USMT3 = YES

Zero Touch Installation (ConfigMgr/SCCM)

The USMT process with ZTI is slightly different than the process with Lite Touch.  The steps in a ZTI task sequence look like the following for capturing User State:

The MDT integrated task sequence uses the built in actions for Request State Store, Capture User State, Release State Store, and Restore User State.  The Ztiuserstate.wsf script is only used in one step: Determine Local or Remote User State. 

With ZTI, the version of USMT that is used is solely dependent on the USMT package that is associated with the Determine Local or Remote User State, Capture User State, and Restore User State steps in the task sequence.  You will need to create a package that contains the files for either USMT 3.01 or USMT 4.0.  Thankfully when you walk through the wizard to create the MDT task sequence in Configuration Manager, the MDT provided wizard will create the USMT 4.0 package for you automatically.  If you want to create a USMT 3.01 package you will need to download and install USMT 3.01 on a client computer and use the installation folder in the Program Files folder as the source directory for your package.

USMT 4.0

The version of USMT that you are using for your USMT package will determine what actions the Determine Local or Remote User State will perform.  If you are using USMT 4.0 then the Determine Local or Remote User State will set the variable needed to do a hard-link migration and also set a variable called USMTLOCAL =TRUE.  The Request State Store and Release State Store steps in the task sequence have a condition on them so that they will only run if USMTLOCAL is not true.  That means if you are using USMT 4, the user state will always be local and the State Migration Point will never be used.  If you would like to use the State Migration Point instead of using hard-link migration then just disable the Determine Local or Remote UserState step in the task sequence

USMT 3.01

If you are using USMT 3.01 then the Determine Local or Remote User State step will perform a USMT Estimate to determine if there is enough space locally on the disk to store the user data.  If there is enough space locally the variable USMTLOCAL is set to TRUE.  Again the Request and Release State Store steps are conditional on this variable so if there is not enough room locally the State Migration Point will be used

Summary

Whew..that is a lot of information.  As you can see, MDT tries to cover all of the scenarios with USMT whether you are using USMT 4.0 or still deploying Windows XP and need USMT 3.01.  Enjoy and happy deploying!

-Tim Mintner

In my MDT 2010 Litetouch environment, how do I identify which hardware devices are not being installed with the correct drivers?

Introducing the “Yellow Bang” tool!

Yellow bang is a slang term used to describe drivers that have “problems” represented by a Yellow exclamation point ( ! ) in the Windows Device Manager:

Now typically, most IT professionals will be using SCCM, that can gather from each machine in the environment, and query computer status in a more structured way. This solution is only designed for IT departments that are using Litetouch only.

New Tool

Use this tool in MDT 2010 to identify all drivers that have problems on a client machine running MDT Litetouch. These are the drivers that have a Yellow Exclamation point (Bang) in the Windows Device Manager. Simply add this script to your …\scripts\ directory, and add the script to your task sequence.

For each driver that is not working properly the details are written to the bdd.log and the ZTIYellowBang.log file for later review.

Example Output

For this example, I have a HP Laptop that is missing a driver for the ACPI\HPQ0004 device, which is the “HP 3D DriveGuard”. <meh>

Microsoft Deployment Toolkit version: 5.0.1641.0
SUCCESS: 0: Create object: Set oScriptClass = New ZTIYellowBang  DRIVER_ERROR [28: Device drivers are not installed.]
DeviceID [ACPI\HPQ0004\3&33FD14CA&0]
HardwareID [ACPI\HPQ0004]
HardwareID [*HPQ0004]
CompatibleID []
ZTIYellowBang processing completed successfully.

Steps

Simply copy the ZTIYellowBang.wsf script to the Deployment Share under the …\scripts\ directory. Then add the ZTIYellowBang.wsf script as a Step to your Task Sequence:

Cscript.exe “%ScriptRoot%\ZTIYellowBang.wsf

Links

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

Keith

ProfessionalPlus.exe /extract:c:\extractedfolder

Now that you have extracted the files you can import Office 2010 directly into MDT 2010 as an application.  Go to the Applications node and choose a New Application, choose Application with Source Files and click on Next.  Enter in the Application Name information and click on Next.  For the source files choose the extracted folder you created earlier and click on Next.  Enter a name for the folder and click on Next.  For the command line just enter setup.exe and click on Next.  Click on Next on the summary screen and the Application will be created.

Now that you have Office 2010 imported as an application you can now go to the Properties of the Application you Created and you should see a new tab that looks like the following:

If you want to customize the installation you can choose to use the Office Customization Tool.  For example to set the product key for the installation you would navigate to Licensing and User Interface as shown below:

Just enter your product key and go to File, Save to save your changes.

Now you are ready to install Office 2010!

- Tim Mintner

What is the correct way to use ZTIGroups.wsf, the Restore Groups MDT action, to populate local group membership of groups that have a space in the name?  As a test I’m trying to use CustomSettings.ini to add domain users/groups to the local Remote Desktop Users group.  I didn’t find a lot of detail in the MDT docs on doing anything other than Administrators or Power Users. 

I had done some work in ZTIGroups.wsf earlier this year. We added the ability to save the list of group names, and create the groups dynamically during restore time, in addition to the ability to add members to the group.

I had done testing with ZTIGroups.wsf, however I didn’t recall testing with the group “Remote Desktop Users” group. How did that work?

I tried running a command:

C:\>cscript ZTIGroups.wsf   /Groups1:"Remote Desktop Users"   "/Remote Desktop Users1:pickett\keith.garner"   /restore /Debug:True /DebugCapture

While looking at the output I noticed that the script was looking for a new property: “RemoteDesktopUsers”, where did that come from?

It turns out that the ZTIGroups.wsf script will look for members using the properly name derived from the name of the group being populated, *without* the spaces in the property name.

So running a deployment with the following properties in the customsettings.ini worked:

Groups001=Remote Desktop Users  RemoteDesktopUsers001=pickett\Keith.Garner

Keith

To fix this you would, right click on the DeploymentShare and choose Update.  Then you would choose Completely regenerate the boot images as shown below:

Now that your boot images are updated you will either need to burn new CDs or re-import the boot images into WDS

- Tim Mintner

FAILURE ( 7705 ): command: FORMAT.COM C: /FS:NTFS /V:OSDisk /Y /Q   FAILED with error = 4

The first step I had him do was reboot the computer and run through the steps that the script ztidiskpart runs manually.  Those steps are:

1. Boot in Windows PE
2. Press F8
3. Run diskpart
4. select disk 0
5. clean
6. create partition primary
7. assign letter=c:
8. active
9. exit
10. format c: /fs:ntfs /v:OSDisk /Y /Q

Again the format command failed.  He then immediately tried the format again and it worked.  So this was truly an intermittent problem.  My suspicions went up that this was driver related and had him check what kind of storage controller is in the laptop and it was the lovely Intel Matrix Storage Driver.  I checked Intel’s web site and had him download the new driver from here: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17882&lang=eng 

After removing the old Intel Matrix Driver from his Deployment Workbench, adding this one back in, and regenerating his boot images it worked!

It was a great lesson for both of us and now hopefully you won’t have to go through as many steps.  If you ever run into any intermittent format or partitioning problems start investigating the storage driver!

- Tim Mintner

This is a Microsoft Deployment Toolkit 2010 Build-out (sometimes called Hydration) system.

It starts off as a small 3MB *.zip file. The MDTBuildout.exe program will automatically download all required files (around 10GB of files), create a Virtual Machine running Windows Server 2008, and build out a functional MDT 2010 system. All the files downloaded are publicly avaiable over the internet.

This sample is *not* designed for production environments. The Server OS and Windows 7 Client OS’es downloaded are time-limited Evaluation versions of Microsoft OS’es, and not intended for production environments. If you would like to setup a functional system for your corporate environment, please let us know.

Xtreme Consulting Service’s Deployment Team is ready to assist you with your deployment needs.

Features

When complete, this Buildout (Hydration) system will create:

• A Virtual Machine running Windows Server 2008 (R1) x86 Server Standard.
• MDT 2010, with all dependencies installed (including WAIK).
  • OS’es: Server 2008 R1 x86, Windows 7 x86 and Windows 7 x64.
  • Microsoft Office 2007 Enterprise Evaluataion Version.
  • Applications: 7-zip, Foxit PDF Reader, MacroMedia player, Silverlight player, SQL Server 2008 Express, Sun Java Runtime, Video Lan Player, Windows Debugger (windbg).
  • Sample Driver package: Intel Chipset drivers.
  • Sample Packages: Windows 7 Language Packs, Hyper-V Drivers, Remote Server Administration Tools (RSAT)
• A Windows 7 Media build DVD image with Office 2007.
• It will also enable a PXE/WDS Service for servicing MDT 2010 WinPE Images (no Domain Controller required).
• A blank Virtual Machine ready to perform a capture of Windows 7 back to the MDT 2010 server.

Requirements

• Your machine must be running windows with a version of either Hyper-V (for Windows Server 2008) or Virtual PC 7 (for Windows 7).
• Your machine must have at least 2GB of ram, and 60GB of free hard disk space.

Walkthrough

Download the MDTBuildout.zip file to your local machine and expand the contents to their own folder. You should see the manual: MDTBuildout.rtf and the Wizard Wrapper MDTBuildout.exe. Go ahead and launch the MDTBuildout.exe.

The MDTBuildout.exe wizard will guide you through the process of creating the virtual machine and downloading the necessary files to get it started. The wizard will create to Virtual Machines:

MDTVirtualServer – This is the Virtual Server that will host MDT 2010. It takes a couple of hours to setup, depending on the speed of your network connection.

MDTVirtualClient – This Virtual Machine will be used later on to capture a reference image of Windows 7 with Office 2007.

It is recommended that you use the default settings during the MDTBuildout.exe wizard, although, you can override the settings if required. Be sure to give the Virtual Machines enough memory, place the *.VHD files on a disk with 40+GB of space free, and select the Virtual Networking adapter with internet access.

When you select “Build” the wizard will begin the process of downloading the Windows Server 2008 Eval *.iso file to the local machine, this file is about 1.8GB. When done, the wizard will automatically create the virtual machines with the required parameters, and start the process. You can continue to watch the progress in the VM window.

The entire build process can take several hours depending on the speed of your network connection. Let the install run. When complete, you should see a dialog showing the status.

The password for the MDT Server is: P@ssword

When complete, you can start the MDT 2010 Workbench (start –> Microsoft Deployment Toolkit –> Deployment Workbench), and view the components added to the system.

The deployment share should be at: c:\deploymentshare

The media share should be at: c:\media

If you wish, you can start the PXE server, to allow other computers on the network to boot into MDT 2010, this is a great way to upgrade machines on your corporate network in a “self-service” fashion. To enable the pxe server, run the command “net start wdsserver”. WARNING: The PXE/WDS Server running on the Virtual Machine *will* conflict with other PXE/WDS servers on the network. Please ensure that you are the *only* PXE/WDS server on the network before starting! This is why the WDS service is disabled by default.

You can also burn the contents of the Win7 Media ISO to a DVD drive. Or perhaps copy the *.iso file to the local machine.

Use this server to evaluate MDT 2010 and try deploying Windows 7 (Evaluation Version), to your test lab.

When ready, you can boot the MDTVirtualClient Virtual Machine, using either the Win7 Media ISO image, or PXE/WDS. The Client Virtual Machine has been specially configured to auto install Windows 7 and upload the captured image back to the MDT 2010 Server in a completely hands off fashion.

More documentation, walkthroughs, and videos to follow.

Link

<Edit> No longer available.

Keith

Here is the basic process that should help troubleshoot the problem:

· Windows PE boots up and runs litetouch.wsf

· Litetouch.wsf calls ztigather /inifile:bootstrap.ini and the DeployRoot value is read from the bootstrap.ini

· Litetouch.wsf then makes a call to connect to the DeployRoot using the wizard credentials or the credentials in the bootrap.ini

· Litetouch.wsf then calls ztigather and reads the values from the customsettings.ini (note if a full Media Deployment is inserted in the DVD or USB drive the customsettings.ini will be read from that location instead of the DeployRoot)

· If the DeployRoot value has changed In the customsettings.ini, the value is updated and Litetouch.wsf tries to connect to the DeployRoot

· The wizard is started and the tasksequences.xml file is read from the DeployRoot

· If the DeployRoot does not contain a valid tasksequences.xml then a blank Task Sequence wizard is displayed

Steps to troubleshoot:

· Open BDD.Log

· Search for the value DeployRoot and do a Find Next to make sure that all values in the log file for DeployRoot are the same.  If they are not then there is some setting either in CustomSettings.ini, the database, or on local media that is changing the value

I passed!!!

I’ve been an in-depth Microsoft technical guy for 14 years now, yet I’ve never gotten around to actually taking any Certification test before.

And I figured that since I was on the Dev team for MDT 2008, I’d start with 070-635 (Microsoft Deployment Toolkit 2008, Desktop Deployment). I took the test cold, no studying.

It was kind of weird going back and taking the test for MDT 2008. There have been two product releases since then, MDT 2008 Update 1 and MDT 2010. And I’ve been working on Windows 7/MDT 2010 components now for about a full year.

I’d take some more exams, but I had to pay for this one out of my own pocket. Perhaps in the new year.

Tim Mintner mentioned once that he took this test as well. Which wasn’t really fair, since he helped write the questions. :^)

Keith

During the development cycle for MDT 2010, one component that had constant change was the Windows Automated Installation Kit. MDT requires several components from the WAIK to perform correctly, so we were constantly upgrading.

One of the components, the WIMGAPI.dll was particularly nasty. The WAIK installer would set the permissions on the file so regular users could not delete it, and the intra-build upgrades didn’t replace the file automatically. Luckily, if you are using the final released (RTM) version of the WAIK, and upgrading from a previously released version, you should be OK.

Why are these files so hard to delete?

Windows protects some installed files by giving only the “Trusted Installer” account access to the file, and explicitly denying everyone else access, including administrators and the SYSTEM account.

Running the icacls.exe command on wimgapi.dll reveals:

NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

The problem is that normal users and administrators don’t have full access to the file and are not allowed to modify the permissions.

How to Modify “Trusted Installer” files

If you ever find yourself in the situation where you need to modify/delete files that are “trusted installer” protected, here is what I do:

1. Start up an elevated command prompt (with administrator privileges).
2. Run “icacls.exe <file>” to see the current permissions.
3. Run “TakeOwn.exe /f <file>” to change ownership.
4. Run “icacls.exe <file> /reset” to change permissions.
5. Run “icacls.exe <file>” to display the new permissions.

Example:

Keith

• Boot from Litetouch CD Boot image. This is about a 200MB *.iso image that allows you to connect to a deployment share on the network.
• Network Booting. You can also take the Litetouch Boot image and PXE boot over the network if you have a WDS (Windows Deployment Services) Server available.
• Media Builds. You can also copy a subset of the deployment share onto a DVD drive for installs that do not have any network access or slow network access.
• OEM installs. If you have a Media Build ready, MDT also has the ability to prepare the DVD for OEM installation.
• USB Flash/USB Hard Disk. If you have a USB Drive, you can prepare the drive to boot either the Litetouch Boot Image, or a Litetouch Media image to boot off of USB. This is helpful if you are trying to deploy an image that is larger than 8GB, the largest DVD Dual Layer size.

Booting from CD/DVD and from the hard disk are fairly straight forwards. But booting from Network and/or USB requires a little bit of work.

Just a few years ago, in order to boot from other devices, each user would need to ensure that the local machine was configured to boot from these other devices by going into the BIOS at the start of the computer boot-up sequence. This method had problems, since it’s possible to configure the machine to boot into these other devices and leave the machine in an unsecure state.

I had a case recently where a user re-configured the boot order to boot from a USB Hard disk first for a “New Computer” install from USB. Unfortunately, he forgot to change the BIOS boot order back to the default settings after he initiated the install, so after the MDT 2010 Litetouch “New Computer” WinPE phase was complete, it did not reboot into the OS, it booted back into WinPE.

Thankfully, most modern BIOS’es have the ability to boot from these other devices without permanently changing the boot order into an unsafe configuration.

Recommended configurations:

So, what if the boot order settings of your BIOS have been modified beyond recognition?

For most machines, I recommend the following boot order:

• Boot from CD-ROM
• Boot from Hard Disk
• Boot from Network
• Everything else

For Security Paranoid people, I recommend:

• Boot from Hard Disk
• Boot from CD ( Remove from the list if possible )
• Boot From Network ( Remove from the list if possible )
• Everything else

For Network/Lab machines that Boot from WDS, you could also do:

• Boot from Network
• Boot From CD-ROM
• Boot From Hard Disk
• Everything Else

Dynamic Selection of Boot Devices

Instead of modifying the boot order in the BIOS, I recommend changing the BIOS boot order dynamically per boot. Most Modern PC’s support the ability to dynamically select the BIOS boot order during boot up using some combination of F12, F10, or sometimes: F9

For example, my Dell machines, pressing F12 should bring up a menu of all available boot devices.

My HP machines have a similar option, pressing F9 should bring up a menu of available boot devices as well.

Keith

I wrote it back in 2007 when I was working for Microsoft IT. At the time, Microsoft IT didn’t have a good Update/Patching story, there were some tools that ran occasionally as part of Group Policy, but it was hard to tell if a given machine was up to date, and what the correct manifest of patches for a given machine were. I was setting up a Litetouch deployment server and wanted to ensure that each machine was up to date when litetouch was done.

ZITWindowsUpdate.wsf was designed to fulfill a specific task: Update the local machine to the latest Updates/Patches/Drivers from Windows Update (WU), Microsoft Update (MU), or a WSUS server.

When the script works, its great. Most of my Dell and HP test machines have great Windows Update Driver support, so I have to spend less time updating my MDT 2010 Out-Of-Box driver folder with the latest drivers. I also don’t have to spend too much time staying up to date on the latest patches from Microsoft (hello patch Tuesday). The script does a good job downloading the latest/greatest patches from Microsoft.

However, things are not always perfect, and it does require some work once in a while. This might be due to new packages that don’t install properly, or other problems.

Most of the changes to ZTIWindowsUpdate.wsf between MDT 2008 and MDT 2010 were changes to improve the robustness of the system if the package failed to install.

One example was a specific patch from Windows Update that would try to install, and fail. However it reported back to the system that it passed. The script would keep retrying, and get into an infinite loop. We added some better logic to ensure that ZTIWindowsUpdate would not get into those kinds of infinite loops.

By default, ZTIWindowsUpdate.wsf will install everything from the WU/MU servers. There are some exceptions:

• If the package says that it “can” request user input, then we skip over the update. ZTIWindowsUpdate.wsf should be fully automated, and User Input could break automation. I added this primarily for IE7 and IE8 updates. So be sure you have IE8 install packages elsewhere if you require IE8.
• We skip Windows Vista and Windows 7 Ultimate “Language Pack” files. It’s just too much data to download.
• We can also skip packages for a specific KB article, or by Package ID.

Manually Excluding Updates

Occasionally you may come across cases where you need to exclude specific packages from installing on ZTIWindowsUpdate.wsf.

First step is to find the bdd.log or ZTIWindowsUpdate.log file generated by your test machine. We need the log files to know which Update ID numbers to exclude. While Microsoft Deployment is running, the log will be located at c:\minint\smsosd\osdlogs, however after the installation has finished, the logs could be uploaded to your SLShare Log Share, or to c:\windows\temp\deploymentlogs.

At the start of the log there will be some connection/diagnostic information. ZTIWindowsUpdate.wsf needs to connect to Microsoft Servers to ensure that the runtime binaries are up to date (yes, even Windows Update needs updating). You’ll want to look for the line “Start Search…”, then we see a list of packages:

Start Search...  INSTALL - d49c3450-6646-4fbc-9e67-da7947bf3f13 -
Update for Microsoft Office Outlook 2007 Junk Email Filter (KB974810)   
  SKIP  - 254a9c2e-0431-4a37-b977-f1652d9d4b4d -
Windows Malicious Software Removal Tool x64 - October 2009 (KB890830)   

Here we see a list of all the relevant packages Windows Update has returned for this machine.

• First column is either “INSTALL” or “SKIP”, all items marked “INSTALL” are to be installed, all items marked “SKIP” are *not* going to be installed.
• Then we see a 36 character GUID – This is the unique ID For the package. Please note that x86 and x64 packages of the same fix may have different ID’s.
• A short description of the fix.
• And sometimes we may have also have the associated Microsoft KB article.

Once you have identified the package you wish to exclude in the future, you can add the ID or the KB article in your customsettings.ini file. Test the install again to ensure that all packages are marked as “SKIP” in the log file, and you are good to go.

Here are some examples of ID’s that I included recently in my customsettings.ini file.

WUMU_ExcludeKB1 = 941160  ; Ultimate Extras WUMU_ExcludeKB2 = 928416  ; .NET Framework 3.0 WUMU_ExcludeKB3 = 955020  ; Add En/De words to dictionary WUMU_ExcludeKB4 = 905474  ; Windows Genuine Advantage ; Bad AuthenTec Driver, blocks installation.
WUMU_ExcludeID001 = 3a130260-44f8-4769-9b9e-57c3bbd4ce45

Other

One trick I use often when testing ZTIWindowsUpdate.wsf directly is to use the /query flag.

net use z: \\server\deploymentshare$
cd /d z:\scripts
cscript \ztiwindowsupdate.wsf /query

When you specify the flag, it will only query windows update, it won’t download or install anything. This is helpful if you need to test your WUMU_ExcludeKB or WUMU_ExcludeID entries to see if they match.

Keith

So for your review, I have included a sample for 7-zip.

Link

7-zip.MDT.ps1

About 7-zip

7-zip is a popular file archiver that supports numerous file formats, and is available for free over the internet.

What also makes 7-zip a great example, is that you can download the *.msi package directly over the internet.

The command line MSI installer, msiexec.exe, supports the ability to install packages over http://, so there is no need to download the package first. Note that this could cause problems if you try to install 7-zip on a machine that does not have full internet access.

Typically, in real world MDT Deployment Shares, I would download the packages first, but this makes for a fine example.

Persistent Drives

For MDT 2010, the concept of the “Deployment Share” ( Distribution Share, or Distribution Point) has been abstracted even further than that in MDT 2008. A ‘”Deployment Share” can be a Network Share, a Local folder, and it doesn’t even have to be on the same machine as the MDT 2010 Workbench Console is currently running on.

It’s also possible to keep track of multiple “Deployment Shares” within a running MDT 2010 Workbench console. The “Deployment Shares” that are added to the MDT 2010 Workbench Console are called “Persistent-Drives” because they are persisted across Workbench sessions.

Behind the scenes, you can see the settings by looking at the configuration file:

“%appdata%\Microsoft\Microsoft Deployment Toolkit\user.config”

Which Drive to use

I wanted to develop a script that you could run as-is and have the contents instantly added to your MDT Deployment Share.

However, since a machine can have multiple Deployment Shares, or none at all, the question became:

How do we find the default MDT Deployment Share, if any exists?

The best way I figured was to use the Persistent Drives defined in the MDT 2010 Workbench. The Persistent Drive meta-data could be easily read using the powershell cmdlet: “Get-MDTPersistentDrve”.

If more than one drive was defined in the MDT 2010 Workbench, then we just select the first one. Typically defined as “DS001:”

Header

With all powershell scripts we start off with a list of parameters:

#  MDT 2010 Exported Application
#  By Keith S. Garner (KeithGa.com)
#  7-Zip File Archiver 4.65   
param(
 [string]$Folder = "Applications\Common", 
 [string]$DPDrive = "DS001",
 [string]$DPShare = "\\$env:ComputerName\DS$",
 [switch]$Confirm,
 [switch] $Verbose,
 [switch] $WhatIf )

Here the Administrator is given the ability to override several defaults:

• Folder – This is the folder where the Application will be placed in the workbench, and displayed in the Deployment Wizard.
• DPDrive – This is the name of the Deployment Drive used in Powershell. Unless defined as something non-standard by the Administrator, it should be DS001:
• DPShare – This is the UNC path to the Deployment Share, typically a Networking Share. It’s only needed if there are no persistent drives defined.
• Confirm, Verbose, WhatIf – For more information look here.

Restore

Once started, the script will need to load the MDT 2010 environment into powershell, and restore everything:

if (!(test-path "$($DPDrive)`:\"))
{
 Add-PSSnapin Microsoft.BDD.PSSnapIn […]
 restore-MDTPErsistentDrive […]    
 if ((!(test-path "$($DPDrive)`:\"))
     -band (test-path $DPShare)) {
   New-PSDrive -Name $DPDrive -PSProvider `
       MDTProvider -Root $DPShare […]
 }
 if (!(test-path "$($DPDrive)`:\")) {
   throw "$DPDrive not Mounted/Persisted."
 }
}

First of all, we don’t do anything if the DPDrive is already visible to Powershell. This means that a calling “wrapper” script can perform the restoration of the Persistent drives once, and we won’t need to perform it each time for every application being imported.

Otherwise, we add the Powershell Snapin, and restore any MDT 2010 Persistent Drive(s).

We then test for DPDrive, if there is still nothing there, then we mount a new DPDrive to the Deployment Share given.

We test for DPDrive again, if there is *still* nothing there, then we fail.

Folders

If we are importing the application into an Application Folder that does not exist, we must first create the folder.

foreach($NewPath in "$($DPDrive)`:\$Folder")
{
  if(!(test-path $NewPath))
  {
    new-item -type directory $NewPath –[…]
  }
}

Import Application

Finally, we import the application using the settings gleamed from the application meta-data in MDT 2010.

$7zipx86 = import-MDTApplication
-path '$($DPDrive)`:\$Folder'
-ShortName '7zipx86' […] 
-Name '7-Zip File Archiver 4.65 – x86'
-CommandLine 'msiexec.exe /qb- […] /i http://[…]'
-UninstallKey '{23170F69-40C1-2701-0462-000001000000}'
-enable 'True' -hide 'True'
-SupportedPlatform @(
   'All x86 Pre-Vista',
   'All x86 Vista and Newer'
)

More to come

I hope this will be the first of many Application Examples from MDT 2010.

Keith

Presented here is the MDT Application Export Tool (MDTAppExport.exe). This tool will export the settings for a selected Application in MDT 2010 into a Powershell *.ps1 script file. This portable powershell script file can be used to import the Application settings into another instance of MDT 2010.

One of the coolest new features of MDT 2010 is the new Powershell Programming interface. This interface makes it possible for 3rd party programs to Read, Manipulate, and Create settings in your MDT 2010 environment.

Still, Powershell is a relatively new programming language. And many IT Pros may still be unfamiliar with it. Which makes this tool so cool, you can create powershell scripts without knowing powershell.

Advantages

Exporting to Powershell provides a good way to share Application metadata between MDT 2010 Shares:

• Upgrade your existing MDT 2008 Deployment Share to MDT 2010, and extract out all of your applications for archival.
• Move individual applications between test and production environments without copying other items still in test.
• Use Powershell scripts as a way to document/store the settings for each application in your environment.
• Share your solutions to difficult/complex application installations to IT Community Forums (please don’t share software files you don’t have the rights to redistribute :^) ).

Notes

While running the Application Script Export Tool Wizard, Simply select one of the Deployment Shares already present in the Microsoft Deployment Toolkit 2010 Workbench. Then Select the Applications you wish to export, and the Target location they should be exported to.

Most applications should export without trouble 97-98% of the time. However it is generally a good idea to review the settings created by the tool to ensure that everything is correct.

This script will create one Powershell *.ps1 script file for each item selected in the wizard. If an Application has dependencies defined in the MDT 2010 Workbench, then the dependencies will also be included in the same *.ps1 file.

All Source Files imported into the Deployment Workbench when the Application was created will be copied to the Target Location.

Limitations

• You must have MDT 2010 installed on the same machine this tool is running on.
• You must have your Deployment Share visible in the MDT 2010 Deployment workbench.
• This tool will create one *.ps1 for each application Selected, and all dependent applications will be imported to the same *.ps1 file.
• If you have hidden and or non-enabled applications defined, they will also be Displayed in the Application Script Export Tool Wizard.
• This tool will create scripts with the –hidden and –enabled settings as defined in the workbench.
• This tool will *not* export the Language Field. Language Field is not used in ZTIApplications.wsf
• If you are exporting Sources, the files must be located in the Deployment Share, meaning that you can’t have a %ResourceRoot% at a different location from the %DeployRoot%.
• If there were any errors in copying the Sources to the Target, there should be an
  “# ERROR – <something>”
  line present in the source.
• Please ensure that all application items imported into MDT are placed in their own directory. Installing more than one Application Item from the same directory may result in duplicate files in the MDT system.

Links

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

Further

This tool has tremendous potential. Beyond just coping application settings between MDT 2010 Servers.

We are already using this tool here at Xtreme Consulting Services to create “repositories” of applications that can be used to quickly build out MDT 2010 deployments for our customers. A fullly functional MDT 2010 Litetouch Deployment System setup on site in Hours, not Days, or Weeks.

It could also be the start of a public repository of Applications for MDT Administrators. Although I have not yet figured out a great hosting site for this kind of community/forum. Have some ideas, drop me a line.

Update: 11/13/09 – I updated the tool to generate scripts that support Powershell v1.0 better, and to fix a problem with applications with spaces in the shortname.

Keith

DoNotCreateExtraPartition = YES

From my previous post, I wrote that for MDT 2010, there is a new common command line parameter called “/debugcapture”. This command line parameter will disable the common MDT error handling functions and let any errors echo out to the console.

This is great when calling MDT Client scripts directly from cscript.exe, however it is not helpful when calling from within a MDT Litetouch Task Sequence. Since the MDT 2010 Litetouch Stand Alone Task Sequencer does not capture the output from the client scripts for logging.

Introducing ZTICscript

To solve this problem, I developed a wrapper script called ZTICScript. It will call a client script with the new /debugcapture flag, capture any error output, and copy the error lines to the standard bdd.log system.

It’s been really great when developing new client scripts that may have errors, and speeds up the identification of bad code. As I mentioned in my earlier post, using the information captured with the /debugcapture flag, I can identify the line number and sometimes the variable name of of any errors.

Another cool thing about getting the output from /debugcapture rather than from the default error handler, is that it can also capture compile time errors. For example, if you have written a script with an unterminated string:

wscript.echo "Unterminated string

These errors are nasty, since the bdd.log will not display any errors from the script. Sometimes you may need to go into the smsts.log file to find out which script it was executing when it failed.

Step 1 – Modify your TS.xml file.

Open up your Ts.xml file ( %deployroot%\control\<dir>\ts.xml ), or ( %programfiles%\microsoft deployment toolkit\templates\client.xml ), and replace every instance of

cscript.exe

with

cmd.exe /c %scriptroot%\zticscript.cmd

For example, if you are trying to capture debugging information from the ZTINextPhase.wsf script, the command line should look like (single line):

cmd.exe /c %scriptroot%\zticscript.cmd
"%SCRIPTROOT%\ZTINextPhase.wsf"

Step 2 – Create ZTICScript.cmd and ZTICScript_log.wsf.

Get the script files from here, and copy them to your %DeployRoot%\script directory.

That’s it!

Now, if there are any errors in your script that would normally be caught by the standard MDT Exception Handler, they will instead be output to the console and piped to the bdd.log file. Very helpful in scenarios where normal bdd.log files are not returning the correct information.

Please note, that for some reason, I have been unable to get this script to wrap around LTISysprep.wsf 100% of the time. I just haven’t had the time to debug what’s happening. I think it may have to do with the heavy resource requirements of sysprep.exe.

Attachments:

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

Keith

Most of the client script in BDD/MDT are written in VBScript. VBScript is a powerful scripting language, and it is avaiable on all versions of windows that MDT supports.

I would have loved to work in a more modern language like Powershell and/or C#, however when deploying an operating system from scratch, there are very few guarantees what kind of run time environments are going to be available. The .NET framework, for example, is not available on Windows XP. So back to VBScript for me.

Error Handling

VBScript has the ability to skip/ignore errors if it comes across them when executing them, using the “On error resume next” command.

This can be helpful if you have a long series of non-interdependent tasks. However if you have a long set of dependent tasks, this can be problematic since the failure of any one step in the task could cause the entire thing to fail.

I would have to agree with Eric Lippert’s comments about error handling in VBScript (He was one of the architects of VBScript):

I think I’m old school in saying that error handling should be very tight. Handle errors where you expect to find them. Everything else is left to fail. I’d rather have a program end in a messy death than to blithely continue on in an unpredictable fashion. Some of my cohorts would rather do broad error handling (whole subroutines or sections of the script). They seem to assume that only the errors they expect will happen. And even if other errors do happen, it’s better to have the script finish as best it can than to do nothing at all.

Most of the code in the MDT client scripts is written with this in mind. If it’s possible for a routine to return an error, the script will handle the error cases. If the results of a routine are unexpected or bad, then we want to halt execution to be notified of the problem, rather than continue in an unexpected state.

MDT Error Handling

BDD/MDT was written with a really cool feature that allows it to pick up run time errors identified by the VBScript host program. These errors are logged to the bdd.log file for review later.

The only problem is that the built in error handling routines made available by the VBScript Host program are not as complete as if we were to run it using cscript.exe with the error written to the console.

For example, here is what an undefined variable error would look like when processed by MDT and it’s built in error handling routines:

c:\>cscript zti_test.wsf
ZTI ERROR - Unhandled error returned by
zti_test: Variable is undefined (500)

New for MDT 2010, is the ability to disable the “on error resume next” main error handler in all MDT client VBScript programs, with the “/DebugCapture” flag. When we run the same script with that flag, we get the following output:

c:\>cscript zti_test.wsf /debugcapture
Property debugcapture is now =
c:\zti_test.wsf(10, 10) Microsoft
VBScript runtime error: Variable
is undefined: 'UndefinedVariableFoo'

Note that when calling the script with the /debugcapture flag, the cscript.exe host program not only found the run time error as in the previous example, but it also displayed the line number where the error occurred and the name of the actual variable!?!?

Really cool stuff, and it has been invaluable for me while debugging scripts in MDT 2010.

Keith

1. Create a folder on the client device and copy the following files from the deployment point to this folder:

• ZTIGather.wsf
• ZTIGather.xml
• ZTIUtility.vbs
• CustomSettings.ini
• ZTIDataAccess.vbs (new script file in MDT 2010 for accessing data sources)
• Create a Tools folder and create an X86 and X64 folders underneath the Tools folder.  Copy the Microsoft.BDD.Utility.dll file from the Tools\X64 and Tools\X86 folders in your deployment share to your newly created Tools\X86 and Tools\X64 folder

  2. Delete C:\MININT directory if it already exists. This folder can also be located at X:\MININT if the C drive is not available.

NOTE: MDT stores configuration and progress information in the MININT folder, if this folder is not removed between tests then the results will be invalid.

  3. From the command prompt navigate to the newly created folder and execute the rule processing script using the following command:

“cscript.exe ZTIGather.wsf /debug:true”

      The script will then be processed and the results outputted to the command prompt and a log file ( .\MININT\SMSOSD\OSDLOGS\ZTIGather.log)

NOTE: The script can be run within Windows PE or the host operating system.

  4. Review the results of the script.

Enjoy!

Tim Mintner is a Principal Consultant with Xtreme Consulting Group

Would you mind sharing that tool you wrote ?

Also, is ES_CONTINUOUS and ES_SYSTEM_REQUIRED flags cleared when the system is rebooted?

What I am thinking of is if you run a util that set the above at the beginning of the Lite Touch process. Would you need to run another util that that clears the EXECUTION_STATE flag at the end of the Lite Touch sequence? Or will it be cleared automatically when you reboot the computer using a Restart Computer entry in the Task Sequence?

More background

When you set the Execution state, although you are setting the state of the entire system, the Operating System will only keep track of the requested state during the lifespan of the Thread that made the call. Once the thread (or process) exits, the request is no longer valid, and the system goes back to whatever the last state was.

In MDT 2010, this was easily solved by making the call to SetThreadExecutionState() from within the litetouch.wsf script. Since the Litetouch.wsf script thread stayed alive during the Task Execution phase (in the background), that worked out fine.

Also, the Thread Execution State does not persist across reboots, so cleanup was not necessary, just exit out of litetouch.wsf, and the machine can go into hibernation.

Side Effects

This *may* have a side effect. If you choose to display the final Summary Dialog Box at the end of the Litetouch process, the machine will stay alive during that time, until the user comes back to the machine.

New Tool

Just in case you have “Other” tasks that require you to keep a machine alive, here is a tool I wrote back in 2005 (cleaned up here). This *.exe tool will keep a Windows Machine alive while it is running. Meaning the machine won’t be able to fall asleep either by hibernate or by suspend.

The tool has to remain running while you want the machine to stay awake. So you can run it with the command line:

start KeepAlive.exe

This program is a Windows Program and will run with no user interface. You can see if it’s running by checking the task manager.

When you are done, just run the command again (Either with or without the –close flag:

KeepAlive.exe

If KeepAlive.exe detects that another instance of itself is running in the background holding up Thread Execution State, the new instance of KeepAlive.exe will signal to the previous instance to stop and release the Execution State.

The source code is included

Link

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

Keith

Now that you have your script and your class named correctly you can add your code under the Function Main.  Once you are finished you just need to save the file and put it into the scripts folder in your deployment share. 

So what does the new structure give you beyond what Ben’s post originally pointed out?  First it gives you some nice debugging capabilities.  Normally you would run your script by calling cscript.exe “%scriptroot%\somescript.wsf” in the task sequence.  If you want to use the advanced debugging you can add /debugcapture.  Adding the /debugcapture will turn on advanced debugging features by disabling the standard On Error Resume Next in the scripts and capturing any errors in the script that might occur and displaying them to the screen.  For example if you forgot to declare a variable the /debugcapture will display the variable that could not be found and the line number that the error occurred on.  You can also use your own test hook scripts to unit test the different functions in the script (more on that later).  For right now, enjoy the template and we will definitely be posting more custom script samples over the next few months!

<job id=”ZTIConnect”>
   <script language=”VBScript” src=”ZTIUtility.vbs”/>
   <script language=”VBScript”>

Option Explicit
RunNewInstance

‘//—————————————————————————-
‘//  Global Constants
‘//—————————————————————————-

Const ANSWER_TO_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42

‘//—————————————————————————-
‘//  Main Class
‘//—————————————————————————-

Class ScriptName

    ‘//—————————————————————————-
    ‘//  Global constant and variable declarations
    ‘//—————————————————————————-

    Dim iRetVal

    ‘//—————————————————————————-
    ‘//  Constructor to initialize needed global objects
    ‘//—————————————————————————-

    Private Sub Class_Initialize

    End Sub
    ‘//—————————————————————————-
    ‘//  Main routine
    ‘//—————————————————————————-

    Function Main

‘Insert your code here

    End Function

End Class

   </script>
</job>

Tim Mintner is a Principal Consultant with Xtreme Consulting Group

This tool can quickly import an application defined in a MicroSoft Installer (*.msi) package. This tool will extract out many of the required fields required to import an Applicaiton into MDT 2010 directly from the *.msi meta-data.

One of the most most overlooked features of MDT is the ability to define the “Uninstall registry key name” for each Application Item. When defined, during install time ZTIApplications will skip over the installation of any application by checking the windows registry.

This is a “Best Practice” for applications, as it will save time and errors during installation if a subset of applications were installed previously. The most common scenario is a set of applications that are installed in the base “Common” image before sysprep. Then afterwards, the user is provided a “full” list of applications to install, MDT install will easily skip over any application already installed in the base image.

There is also a command line interface below for scripting.

Fields auto-generated

The following Fields are Auto-Added:

• ShortName – Generated from the name of the *.msi package.
• Folder – Placed in the root of .\Applications by default. Can be changed in the command line.
• Version – From the MSI Package “ProductVersion”.
• UnInstallKey – From MSI Package “ProductCode”.
• Publisher – From MSI Package “Manufacturer”
• Name – From MSI Package “PackageName”
• DisplayName – From MSI Package
  “Manufacturer” + “PackageName” + “ProductVersion”
  (If the Manufacturer name is duplicated in the PackageName, only one is added).
• CommandLine – The following default command line will be used:
  ‘msiexec.exe /qb- /l*vx %LogPath%\<ShortName>.log REBOOT=ReallySuppress /i <MSIFile>‘

Links

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

Keith

As I described in my earlier post. MDT has a great system for Driver Management. You import a driver via it’s *.INF file, and that driver will be installed on every machine where that PnP ID is found. No need to associate a driver via a Make/Model.

However, there are some cases (very rare), when a driver package can’t be installed by *.inf file alone, or a *.exe installation package may need to be installed along side a specific piece of hardware.

The ZTIInstallDriverExePackage.wsf tool was designed to allow an Driver *.exe installation package to associate with a set of PnPID’s defined in the Workbench.

Steps

• Download the Driver Installation *.exe Package to your MDT Workbench machine. Ensure that you copy the package to its own directory.
• Add the Application to the MDT workbench as you would any other Application Installation Package.
• You will need to extract out the GUID for the Application added. It may be in the depoyment share under \Control\applications.xml
• Extract out as much of the driver *.inf component as you can to a separate directory (not a sub-directory). There are several tools available on the internet for extracting out compressed files from Self extracting Executables. My personal favorite is 7-Zip (see 7-zip.org)
• Add the Driver Package to the MDT workbench as you would any other Driver Package.
  It is not necessary that it be fully functional. However the PnPID’s should be properly added.
• Once the driver has been imported successfully. Open the Properties for the new device
  • You may disable the driver. Uncheck “Enabled”. Disable only if you want the Exe Package to be the only way for the driver to be installed.
  • Add the following string to the comments section:
    “DriverExePackage {GUID}”
    Where {GUID} is the Application GUID extracted from the 3^rd step above.
• Copy the ZTIInstallDriverExePackage.wsf file to the Deployment Share under …\Scripts\
• Add a new Step in your Task Sequence calling ZTIInstallDriverExePackage.wsf
  cscript.exe “%ScriptRoot%\ZTIInstallDriverExePackage.wsf”

Script Flow

ZTIInstallDriverExePackage.wsf will operate in a manner similar to ZTIDrivers.wsf.

• It will enumerate though all hardware devices on the machine, and extract out their PnPID’s. 
• For each Hardware PnPID found, it will try to match that ID with any driver found in the Deployment Share.
• For each Driver package found it will search the comments field, searching for the “DriverExePackage” string followed by the Application GUID.
• The script will then call ZTIApplications.wsf with the GUID from the Comments section.

ZTIApplications.wsf will do a good job of ensuring that the corresponding application is installed only once.

Assumptions

• In most cases, I personally recommend sticking with the *.inf only method of driver installation. The Exe only method should only be used in rare cases.
• This script uses the drivers.xml file from the distribution share to associate the PnPID’s with the Application GUID. It is important that the MDT Workbench Add the driver package to the system. IT is not necessary for the driver package to actually work. The Driver Package can be disabled if it is failing to work, it should not be removed.
• To associate a Device with an Application Item, you also need to add the Application GUID of the device prefixed with the string “DriverExePackage” into the comments of the driver in the MDT Workbench.

Links

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

Keith

When a new hardware device is added to the system, Windows will detect the device and gather as much information about it as possible. This includes a list of Plug and Play Device ID’s (PnPID’s) that are unique to that make and model of device. For example:

PCI\VEN_8086&DEV_4236&SUBSYS_10118086

An *.inf file in turn will contain a list of Plug and Play devices its compatible with.

Matching

When presented with a list of Devices, and a collection of drivers, the OS will find all combinations that match, and determine which one is the best (most descriptive) match.

What’s cool about MDT is if you have more than one possible match, the MDT system will copy all possible matches to the OS. Windows has Driver Ranking Algorithms that will determine the best possible match given a set of possible matches.

It can be important, therefore, to insure that you keep your MDT Driver store clear of all duplicates.

Driver Install Packages

Most hardware manufacturers will produce a driver in two parts:

• A basic driver package, Containing an *.inf file describing the package, a *.sys file containing any driver code, and a *.cat digital signature. The digital signature indicates that the driver has gone through some basic testing, what it’s origin is, and that it has not been tampered with. This driver package could be copied to Windows Update or the Windows Update Catalog, and is typically the kind of driver package that is best when importing drivers into MDT 2010 workbench.
• In addition, a company may wish to include add-ons: Tools, Utilities, or Setup wrappers for end-users to install the drivers from the *.inf package more easily. An example might be an advanced radio tuning tool included with a Wi-Fi Driver, or perhaps a Video Communications sample included with a Web-Cam driver. These packages are typically optional, however sometimes they may be required.

When searching for a basic driver *.inf package, typically the best place to start is looking *within* an *.exe Driver Install Package. I like to use 7-Zip to search within self extracting *.exe files for *.inf files.

MDT Drivers

MDT was designed to handle the OS relationship between Devices and Drivers. In other systems, you might assign a driver package to a specific Make and Model. However, whenever a new system comes out, you need to re-define the relationship between the drivers and the Make and Models. Say you have the drivers defined for the Dell D620, and you need to add support for the Dell D820. These two machines mostly share the same class of components, with the same PnP ID’s. With the Driver system in MDT, the drivers are not associated with the Make/Model, instead they are associated with the PnPID of the device itself. All the components of the Dell D620 will automatically be used in the D820, if they share the same PnPID (same device), which in this case they mostly do.

Keith

As many of you already know Tim, Keith, and about a half dozen other Specialists from Xtreme Consulting have recently come off an engagement with Microsoft, where we worked on the development team for the Microsoft Deployment Toolkit 2010.

We are all extremely proud of this product, having worked many long hours, to see a final product of such immense ability, and high quality.

During that time we developed solutions to solve “hundreds” of different problems and scenarios.

Submitted for your approval this week, is a collection of “other” tools for MDT 2010. Some of these tools fit a small niche, others are just demonstrations.

• We have a couple of driver examples.
• Some tools for importing and exporting applications
• And time permitting, some Powershell Scripting Demos!

Keith

Using the Microsoft Deployment Toolkit deployment wizard, how do I filter out x86 applications when installing a x64 OS, and vice versa?

Say you have two applications defined in the MDT Management Console:

• 7-Zip (x86 version)
• 7-Zip (x64 version)

You have done the right thing and marked each one with the correct client platform types (See my previous blog entry). For x86, the new Platform Types in MDT 2010 are:

• All x86 Pre-Vista
• All x86 Vista and Newer

And for x64, the new Platform Types are:

• All x64 Pre-Vista
• All x64 Vista and Newer

However, when you start up the Litetouch Deployment Wizard in MDT 2010, it does not filter out the “7-Zip (x86 version)” when installing a x64 OS, and does not filter out “7-Zip (x64 version)” when installing a x86 OS. This is by design.

The file ZTISupportedPlatforms.xml contains a list of all platform types, the corresponding WMI Query Language (WQL) string used to validate each Supported Platform Types.

Unfortunately, the WQL string needs to be validated during the actual application, not during the Deployment Wizard pages. Most of the time, the Wizard Page is not running on the same as the OS we are installing to, so the Supported Platforms WQL test will return back false information. Supported platforms can only be evaluated during the actual install when the OS is running.

So how do we get the only one Application or the other to display?

The trick here is to create a “Application Bundle”. An Application Bundle is an Application defined in the MDT Management Console, that does not perform any application installation itself, but instead contains a dependency on other applications that do the actual installation.

In the case above we would create a new Application Bundle in the Management Console called “7-Zip” that is dependent on “7-Zip (x86 version)” and “7-zip (x64 version)”.

We would also go back to the “7-Zip (x86 version)” and “7-zip (x64 version)” entries and mark them as “Hidden” in the Property Pages.

• 7-Zip <—New dependent on 7-zip x86 and x64
• 7-Zip (x86 version) <– Hidden
• 7-Zip (x64 version) <– Hidden

Now in the Microsoft Deployment Toolkit Deployment Wizard Page we will see only one entry

• 7-zip

When it comes time to perform the actual installation, the ZTIApplications.wsf script will see that 7-Zip is dependent on two other items. When it tries to install the other two applications, only one will pass, depending on the platform type specified. The other platform type will not error, but silently continue.

Keith

Most of the wizard work I did on BDD/MDT was done by hand, editing html source code in a text editor. Michael Niehaus wrote an excellent tool to help develop and show MDT wizard pages in a C# application, however I prefer to develop by hand.

See: http://mdtwizardeditor.codeplex.com/

For this solution the customer wanted to allow their clients the ability to clean the partitions using the default MDT installation “New Computer” installation process, or to keep the existing partition configuration (and therefore keeping any 2nd data partition).

I created a web page that would query the partition configuration for disk 0, and display it in a graphical fashion, along with a graphical representation of the proposed “Clean” configuration.

Please note that there are technical problems with more than one partition on a Windows Deployment. It’s easy to setup, however, it can also creates management headaches later on if you need to service the machine.

Keith

When adding an application in MDT 2010, you can create the application using the MDT 2010 Management Console, or you can use powershell as a programming interface.

For a while now I had been using the following command in powershell to create applications (example single line):

import-MDTApplication
-path 'DS001:\Applications'
-ShortName 'MacroMedia'
-Name 'Adobe Macromedia Flash Player 10'
-CommandLine 'flash_player_ax.exe /S'
-WorkingDirectory '.\Applications\MacroMedia'
-DestinationFolder 'MacroMedia'
-ApplicationSourcePath '$LocalPath\Sources'

However, I noticed that although my applications were appearing correctly in the Client Deployment Wizard, and installing correctly by ZTIApplications.wsf, they were not being copied from one Deployment point to another by the MDT Management Console (in my case a Media Deployment Point).

After some experimentation, I discovered that none of my applications added from my powershell scripts were “enabled” in the MDT Management Console. This was blocking the copies.

A simple addition to my scripts the explicit use of -enable “True”, fixed everything.

import-MDTApplication
-path 'DS001:\Applications'
-ShortName 'MacroMedia'
-Name 'Adobe Macromedia Flash Player 10'
-CommandLine 'flash_player_ax.exe /S'
-WorkingDirectory '.\Applications\MacroMedia'
-DestinationFolder 'MacroMedia'
-ApplicationSourcePath '$LocalPath\Sources'
-enable 'True'

It appears that the client scripts and the server scripts have different interpretations of what the default of “enable” should be if the element is not present in the applications.xml file.

Luckily for me, it’s an easy fix/work around to my powershell scripts.

Keith

One of the things we worked on for MDT 2010 were improvements to the user interface for “New Computer” scenarios in the Windows Pre-installation Environment (WinPE).

WinPE is used by MDT 2010 Litetouch, and SCCM to prepare the machine for OS installation. It’s a bare bones implementation of Windows, with out the Windows Shell (Start Button), and typically only runs with a command prompt “console” window.

One of the distracting things about BDD 2007 and MDT 2008, was the Console window that appeared at the start of the WinPE Litetouch New Computer” process. It really didn’t do anything, was a little distracting, and didn’t give MDT the feel of a polished product.

It’s fairly easy to use a different shell for WinPE, however we were concerned about proper error recovery. If something goes wrong with any child script in the process, we want to ensure that we have a chance to debug the problem before the machine reboots. If we replaced the standard WinPE shell with something that didn’t properly handle errors, then WinPE could reboot before we knew what happened.

We also wanted the ability to break out into a cmd.exe prompt if we needed to debug a background process or verify something else.

The final solution was to make some modifications to BDDRun.exe to act as a wrapper around wpeinit.exe. It does two things:

• It calls wpeinit.exe, and if wpeinit.exe returns any failure, it will launch a cmd.exe prompt allowing debugging.
• It also launches a thread in the background monitoring for the user to press the F8 button, if pressed, it will launch a cmd.exe window for debugging.
• If there are any instances of cmd.exe (spawned by pressing F8), and wpeinit.exe exits ready for a reboot, the bddrun.exe program will wait until all cmd.exe windows are closed. So be sure to close all windows if you expect the process to continue.
• If you wish to disable the F8 feature, modify the unattend_pe_x86.xml and unattend_pe_x64.xml in the templates directory of your MDT 2010 installation, and replace “/Bootstrap” with “/BootstrapNoSF8”.

Not sure why someone would want to disable the F8 windows (perhaps the F8 keystroke conflicts with another application. Disabling F8 won’t make things secure. Someone could still come in with a WinPE DVD and bypass the security.

Why is it called “SF8″ not “F8″? I had originally programmed the keystroke to be Shift-F8 (similar to the Shift-F10 used by Windows Setup. However the feedback I got from early builds is that it should mimmic SCCM behaviour which uses just F8. I changed the keystroke from F8 to Shift-F8, but forgot to change the command line string from /BootstrapNoSF8 to /BootstrapNoF8. Sorry about that…

Keith

Here is a quick overview for adding (non-boot) drivers in Windows. (Please note: Windows XP/2003 Boot drivers use a different process. Drivers like Storage Drivers. )

ZTIDrivers.wsf process

ZTIDrivers.wsf does not actually install a driver for each device during an OS installation. Instead during the pre-installation phase it will:

• Gather a list of all devices on the machine and their corresponding Plug and Play Device ID (PnPID). 
  A PnPID might look something like: PCI\VEN_8086&DEV_27C9&SUBSYS_01C21028
• It will then search for any matches in the “Out-of-Box Drivers” folder on your Deployment Share ( in the Out-of-Box Drivers folder, and the control\drivers.xml file).
• For each driver package found, it will copy the driver locally into the c:\drivers folder.
• For each folder added into c:\drivers. The folder will be added to the registry:
  HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath
• When the real OS begins installation, and it finds new devices, it will look in these paths for the drivers.

ZTIDriver.wsf assumptions:

Most of the time, it works just fine, however there are some things are assumed:

• You must be using a driver that contains at least one PnPID match with the device being installed.
• Windows will only auto-install drivers that have a valid Driver Signature.
  If one file has been modified, or corrupted, even the *.inf file, the Signature is no longer valid.
• You might be able to install non-signed drivers depending on the OS, but not for new OS’es like Vista 64-bit.
• It is possible that there may be other drivers on the local machine that the OS feels are a better match to the driver from the Out-of-Box drivers folder.
• It is also possible that the device just isn’t working, or the driver just doesn’t work.

I typically only use drivers that are WHQL signed (Disclaimer: I used to work for Microsoft, WHQL), and since Windows Vista, Windows Server 2008, and Windows 7, 64-bit modes will only support signed drivers, it’s usually a good idea to get into the habit of using Signed Drivers only.

Shout out: Michael Niehaus was kind enough to add a check for signed drivers in the MDT 2010 Workbench Driver Import routines. (Thanks Mike!)

To see if your driver is signed, go into the MDT 2010 Workbench, Out-of-Box Drivers, and find your Driver. When found, open the “Properties” page, “Details” tab, and verify the checkbox at the bottom of the screen: “This driver is WHQL signed”.

Debugging Steps:

If you are having troubles with device drivers, it’s typically a good idea to start looking at some basic things:

• Verify that you have the correct drivers imported into the workbench. Including:
  • Go into the MDT Workbench and find your driver. Verify that the drivers are installed.
  • You should also be able to verify the drivers are present in the Deployment Share.
• Test the deployment on physical hardware with the actual device installed. It may not be possible to test Video Driver X with Video Card Y, unless they have a subset of matching PnPID’s.
• Look to see if the Drivers were copied by ZTIDrivers.wsf.
  • You should see ZTIDrivers.wsf identify the PnPID for your device.
  • You should also see ZTIDrivers.wsf xcopy the driver from the Deployment Share locally.
• If the device and corresponding driver were found by ZTIDrivers.wsf and copied locally. Then Windows should find the device and install. Best place to look for more information is the SetupAPI.log file, used by the PnP Subsystem to log all issues with Device Driver Installation.

More information:

Windows Vista setup log file locations
Troubleshooting Device Installation with the SetupAPI Log File
Windows Setup and Device Installation Logging
Troubleshooting Device and Driver Installations

Keith

When adding applications in Microsoft Deployment Toolkit it is possible to associate them with a specific OS or platform.

For example, if I wanted to associate an application with “Windows XP – x86 (any service pack version)”, I would select the item in the MDT Management Console, “Properties”, “Details”, “This can run only on the specified client platform:” with the item:

• All x86 Windows XP

When it comes time to install the application using ZTIApplications.wsf, the script will look up “All x86 Windows XP” in the file ZTISupportedPlatforms.xml and query the local machine using WMI Query Language (WQL):

SELECT * FROM Win32_OperatingSystem
WHERE BuildNumber = '2600' AND OSType=18
SELECT * FROM Win32_Processor
WHERE Architecture=0

In MDT 2008, if we wanted to have an application work on all x86 platforms, and *only* x86, then we would need to select more than one platform.

• All x86 NT
• All x86 Windows 2000
• All x86 Windows XP
• All x86 Windows Server 2003
• All x86 Windows Server 2003 R2
• All x86 Windows Vista
• All x86 Windows 7 Client
• All x86 Windows Server 2008
• All x86 Windows Server 2008 R2

This became a bit of a pain when a new version of windows came along like Windows 7, and I wondered what would happen when Windows 8 came out. Would we need to change our definitions, yet again? The answer was yes.

This was made more complex by the limitations of the WMI provider we use to determine if an OS is x86 or x64, they are different for Windows 5.0 vs Windows 6.0. So there is no way we could create a single entry for “All x86” or “All x64”.

So for Microsoft Deployment Toolkit 2010, we created four new entries that are mostly OS version agnostic.

• All x86 Pre-Vista
• All x86 Vista and Newer
• All x64 Pre-Vista
• All x64 Vista and Newer

Including “All x86 Pre-Vista” and “All x86 Vista and Newer” in the property page of your Application will ensure that it won’t be installed on a x86 OS.

Keith

Windows Recovery Environment (WinRE) is a set of tools included in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2. It can help diagnose and recover from errors that prevent Windows from booting successfully. It’s the modern equivalent of repair tools like “fixmbr”.

Typically WinRE works along side of WinPE. There is no need to install it into a functioning OS, if you can get to a functioning OS, then there is typically nothing to recover.

Back in BDD 2007, we added code to the BDD Welcome Wizard to display a link to the WinRE tools if they were installed on the image. However for some reason, WinRE support was yanked from the WAIK, so most people could never install WinRE into their BDD/MDT Litetouch boot images.

Changes for MDT 2010

New for MDT 2010, when building a new Litetouch WinPE WIM (Update Deployment), if MDT detects the presence of Windows 7/Windows Server 2008 R2 in the workbench, then it will leverage the boot.wim file from those directories, which is great since these boot.wim files contain the WinRE bits. This is a change from MDT 2008, where the Litetouch.wim boot file comes directly from the WAIK.

If you have a pre-existing delivery mechanism for distributing Litetouch Images in your company, like PXE, USB Flash, or DVD, you now automatically have a boot recovery method, since WinRE is automatically included in the litetouch WinPE Boot wim.

It is possible to add WinRE to the local machine for recovery, however chances are that if your client machines are having problems booting to the OS, either they have bad hardware (not fixable by WinRE), or their boot environment is messed up enough that booting to WinRE off the local hard disk is also not an option. Having WinRE available over the network via PXE boot is typically good enough.

Keith

The Administrator Password is typically gathered by the Deployment Wizard, stored locally in the c:\MININT\SMSOSD\OSDLOGS\VARIABLES.DAT file, and later set by ZTIConfigure.wsf and Litetouch.wsf.

I would be great if this data was encrypted during installation, however, that is not possible in all instances. The Administrator Password, for example, must be available as plaintext (unencrypted) for AutoLogon to work. And Windows AutoLogon does not itself encrypt the Administrator Password.

For MDT 2010, we added a new feature that obfuscates critical data in the variables.dat file using the same obfuscation method used by Windows in the Windows System Image Manager found in the WAIK. This data is not 100% secure, I know the method used to obfuscate the data, and I can easily read the information, however most users can’t. (Can you guess the algorithm? Don’t tell anyone :^)).

In most scenarios though, this shouldn’t be a problem. The user will type in a local password, the scripts will save the information locally, but the data is purged at the end of the Litetouch Deployment process.

There are ways that we *can* help protect sensitive information like the Administrator Password if required. One possible way is to get the user to input a “Less Secure” Administrator password at the start of the installation process. We can then inject at the end of the Litetouch deployment process a new step to auto-expire the administrator account’s password. Then the next time a user logs into the administrator’s account, they will be forced to change the password.

Forcing the user to change the password at the end of the Litetouch process has another advantage. When we start the Litetouch installation process for an OS (new computer), we are not joined to a domain. Meaning any Local Administrator Password complexity policies are not applied. If we force the user to change the password at the end of the install process, after the machine has been auto-joined to a domain, then we can enforce any Complexity Requirements required by the domain.

Keith

One of the new features of Windows 7 is a new aggressive power management policy. For machines that are plugged in, the new “Balanced” default policy will put a machine to sleep in 30 minutes. For Windows Vista, the default was 60 minutes.

For Deployments, that’s a problem if you have application installs that take longer than 30 minutes, like Microsoft Office 2007, with all the service packs. Half way through the deployment, the install pauses because the machine went to sleep.

I first noticed this in early tests of the Microsoft Deployment Toolkit 2010. I had written a utility for a similar problem back when I worked for Microsoft IT. It uses a Win32 API call:  Win32 SetThreadExecutionState()

It’s a simple C/C++ call:

SetThreadExecutionState( ES_CONTINUOUS | ES_SYSTEM_REQUIRED );

This command resets the idle timer of the OS, and forces the machine to stay in a state while the Litetouch Task Sequence is running.

Updated (11/3/09):

KeepAlive was added to MDT 2010 in the Microsoft.BDD.Utility.dll file, you can see it being called in the litetouch.wsf script:

' Ensure that this machine does *not* go to sleep while running the task sequence steps.
On error resume next
oUtility.BDDUtility.KeepAlive
On error goto 0

Keith

SDDL

When dealing with Security Permissions, I had to dig down into the details of Security Descriptors and Security Descriptor Definition Language Strings.

For a good tutorial about Security Descriptor Definition Language Strings (SDDL), go here:

http://www.washington.edu/computing/support/windows/UWdomains/SDDL.html

The advantage of SDDL strings is that they provide a good portable way to define and apply settings. You can use the cacls.exe tool included in Windows, for example to apply security strings to an existing folder.

cacls c:\DeploymentShare\LogFiles /s:"D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;;0x100004;;;AU)"

1 – Share Security

\\<server>\DeploymentShare$

For the primary Distribution share, just set the folder to Everyone: Full. Unless all operations to the share are read only, then Everyone: read.

Reasoning: NTFS Security really is more robust and granular than Share level security, so it’s better to just  skip share level security.

2 – Most Read/Only Folders

\\<server>\DeploymentShare$\[Applicaitons,Packages,etc…]

For most folders under \\server\distribution$, the permissions will be like:

SDDL: D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICI;0x1200a9;;;AU)

• Allow “NT AUTHORITY\SYSTEM” Full Control, This folder, subfolders, and files.
• Allow “BUILTIN\Administrators” Full Control, This folder, subfolders, and files.
• Allow “NT AUTHORITY\Authenticated Users” Read & Execute, This folder, subfolders, and files.

This is basic stuff, and will allow administrators to perform basic maintenance, yet prevent normal users from accidently modifying files.

3 – Most Write Only Folders

\\<server>\DeploymentShare$\[LogFiles,MigData,Captures]

This could be things like Log files, user backups, computer backups, USMT Migration files, Bitlocker Keys?, etc… Folders where users/machines may need to write to the Distribution machine (or any other share):

SDDL: D:PAI(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)(A;OICIIO;FA;;;CO)(A;;0x100004;;;AU)

• Allow “NT AUTHORITY\SYSTEM” Full Control, This folder, subfolders, and files.
• Allow “BUILTIN\Administrators” Full Control, This folder, subfolders, and files.
• Allow “CREATOR OWNER” Full Control, Subfolders, and files only.
• Allow “NT AUTHORITY\Authenticated Users” Create folders / append data, This folder only.

Again, this will Administrators the ability to perform all basic maintenance tasks.

The last entry “Allow “NT AUTHORITY\Authenticated Users” Create folders / append data, This folder only.” allows users to create subfolders freely, however it does not give anyone the right to read or write to other folders.

Once a user has created the folder they are the Creator Owner, and the 3rd entry: “Allow “CREATOR OWNER” Full Control, Subfolders, and files only.” allows users to write to the directory they created, and only that directory.

It’s a way that we can allow anyone to write to the MDT Distribution share, without allowing them any access to other users folders. This is great in scenarios like User State Migration, where we wish to save a users state to a common public location, yet don’t wish to allow other users the ability to read those possibly sensitive files.

Please let me know if you have any good ideas about securing files for your deployments.

Keith

Microsoft Deployment Toolkit 2010 writes log files to the bdd.log file in a standardized format use by the SMS team. This log file format looks like XML.

Example:

<![LOG[Property debug is now = TRUE]LOG]!>
<time="00:19:03.000+000" date="10-15-2009" 
component="ZTIWindowsUpdate" context="" 
type="1" thread="" file="ZTIWindowsUpdate">

As you can see, that’s a lot of text to just write out: “Property debug is now = TRUE”.

To assist in reading these log files, I use the trace32.exe program written by Microsoft. You can download this program for free at Microsoft as part of the: “System Center Configuration Manager 2007 Toolkit” This program displays MDT log files in a easy to read format.

Another cool feature of trace32.exe is that it does a good job of monitoring changes to the log files when being written to. You can see the changes being performed in real time within trace32.exe.

Link: http://www.microsoft.com/downloads/details.aspx?FamilyID=948e477e-fd3b-4a09-9015-141683c7ad5f&DisplayLang=en

(Updated: 10/26/09 to fix formatting)

Keith

In a continuation of my last post on debugging Litetouch failures by viewing the bdd.log file. Let me also discuss some of the *other* log files that may appear during a Litetouch Deployment.

• During WinPE bootup, there may be problems with the WinPE itself, for example the network driver may fail to load. Look in x:\windows\system32\WPEInit.log, for details
• During Windows Vista and Windows 7 setup, any setup errors should be logged in the panther directory. A good description of these files, and where they are located can be found here: http://support.microsoft.com/kb/927521.
• When performing a domain join, Windows will write logging information to: c:\windows\debug\netsetup.log.
• During a State Capture and State Restore (USMT), MDT will write to the standard MDT log file locations to the files: USMTEstimate.log, USMTCapture.log, USMTRestore.log.
• Finally, in Litetouch scenarios, when processing the tasks defined in the task sequence list, the SCCM Stand Alone Task Sequencer will write to a file called smsts.log. Typically this file is located at %Temp%\smsts.log. However, you can also tell by searching within the bdd.log file. If Litetouch sees where the smsts.log file is located then it will log the path. Just search for smsts.log. Also, when complete, Litetouch will archive the smsts.log file to the c:\windows\temp\deploymentlogs\smsts.log location like bdd.log.

Keith

Most of the time the best place to start looking is the Bdd.log file. While on the MDT development team, we tried hard to ensure that the client scripts wrote to the logs frequently, so we could debug problems later with minimal effort.

Typically each script will write out to a corresponding log file *and* to bdd.log. So for example if you were running the ZTIWindowsUpdate.wsf script, that script would write out to ZTIWindowsUpdate.log *and* bdd.log.

MDT Litetouch log files are written to a common location, bdd.log. This log file is located typically in one of the following locations:

• If you are running from a WinPE boot disk, and the local machine does not yet have any partitions defined, typically the logs are located on the WinPE Disk: x:\MININT\SMSOSD\OSDLOGS\bdd.log.
• After the main hard disk partition on the client machine has been created, MDT will start logging to the local c: drive at: c:\MININT\SMSOSD\OSDLOGS\bdd.log. Typically, during scenarios when we are not installing an OS from scratch, this is the default location for Log files. For example if we are running a Task Sequence that is installing a set of applications only.
• When the entire Litetouch process is finished, MDT will archive the contents of the logs to c:\windows\temp\depoymentlogs\bdd.log.
• Also if you have the variable SLShare defined, when the Litetouch Process is finished, MDT will archive the contents of the log to that share. For example: SLSHARE=%DeployRoot%\BDDLogs.

There is a new property I created for MDT 2010, called SLShareDynamicLogging. For example: SLShareDynamicLogging = \\MyServer\PublicWriteShare\MDTLogs\. This property will write debugging information to the network share defined in addition to c:\MININT\SMSOSD\OSDLOGS. Please be aware that MDT 2010 writes a *lot* of debugging information to the log, and adding another logging destination will slow down MDT. I recommend using it only in advanced debugging scenarios when you can’t access the log files on the client machine.

Keith

Here is the agenda for the day:

Agenda:

9:30 – 10:00 Welcome and Coffee
10:00 – 11:30 MDT 2010 – Intro and Intermediate

11:30- 12:30 Lunch
12:30 – 3:30 MDT 2010 – Advanced, and MDT Extensions for ConfigMgr
3:30 – Post-Meeting Social at Dave and Busters

Register early! This meeting may be a sell-out!

Directions

Xtreme Consulting Group is pleased to announce the formation of the Xtreme Consulting Deployment Team. A team within Xtreme Consulting Group, specializing in Windows Deployments.

Several Members of the Xtreme Consulting Deployment Team have recently come off an engagement with the Microsoft team that developed the Microsoft Deployment Toolkit 2010.

The Microsoft Deployment Toolkit (MDT) 2010 is the latest version of the critically acclaimed deployment software for the Windows Operating System. Microsoft Deployment Toolkit is the de-facto reference design for deployments of Windows Operating Systems and Applications.

The Xtreme Consulting Deployment Team has been formed to fill a critical need for experts in Windows Deployment. Whether are preparing your first deployment system, or need help developing customized scripts or enhancements for your existing system. Xreme Consulting’s Deployment Team is resource you need.

The formation of the Xtreme Consulting Deployment Team comes at the same time as Microsoft is releasing their new flagship product Windows 7. With the release of Windows 7, more and more companies are evaluating their internal desktop platform requirements, and looking into methods and scripts to deploy this new operating system.

Here are a few of the members on the team:

• Tim Mintner – Tim Mintner has over fifteen years consulting experience with many of the largest companies in the world on Systems Management and Operating System Deployment.  Most recently, Tim was a Senior Software Development Engineer for Microsoft on the Microsoft Deployment Toolkit and helped ship six versions of MDT that have been downloaded by over 300,000 customers worldwide.  Tim has been an author for Technet Magazine and is a highly rated speaker at Microsoft events such as the Microsoft Management Summit and Microsoft TechEd.  Tim is actively involved in the Systems Management and OS Deployment community and has been recognized as a Microsoft Most Valued Professional for his efforts with User Groups and online communities.
• Keith Garner - Keith Garner has been working in the Puget Sound region at the Microsoft Corporate Headquarters as a Software Developer for fifteen years, mostly in the Windows Product Group, and Microsoft IT, specializing in Windows OS Internals, and Deployment. For the past 4 years, Keith has been working as a consultant with Xtreme Consulting Group, working on several Microsoft projects, including BDD/MDT, and most recently MDT 2010.
• Polly Reese – Polly has almost 20 years of industry experience. Responsible for the delivery and engagement management of Microsoft Consulting Services for the Global Deployment practice including pipeline, revenue, utilization, and delivery management of desktop deployment services worldwide.   Provided leadership, evangelism and education to the global Microsoft deployment expert community.

Xtreme Consulting Deployment Team is the resource for your next deployment project. And we have solutions and resources for a wide range of projects.

• Xtreme Consulting Deployment Team are the experts on MDT 2010. MDT 2010 is the de-facto reference system designed by Microsoft for Windows Deployments in the business environment.
• Xtreme Consulting Services has a large library of common deployment tools and systems ready to be droped into your Corporate environment.
  In some instances, we can setup a fully functional, common deployment (MDT Litetouch) solution on site, and in just hours containing:
  • Windows XP, Windows Vista, Windows 7, Windows Server 2003, and Windows Server 2008
  • Microsoft Office Suite, Microsoft Project, Microsoft Visio, and more…
  • PDF Readers, Media Players, Microsoft Silverlight Clients, Anti Virus clients.
  • Runtime Environments like: .NET Frameworks (all versions), Java Runtimes.
  • Server tools like: SQL Server, Sharepoint Server.
  • Development Environments: Visual Studio,
• Xtreme Consulting Services has several Subject Matter Experts on the critically aclaimed Microsoft Deployment Toolkit 2010.
  • Custom Scripts, configurations, custom wizard pages, etc…
  • Advanced Debugging of complex scenarios, etc..

Let Xtreme Consulting Services Deployment Team help you get your IT infrastructure under control.

Xtreme Consulting Group, Inc. is a business and IT services firm that delivers project management and consulting services to help clients reduce costs, enhance organizational flexibility, and improve performance. The company specializes in project/program management, development infrastructure & engineering planned IT, web design & development, and SharePoint portal development. Xtreme Consulting Group operates throughout the US from their corporate offices in Redmond, WA. More information about Xtreme can be found at www.xtremeconsulting.com