OSD Driver Management the easy way…

Driver management in OSD has always been a hot topic for deployment folks. If your using ConfigMgr for deployment you have the option of Applying Driver Packages or Auto-Apply drivers. There have been many posts over the years to discuss the merits of both so I won’t go over old ground…but if you want a refresher please refer to the many posts from @mniehaus and @jarwidmark

Back when Windows 8 was released and everyone was preoccupied with the Start Screen a new command was added to DISM to add drivers to an offline image. This command combined with a standard ConfigMgr package containing driver inf files gives us a third driver management option in ConfigMgr. I had never thought of using the command during OSD until I read @agerlund mention this in a tweet a few months back and I thought I would give it a go.

This is how it works:

  1. Download drivers for the chosen model from the vendor website.
  2. Extract drivers to a source folder and remove any unnecessary drivers (this is important…don’t include everything…only what is needed. Weed out drivers for other OS’s and different architectures.)
  3. Create a standard ConfigMgr Package (Not a driver package) pointing to the source folder containing the drivers. No program is needed.
  4. Edit your Task Sequence and add a “Run command Line” step in the “Post Install” phase of the Task Sequence…immediately after the default “Auto Apply drivers” step.
  5. Rename the Step to something more appropriate.
  6. Add the following command line:

    DISM.exe /Image:%OSDisk%\ /Add-Driver /Driver:.\ /Recurse

  7. Tick “Package” and browse to the package you created in step 3:
  8. Add a WMI query condition for the model you are deploying.
  9. Save changes.
  10. Deploy the Task Sequence

This is what the logs look like:
Driver Package method:
Drivers_03DISM Add-Driver Method:

As you can see from above, DISM does a pretty good job logging out to SMSTS however if you want to run a post deployment verification check you can run the following PowerShell command to ensure all the drivers have been successfully added to the driver store:

Get-WindowsDriver -Online -All | ? {$_.Inbox -eq $false} | Select-object -Property OriginalFileName

Why I like this option:

  1. It’s simple. No need to import drivers into the ConfigMgr driver store which has always been slow and clunky. You can pretty much do away with the driver store completely unless you want to add drivers to boot images through the console.
  2. It’s quick. In my limited testing I found this to be quicker than applying the same drivers with a Driver Package (via unattend.xml). Around 40% faster in my test on a Surface Pro 3.

The downside is that as this is a legacy package it will not benefit from single instance storage…so takes up more space on DP’s if the content is duplicated.

Also note DISM with the recurse parameter will import every driver conatined in the package into the driver store. So keep the drivers clean.

. Surj


Surface Pro 2 Firmware and OSD problems

I’m currently working on a Windows 8.1 project and recently needed to deploy a number of Surface Pro 2 devices.  This should have been a pretty straight forward task but I started to see random failures during the Task Sequence.  I was using a Configuration Manager 2012 R2 Task Sequence (with MDT 2013 integration) and the latest Surface Pro 2 Driver/Firmware set (March Update).  The issues occurred only on certain machines where I would see application installation hangs during the build process and general instability of the build process.

After a bit of investigation I was pointed to the following KB Article:

KB2963062: Surface Pro 2 devices intermittently cannot boot past the UEFI screen

Although the symptom does not describe my issue the following does make me wonder if there were other issues with the march update:

This problem occurs because of a negative interaction between new libraries in the March 2014 UEFI update, and hardware components on a very small percentage of Surface Pro 2 devices. This interaction results in a timing issue in which the hardware component is not ready for the instructions that it receives from the UEFI, and this results in the boot process being unable to continue. Subtle differences in hardware component tolerances cause this problem to occur more frequently on some devices.

The KB Article links to an updated version of the Firmware and by injecting the new firmware into the my driver package for the Surface Pro 2 I was able successfully build again.

Moral of the story….if you are deploying Surface Pro 2’s make sure you update the firmware in your driver pack to this version: