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.
    Drivers_01
  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:
    Drivers_02
  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:
Drivers_04

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

Advertisements

Quickly Applying MBAM Policy

Implementing Microsoft Bitlocker Administration and Monitoring (MBAM) is a great way to manage Bitlocker on your devices and can be quickly included in the deployment task sequence so that devices are encrypted as part of the task sequence and policy is enforced right from the start… almost.

My preferred way to implement MBAM during an OS deployment is to configure Bitlocker to use the protector “TPM Only” and encrypt the disk as part of the task sequence.  Once the deployment is complete the computer reboots and Group Policy is then applied.  In this Group Policy are the MBAM policy settings that dictate that devices should be protected by both the “TPM Only” and “Startup PIN” protectors.  Therefore, when the MBAM agent refreshes policy, it realises the discrepancy between how Bitlocker is currently configured (TPM Only) and what Group Policy is stipulating and then goes ahead and prompts the user to configure a PIN via the MBAM GUI.

Doing it this way works great except for one simple fact: you need to wait for the MBAM agent policy refresh cycle to run and display the GUI to the user to resolve the configuration discrepancy.  This can take up to 90 minutes which means that during this time window a device is not configured with the Startup PIN as required.

If you don’t want to wait for this policy refresh you can shortcut it by using the below trick.

 

The MBAM agent actually detects straight away that the configuration set on the device does not match Group Policy and logs an error 2 event in the MBAM event log, but it doesn’t display the MBAM GUI immediately that obliges the user to add the PIN.  You can use the Windows Task Scheduler to attach a task to this event so that, when it is logged, the GUI will be loaded immediately.

The below screenshots show the configuration I use in the scheduled task.

I publish the scheduled task via a Group Policy Preference which means that it is automatically deployed to all in-scope computers as soon as they are built.  Doing it this way means it can be centrally managed and updated easily.

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:

http://download.microsoft.com/download/5/7/A/57A4F5B1-FB4B-478A-B780-7A834B24C835/May%202014%20Pro%202%20FW.zip