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

DISM Cmdlets fail to run in Win PE with MDT 2013 Update 1 – WORKAROUND

Whilst working with Windows 10 and MDT 2013 Update 1 my colleague Graham Hardie and I ran into an issue which was preventing us from running DISM Cmdlets in Win PE.

The issue became apparent whilst trying to implement Michael Niehaus’s Windows 10 Inbox App Removal script and specifically trying to run the script offline in Win PE.

The MDT boot Image was successfully generated with the MDAC, .NET, PowerShell and DISM Cmdlets features but would fail to run the “Get-AppxProvisionedPackage” Cmdlet with the following error:

Get-AppxProvisionedPackage : The ‘Get-AppxProvisionedPackage’ command was found in the module ‘Dism’, but the module could not be loaded. For more information, run ‘Import-Module Dism’.
At line:1 char:1
+ Get-AppxProvisionedPackage -Path e:\
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : ObjectNotFound: (Get-AppxProvisionedPackage:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule

We found that the Microsoft.Dism.Powershell.dll file was becoming corrupt at boot up…not had the chance to investigate what exactly is causing the corruption yet.

However, to workaround the issue you need to do the following:

  1. Delete the file from:
  2. Copy the file back down to the X: drive from the Deployment share:

You can obviously automate this as part of your Task Sequence. I simply added two ‘Run Command Line’ steps to Delete the file and copy the new file.  The steps need to be added before you run any script which has a dependency on DISM Cmdlets…in our case before Michael’s Inbox App Removal script:

The first step:

Command Line:

cmd.exe /c Del “%SystemRoot%\System32\WindowsPowerShell\v1.0\Modules\Dism\Microsoft.Dism.Powershell.dll” /q /s

The Second step:

Command Line:

robocopy Z:\Servicing\x64 X:\Windows\System32\WindowsPowerShell\v1.0\Modules\Dism Microsoft.Dism.Powershell.dll /is

Note: Add Error Code 1 to Success Codes for this step…robocopy can report a success with a non zero return.

A bug has also been opened on Connect.

Let us know if this works for you or better still if you identify the root cause of the issue.