DISM Apply Drivers – TSProgressUI SubBar

Did you move to using Standard Packages instead of the native driver packages in ConfigMgr years ago? Why use standard packages, and the DISM command instead of importing drivers and using the built in native functions? I’ll tell you why I do, Flexibility and Automation, and the cool people like Johan are doing it.

TLDR: Script: garytown/OSD/CloudOSD/TS_DISM_Drivers.ps1

Relevant Links

• Apply Driver Package – Recast Software
• Apply Package of Drivers Manually (DISM) – Recast Software
• Speed Up Driver Package Downloads for ConfigMgr OSD – Deployment Research

I’m going to skip covering the basics on this, as those other links will do a great job of that, and move right into the deeper dive of taking the TSProgressUI experience from the basic, to pretty.

Sample of Standard TS Progress Bar when Running the DISM Command via Command Line Step. Here I have the smsts.log open, you can see it is applying drivers using DISM, but the Progress UI just stays static until the step is complete.

The Original Step in CM Looks like:

Replacement Step:

I’ve moved to a PowerShell Script, which takes two parameters, the source path of where you downloaded the driver pack contents to (or for the really cool people, where you mounted your driver pack WIM to), and the offline windows image path.

Script: garytown/OSD/CloudOSD/TS_DISM_Drivers.ps1

I’m going to break this down a little bit… first off, I have borrowed the functions from sombrerosheep: sombrerosheep/TaskSequenceModule: Powershell Module (Wrapper) for Task Sequence COM Objects, this saved me a bit of time having to write them myself.

First Two Functions, Confirm-TSProgressUISetup & Confirm-TSEnvironmentSetup, these create the com objects for the Task Sequence and TSProgresUI, allowing you to interact with the objects and control them via PowerShell

Third Function, Show-TSActionProgress, this will create the Action Sub Bar in the TSProgressUI, which you need to feed several parameters.

Now, we get to the action part of the script. Here I do several write-outputs, which will go right into the SMSTS.log file.
DISM gets called, and runs the command to add drivers from the locations of your driver pack that you provided in the parameters. It writes the DISM information out to a log, and while it’s doing that, do loop runs, reading in that log file, cleaning up the log lines, and feeding them into the TS Progress UI Com Object. Pretty slick simple solution, eh?

To get the Counts (Step & MaxStep) needed for the function, I get a little creative, which I can do, since I know how DISM logs look, and I manually set the Step Value based on a few of the lines that could have been read in, but for the “Installing Y of X” section in the log, I do some create string selection to get the Y ($Counter) and X ($Total) values from the log line. [Yes, that’s a run-on sentence, but looking back, I don’t really feel like breaking it up]

With that information, I feed it in with the Show-TSActionProgress function like so:

Show-TSActionProgress -Message $Message -Step $Counter -MaxStep $Total -ErrorAction SilentlyContinue

When we’re done, the SMSTS.log file still has relevant info, plus a note to where it can find the actual DISM log file, and you had a nice pretty TS Progress UI bar that kept you in the loop (PUN INTENDED) while it was applying drivers.

DEMO

Images from OSD with TSDebugMode Enabled:

Note the fun you can have with TS Step Names to include dynamic information:

Summary

So wrapping up, this is a slick way to provide more information in the UI during OSD when you’re using DISM to apply drivers. Feel free to play with the start-sleep timer, as you can see from the SMSTS.log file, my 500 ms sleep was too long to catch every driver, but honestly, for me, I didn’t care, I really wanted a better experience in the UI, which I have.

Hopefully even these sparked other ideas how you could use these functions to improve the UI experience during OSD, to better keep those Imaging Technicians glued to the seat watching those progress bars. You know what happens when a progress bar doesn’t change fast enough….

And More…
The Driver Packs I have in my lab are created via PowerShell, Include important metadata information, and I can update the contents in an automated way as well. A couple of scripts run, and while later, and lots of downloading, and all my driver packs are created and populated, task sequences updated, and work completed, much in thanks to HP’s CMSL. Ping me if you want me to blog how we (Mike Terrill and I) setup our Driver management processes.