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  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.)


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.


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.


Here is the detection script I use:

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

   2: strBIOSUpdateVersion = "A05"


   4: 'Get BIOS Version from Win32_BIOS


   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:


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


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.


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.


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.


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.

Author: dhedges

I'm a Senior Client Systems Engineer specializing in OS Deployments and Automation using VBScript, PowerShell, MDT and SCCM. I enjoy working with technology and bending it to my will.

26 thoughts on “SCCM 2012: Deploying Dell BIOS Updates using the Application Model (Updated)”

  1. Hello mate, very nice and informative article you have shared with all of us. I appreciate your efforts. Thanks

  2. First of I must say this was a great detailed post which can be applied to other similar problems! I do have a question though, wouldn’t it be easier just to deploy the DELL bios updates they make available from their SCUP catalog? All the applicability rules are built into each update so adding them all into a single SCCM software updates deployment works fine.

    1. There are a couple of issues I have with using SCUP for this.

      1. It doesn’t account for BitLocker or BIOS passwords (which you can do with method by scripting it).
      2. While Dell regularly releases updates to their SCUP catalog, they don’t always update things as fast as I need them.

      Using this method is simple and gives me a ton of flexibility for deployments inside and outside of OSD and can be easily extended to non-Dell BIOS updates as well.

      I personally use this method on Dell Latitude, Precision, Optipkex and XPS systems. In addition I use it for some Lenovo and Samsung systems as well.

  3. Great guide.

    Just wondering the best way to install the multiple updates. i.e. Latitude E6320 I have E6320A05.exe, then E6320A08.exe then E6320A18.exe.

    Do I need to run a task sequence similar to this guide:

    I was thinking something like this:
    Disable BitLocker
    Run Dell Enterprise BIOS Updates
    Run Dell Enterprise BIOS Updates
    Run Dell Enterprise BIOS Updates
    Enable BitLocker

    Is there an easier/better way to accomplish this? With the above I’m guessing there will be 3 reboots even if the machine only requires one update?

    Thanks 🙂

    1. Using the App Model and the dependency configurations I outlined will handle the “down-level” updates if needed and you can have ConfigMgr automatically reboot the system (part of the Deployment Type).

      1. How do you know if the down level updates are needed? I thought you could just install the latest and greatest.

      2. Downlevel updates can be identified by looking at the comments of the update. Older models often required them however the newer ones do not (thankfully). You’ll see a comment in the release notes or installation instructions saying that it needs Bios Update version AXX before it can be applied.

  4. Pingback: Dell Bios Update
  5. first, thanks for posting this. this helps a ton. Second, how do you get it to work in PE. I’ve only tried the 755 and 760 and both are failing wanting a “full os”. cctk tool kit is working because i have it remove the bios password first and that is working. Made sure the its booting into 32bit pe. any tips? using 2012 r2 cu3

  6. @jz: maybe put your step later in the deployement, after the Os and sccm client are installed.

    @dhedges: thanks for this it’s really helpfull, question how do you manage if the bios is password protected or not? Can you check for that as a requirement in wmi? or if the deployement type A (including password ) fail run deployment type B (without password?) (I know you can do that with a task sequence but I’d like to do it just with the application model)

    1. I’d recommend wrapping it in a script and first try the command with the password and if that fails then do it without. Just remember to capture the error and handle it appropriately to ensure your script doesn’t bomb out.

  7. What setting do you on the User Experience tab when you are installing firmware with down level updates? Are you using “Determine behavior based on return codes” or “Configuration Manager client will force a mandatory device restart?” If you use “…based on return codes”, what are your settings for return codes? i.e. 0 – Soft Reboot or Hard Reboot? 2 – Soft Reboot or Hard Reboot. I am finding that if I use “….force mandatory device reboots” and it has two or more updates to do the task sequence will fail after the second reboot.

    1. I determine behavior based on return codes. For return codes I use the following (they are the same on all Dell BIOS Updates that I’ve tested thus far):

      1 = Failure (no reboot) NAME = UNSUCCESSFUL
      2 = Soft Reboot NAME = REBOOT_REQUIRED
      3 = Success (No Reboot) NAME = DEP_SOFT_ERROR
      4 = Failure (no reboot) NAME = DEP_HARD_ERROR
      5 = Success (no reboot) NAME = QUAL_HARD_ERROR
      6 = Hard Reboot NAME = REBOOTING_SYSTEM

      Hope this helps!

      1. Yes it does. Also, I was installing it immediately after the “Setup Windows and ConfigMgr R2 CU4” step but it was failing because I needed a reboot. If I didn’t have the reboot in place the application would give an unknown error trying to trigger the reboot after installing the new bios. I thought previous to CU4 the “Setup Windows and ConfigMgr” step would reboot after completing, but maybe I remembered incorrectly.

  8. Do you have to make a different machine a Dependency to the first one ever if it is a different machine or just newer versions of the same machine BIOS. I’m running into a problem that ConfigMgr sees the different types of machine and downloads the update but never runs it.

    Also I’ve found that the newer Dell BIOS can pass BIOS passwords through command line. I add a /s (for silent) and a /p= (for password) and ConfigMgr handles the reboots during Maintenance Window.
    The new Dell switches:

    Also super thanks for this blog, it looks just like what i needed.

  9. Can someone share step by step process to upgrade DELL BIOS on bitlocker encrypted system through SCCM?

  10. A very nice article!
    Following the steps, I am noticing something strange when I am making the application an “available” deployment to a device collection. When there is more than one deployment type it automatically installs like a “required” deployment.

    1. Hi Joakim, you are correct and I actually need to update this post. I spoke with Microsoft Premier Support and this is apparently “by design” and not a bug. The proper way is to put your Dependent Deployment Types in a different Application.

      I hope this helps with your issue. I’ll try to prepare a blog update over the weekend.

  11. Great post and script. Although I did need to change a line at the end of the script to get the Powershell script to report the exit code back to CMD/SCCM. I removed return $process.ExitCode and replaced with [System.Environment]::Exit($process.Exitcode). Before that every run was an exit code 0. I may also need to modify the script to re-enable Bitlocker if the run is a failure or generally is not going to trigger a reboot, but have not yet done so.

Leave a Reply to dhedges Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s