Install Driver EXE Package (New Tool) November 2, 2009
Posted by keithga in MDT 2010, VBscript.2 comments
New Tool! ZTIInstallDriverExePackage.wsf
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 3rd 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
ZTIInstallDriverExePackage.wsf
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupBackground on Driver Installation in MDT November 2, 2009
Posted by keithga in MDT 2010.1 comment so far
Most Drivers are installed via an *.inf file. These *.inf files contain all the meta-data needed to define what a driver does, what devices it’s used for, and how it’s installed, including files, registry keys, and any other custom action(s).
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
Keith Garner is a Deployment Specialist with Xtreme Consulting GroupTools Week at Xtreme Consulting Deployment Team November 2, 2009
Posted by keithga in Announcements.add a comment
Got some tools to share this week.
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!
Do you have an idea, and need someone to execute it?
We are here to solve your Deployment Challenges. Large or small.
Keith
Keith Garner is a Deployment Specialist with Xtreme Consulting Group