About Jacob.Elert

This author has not yet filled in any details.
So far Jacob.Elert has created 1 blog entries.

A Wrinkle with a Bundled Wireless Driver and DPInst32…

2017-07-27T00:01:04+00:00 February 20th, 2013|Uncategorized|

Fellow Coreteker Scott DeLand and I were recently working on a “QC” for some bundled wireless drivers, for which the customer used DPInst32.exe to install the drivers.  After the wireless driver folder has been installed to C:ExamplePath, DPInst is launched to install that driver.  Here’s what the launch action originally looked like in ZENworks Configuration Manager (ZCM):

Command:
${WinDisk}ExamplePathCompanyWireless DriverDPInst32.exe

Command Line Parameters:
/s /PATH ${WinDisk}ExamplePathCompanyWireless Driver

Working Directory:
${WinDisk}ExamplePathCompanyWireless Driver

There were a few problems with this, though.  For one, all of the installed driver folders had spaces in them.  When spaces are present in the command line parameters for some executables, they will fail without special care… and DPInst is included in this list. 

The other problem was that the install wasn’t creating an OEM file in C:Windowsinf.  When a new driver is installed, it should create a new OEM file with an incremental counter… so if the last OEM file was OEM94.inf, the next driver install will create an OEM file called OEM95.inf.  Scott pointed out that the drivers weren’t creating a new OEM file… were they really working? 

We tested with the command line and found that if we didn’t use quotes around the /PATH parameter and the parameter contained spaces, DPInst would not work.  Now the Command Line Parameters looked like this:

/s /PATH "${WinDisk}ExamplePathCompanyWireless Driver"

But there was still another problem:  On some machines, this action would fail with an exit code of 768 — and on some bundles, a new OEM file wouldn’t be generated.  Exit code 768 occurs when there is already a wireless driver on the machine, which we discovered previously.  We solved the new issue by adding code 768 as a success return code in the launch action, allowing the process to complete.  The other thing that was discovered was that if the driver was of the same type as another already installed driver, it wouldn’t create a new OEM file.

I thought I’d pass this along to see if it might help others!