Downloading Dell Driver CAB files automagically with the Driver Pack Catalog

Dell has been hard at work behind the scenes trying to make our lives as IT Pros easier.  From their Enterprise Client Tools such as OMCI and the Client Configuration Toolkit (CCTK) to the more recent (past few years) Driver CAB files.  Well yesterday we got another tool to help us in the fight to manage our drivers and ease the pain of obtaining them.  Yesterday Dell unleashed the Dell Driver Pack Catalog.

What is the Dell Driver Pack Catalog you ask?  Warren Byle (Dell) sums it up nicely:

                The Driver Pack Catalog is an XML file containing metadata about the  new Dell systems and WinPE Driver Packs. This XML file is compressed as a Microsoft Cabinet (.CAB) file and digitally signed for delivering it to the customers over the internet.

Basically, it gives is a structured way of identifying the latest and greatest driver packages (CABs) available from Dell.  And with that, I’m here to introduce a new companion script that should give you a jumpstart.

I call it the Dell Driver CAB Downloader Script Thingy (Ok, I’m still working on a name).  You can get the script from here.

What It Does

It’s pretty simple really. You supply the script with some input parameters such as the Model and/or Operating System you would like to download driver packages for, and it does the rest.

First things first let’s explain the general flow of the script once executed:

  1. The script will connect out to Dell’s HTTP download site and download the latest CAB file. NOTE: You have an option to supply a local file if you wish
  2. After downloading the file (Uses currently logged on users credentials), it extracts it to the Download Folder that you provide
  3. Next we consume the extracted XML file and begin searching thru all listed Driver Packages for a match (Model and/or Operating System)

Examples

Execute the following command to download a single WinPE Driver CAB:

.\Download-DellDriverPacks.ps1 –DownloadFolder “C:\Downloads” –TargetOS 32-Bit_-_WinPE_3.0 –Verbose -DontWaitForDownload

WinPE

Execute the following command to download all Driver CAB’s for a specific model:

.\Download-DellDriverPacks.ps1 -DownloadFolder "C:\Downloads" -TargetModel "Latitude E7240" –Verbose

ModelTarget

Closing Thoughts

The introduction of this new Driver Pack Catalog brings with it a new set of possibilities for Driver Management.  While the script I’ve outlined here only solves a small piece of the puzzle, my hope is that it will lay the groudwork for some great tools to provide an end-to-end solution of Downloading, Importing and Distributing drivers for Dell systems.

Advertisements

SCCM 2012: Deploying Dell BIOS Updates using the Application Model (Updated)

UPDATE 2016-07-20: I’ve seen the comments about the download link not working.  I’ve instead made an updated script available on GitHub at https://github.com/dhedges01/Blog.  The new script uses new command line syntax as well so I’ve updated the post below to reflect those changes.

During a recent migration from SCCM 2007 to SCCM 2012 SP1, I wanted to really start taking advantage of the new Application Model for software and driver deployments. My goal was simple, to create an Application that would deploy any Dell BIOS Update, to any applicable system, and handle daisy-chaining and even reboots. All this without (much) scripting.

The process outlined below should give you a good understanding of the steps needed to create an Application and various Deployment Types with all of the necessary Detection, Requirement and Dependency Rules needed to successfully deploy Dell BIOS updates using Configuration Manager 2012.

Note: If you are reading this then you are likely familiar with my other post about Updating Dell BIOS with PowerShell.  Much of the concept and setup here is the same, however using the Application Model we get some added benefits.

  1. We only download content for our specific version.  If you have a lot of models to deal with (like I do), this really has an impact in overall download and execution times (My BIOS Update package was well over 300MB when I implemented this method).
  2. Configuration Manager 2012 now gracefully handles reboots from the Application Model meaning we only need to reference the step once in the Task Sequence.  We also don’t need to stage any subsequent updates to the local drive because we aren’t downloading ALL of the BIOS Updates.
  3. We get applicability reporting within Configuration Manager’s AppEnforce.log file which aids troubleshooting
  4. Using this model we can now more easily handle BIOS Updates from other vendors and can even deal with those pesky “Consumer” BIOS updates as well (I’m looking at you Dell XPS…).

First things first, gather up all the latest (tested) BIOS updates for the models you support and organize them (I organize them by model). Each “model” folder will end up being the Content Source location for each Deployment Type. (You could go a step further and create a Version# folder for each version of BIOS update.  But since each model will likely only have 1 or 2 applicable BIOS Updates, it’s not really necessary.)

image

Next up we create our custom SCCM Application. All fields are filled out manually. Make sure you use an appropriate naming convention according to your companies standards.

image

The next step is one that will be repeated over and over again (with a little assistance from the Copy function). We will start by creating the first of many Deployment Types. I’m going to use the BIOS updates for the Dell Latitude E6420 as my example in this post so you can see how to use dependencies in order to install “down level” updates in order.

I like to start with the lowest version number first so we can add the dependencies as we go. We’ll start off with version A05.  Provide the general items such as Name, Content Source, Installation Program, etc.

Installation Program: powershell.exe -NoProfile -NonInteractive -ExecutionPolicy Bypass -Command ".\Invoke-BIOSUpdate.ps1 -UpdateFile .\E6420A05.exe -Arguments /s,/l="C:\WINDOWS\eBay_Deployments\Dell_BIOS_Update_E6420A05.log""

For the Detection Method, I chose to leverage a custom script to detect the BIOS version. This allows me to deal with those pesky “patch” updates that sometimes come out.

image

Here is the detection script I use:

   1: 'Change strBIOSUpdateVersion to the version you are deploying to

   2: strBIOSUpdateVersion = "A05"

   3:

   4: 'Get BIOS Version from Win32_BIOS

   5:

   6: Set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")

   7: Set colBIOS = objWMI.ExecQuery("Select * from Win32_BIOS")

   8: For Each objBIOS In colBIOS

   9:     If objBIOS.SMBIOSBIOSVersion >= strBIOSUpdateVersion Then

  10:         WScript.Echo "Detected"

  11:     End If

  12: Next

Add Requirements.

I created a custom Global Condition to echo out the Model from WMI. I use this requirement rule to ensure the Deployment Type only applies to the appropriate system type.

Here is the configured Global Condition:

image

And here is how it’s referenced within the Deployment Type:

image

Configure the User Experience.

Depending on how you configure the install command, you can have ConfigMgr handle the restart or allow the BIOS update to restart the computer. If you choose the latter, make sure you configure the appropriate return code so ConfigMgr is aware of a potential restart.

image

After setting up the first Deployment Type, hit the Apply button so the Deployment Type is saved within the application. Failing to do this will make it unavailable when you try to add it as a dependency.

Copy the Deployment Type and make the necessary updates to the Name, Content Source, Install Command and Detection Method. Click on the Dependency Tab and create a new Dependency Group. Then add a Dependency selecting the first BIOS update you created.

image

After all of the Deployment Types are created, distribute the content and deploy your new application to a test system (or you can add it into an OSD Task Sequence for testing, ConfigMgr should automatically handle the reboots and ensuring that all “down level” updates are applied in order for each model you add.

Update: 

One thing I forgot to mention in this post is the ordering of Deployment Type Priority.  When an application is evaluated, the client evaluates all of the rules for each Deployment Type in order of Priority.  Once it finds an applicable Deployment Type, it executes that one, and it no longer evaluates anymore Deployment Types within that application.  So, as an addendum to this posting, here is how I have the BIOS Updates in my Application sorted by priority.

 

ConfigMgr 2012 Dell BIOS Application Deployment Type Priority

 

As you can see from the screenshot above, I am ordering the Priority of evaluation looking at the Latest BIOS Version first.  Each “down level” BIOS Update is a dependency of the next highest version.  (i.e. A17 has a dependency of A08 and A08 has a dependency of A05).  What happens here is that if the requirements for A17 are not met (version is less than A17), then A17’s dependency (A08) will then be evaluated.  If A08’s requirements aren’t met, it will evaluate A05 and so on until all dependencies are evaluated and executed (in order).  Once the dependencies are met, then A17 can execute.

The important takeaway here is make sure your highest version of BIOS Update is evaluated first because once a Deployment Type is deemed applicable, ConfigMgr stops searching for others unless they are a dependency of the one it finds first.

Updating Dell BIOS with PowerShell (Updated)

Some of you may be familiar from my earlier article “Dell BIOS Updates with PowerShell” and hopefully you have gotten some good use out of it.  There have been a few comments on that article and over time I’ve also had some issues with that version of the script brought to my attention.

Some of these issues are:

  1. 1. Dell OptiPlex 745 updates don’t work because of the naming convention
  2. 2. Bios updates are overriding newer versions that come from the factory
  3. Still not updating to the latest available version due to supersedence rules for the BIOS updates (i.e. Needing A05, then A08, then finally A12).

So with that I fired up PowerGUI and started analyzing the entire flow of the script.  And more importantly kept in mind the overall process needed when multiple versions of a BIOS Update may be required (from A01 to Axx).  With this new script, I’ve introduced some new “features”

  1. Added a loop to parse multiple available BIOS update files
  2. Added a switch condition to allow for “oddly-named” BIOS file versions (read: OptiPlex 745)
  3. Added BIOS Release Date information (Universal Time Format) to check for BIOS “Patches” (i.e. P02 on Latitude E6410/E6510)
  4. Added OSD-Specific tasks (separate script)
  5. Embedded function for actually invoking the BIOS Update process itself with custom parameters.
  6. Removed dependency on Dell OMCI for BIOS identification (using Win32_BIOS now)

Dell_BIOSUpdates.zip

Using this with OSD/MDT

I’m not going to go over the script in its entirety here, however I will put out a few things specifically for using the “OSD” version of the script.  This additional script will connect to the Microsoft.SMS.TSEnvironment in order to interact with and create a new Task Sequence Variable.

When using this with OSD/MDT, you’ll want to have the script run multiple times in order to fully update the BIOS to the latest possible revision in the case that multiple executions are necessary.  Below I’ve documented the process that I have implemented to do just this.


Task Sequence Structure:

shot_662012_104220_amAs you can see here, we have multiple nested groups that will run the Dell BIOS Update script and enforce a reboot after the update has been staged.  One thing to point out here is that after the first run (which I’m calling as a regular Package/Program) is the word “Local”.  That’s right, the OSD script is copying the model-specific BIOS Updates locally (if there is more than one) so we don’t re-download the whole package again.

Update BIOS Group Condition:

shot_662012_105011_am

Update Dell BIOS Run Commandline:
powershell.exe -NoProfile -NonInteractive -File
“C:\Temp\Dell_BIOS_Updates\Invoke-DellBIOSUpdate-OSD.ps1”

Dell_BIOSUpdates.zip