Updated Hardware Detection Script

Or… How Not to Create Boolean Properties in an MDT Script

I my posts about Windows XP Tablet PC Edition 2005, I provided a script that could be used for detecting Tablet PC digitizers or an set of devices by Plug & Play ID (ZTI-DetectHardwareExit.vbs).  My customer has been using this script for months in Windows XP deployments without issue to determine if the target PC was a Tablet PC and apply the correct OS image. This was until the customer tried the first European deployment in Italy.

When they first tried the XP deployment it failed on the Apply Driver Package step.  We found that no OS had been applied and the Apply Driver Package was trying to work against the Windows 2000 OS still on the disk.  After troubleshooting we discovered that the way I was setting the IsTablet value (the return value of the DetectDevices function) in the script was the cause.  MDT Properties are strings, so to convert the Boolean value in my script to a string I simply used the VBScript CStr function.  What I failed to realize is that CStr will do a language specific conversion of the Boolean to a string.  So when the language was set to Italian, the IsTablet property was being set to either “Vero” or “Falso” instead of “True” or “False”.  Since our Apply Operating System Image steps in the Windows XP Task Sequences were conditioned on whether IsTablet equals “True” or “False”, no OS image was being applied.

Once I realized what was happening, I looked to see how ZTIGather.wsf was doing the Boolean to string conversions.  Lo and behold, the MDT Team had, of course, made accommodation for this.  ZTIGather.wsf has a ConvertBooleanToString function that performs “a Cstr operation manually to prevent localization from converting True/False to non-english values”.  Once I changed the script to use the ConvertBooleanToString function, it worked correctly with the Italian language machines.

I have place an updated version of ZTI-DetectHardwareExit.vbs in the download for the previous post.  This version also has some additional changes based on another issue we encountered.  The installations in Italy were done using DVD media.  The ISO files were copied over the customer’s WAN.  Some of the ISO images did not copy properly.  On some of the DVDs, the Microsoft.BDD.PnpEnum.exe utility was corrupted.  The caused the utility to simply do nothing.  Since the text file generated using this tool was now blank instead of containing the needed XML data, my script was failing.  So I’ve included additional error checking and when an error occurs the return value will be the string “Error”.  This was done to allow the ability to optionally fail the Task Sequence when an error is encountered in ZTI-DetectHardwareExit.vbs.  My customer wanted the Task Sequence to fail if the IsTablet properly was not properly set because either no OS or the wrong OS would be applied.

The CustomSettings.ini entries for enabling this failure on error should look like this (changes for this in red):

[Settings]
Priority=IsTabletCheck, ByTabletType, Default
Properties=MyCustomProperty, TabletPnpIds, IsTablet, XPTabletProductKey

[IsTabletCheck]
TabletPnpIds=ACPI\WACF004,ACPI\WACF008,ACPI\MAI3310,ACPI\FUJ02E5
UserExit=ZTI-DetectHardwareExit.vbs
IsTablet=#DetectDevices("%TabletPnpIds%")#

[ByTabletType]
Subsection=Tablet-%IsTablet%

[Tablet-True]
XPTabletProductKey=XPTabletProductKey=AAAAA-BBBBB-CCCCC-DDDDD-EEEEE
OSInstall=Y

[Tablet-False]
OSInstall=Y

[Tablet-Error]
OSInstall=N

[Default]

When OSInstall=N, the step in the Task Sequence that runs ZTIValidate.wsf will exit with failure.

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use .

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region.