Blog Posts tagged with Driver Deployment

Ask a question

Driver Installation from an MSI using Microsoft DIFx

Creating a driver installation in an MSI can be a challenging task. One of the more popular methods to achieve this is to use Microsoft's Driver Installation Framework (DIFx).

Microsoft provides documentation on DIFx, however it is limited and doesn’t provide any examples.

This article provides a step by step working example of how to achieve this task. For this purpose, we are going to create a Windows XP installation for a Signed Driver: ‘Synaptics Touchpad’ with Wise Package Studio.


Step by Step - Creating a driver installation with DIFx using Wise Package Studio


1.  Create a new Windows Installer (WSI) file


Work bench –> Tools–> Windows Installer Editor



If you do not get the ‘New Installation File’ window shown below, select File –> New from the main menu inside Windows Installer Editor

(by default, the last edited .WSI file will be opened).


Select Windows Application



Inside Installation Expert, complete the relevant fields under Product Details and General Information



As this will be a Driver only installation we are renaming the default Wise feature from ‘Complete’ to ‘Drivers’.

Note: If your own installation is to also contain non driver files (e.g. captured application files). Ensure there is a SEPARATE feature which will contain these.


Installation Expert –> Features

Rename the default feature from ‘Complete’ to ‘Drivers’



2.  Next, we add the DIFxApp Merge Module to the ‘Drivers’ Feature


Merge Modules –> Add



Select the DIFxApp Merge Module and click Next then Finish

(if the Module is not present select ‘Download’ then ‘Wise Web Site’ to obtain it)


Note: Make sure you are using at least version 2.0 of DIFxApp Merge Module.



The DIFxApp Merge Module should then be visible.



3.  Create a folder EXCLUSIVELY for driver files.


Note: If there is more than one driver (not the case with our example), there must be a SEPARATE folder for EACH driver and associated files.


Open the Filesview, then in the bottom window Right Click on ‘Program Files’ and select ‘New Folder’



For purposes of our example, we are calling the new folder 'TouchpadDriver'


Name the folder and click OK



4.  Add the relevant driver files


To save experiencing a common problem (this issue will be detailed later), ensure the synpd.inf file is added FIRST. Doing this step ensures the .inf file becomes the KeyPath for the component to contain the driver files.


Highlight the ‘TouchpadDriver’ folder in the bottom left window, then select ONLY the synpd.inf file in the top window and click the Add File button.



The synpd.inf file should be visible in the bottom right window as shown below.

Next, add the remaining files to the ‘TouchpadDriver’ folder:


Check the ‘TouchpadDriver’ folder is highlighted in the bottom left window, then select the remaining files in the top right window and click the Add File button.



Tip: Some drivers have several different folders containing the relevant files. If this appears to be the case, check the entries of the .inf file to see if there are references to files in a subfolder(s). 

If so, you may need to modify the file path entries in the .inf file, to allow all the files to be in ONE root folder.


All files for a specific driver need to be in one root folder along with the .inf file for a successful installation via DifX.



5.  Configure Driver Installation Options


Double click on the synpd.inf file in the bottom right window to set driver options.


Installation Expert –> Files –> synpd.inf



Select the Driver tab



What to do if there is no Driver tab

Note: If the Driver tab IS present, skip to the next section: ‘Configure Driver Installation Options (Continued)’


This is a common problem with a relatively straight forward solution.

Open Setup Editor from the bottom of your screen and select the Components tab at the top of the left window.

Expand out each component in the left window and look in the relevant Files section until you find the synpd.inf file.


In our example below, the component containing the .inf file is called synpd.inf. We can see that there is a small yellow key icon beside the in the synpd.inf file in top of the right window.

This means that the file is the KEYPATH for the component it is in.


Setup Editor –> Components



If the yellow key is NOT present beside the .inf file then it needs to be enabled:

Right Click on the synpd.inf file and click Set as Key



Note: If you are familiar with using the MSI Tables, the same as above can be achieved there: Reference synpd.inf in the File table to find the relevant component name.

Then, edit the KeyPath of the matching entry in the Component table.




Configure Driver Installation Options (Continued)


Under the Driver tab, ensure the ‘Use DIFxApp to install this driver file’ option is enabled.


Enable the DIFxApp Installation Options to meet your preferences (these are described below).



DIFxApp Installation Options


Retain better-matching Pnp function drivers

Enabling this option will keep an existing Plug and Play driver on the computer if it is seen to be a better match (“better match” means if there is a signed and/or newer driver already on the computer this will be retained and the driver in this installation will not be installed).

If you clear this checkbox, the installation's driver will be installed and over-ride any existing driver on the computer.


Prompt for missing device

Enabling this option gives a prompt and the end of the installation. This will occur if the matching device to the driver is NOT connected to the computer.

Note: Even if this option is enabled, the prompt will NOT appear under a silent install.




Create entry under Add/Remove Programs

This will add an entry under Add/Remove Programs for the driver(s) installed in ADDITION to the standard entry for the MSI installed.



Configure the above DIFxApp Installation Options to your preferences then click OK to confirm.



OS Specific Launch Condition

Once all the steps above have been completed, consider what version of OS the driver is intended for. An ‘accidental’ rollout of out a Windows XP Driver Package to a Windows 2000 PC may not give very desirable results!


The best safeguard is to condition the installation so it will only install on the intended OS.

This can be achieved through setting System Requirements.


Under Installation Expert in the left window select System Requirements.

The relevant options to configure are Windows Version and Windows NT Version. These are shown highlighted in the right window below. Double click to edit them.


In the case of our example our driver is intended for Windows XP, so we have set Windows Version (i.e. Windows 95, Windows 98 etc) to ‘Not supported’.

Also the Windows NT Version has been set to ‘Windows XP’.


The Message Text field defines the actual message to display if the OS Condition is NOT met.


Installation Expert –> System Requirements



Once this has been completed, compile your MSI and the Driver Package is ready to go!



Behind the Scenes - What's happening in the MSI Tables


The key table involved for a driver installation using DifX is the MsiDriverPackages table. The use of each column is as follows:



Should have the name of the component containing the .inf file for the driver.



A number which defines the type of driver to be installed, (Signed or Unsigned) along with the specific Installation Options.



Controls then install order of drivers (if there is more than one driver, lowest number installs first).


Setup Editor –> Tables –> MsiDriverPackages



The following are common examples of values for the Flags column:


Signed Driver Installation


7 = Signed driver install (Standard install with no options configured)

6 = Signed driver install + “Retain better-matching PnP function drivers”

5 = Signed driver install + “Prompt for missing device”

3 = Signed driver install + “Create entry under Add/Remove Programs”



Unsigned Driver Installation


8 = Unsigned driver install (Standard install with no options configured)

14 = Unsigned driver install + “Retain better-matching PnP function drivers”

13 = Unsigned driver install + “Prompt for missing device”

11 = Unsigned driver install + “Create entry under Add/Remove Programs”


Note: Officially, the valid range that can be used in the Flags column is a number between 0 – 7.

Because unsigned driver installations are ‘unsupported’ by Microsoft, the range for unsigned driver installations is 8 and above. Any of these options will show up as a table error (in addition it will appear as an ICE error if a validation is run). This is normal.




Tip: For an unsigned driver installation you won’t be able to set the options via the interface in Wise (using the Driver tab of the .INF file). You will need to go into the MsiDriverPackages table and set the Flags value directly.




Jeremy Boyes                          

February 2011


View comments (7)

Unsigned Driver Packaging


Unsigned Driver Packaging

Assumption: You have the .inf file and the .sys file. Sometimes you don’t even have the .sys file.

Packaging Tool: Wise Packaging Studio 8.0 (You can also do it using ORCA or InstallShield). Need the DIFx Merge Module. Copy the Merge Module into the …\Wise Share Point\Merge Modules folder.

Driver Tools: Download MS Platform 2003 SP1 SDK and MS Windows Driver SDK v7 (Need dpinst.exe and Inf2Cat.exe). Need the following files.

Steps to create the certificate and catalog file

Step 1

Run the following command

Makecert.exe-r-svXYZGGC.pvk-n"CN=XYZGGC" XYZGGC.cer

Provide a password twice; make sure it’s not a strong password. I have used password as the password

XYZGGC.cer and XYZGGC.pvk will be created.

Step 2

Run the following command

Cert2spc.exe XYZGGC.cer XYZGGC.spc

It creates XYZGGC.spc

Step 3

Run the following command (the password needs to be same as the above)


Creates an XYZGGC.pfx file.

Step 4: Creating catalog file for the driver

Run the following command

Inf2cat /driver:" C:\UnsignedDriver\Drivers" /os:7_x86,XP_X86 /verbose

You might get some errors


Some common errors and fixes:

For Win7 date should be after 4/21/2009.

Add the entry CatalogFile.ntx86=DhrunAK128.cat after the DriverVer. DhrunAK128 is the same name as the inf file.

If the driver comes with addition files, then they have to be added under the [SourceDisksFiles] in the inf file.

So you have a catalog file dhrunak128.cat

Step 5: Signing the catalog file

Run the following command

Signtool sign /f XYZGGC.pfx /p password /t

http://timestamp.verisign.com/scripts/timestamp.dll /v


Needs the same password as used earlier on.

Now we have a signed off certificate for the catalog file.


Making the Driver Package using Wise Packaging Studio


Open Wise Packaging Studio

Select Windows Installer Editor

Select Device Driver

Rename the Default Feature(Complete) as DriverDriver

Go to Merge Module and add the DIFxApp Merge Module in the feature Driver. Next > Finish

 Create a folder with a name of your choice under program file for the driver files and make it the INSTALLDIR.

In case of multiple drivers create separate folders for each one inside the INSTALLDIR. Make sure that the files are not in the same folder.

Now add the .inf, .sys, .cat and other files(following the same folder order as supplied by the vendor) in the respective driver folders.

Now go the components of the .inf files and make sure that the .inf files are the key files for the components.

Now click on the .inf file of one driver and select details.

Now go to Drivers and tick the Use DIFApp to install this driver file box.


Do the same for the other drivers. You can see the Driver Installation Order as you keep on adding driver installation.

Now for Unsigned Drivers you need to import the certificates before installing the drivers.

For this you need to write a custom action and also add the certificate manager and the certificate (created above) in the installation.

Create a folder under the INSTALLDIR named Cert and put the CertMgr.exe and the XYZGGC.cer in the folder.

Now go to MSI Script and you need to add two custom actions.

The CA should be after the BindImage Action. Add an End Statement.

Now Select Execute Program from Installed Files.

Give a Name, Call the CertMgr.exe by browsing to the required target folder inside installation.

Add the command line

-add“C:\Program Files\******\Cert\XYZGGC.cer”-s-rLocalMachine TRUSTEDPUBLISHER

For properties select, Deferred Execution in System Context and Synchronous , Ignore Exit code.


Just after this Custom action add another similar Custom Action with a different Command Line Argument

-add“C:\Program Files\*****\Cert\XYZGGC.cer”-s-rLocalMachine ROOT

Add an End Statement.

Now compile the WPS Project file to get a msi.

Now open the msi with WPS.

Go to the InstallExecuteSequence Table.

Make sure that the sequence number for MsiProcessDrivers is higher than the Custom action you have created to import the certificates.

Recompile the MSI.

Be the first to comment

DIY Driver Feed

We have lots of Dell machines that don't seem to pick up all their drivers from the K2 Driver Feed.  The typical solution posted here seems to be to create post-install tasks that install specific drivers.  That's well and good if you want to manage a dozen different image options.  I don't want to do that, I want to have a single image option for our gold master image that will always install every driver for any model.

So I have devised a way that accomplishes this.  I have this script setup as a post-install task:


title Installing any missing drivers, please wait...

FOR /F "tokens=2 delims==" %%A IN ('WMIC csproduct GET Name /VALUE ^| FIND /I "Name="') DO SET machine=%%A

ECHO Computer model: %machine%

net use w: "\\servername\share\%machine%" password /user:domain\user

call w:\install.cmd

net use w: /delete

The script uses the computer model as a variable to map to specific folders on a server share. Inside of these folders I have placed the drivers for each particular model that the K2 doesn't install (for whatever reason).  I have also placed a "install.cmd" file at the root of each folder with variations of the following commands:

@echo off

echo Installing video...
start /wait w:\video\setup.exe -s echo Installing chipset...
start /wait w:\chipset\setup.exe -s echo Installing USB 3.0...
start /wait w:\usb3.0\setup.exe -s echo Installing freefall sensor...
start /wait w:\freefall\setup.exe /s

When this post-install is used in conjunction with the RunOnceEx Convertor, the install.cmd file will be called during the first logon and will map to the share with the drivers.  Because the variable will change which folder gets mapped, I only need this one post-install task regardless of what model is being imaged.  As long as I have a "install.cmd" file inside of each folder, I can edit them separately and never touch the post-install task

View comments (3)

Driver Feed Builder

Driver Feed Builder - version 3.0

This portable application tool will allow users to harvest drivers from the current workstation using Double Driver or by downloading drivers from vendor websites and extracting the executibles (when applicable).

The tool makes a WMI call on the workstation to get the model name of the workstation, and either harvests the drivers of the current workstation or extracts drivers from specified executibles and uploads them to your K2000 in the appropriate drivers_postinstall directory.  See the help file in the application for full instructions of usage.

This tool was created by employees of Quest | KACE, but is not officially supported.  If there are issues or bugs that exist, please use the comment section below for reporting these issues.

Scripting Ninjas responsible for this tool:
Kent Feid - concept creator, author of version 1
Corey A. Serrins and Patrick Warme - code additions for version 2


Download Driver Feed Builder version 3
*Quest Software Support credentials are required for download

Back to K2000 Deployment Workbench

Release Notes


Release Date

Summary of changes











-rebranded to Quest
-if model or manufacturer is empty in WMI use temp values instead so feed doesn't fail (driver can then be placed manually)
-check for drvstr.cfg when looking for mapped drives
-if drvstr.cfg file cannot be found, download from service
-if drvstr.cfg was downloaded from service, there was probably an issue with mapping, so copy driver folder to script location to be sent to K2000 manually.
-added ability to save drivers locally instead of mapping to the K2000
-added additional debug logging

-added Windows 10 support

-minimum version is now 3.7.113224 to support drvstr.cfg file
-revamped UI to look like K2000

-added ability to use Driver Feed Builder as a portable app -moved settings to registry or to ini file if portable
-moved some gui objects to menu items
-changed password encryption to AES 256
-changed Lenovo to use friendly name from WMI -added model excepts for Venue 11, XPS 13, XPS 15 -removed periods and commas in model names. -updated documentation
-fixed defect when drivers_postinstall was already mapped
-set focus of gui to ip address to start
-Full logging can be invoked with the /debug commandline switch or pressing shift-alt-d hotkey -checks for updates automatically
-added an installer

-added progress bar for harvesting drivers

-added ability to remember the K2000 IP address and password
-added the ability to harvest drivers using Double Driver
-modified UI so that user chose between harvesting and extracting and added disabling controls depending on option
-added error checking for mapping network drive.
-version 3.6 ready



-added in 3.5 support



-fixed missing logo on exit screen
-change folder name to match name of driver.exe
-added in help option



-initial GA release

View comments (17)

A syncretic overview on how driver management works in K2000 3.5 & 3.6

After joining the Dell KACE Training team I started to learn the  K1000 and after that I started to dig in the K2000 secrets. 
It is a really nice and powerful product, very flexible and expandable but one thing over the others was surrounded by mystery (at least that was my feeling of novice user): the driver management!

I started to read articles here and there, asking to friends and colleagues, watching various videos and I found out that there are many ‘’doctrines’’ and pieces of information spread all over the places that you need to know to unveil how the driver management mechanism was really working.

After studying all the available material I wrote my first “syncretic” article about the K2000 3.4 version that you can still find here:


The introduction of K2000 3.5 introduced some nice changes simplifying a lot the driver management and avoiding the need to create and use the famous "Driver Feed Workaround" so I thought to write a new and updated “syncretic” article for the 3.5 & 3.6 users.

I do not have the presumption to have discovered something revolutionary or have written a complete and ‘’dogmatic’’ document so please comment it if you have something to add or if I wrote something not exact.

The K2000 exposes 3 shares:

  • drivers
  • drivers_postinstall
  • restore

What are these folders for?

Let start with the DRIVERS folder

Under this folder there is a folder for every OS supported and two folders for KBE, one for the KBE 32 bit and another for the KBE 64 bit.

What drivers you need to have under the KBE folders?

In these folders you need to put the drivers for storage and network: so the bare minimum drivers needed for the KBE to be able to access the disks of the device where it is booting from and the network to talk back to the K2000.

Do not add to these folders drivers for video, sound or strange devices not really needed: remember that KBE exists only in the memory and it will be totally gone after the reboot.

How to add drivers under the KBE folders

Excluding the feed folder that is automatically created and managed from the Driver Feed functionality you need to create a new folder, the name does not matter but I’d suggest you to name it using the brand of the machine the driver belongs to.

Under that folder I suggest you to create a subfolder with the name of the driver and put the driver files there.

NOTE: if the driver is included in a single EXE or MSI you need to extract the files and put them under the folder: we cannot install EXEs or MSI as driver in this phase.

Which driver’s platform I need to add for KBE?

KBE 32 is a special version of Windows 7 32 bit and KBE 64 bit is a special version of Windows 7 64 bit, so you need to download drivers for Windows 7 32 or 64 bit to be added to the KBE folders.

If you are you using the AIK for Windows 8 (WinPE 4.0) to build your KBE you will need to use the drivers for Windows 8 32 or 64 bit and you used AIK for Windows 8.1 (WinPE 5 .0) you will need to use the drivers for Windows 8.1 32 or 64 bit. The following table clarifies the drivers you will need: 

If you are using It contains   and you need to use these drivers in the KBE folders
WAIK for Windows 7 WinPE 3.0 use drivers for Windows 7
AIK for Windows 8 WinPE 4.0 use drivers for Windows 8
AIK for Windows 8.1 WinPE 5.0 use drivers for Windows 8.1

IMPORTANT Due to the fact that there are only 2 folders for KBE drivers, one for the 32bit and the other for the 64bit version, and not a couple of folder for every type of WinPE/WAIK, remember that only one type of drivers at time can be in that folder.

Do not mix Windows 7, Windows 8 and Windows 8.1 drivers in these folders.

If you previously built a WinPE 3.0 based KBE and now you want to build a WinPE 4.0 based KBE you need to delete all the drivers from the two KBE folders and put under them the drivers for Windows 8.

For Dell hardware we made available the Dell KBE Drivers packs. You can find them here:  http://www.kace.com/support/resources/kb/solutiondetail?sol=SOL111717 

After adding the drivers under the KBE folders we need to recache the drivers (in the web interface click on Library -> Drivers and choose the action Recache drivers).            

After recaching the drivers you need to rebuild the KBEs using the Media Manager utility: it will use the WAIK installed on the machine to rebuild the KBE and will inject automatically in it the drivers you added in the KBEs folder that are under the DRIVERS share.

NOTE: when you use Media Manager do not name the KBE as a name of a KBE that already exists: the Media Manager is not able to overwrite an existing KBE.

How and which kind of drivers you need to add under the OS folders

Under the OS folders you need to add, as in the KBE folders, the bare minimum drivers that the scripted installation of Windows needs to run effectively, so again: network and storage drivers only.

After adding the drivers under the OS folders (you can organize them as for the KBE folders) you need to recache the drivers.

If you added drivers only to the OS folders but not to the KBE folders you do not need to rebuild the KBEs with the Media Manager.

The drivers_postinstall folder

Under this folder you need to add all the drivers that the machine will need after the scripted install is finished (so for its ‘’normal life’’) : storage, network, audio, video etc etc…

If your machine is a Dell machine the Driver Feed functionality does most of the job for you: under Library -> Driver Feed you can search for the device you need to image the OS to and download the driver packages: job done!

If your machine is not a Dell machine or you need to add additional drivers you will need to add them under this directory but how??

The folder names and structure is not so context free as for the DRIVERS folder

The folder structure under the DRIVERS_POSTINSTALL is the following:

<Manufacturer name>\<OS Name>\<Model name>

It seems complex but is not: we have a script that will help you to determine the name of the manufacturer and the name of the model: they are taken from the BIOS.

Simply execute on the machine this VBscript program:


This script will show you the exact manufacturer and model name of that device.

After you press the OK button you may see some other message box and sometimes a script error: no panic! is all ok..simply ignore them.

So in this case where do you need to put the drivers?

\\<your k2000 box>\drivers_postinstall\dell\ windows_7_x64\E6420\

Under this folder I suggest to create a folder for each driver and put under that folder all the files needed. Once again: if the driver is shipped as a monolithic ZIP, EXE or MSI you will need to extract the files and put there under the folder.

If you want to install an “applicative driver” (and EXE or MSI that install drivers) you can do this as a post installation task or through the K1000 once the system will have a K1000 agent with a software distribution job.

If you added drivers only to this folder without touching the DRIVERS folder you do not need to recache the drivers.

It is fundamental that under the drivers_postinstall you name correctly the folders.

Imaging vs. Scripted Install

If you only use scripted install and you have followed the entire article so far you are done! No other steps, other than test your solution, are needed. Big success!

If you are deploying an image with K2000 3.5 or 3.6 there are only two things to remember to be able for the driver management mechanism to work:

  1. The image you captured need to be a "sysprepped" image. (prepared and closed with SYSPREP before to capture it)
  2. You need to remember to flag the checkbox "Use driver feed"

The RESTORE folder

This folder is not used for the drivers mechanism but it is used to import and export packages.

So if you export a software distribution job from the K1000 you will need to copy it there to import it in the K2000


Thanks to all my colleagues that helped me to understand better this technology.

View comments (5)
Showing 1 - 5 of 7 results

Top Contributors

Talk About K1000 Asset Management