- How to create a PowerShell alias - Tue, Jul 29 2014
- System Center Updates Publisher – Create a SCUP catalog - Fri, May 23 2014
- System Center Updates Publisher – Third-party patch management - Wed, May 21 2014
If you need to deploy a build to more than one model of hardware, you are going to have to download, install and manage dozens of device drivers. There are three challenges at this point: identifying all the unknown devices, installing the correct driver for each, and then capturing all the details. The result forms a master driver repository to document the drivers for each model that you import to MDT or SCCM. As there is nothing in the WAIK or MDT to help, I’ve collected my own toolkit. I use NirSoft’s DevManView for identifying devices and Double Driver to help create a backup repository.
DevManView
Driver deployment tool DevManView
Sometimes after downloading and installing all the OEM’s drivers, you get a mystery device which you can’t match with anything from the manufacturer's list of available drivers, leaving you scratching your head and wondering what it is. The machine below (in figure 3) is an HP laptop missing its driver for its webcam.
In Device Manager, it appears with a yellow exclamation and the the name "HP Integrated module". That is no help, so the key to unlocking the mystery is the plug and play ID (PnP ID) that you can see listed as the Device Instance ID column. Using Device Manager to get this key information is clumsy at best.
DevManView is a deceptively simple alternative to Device Manager. The advantage is that it exposes device plug and play IDs in its interface. When you have several devices missing, this view makes things so much easier than wrestling with Device Manager. You can easily hunt down each mystery device directly, by entering each PnP ID into the superb PCIdatabase.com to identify the vendor and the device, respectively.
Double Driver
Using Double Driver to backup OEM drivers
Once I have got all the drivers and installed them manually, I run Double Driver (v4.1). It supports both 32-bit and 64-bit and is portable. My main use for it is to capture OEM, non-Microsoft drivers of new hardware before you wipe the hard disk and put your own image on it. This is the default selection. The other use is to save all driver details using the "save" button when your new build is complete, as part of your documentation. Note it only saves the list of drivers as plain text.
DoubleDriver backup options
DriverInfInfo
If a plain text list of drivers is not quite good enough, then Michael Murgolo from Microsoft consulting has written DriverInfInfo.vbs that will help. It will delve into your driver repository and pull out the version, plug and play IDs, descriptions and the providers from all inf files it finds, and write to an INI, CSV or XML file.
Drivers.exe and Dpinst
Drivers.exe is available from the Windows 2000 resource kit, and simply lists loaded drivers. It is old-school but you might still find a use for it.
On rare occasions you might discover a device, install the correct driver only to find it refuses to install through MDT or SCCM. Microsoft has a secret weapon that many manufacturers use, called Dpinst. If you call this from the command line, it will install silently. The one inconvenience is you can only get it as part of Windows Driver Kit (WDK) 7.1.0. Full details are here.
