Archive for the ‘System Imaging and Deployment’ Category

Automated Driver Import in MDT 2013

As a follow up to my previous post, I also have developed a script to automate the import of drivers into MDT 2013.  This PowerShell script takes a source folder structure and duplicates the top two levels of folders in the MDT Deployment Share “Out-of-box drivers ” branch.  The script then imports all drivers found in the source directories to the matching folders in MDT.

All we have to do is extract all drivers for a given computer model into an appropriately named folder in the source directory, and then run the script.

#  Create-MDTDriverStructure.ps1
#  J. Greg Mackinnon, University of Vermont, 2013-11-05
#  Creates a folder structure in the "Out of Box Drivers" branch of a MDT 2013
#    deployment share.  The structure matches the first two subdirectories of 
#    the source filesystem defined in $srcRoot.  All drivers contained within
#    $srcRoot are imported into the deployment share.
#  Requires: 
#    $srcDir - A driver source directory, 
#    $MDTRoot - a MDT 2013 deployment share
#    - MDT 2013 must be installed in the path noted in $modDir!!!

# Define source driver directories:
[string] $srcRoot = 'E:\staging\drivers\import'
[string[]] $sources = gci -Attributes D $srcRoot | `
    Select-Object -Property name | % {$}
# Initialize MDT Working Environment:
[string] $MDTRoot = 'E:\DevRoot'
[string] $PSDriveName = 'DS100'
[string] $oobRoot = $PSDriveName + ":\Out-Of-Box Drivers"
[string] $modDir = `
	'C:\Program Files\Microsoft Deployment Toolkit\Bin\MicrosoftDeploymentToolkit.psd1'
Import-Module $modDir
New-PSDrive -Name "$PSDriveName" -PSProvider MDTProvider -Root $MDTRoot

foreach ($source in $sources){
    Write-Host "Working with source: " $source -ForegroundColor Magenta
    # Create the OOB Top-level folders:
    new-item -path $oobRoot -name $source -itemType "directory" -Verbose
    # Define a variable for the current working directory:
    $sub1 = $srcRoot + "\" + $source
    # Create an array containing the folders to be imported:
    $items = gci -Attributes D $sub1 | Select-Object -Property name | % {$}
    $oobDir = $oobRoot + "\" + $source

    foreach ($item in $items) {
		# Define source and target directories for driver import:
	    [string] $dstDir = $oobDir + "\" + $item
	    [string] $srcDir = $sub1 + "\" + $item
	    # Clean up "cruft" files that lead to duplicate drivers in the share:
		Write-Host "Processing $item" -ForeGroundColor Green
	    Write-Host "Cleaning extraneous files..." -ForegroundColor Cyan
        $delItems = gci -recurse -Include version.txt,release.dat,cachescrubbed.txt $srcDir
        Write-Host "Found " $delItems.count " files to delete..." -ForegroundColor Yellow
	    $delItems | remove-Item -force -confirm:$false
        $delItems = gci -recurse -Include version.txt,release.dat,cachescrubbed.txt $srcDir
        Write-Host "New count for extraneous files: " $delItems.count -ForegroundColor Yellow

	    # Create the target directory:
		Write-Host "Creating $item folder" -ForegroundColor Cyan
	    new-item -path $oobDir -name $item -itemType "directory" -Verbose
	    # Import all drivers from the source to the new target:
		Write-Host "Importing Drivers for $item" -ForegroundColor Cyan
	    Import-MDTDriver -Path $dstDir -SourcePath $srcDir 
        Write-Host "Moving to next directory..." -ForegroundColor Green
    } # End ForEach Item
} # End ForEach Source

Remove-PSDrive -Name "$PSDriveName"


Rethinking Driver Management in MDT 2013

We have been using the Microsoft Deployment Toolkit (MDT) in LTI/Lite Touch mode here at the University for a long time now.  Why, we used it to deploy XP back when MDT still was called the Business Desktop Deployment Solution Accelerator (BDD).  In this time, we have gone though several different driver management methods.  Gone are the nightmare days of dealing with OEMSETUP files, $OEM$ directories, can elaborate “DriverPack” injection scripts for XP (thank goodness).  

With the release of Vista, we moved from a PnP free-for-all model of driver detection.  After Windows 8.0, we found we really needed to separate our drivers by operating system.  Thus, we created Win7, Win8, and WinPE driver selection profiles.

But now we are finding that driver sprawl is becoming a major issue again.  On many new systems we run though a seemingly successful deployment, but end up with a non-responsive touch screen, a buggy track pad, and (sometimes) a very unstable system.

Starting this week, we are trying a new hybrid driver management approach.  We will create a driver folder for each computer model sold though our computer depot.  I have developed a custom bit of VBScript to check to see if the hardware being deployed to is a known model.  Driver injection will be restricted to this model if a match is found.  The script contains additional logic to detect support for both Windows 7 and Windows 8 variants, and to select the most current drivers detected.  Unknown models will fall back on the PnP free-for-all detection method.

Here is how it works…

  1. Create a new group in your OS deployment task sequence named “Custom Driver Inject”, or something similar.  Grouping all actions together will allow easier transfer of these custom actions to other Task Sequences:
  2. Under this new group, add a new action of type “Set Task Sequence Variable”.  Name the variable “TargetOS”,and set the value to the OS that you are deploying from this task sequence.  You must follow the same naming convention that you use in your Out-of-box driver folder.  I use Win(X), where (X) is the major OS version of the drivers in the folder.  In this example, I have chose “Win8″:
  3. Add an action of type “Run Command Line”.  Name this action “Supported Model Check”.  Under the Command line field, enter “cscript “%SCRIPTROOT%\ZUVMCheckModel.wsf”.  (We will import this script into the deployment share later on.)
  4. Add a sub-group named “Supported Model Actions”.  Under the “Options” tab, add a condition of type “Task Sequence Variable”.  Use the variable “SupportedModel”, the Condition “equals”, and the Value “YES”.  (The SupportedModel variable gets set by the CheckModel script run in the previous step.):
  5. Under this new group, add a new action of type “Set Task Sequence Variable”.  Name this task “Set Variable DriverGroup002″.  Under “Task Sequence Variable”, set “DriverGroup002″, and set the value to “Models\%TargetOS%\%Model%”.  (Note:  You could use “DriverGroup001″, but I already am using this variable to hold a default group of drivers that I want added to all systems.  The value “%TargetOS%\%Model%” defines the path to the driver group in the deployment share.  If you use a different folder structure, you will need to modify this path.):
  6. Create a new task of type “Inject Drivers”.  Name this task “Inject Model-Specific Drivers”.  For the selection profile, select “Nothing”.  Be sure to select “Install all drivers from the selection profile”.  (NOTE: The dialog implies that we will be injecting only divers from a selection profile.  In fact, this step will inject drivers from any paths defined in any present “DriverGroupXXX” Task Sequence variables.)
  7. Now, under our original Custom Driver Inject group, add a new task of type “Inject Drivers”.  Choose from the selection profile “All Drivers”, or use a different fallback selection profile that suits the needs of your task sequence.  This time, select “Install only matching drivers from the selection profile”:
    Under the “Options” tab, add the condition where the “Task Sequence Variable” named “Supported Model” equals “NO”:
    This step will handle injection of matching drivers into hardware models for which we do not have a pre-defined driver group.
  8. Optionally, you now can open the “CustomSettings.ini” file and add the following to your “Default” section:
    (I have a “Peripherals” driver group configured which contains USB Ethernet drivers used in our environment.  These are a necessity when deploying to hardware that does not have an embedded Ethernet port, such as the Dell XPS 12 and XPS 13.  You also could add common peripherals with complicated drivers such as a DisplayLink docking station or a Dell touch screen monitor.)
  9. Add the “ZUVMCheckMedia.wsf” script to the “Scripts” folder of your deployment share.  The code for this script is included below.  I think the script should be fairly easy to adapt for your environment.
  10. Finally, structure your “Out-of-Box Drivers” folder to contain a “Models” folder, and a single folder for each matching hardware model in your environment.  I get most of our driver collections from Dell:
    (NOTE:  Thanks Dell!)
    The real challenge of maintaining this tree is in getting the model names right.  Use “wmic computersystem get model” to discover the model string for any new systems in your environment.  A table of a few current models I have been working with is included below.

Dell Marketing Model Name to WMI Name Translator Table:

  • Dell XPS 12 (first generation) – “XPS 12 9Q23″
  • Dell XPS 12 (second generation) – “XPS 12-9Q33″
  • Dell XPS 13 (first generation) – “Dell System XPS L321X”
  • Dell XPS 13 (second generation) – “Dell System XPS L322X”
  • Dell XPS 14 – “XPS L421Q”
  • Dell Latitude 10 – “Latitude 10 – ST2″
  • VMware Virtual Machine – “VMware Virtual Platform”
  • Microsoft Hyper-V Virtual Machine – “Virtual Machine”

A fun nuance we encountered last week was a Latitude E5430 model that contained “no-vPro” after the model number. Dell does not provide separate driver CABs for vPro/non-vPro models, so I added a regular expression test for Latitudes, and strip any cruft after the model number. There is one more problem down…

The following site contains a list of older model name translations:
As you can see, most Latitudes and Optiplexes follow sane and predictable model name conventions. I wish the same were true for the XPS.

Finally, I am indebted to the following sources for their generously detailed posts on driver management. Without their help, I doubt I would have been able to make this solution fly:

Jeff Hughes of the Windows Enterprise Support Server Core Team:

Andrew Barnes (aka Scriptimus Prime), whose posts on MDT driver management give the basics DriverGroups and model selection:
AND, of automating driver import into MDT (written for MDT 2012… some changes required for 2013):

The incredible Michael Neihaus, who in this post discusses the use of DriverGroups and Selection Profiles:

And finally Eric Schloss of the “Admin Nexus”, who give me the idea of developing a fallback for systems that do not match a known model. It was this key bit of smarts that gave me the confidence to move forward with a model-specific driver grouping strategy:

ZUVMCheckModel.wsf script:

(NOTE: WordPress stripped off the WSF headers and footers from my script. These are the first three and last two lines in the script. If you copy from this post, please remember to place greater than and less than tags around these lines before running, as indicated in the comments.)

' Uncomment and wrap each of the following three lines in less than/greater than characters to convert them to tags.
'job id="ZUVMCheckModel"
'script language="VBScript" src="ZTIUtility.vbs"/
'script language="VBScript"

Option Explicit

'// Main Class
Class ZUVMCheckModel
	'//  Constructor to initialize needed global objects
	Private Sub Class_Initialize
	End Sub
	'// Main routine

	Function Main()
	' //*******************************************************
	' //
	' // File: ZTIUVMCheckModel.wsf
	' //
	' // Purpose: Checks the model of this system against
	' //          a list of known machine models.  Returns
	' //          TRUE if a matching model is detected.
	' //
	' // Usage: cscript ZUVMCheckModel.wsf /Model: [/debug:true]
	' //
	' //*******************************************************
	'Use the following lines for debugging only.
	'oEnvironment.Item("TargetOS") = "Win7"
	'oEnvironment.item("DeployRoot") = "c:\local\mdt"
	'oEnvironment.Item("Model") = "Latitude E6500 some annoying variation"
	'End debug Params

	  Dim aModels()          'Array of models taken from DriverGroups.xml
	  Dim bOldDrivers        'Boolean indicating drivers present for an older OS version
	  Dim i                  'Generic integer for looping
	  Dim j                  'Generic integer for looping
	  Dim iRetVal            'Return code variable
	  Dim iMaxOS             'Integer representing the highest matching OS driver store
	  Dim oRegEx
	  Dim oMatch
	  Dim match
	  Dim oXMLDoc            'XML Document Object, for reading DriverGroups.xml
	  Dim Root,NodeList,Elem 'Objects in support of oXMLdoc
	  Dim sDGPath            'Path to DriverGroups.xml file
	  Dim sInitModel         'String representing the initial value of
	                         '   oEnvironment.Item("Model")
	  Dim sItem	             'Item in aModels array.
	  Dim sMaxOS             'OS Name of highest matching OS driver store
	  Dim sOSFound           'OS Name for a given matching driver set.
	  oLogging.CreateEntry "Begin ZUVMCheckModel...", LogTypeInfo
	  'Set the default values:
	  oEnvironment.Item("SupportedModel") = "NO"
	  iMaxOS = CInt(Right(oEnvironment.Item("TargetOS"),1))
	  'wscript.echo "Default value for iMaxOS = " & iMaxOS
	  bOldDrivers = false
	  sInitModel = oEnvironment.Item("Model")
	  'wscript.echo "sInitModel value = " & sInitModel
	  Set oRegEx = New RegExp
	  oRegEx.Global = True
	  oRegEx.IgnoreCase = True
	  'Modify the detected model name to handle known variations:
	  oRegEx.pattern = "Latitude"
	  if oRegEx.test(sInitModel) then
		oLogging.CreateEntry "Model is a Latitude.  Cleaning up the model name...", LogTypeInfo
		oRegEx.pattern = " "
		set oMatch = oRegEx.Execute(sInitModel)
		'wscript.echo "oMatch Count is: " & oMatch.count
		if oMatch.Count > 1 then
			i = oMatch.item(1).FirstIndex
			oEnvironment.Item("Model") = Left(sInitModel,i)
			'wscript.echo """"&oEnvironment.Item("Model")&""""
		end if
	  end if

	  'Check for DriverGroups.xml file, which will contain the supported model list:
	  iRetVal = Failure
	  iRetVal = oUtility.FindFile("DriverGroups.xml", sDGPath)
	  if iRetVal  Success then
		oLogging.CreateEntry "DriverGroups file not found. ", LogTypeError
		exit function
	  end if 
	  oLogging.CreateEntry "Path to DriverGroups.xml: " & sDGPath, LogTypeInfo
	  'Parse the DriverGroups.xml file:
	  oLogging.CreateEntry "Parsing DriverGroups.xml...", LogTypeInfo
	  Set oXMLDoc = CreateObject("Msxml2.DOMDocument") 
	  oXMLDoc.setProperty "SelectionLanguage", "XPath"
	  Set Root = oXMLDoc.documentElement 
	  Set NodeList = Root.getElementsByTagName("Name")
	  oLogging.CreateEntry "NodeList Member Count is: " & NodeList.length, LogTypeInfo
	  'oLogging.CreateEntry "NodeList.Length variant type is: " & TypeName(NodeList.Length), LogTypeInfo
	  i = CInt(NodeList.length) - 1
	  ReDim aModels(i) 'Resize aModels to hold all matching DriverGroup items.
	  'oLogging.CreateEntry "List of Available Driver Groups:", LogTypeInfo
	  i = 0
	  For Each Elem In NodeList
		if InStr(Elem.Text,"Models\") then
			aModels(i) = Mid(Elem.Text,8)	'Add text after "Models\"
			'oLogging.CreateEntry aModels(i), LogTypeInfo
			i = i + 1
		end if
	  oLogging.CreateEntry "End Parsing DriverGroups.xml.", LogTypeInfo

	  'Loop through the list of supported models to find a match:
	  oLogging.CreateEntry "Checking discovered driver groups for match to: " & oenvironment.Item("Model"), LogTypeInfo
	  For Each sItem in aModels
		oLogging.CreateEntry "Checking Driver Group: " & sItem, LogTypeInfo
		i = InStr(1, sItem, oEnvironment.Item("Model"), vbTextCompare)

		'wscript.echo TypeName(i) 'i is a "Long" number type.
		If i  0 Then
			oLogging.CreateEntry "Matching Model found.", LogTypeInfo
			j = InStr(sItem,"\")
			sOSFound = Left(sItem,j-1)
			'wscript.echo "sOSFound = " & sOSFound 
			if (InStr(1,sOSFound,oEnvironment.Item("TargetOS"),vbTextCompare)  0) then
				oLogging.CreateEntry "Drivers matching the requested OS are available.  Exiting with success.", LogTypeInfo
				oEnvironment.Item("SupportedModel") = "YES"
				iRetVal = Success
				Main = iRetVal
				Exit Function
			end if
			if iMaxOS > CInt(Right(sOSFound,1)) then
				iMaxOS = CInt(Right(sOSFound,1))
				'wscript.echo "iMaxOS = " & iMaxOS
				sMaxOS = sOSFound
				bOldDrivers = true
				'wscript.echo "sMaxOS = " & sMaxOS
			end if
		End If
	  If bOldDrivers Then 'Run if sMaxOS is defined... set a boolean when this is defined and test against that?
		oLogging.CreateEntry "Model drivers were found for an OS older than the one selected...", LogTypeWarning
		oEnvironment.Item("SupportedModel") = "YES"
		oEnvironment.Item("TargetOS") = sMaxOS
	    oLogging.CreateEntry "No matching drivers were found for this model.", LogTypeInfo
	  End If
	  oLogging.CreateEntry "End ZUVMCheckModel.", LogTypeInfo

	  iRetVal = Success
	  Main = iRetVal

	End Function

End Class

' Uncomment and wrap each of the following two lines in less than/greater than characters to convert them to tags.

LiteTouch failures on UEFI systems

Today I got a complaint that a user could not deploy Windows 8 on a UEFI-enabled computer (a Latitude 10 tablet, to be precise) using our MDT 2012 Update 1 deployment share (in Lite Touch mode, of course).  At the same time, I was experiencing problems deploying Windows 8 on a Dell XPS 14 with UEFI firmware enabled.  Interestingly, the deployment problem did not occur when running with Legacy BIOS enabled.  What gives?

The error reported by Lite Touch was: “MDT FAILURE (5616): Verify BCDbootex”.  Much digging though the logs revealed the command line that triggered the problem (It was spelled out in the “LTIApply.log”).  This command was something like:
\\server\deployShare\Tools\x64\bcdboot c:\windows /l en-us /s v: /f UEFI

If I try to run the command above manually, I just get back the bcdboot.exe help dialog.  Further investigation revealed that the version of bcdboot.exe on the server share is dated to 2009.  This is the Windows 7 RTM release version!

I created a new deployment share to see if the bad version of bcdboot.exe gets placed there again… it did not.  So, I removed bcdboot.exe from the deployment share (along with an old version of ImageX.exe and some other expired utilities).  Upon re-running LiteTouch, deployment succeeds.  Both Windows 7 and Windows 8 boot media contain bcdboot.exe in the search path… no server side copy is required.  I wonder how it got there in the first place?  Maybe we were trying to make it easier for people to capture system images using the LiteTouch boot media.  Another entry for the department of unintended consequences…

View Desktop Template Building Notes – Nothing is Easy

This week I have been working on updating our VMware View template for our public terminals (those are kiosk and lab systems).  As always, simple things have become difficult, and time has disappeared like cookies at a preschool party. Here are some resources that were useful to me in cleaning up the reference system:

Default User Profile Settings:

Why must this be so hard?  Under XP, you used to be able to tweak the Default User profile to within an inch of its life, then copy it.  Easy!  But MS maintains that this “caused problems” of some vague nature, and so the process is now not possible.  Instead, we are supposed to use the “CopyProfile” action in the unattend.xml file used by sysprep to trigger copying of the “Administrator” profile to “Default”.  However, this operation does not copy all settings… aargh!  And the settings that are excluded are not documented… double aargh!  And if you have any profile traces left over on your system for any user other than “Administrator”, sysprep will fail miserably… triple aargh!

Fortunately, there is help available:

I found especially helpful the following post on managing Windows 7 Taskbar links:

Ultimately, I used a variation on this script to pin items to the Win 7 taskbar:
(I’ll post the final script I developed separately.  I could not find a fully functional script on the internet.  I had to do some significant mods to the scripts in the above post to get something that does everything that I want.)

Hey, would it not be nice if there were an Group Policy Preference for “shortcuts” to have “taskbar” as a target location?  Yes… yes it would.

Configuration Manager Client Preparation:

I understand you are not supposed to clone a system that has the SCCM client installed on it.  MS documents steps that should be taken to remove the fingerprints of an existing SCCM client prior to cloning… what, so script?

I did some digging and found that the OS Deployment Task Sequences include a step that is supposed to do just this.  After more digging, I determined that the tool for this step is embedded in the SCCM OSD Capture Media.  I generated an OSD Capture Media set, extracted the contents, and found a small executable named “OsdPrepareSmsClient.exe”.  Perhaps this is what I was looking for?  I will test it and find out.

User Profile Cleanup:

Some of our lab admins used to use the profile cleaner utility from MS to erase user profiles from Win2000/XP on logout.  That utility is gone, but you can now use Group Policy to force deletion of all non-Administrator profiles on a schedule.  Unfortunately, this only happens on system restart.

I have settled on “DelProf2.exe” as a replacement:
This excellent freeware utility by Helge Klein will delete all profiles that are not in use, and will clean up the ProfileList registry entries as well.  You can exclude specific named profiles as well.

Java Update… make it stop! :

Unofficial Mozilla Builds for Windows:
(Includes “BlueGriffon” installers that do not embed the obnoxious “iminent toolbar”.  Kudos to Glazman for this excellent basic HTML editor.  Boo to the invasive toolbar installer.)

Unattended Install and Upgrade of Adobe Reader

Previously we explored how to increase the success rate of unattended application upgrades using our handy “killAndExec” VBScript. This works well for about 80% of our applications. What about Adobe Reader? Well… not so much.

Thankfully, the stock Adobe Reader installer deals with open files quite nicely, and does not care if Reader is in use by a browser during silent installs (this is the main reason that we needed killAndExec.vbs in the first place). However, not all Reader install operations are full installs. Interestingly, Adobe is one of the few vendors that I deal with that actually uses MSI patch files (MSP). To install a patch release of Reader (i.e. 10.1.4), you need first to install the base version (10.1), then one or more patch MSP files. This is easy for new installs… just run “setup.exe” silently, then run “msiexec /p (patchFileName) /qn” to install the patch.

However, the situation gets more complicated for upgrades. If the base product already is installed, setup.exe will return an error code. So, for upgrade scenarios, I have put together another handy VBScript to handle base version detection. The script follows:

option explicit
' Install Adobe Reader Script:
' J. Greg Mackinnon, 2012-06-12
' Intended to perform unattended installations of Adobe Reader by MS SCCM 2012.
' Installs the version of Adobe Reader in the same directory as the script, if not already installed.
' Also installs the current Reader patch, if requested.
' Installer string is specified in "sInstall".
' Requires: 
'     Adobe Reader setup and patch files in the same directory as the script.
'     "setup" and "basever" arguments required.
'     "patch" argument optional.
' Returns:
'     - Code 100 - if required arguments are not provided to the script.
'     - Return code of setup program added to the return code of the patch program, if no other errors occur.

dim oExec, oFS, oLog, oShell
dim cScrArgs
dim iExit
dim sBaseVer, sInstall, sLog, sOut, sPatch, sPath, sPF, sScrArg, sTemp, sVer
dim bDoPatch

sLog = "installAdobeReader.log"
iExit = cLng(0)

' Instantiate objects:
Set oShell = CreateObject( "WScript.Shell" )
Set oFS = CreateObject("Scripting.FileSystemObject")
sTemp = oShell.ExpandEnvironmentStrings("%TEMP%")
Set oLog = oFS.OpenTextFile(sTemp & "\" & sLog, 2, True)

' Define Functions
function echoAndLog(sText)
'EchoAndLog Function:
' Writes string data provided by "sText" to the console and to Log file
' Requires: 
'     sText - a string containig text to write
'     oLog - a pre-existing Scripting.FileSystemObject.OpenTextFile object
	'If we are in cscript, then echo output to the command line:
	If LCase( Right( WScript.FullName, 12 ) ) = "\cscript.exe" Then
		wscript.echo sText
	end if
	'Write output to log either way:
	oLog.writeLine sText
end function

sub subHelp
	echoAndLog "installAdobeReader.vbs Script"
	echoAndLog "by J. Greg Mackinnon, University of Vermont"
	echoAndLog ""
	echoAndLog "Runs Adobe Reader silent setup (if not already present), then applies "
	echoAndLog "any specified MSP patch files for Reader."
	echoAndLog "Logs output to 'installAdobeReader.log' in the %temp% directory."
	echoAndLog ""
	echoAndLog "Required arguments and syntax:"
	echoAndLog "/setup:""[setupFile]"""
	echoAndLog "     The primary Adobe Reader installation program.  If switches "
	echoAndLog "    are required for setup to run silently, they must be provided."
	echoAndLog "/basever:"
	echoAndLog "     The base Adobe Reader product version for which to check (i.e. 10.1)"
	echoAndLog ""
	echoAndLog "Optional arguments and syntax:"
	echoAndLog "/patch:""[patchFile]"""
	echoAndLog "     MSP patch file to install after Adobe Reader setup completes."
end sub
' End Functions

' Parse Arguments
if WScript.Arguments.Named.Count > 0 Then
	Set cScrArgs = WScript.Arguments.Named
'	For Each sScrArg in cScrArgs
'		echoAndLog sScrArg 'Echo supplied arguments to console
'	Next

	for each sScrArg in cScrArgs
		select case LCase(sScrArg)
			Case "setup"
				sInstall = cScrArgs.Item(sScrArg)
			Case "patch"
				sPatch = cScrArgs.Item(sScrArg)
			Case "basever"
				sBaseVer = CStr(cScrArgs.Item(sScrArg))
			Case Else
				echoAndLog vbCrLf & "Unknown switch or argument: " & sScrArg & "."
				echoAndLog "**********************************" & vbCrLf
		end select
	if (IsNull(sInstall) or IsEmpty(sInstall)) then
		echoAndLog "Required argument 'setup' was not provided."
		echoAndLog "**********************************" & vbCrLf
	elseif (IsNull(sBaseVer) or IsEmpty(sBaseVer)) then
		echoAndLog "Required argument 'basever' was not provided."
		echoAndLog "**********************************" & vbCrLf
	elseif (IsNull(sPatch) or IsEmpty(sPatch)) then 
		bDoPatch = False
		bDoPatch = True
	end if
elseif WScript.Arguments.Named.Count = 0 then 'Detect if required args are not defined.
	echoAndLog vbCrLf & "Required arguments were not specified."
	echoAndLog "**********************************" & vbCrLf
end if
' End Argument Parsing

' Begin Main

' Complete version and installation strings:
sInstall = ".\" & sInstall
sPatch = "msiexec.exe /p " & sPatch & " /qb /norestart"

' Build path to Adobe Reader executable:
sPF = oShell.ExpandEnvironmentStrings( "%ProgramFiles%" )
sPath = sPF & "\Adobe\Reader 10.0\Reader\AcroRd32.exe"
echoAndLog "Acrobat Reader Path: " & sPath

' Get the version string on the currently installed Reader executable:
on error resume next
sVer = oFS.GetFileVersion(sPath)
on error goto 0
echoAndLog "Version of currently installer Adober Reader: " & sVer

' See if we already have the base version installed:
if InStr(Left(cStr(sVer),4),sBaseVer) then
	'Reader 10.1.x is already installed skip base product installation.
	echoAndLog "Base product installed.  Skipping setup..."
	'Install the base product.
	echoAndLog "Installing base product with command: " & sInstall
	set oExec = oShell.Exec(sInstall)
	Do While Not oExec.Status  1
	sOut = oExec.StdOut.ReadAll()
	echoAndLog "Return code from installer: " & oExec.ExitCode
	echoAndLog "Standard output: " & sOut
	iExit = cLng(oExec.ExitCode)
end if

'Now install the patch:
if bDoPatch = True then
	echoAndLog "Patch installation requested."
	echoAndLog "Installing patch with command: " & sPatch
	set oExec = oShell.Exec(sPatch)
	Do While Not oExec.Status  1
	sOut = oExec.StdOut.ReadAll()
	echoAndLog "Return code from patch installer: " & oExec.ExitCode
	echoAndLog "Standard output: " & sOut
	iExit = cLng(oExec.ExitCode) + iExit
	echoAndLog "Patch installation was not requested.  Exiting."
end if

' End Main

KillAndExec.vbs – Ensuring application installer success with VBScript

Today’s scripting challenge…

We are attempting to use SCCM 2012 as a patch management solution for our centrally supported third party applications.  Great new features in SCCM 2012 allow us to write detection rules for applications to determine if superseded versions are present on the client system, and to trigger an immediate upgrade.  Cool Beans.  Problem is, a lot of application installers that ran reliably in our MDT “LiteTouch” environment (which is used to deploy new operating systems with no previously installed software) will not run silently or successfully on systems where previous application versions were already installed, and may currently be running.

This is an old problem for client system management… how can you update in-use files?  In most cases I have seen, the admin will schedule the updates to run when no one is logged in.  Unfortunately, this is an edge case for us.  Most systems are off when no one is logged in.  Another system is to force logoff for application updates.  While this would work, it seems like a “heavy” solution… why force the user to log off to update one application that may or may not be running?  Why force all applications closed on the off chance that one application will need to be terminated.

Our solution?  Kill only the processes that need to be terminated to ensure application installation success.  See the VBScript solution below (I flirted with writing this one in PowerShell, but the code signing requirements still intimidate me, and I may have the odd-duck XP client that still does not have PowerShell).  I have tested the script on Firefox, Thunderbird, VLC, Notepad++, WinSCP, Filezilla, and KeePass.  Rock On!

UPDATE: Since initial publication, I have added some logic to handle execution from “wscript”. If the script is executed from wscript.exe, console output will be suppressed. Additionally, the log file now is named “killAndExec-(exeFileName).log”. (This prevents SCCM from overwriting the log file the next time a program installer runs that also uses this script).

'KillAndExec.vbs script, J. Greg Mackinnon, 2012-09-13
' Kills processes named in the "kill" argument (comma-delimited)
' Runs the executable named in the "exec" argument
' Appends the executable arguments specified in the "args" argument (comma-delimited)
'Requires: "kill" and "exec" arguments.  The executable named in the "exec" arg must be in the same directory as this script.
' RC=101 - Error terminating the requests processes
' RC=100 - Invalid input parameters
' Other return codes - Pass-though of return code from WShell.Exec.Run using the provided input parameters

Option Explicit

const quote = """"

'Declare Variables:
Dim aExeArgs, aKills
Dim bBadArg, bNoArgs, bNoExeArg, bNoExec, bNoKill, bNoKillArg 
Dim cScrArgs
Dim iReturn
Dim oShell, oFS, oLog
Dim sBadArg, sCmd, sExe, sExeArg, sKill, sLog, sScrArg, sTemp

'Set initial values:
bBadArg = false
bNoArgs = false
bNoExeArg = false
bNoExec = false
bNoKill = false
bNoKillArg = false
iReturn = 0

'Instantiate Global Objects:
Set oShell = CreateObject("WScript.Shell")
Set oFS  = CreateObject("Scripting.FileSystemObject")

' Define Functions
Sub subHelp
	echoAndLog "KillAndExec.vbs Script"
	echoAndLog "by J. Greg Mackinnon, University of Vermont"
	echoAndLog ""
	echoAndLog "Kills named processes and runs the provided executable."
	echoAndLog "Logs output to 'KillAndExec.vbs' in the %temp% directory."
	echoAndLog ""
	echoAndLog "Required arguments and syntax:"
	echoAndLog "/kill:""[process1];[process2]..."""
	echoAndLog "     Specify the image name of one or more processes to terminate."
	echoAndLog "/exe:""[ExecutableFile.exe]"""
	echoAndLog "     Specify the name of the executable to run."
	echoAndLog ""
	echoAndLog "Optional arguments:"
	echoAndLog "/args""[arg1];[arg2];[arg3]..."""
	echoAndLog "     Specify one or more arguments to pass to the executable."
	echoAndLog "/noKill"
	echoAndLog "     Switch to suppress default process termination.  Used for testing."
	echoAndLog "/noExec"
	echoAndLog "     Switch to suppress default program execution.  USed for testing."
End Sub

function echoAndLog(sText)
'EchoAndLog Function:
' Writes string data provided by "sText" to the console and to Log file
' Requires: 
'     sText - a string containig text to write
'     oLog - a pre-existing Scripting.FileSystemObject.OpenTextFile object
	'If we are in cscript, then echo output to the command line:
	If LCase( Right( WScript.FullName, 12 ) ) = "\cscript.exe" Then
		wscript.echo sText
	end if
	'Write output to log either way:
	oLog.writeLine sText
end function

function fKillProcs(aKills)
' Requires:
'     aKills - an array of strings, with each entry being the name of a running process.   
	Dim cProcs
	Dim sProc, sQuery
	Dim oWMISvc, oProc

	Set oWMISvc = GetObject("winmgmts:{impersonationLevel=impersonate, (Debug)}\\.\root\cimv2")
	sQuery = "Select Name from Win32_Process Where " 'Root query, will be expanded.	
	'Complete the query string using process names in "aKill"
	for each sProc in aKills
		sQuery = sQuery & "Name = '" & sProc & "' OR "
	'Remove the trailing " OR" from the query string
	sQuery = Left(sQuery,Len(sQuery)-3)

	'Create a collection of processes named in the constructed WQL query
	Set cProcs = oWMISvc.ExecQuery(sQuery, "WQL", 48)
	echoAndLog vbCrLf & "----------------------------------"
	echoAndLog "Checking for processes to terminate..."
	'Set this to look for errors that aren't fatal when killing processes.
	On Error Resume Next
	'Cycle through found problematic processes and kill them.
	For Each oProc in cProcs
	   echoAndLog "Found process " & oProc.Name & "."
	   Select Case Err.Number
		   Case 0
			   echoAndLog "Killed process " & oProc.Name & "."
		   Case -2147217406
			   echoAndLog "Process " & oProc.Name & " already closed."
		   Case Else
			   echoAndLog "Could not kill process " & oProc.Name & "! Aborting Script!"
			   echoAndLog "Error Number: " & Err.Number
			   echoAndLog "Error Description: " & Err.Description
			   echoAndLog "Finished process termination function with error."
			   echoAndLog "----------------------------------"
			   echoAndLog vbCrLf & "Kill and Exec script finished."
			   echoAndLog "**********************************" & vbCrLf
	   End Select
	'Resume normal error handling.
	On Error Goto 0
	echoAndLog "Finished process termination function."
	echoAndLog "----------------------------------"
end function

function fGetHlpMsg(sReturn)
' Gets known help message content for the return code provided in "sReturn".
' Requires:
'     Existing WScript.Shell object named "oShell"
	Dim sCmd, sLine, sOut
	Dim oExec
	sCmd = "net.exe helpmsg " & sReturn
	echoAndLog "Help Text for Return Code:"
	set oExec = oShell.Exec(sCmd)
	Do While oExec.StdOut.AtEndOfStream  True
		sLine = oExec.StdOut.ReadLine
		sOut = sOut & sLine
	fGetHlpMsg = sOut
end function
' End Define Functions

' Parse Arguments
If WScript.Arguments.Named.Count > 0 Then
	Set cScrArgs = WScript.Arguments.Named
	For Each sScrArg in cScrArgs
		Select Case LCase(sScrArg)
			Case "nokill"
				bNoKill = true
			Case "noexec"
				bNoExec = true
			Case "kill"
				aKills = Split(cScrArgs.Item(sScrArg), ";", -1, 1)
			Case "exe"
				sExe = cScrArgs.Item(sScrArg)
			Case "args"
				aExeArgs = Split(cScrArgs.Item(sScrArg), ";", -1 ,1)
			Case Else
				bBadArg = True
				sBadArg = sScrArg
		End Select
	If (IsNull(sExe) or IsEmpty(sExe)) Then
		bNoExeArg = True
	ElseIf (IsNull(aKills) or IsEmpty(aKills)) Then
		bNoKillArg = True
	End If
ElseIf WScript.Arguments.Named.Count = 0 Then 'Detect if required args are not defined.
	bNoArgs = True
End If 
' End Argument Parsing

' Initialize Logging
sTemp = oShell.ExpandEnvironmentStrings("%TEMP%")
sLog = "killAndExec-" & sExe & ".log"
Set oLog = oFS.OpenTextFile(sTemp & "\" & sLog, 2, True)
' End Initialize Logging

' Process Arguments
if bBadArg then
	echoAndLog vbCrLf & "Unknown switch or argument: " & sBadArg & "."
	echoAndLog "**********************************" & vbCrLf
elseif bNoArgs then
	echoAndLog vbCrLf & "Required arguments were not specified."
	echoAndLog "**********************************" & vbCrLf
elseif bNoExeArg then
	echoAndLog "Required argument 'exe' was not provided."
	echoAndLog "**********************************" & vbCrLf
elseif bNoKillArg then
	echoAndLog "Required argument 'kill' was not provided."
	echoAndLog "**********************************" & vbCrLf
end if
' Log processes to kill:
for each sKill in aKills
	echoAndLog "Process to kill: " & sKill
' Log executable arguments:
echoAndLog "Executable to run: " & sExe
if not (IsNull(aExeArgs) or IsEmpty(aExeArgs)) then
	for each sExeArg in aExeArgs
		echoAndLog "Executable argument: " & sExeArg
	echoAndLog "Executable has no provided arguments."	
end if
' End Process Arguments

'Begin Main
'Build full command string:
if inStr(sExe," ") then 'Spaces in the exe file
	sExe = quote & sExe & quote 'Add quotations around the executable.
end if
if not (IsNull(aExeArgs) or IsEmpty(aExeArgs)) then
	sCmd = sExe & " " 
	for each sExeArg in aExeArgs
		if inStr(sExeArg," ") then
			sExeArg = quote & sExeArg & quote 'Add quotations around the argument.
		end if
		sCmd = sCmd & sExeArg & " "
	sCmd = sExe
end if
echoAndLog "Command to execute:"
echoAndLog sCmd

'Kill requested processes:
if bNoKill = false then
	fKillProcs aKills
	echoAndLog "/noKill switch has been set.  Processes will not be terminated."
end if
'Run the requested command:
echoAndLog vbCrLf & "----------------------------------"
if bNoExec = false then
	echoAndLog "Running the command..."
	on error resume next 'Disable exit on error to allow capture of oShell.Run execution problems.
	iReturn = oShell.Run(sCmd,10,True)
	if err.number  0 then 'Gather error data if oShell.Run failed.
	    echoAndLog "Error: " & Err.Number
		echoAndLog "Error (Hex): " & Hex(Err.Number)
		echoAndLog "Source: " &  Err.Source
		echoAndLog "Description: " &  Err.Description
		iReturn = Err.Number
	end if
	on error goto 0
	echoAndLog "Return code from the command: " & iReturn
	if iReturn  0 then 'If the command returned a non-zero code, then get help for the code:
		fGetHlpMsg iReturn
	end if 
	echoAndLog "/noExec switch has been set.  Executable will not run."
end if
echoAndLog "----------------------------------"

' End Main

.NET Framework 2/3 Installation on Windows 8 Release Preview

Trouble getting applications developed using .NET Framework 2 or 3 to install on Windows 8 Release Preview? “Error message 0x800f0906:  “Windows couldn’t connect to the Internet to download necessary files. Make sure that you’re connected to the Internet, and click Retry to try again.”?  Me too…

Windows 8 features a new “install on demand” model for optional OS features.  In Win7 and Vista, all optional components were cached on the hard drive for later install.  With Win8, all optional components are on the DVD, and available at install time.  However, if you want to enable features later, they will be downloaded from “the cloud” via Windows Update.  One problem… it does not work with WSUS (at least, not yet?).

There is a page on this on MSDN:

Their suggestion? “Please ask your administrator to enable the policy to use Windows Update instead of WSUS.”  Um… I don’t think so.

Instead, insert the Win 8 DVD (or mount the ISO, using the native Explorer right-click “mount” option… THANK YOU MICROSOFT!), then run the following command:

Dism /online /enable-feature /featurename:NetFx3 /All /Source:x:\sources\sxs /LimitAccess

(where you use your DVD drive letter in place of “X:”)

Now I will need to look into enabling .NET framework 2-3.5 using unattend.xml. I don’t want everyone at UVM to have to do this, too.

The Mysterious Case of the Un-Deletable MBR (Or, More Reasons to Hate PGP)

Shortly after releasing MDT 2012 on the general public I got a call from a colleague who told me that his LiteTouch deployment was failing.  He was able to boot to LiteTouch media, go though the configuration wizard, and initiate setup.  LiteTouch would partition the drive, Windows Setup would start, the image would get written to the computer, and then the system would reboot… so far so good. What happened next was unexpected.  The computer booted to the PGP BootGuard screen.

Turns out we were dealing with a system that had been encrypted using PGP Whole Disk Encryption. However, we have a lot of those, and deployment has not failed on them before.  In the past, LiteTouch dutifully has erased the Master Boot Record (MBR) and all existing partition tables on the system, effectively wiping PGP BootGuard from the machine before running Windows Setup.

So what changed?  Is this a bug in MDT 2012?  Something new in PGP Desktop version 10.2.0 MP4?  Or a configuration problem in our LiteTouch environment.

Let’s omit the details of ~6 hours of troubleshooting… it was a change in the WinPE LiteTouch environment, and PGP.  It appears, though investigation, that the PGP filter drivers attempt to block access to the MBR of the hard drive.  Since I had injected PGP drivers into the LiteTouch 32-bit boot media, I had, effectively created a situation where DiskPart.exe would be unable to remove PGP BootGuard from the system.  The really irritating part is that the PGP drivers do not pass any indication to the Windows utilities that there has been an error writing to the MBR.  DiskPart.exe, BootSect.exe, and the DaRT Disk Commander all can be used to repair MBRs.  But when used in a PGP-enabled environment they all report success in manipulating the disk MBR, but all of them fail to make any real change to the true MBR.  How do you usually erase a drive?  For me, I would run “diskpart.exe, select disk 0, clean”.  With PGP drivers in place, you could run this series of commands, think that you had erased the drive, but still end up with PGP BootGuard in your MBR.  It really is maddening.

Symantec/PGP claim that you can remove the MBR data by “deinstrumenting” the disk using the “pgpwde.exe” command.  The problem with this is, pgpwde will not let you deinstrument an encrypted drive.  So, you would have to decrypt the drive first, then deinstrument.  I am not wasting time on that.  Worse yet, if your drive was partially encrypted when you erased the data partition, PGPWDE still reports the drive status as “partially encrypted”, and refuses to perform any actions on the drive (such as “deinstrument”) until the current encryption (on the nonexistent drive) completes.  AARGH!

Fortunately, I was able to find a low-level disk manipulation utility that actually works in 32-bit PGP-enabled WinPE environments.  PlDD.exe:

There are other “DD” equivalents for Windows.  Most of them either fail to work against PGP (GnuWin32 DD.exe and the Crysocome DD), or will not function under WinPE (FAU DD).  PlDD is pretty old, and it does not work under 64-bit Windows.  But, we don’t need 64-bit support (PGP does not provide 64-bit drivers for WinPE!), it works perfectly in 32-bit Windows.  Thus, this is the perfect tool for the time being.

Getting the right command syntax to pldd.exe was a bit challenging as the tool itself has scarce documentation.  I wish I could credit all of the resources that I used to put this dense command together, but I have since lost the browser tabs.  The following is the pldd.exe command, suitable for plugging into an MDT task sequence as a custom command:

cmd.exe /c “%SCRIPTROOT%\Pldd.exe if of=\\.\PhysicalDrive0 bs=512 count=1″

Argument breakdown:

  • if = In File.  In this version of DD, if provided with parameters, will use a string of zeros as input.
  • of = Out file.  In this case, we are using the Windows device path “\\.\PhysicalDrive0″, which is fixed disk zero.  I think this device path is referenced in the gnuwin32 dd docs.
  • bs = Block size.  We are choosing to write in 512 byte blocks.
  • count = The number of blocks to write.  We are going to write one 512 byte block to the “out file”.

To summarize, we use pldd to write 512 bytes of zeros to the start of physical drive zero.  This action wipes out the MBR and the disk signature of the drive (sorry, I lost my reference for this factoid, too).  Zeroing 512 bytes of disk is rather faster than zeroing the entire drive, which is the only other option I have seen referenced in the tubes for fixing this issue.

Share and Enjoy.

MDT 2012 – Taking LiteTouch Offline

I decided to give some of my user base something that they have been asking for for a long time… the ability to run MDT/LiteTouch deployments entirely from removable storage media. I had avoided doing this in the past as we made significant use of the MDT database in selecting hardware-specific support applications (such as Dell QuickSet).  However, with MDT 2012 (and the general deprecation of hardware-specific support software under Windows 7), I have decided to abandon the MDT database.  This makes generation of offline MDT media much more feasible.

“I should be able to get this done in a few hours!”, I thought.  Ha!  Four days later…

Gotchas in adding LiteTouch Offline media to a previously online-only environment:

Expiring stale media:

One of the leading arguments we make to persuade users to adopt the use of LiteTouch is that “we keep it up to date for you”.  What about offline media?  How to we ensure that that stays current?  One of the Brad Tucker, Deployment Guy, has a solution for that:

The problem there is that his script was developed for the SCCM ZTI scenatio, not LiteTouch.  However, with a little work I was able to adapt his script for use in LiteTouch.  The script body is available below.  To run it, I needed to modify the “winpeshl.ini” file in %ProgramFiles%\Microsoft Deployment Toolkit\Templates as follows:


The script referenced above (ZUVMExpiredMediaCheck.vbs) needs to be defined in the “Extra Directory to Include” field in the WinPE section of the Media set in the Deployment Workbench.  You need to include the “\Deploy\Scripts” folder structure in the Extras directory, too.

WinRE installation problems:

Since deploying MDT 2012, I finally worked though the problem of including both WinRE and MS DaRT tools into the LiteTouch boot media, and in the WinRE environment installed with the operating system.  However, with offline media the inclusion we would not want to copy the LiteTouch WinPE instance to disk.  Two reasons.  Firstly, the OS Deployment option simply would not work (Offline media would not be available), and secondly, we just included a script to disable the media.  To solve this problem, I needed to set the “PrepareWinRE” Property in the CustomSettings.ini file for the media set to “NO”.

MS DaRT Integration Problem:

When testing LiteTouch from a fully offline machine, I started to get a “network connection not available” error pop up at seemingly random places after starting up the boot media.  Eventually I realized that the error was coming from the DaRT Remote Connection tool that starts up with WinPE.  While this error does not cause any problems with actual deployment, I don’t want it causing end-user panic, so I decided to see if I could disable the feature.  According to documentation, I need to generate a “DartConfig.DAT” file using the DaRT configuration tool.  DartConfig.DAT is a binary configuration file (not plain text).  It’s options are not documented anywhere, so you really do have to run the GUI tool to generate a new DAT.  You then are supposed to drop the DAT file into “%ProgramFiles%\Microsoft Deployment Toolkit\Templates”, and update your boot media.  A few problems with this:

  1. If you want different configuration files installed into your WinPE instances, you will either to switch out the DartConfig.dat in the Templates directory each time you update boot media, or run the updates from a different MDT instance, or edit the LiteTouch boot WIM files each time you update the boot media.  There is no way to specify different DartConfig.dat files per deployment share or media set.
  2. The Deployment Workbench does not consistently insert the DartConfig.dat file into the LiteTouch boot media.  If you update your DartConfig.dat in the Templates directory, then update your boot media, there is no guarantee that your DartConfig.dat will get updated.  The only sure-fire way to get a new DartConfig in your deployment share seems to be to force regeneration of the boot media (i.e. you need to throw out your existing boot WIM files, not update them).  The situation is worse with offline media sets.  Rather the workbench will copy any existing boot WIMs from the root deployment share to serve as a baseline image when generating offline boot images.  Thus, to update DartConfig.dat in a media set, you need to delete both the root share boot WIMs, and the offline boot WIMs prior to updating media.
  3. You might think that you could work around that whole one-template-per-workbench problem by including a per-media-set DartConfig.dat in the “Extras” folder that you can optionally include in each media set or deployment share.  After all, the media update procedure appears to add the extras after the templates.  But if you did think this, you would be wrong.  The update apparently will not overwrite existing files within the source WIM.
  4. You might, out of sheer desperation, decided to remove DaRT from the offline boot media  by deselecting the component from the WinPE properties of the media set.  This also will fail.  The workbench will report that “DaRT cannot be removed from the media.  Use the -Force option to regenerate the media.”  Presumably the error is suggesting that you should add “-force” to the Update-MDTMedia PowerShell Cmdlet that is used to update the media set.  Sadly, “-Force” is not a valid flag for this cmdlet.

Ultimately, I just used imagex to mount the LiteTouch Offline boot media, and switched out the DartConfig.dat file using a simple “copy” command.  Now I just need to remember to do that every time.

UserExit Script – Required Modifications:

Back in 2008 I added a UserExit script to LiteTouch to generate a semi-unique computer name by taking the last eight characters of the computer’s MAC address, then appending a hyphen and a date string.  It turns out that the routine in MDT that captures the MAC address (presumably ZTIGather.vbs) will not succeed unless the computer has a functional Ethernet connection.  Grrr… When testing LiteTouch offline, we were getting computer names like “Address%-1214″.  Percent characters are not valid in computer names  so, I needed to update our UserExit to use other semi-unique system attributes such as “Serial Number” to “Asset Tag” if the MAC is not available.  I also added a fallback string of “UVMLT” if none of those variables are found.  The new script is available below, along with a sample call to the script from CustomSettings.ini.

' // ****************************************************************************
' // File:      ZUVMExpiredMediaCheck.vbs
' // Version:   1.0
' // Purpose:   Check to see if stand-alone media is expired
' // Actions:   Shuts down WinPE if media is older than iExpAge variable months
' //            Otherwise, script exits with Return 0.
' // Usage:     cscript/wscript ZUVMExpiredMediaCheck.vbs
' //            (to be added to winpeshl.ini, before bddrun.exe)
' // ****************************************************************************
Option Explicit

' // Declare Variables:
Dim cFiles
Dim dtCreationDate, dtEndDate, dtXMonthsAgo
Dim iExpAge
Dim oDiskDrive, oDrives, oExec, oFile, oFSO, oShell, oWMIService
Dim sCommand, sComputer, sExpText, sSysRoot, sUSBPath

' // Initialize Variables:
' Media Expiration Age, in months:
iExpAge = 4

' // -----------------------------------------------------------------------------------------
' // Function: Converts the WMI date query response to a simple date format.  (e.g. 09/21/2010)
Function WMIDateStringToDate(dtmInstallDate)
	WMIDateStringToDate = CDate(Mid(dtmInstallDate, 5, 2) & "/" & Mid(dtmInstallDate, 7, 2) _
	& "/" & Left(dtmInstallDate, 4) & " " & Mid(dtmInstallDate, 9, 2) & ":" _
	& Mid(dtmInstallDate, 11, 2) & ":" & Mid(dtmInstallDate, 13, 2))
End Function
' // -----------------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // Find the environment variable %SYSTEMROOT% for location of LiteTouch Executables.
Set oShell = CreateObject("WScript.Shell")
sSysRoot = oShell.ExpandEnvironmentStrings("%SYSTEMROOT%")
' // ---------------------------------------------------------------------------------

' // --------------------------------
' // Find driver letter for USB Media
Set oFSO = CreateObject("Scripting.FileSystemObject")
Set oDrives = oFSO.Drives
For Each oDiskDrive In oDrives
	If oDiskDrive.DriveType = "1" Then
		sUSBPath = oDiskDrive.Path
	End If
' // --------------------------------

' // -------------------------------------------------------------------------
' // Media Check - Check for Applications.xml presence and age.
sComputer = "."
Set oWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & sComputer & "\root\cimv2")
' Query WMI for creation date of the Applications.xml file on the USB Drive:
'    NOTE: Do not add the wbemFlagForwardOnly (Decimal 32) flag to this query.  While the query would run faster
' with the flag, we also will not be able test for empty queries.
Set cFiles = oWMIService.ExecQuery("Select * From CIM_DataFile Where Name = '" & sUSBPath & "\\Deploy\\Control\\Applications.xml'")
' // -------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------
' // If Applications.xml file is not present, this is not offline media.  Exit script.
if cFiles.Count = 0 then
end if
' // ---------------------------------------------------------------------------------

' // ---------------------------------------------------------------------------------------------
' // If the Applications.xml file creation date is more than "iExpAge" months ago, shutdown WinPE.
For Each oFile in cFiles
	dtCreationDate = WMIDateStringToDate(oFile.CreationDate)
	dtEndDate = DateAdd("m", iExpAge, dtCreationDate)
	' Set the date iExpAge months ago from today
	dtXMonthsAgo = DateAdd("m", -iExpAge, Now)
	If dtCreationDate < dtXMonthsAgo then
		' Expiration Text, to be displayed to the user if older than iExpAge months:
		sExpText = "This LiteTouch Offline Media expired on: " & dtEndDate & chr(13) _
			& "Refresh your media using the README file located here:" & chr(13) _
			& "\\\software\Windows_Deployment_Services"
		MsgBox sExpText,vbMsgBoxSetForeground,"Expired Media"
		'Shutdown WinPE immediately:
		sCommand = sSysRoot & "\system32\wpeutil.exe shutdown"
		set oExec = oShell.Exec(sCommand)
		' If the media is fresh, run LiteTouch Offline.
	End If
' // ---------------------------------------------------------------------------------------------

' // ZUVMUserExit.vbs
' // Custom Function library for use with the Microsoft Deployment Toolkit
' // Currently includes "GenUniComp" - a function for generating unique computer names

' code adapted from source content:

Function UserExit(sType, sWhen, sDetail, bSkip)
	UserExit = Successfs
End Function

Function GenSimDate(sSimDate)
	'Generates a simple date string in the format of YYMMDD
	Dim dNow, sYear, sMonth, sDay
	dNow = Date()
	sYear = Right(cStr(Year(dNow)), 2)
	sMonth = cStr(Month(dNow))
	sDay = cStr(Day(dNow))
	GenSimDate = sYear + sMonth + sDay
End Function

Function CleanMac(sMac)
	'Strips colon (:) characters from the variable passed to this function.  The passed variable is presumed to be a Mac address.
	Dim oRegExp
	Set oRegExp = new RegExp
	oRegExp.IgnoreCase = true
	oRegExp.Global = true
	oRegExp.Pattern = ":"
	CleanMac = oRegExp.Replace(sMac, "")
End Function

Function GenUniComp(sMac,sSerial,sATag)
	'Generates a hopefully unique computer name by:
	'   Selecting from available MacAddress, SerialNumber, or Asset Tag then
	'   triming the right eight digits from the value and appending a hyphen with the current date.
	Dim sSimDate, sUniVal
	oLogging.CreateEntry "ZUVMUserExit: sMac value in UserExit script is: " & sMac,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sSerial value in UserExit script is: " & sSerial,LogTypeInfo
	oLogging.CreateEntry "ZUVMUserExit: sATag value in UserExit script is: " & sATag,LogTypeInfo
	if InStr(sMac,"%Mac") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Mac Address to generate computer name",LogTypeInfo
		sMac = CleanMac(sMac)
		oLogging.CreateEntry "ZUVMUserExit: Cleaned sMac values now is: " & sMac,LogTypeInfo
		sUniVal = sMac
	elseif InStr(sSerial,"%Serial") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Serial Number to generate computer name.",LogTypeInfo
		sUniVal = sSerial
	elseif InStr(sATTag,"%Asset") = 0 then
		oLogging.CreateEntry "ZUVMUserExit: Using Asset Tag to generate computer name.",LogTypeInfo
		sUniVal = sATag
		oLogging.CreateEntry "ZUVMUserExit: Using Fallback Computer Name",LogTypeInfo
		sUniVal = "UVMLT"
	end if
	oLogging.CreateEntry "ZUVMUserExit: sUniVal now set to: " & sUniVal,LogTypeInfo
	sSimDate = GenSimDate(sSimDate)
	GenUniComp = Right(sUniVal, 8) + "-" + sSimDate
	oLogging.CreateEntry "ZUVMUserExit: Unique Computer Name will be: " & GenUniComp,LogTypeInfo
End Function

Calling the GenUniComp function from CustomSettings.ini:


MDT 2012 – The Ultimate WinPE Boot Media

This week I went to rebuild our MS DaRT Emergency Rescue Disk media.  While looking into the available tools to automate injection of our LiteTouch / MDT Deployment Workbench driver store into the DaRT boot media, I discovered something interesting in the MDT 2012 RC1 release notes… MDT 2012 supports the addition of DaRT into the LiteTouch boot media.  Once complete, you will have boot media that will support LiteTouch deployment, Standard WinRE recovery tools, and MS DaRT tools.  Too cool!  Some hours of work and a few gotchas later, it is done.  My LiteTouch media contains LiteTouch scripts, WinRE, DaRT, and PGP command line utilities.  Best of all, rebuilding of the media is sustainable.  Here is how it is done:

  1. Making WinRE available in LiteTouch boot media:
    In the Operating Systems section of the workbench, create a DEV folder.  Add to this one operating system with source files for each architecture that you need boot media for (i.e. amd64 and x86).  The OS version must match the version of WinPE used by the AIK on your build system.  (e.g. If you are using the Windows 7 AIK, you need current Windows 7 sources in the deployment share.)  To avoid trouble, make sure that these are the only operating systems with source files for this version of the AIK (e.g. You can have Vista source files if you need them, but keep only one Win 7 source so you will know which boot.wim is being used to generate your LiteTouch media).
  2. Adding DaRT:
    Follow the directions in the MDT help to install and activate the DaRT tools into the deployment share.
    In the deployment share CustomSettings.ini, set the variable:
    This will insure that the workbench will generate a combined WinRE/DaRT image.
  3. Adding PGP:
    To make PGP tools available, use the PGPPE tools to apply pgpwde.exe to the boot.wim in the 32-bit operating system source files that you created in step 1, as follows:
    pgppe.exe /vista [pathToOSSource] [pathToPGPFiles]
    This will install PGP tools into both the Windows Setup and WinPE images in the stock boot.wim.  When you generate LiteTouch media from the Workbench, the PGP tools already will be present.
    Documentation on the use of PGPPE can be found here:
    and here:
    (The first article contains corrections to the second article.  Note that PGPPE now is part of a standard PGP Desktop install, and does not need to be downloaded separately).

Of course, there is a lot more going on with MDT 2012 than just boot media changes… more on that later.