Updating Dell Bios with ConfigMgr–Post 3–The Application Deployment


First, you’ll need to add global conditions for your model, I was able to use @agerlund  Kent Agerlund’s blog to achieve this: http://blog.coretech.dk/kea/global-conditions-in-configmgr-2012/
These next few parts are borrowed directly from his post (When a Master creates good content, why re-invent the wheel):

  1. Creating the condition, open the ConfigMgr. administrator console, select Software Library, Application Management, Global Conditions and click Create Global Condition from the ribbon.
  2. Create a condition with these settings:
    Name: Computer model
    Device type: Windows
    Condition type: Setting
    Setting Type: WQL query
    Name space: root\cimv2
    Class: win32_computersystem
    Property: Model



Now that we have the Condition, lets build the Application to Deploy these Bios Scripts.
We will use the Dell Latitude E6540 for our example with the A16 Bios (Current as of 12/7/2015, change A16 with the current bios level anywhere you see it)


image imageimageimage imageimage imageimageimage


Now you have your Application with 1 Deployment type for the E6540 Model.
Going back through the images 1-10

  1. Create new Application – Set to Manually specify information
  2. Put in your Name “Dell Bios Updates (Auto Reboot)” & Check the Box to run in a TS
  3. Add some info in the description and change your icon
  4. Choose Script Install and Manually specify
  5. Create a name for the Script “E6540 A16” (Change A16 for the current Level of Bios)
  6. Set your Content Location & Installation Program (E6540Reboot.cmd)
  7. Detection Method will be the Log File created in the script, our example is C:\InstallLogs\E6540A16.log
  8. User Experience – Install for System & Whether or Not a user is logged on
  9. Requirements – set to Custom – Computer Model – equals Latitude E6540
  10. Double check your summary and finish.

Note to remember, when new bios come out, you need to change 3 things.

  1. Script File – Change the Bios EXE that you’re running and Update the LogFile to Match so you can get a new detection Method
  2. Deployment Type Name.  By naming the Deployment Type the Model & Bios Level, it’s easy to quick see which Bios level you’re deployment, just remember to update the Name to reflect the new Bios Level.
  3. Detection Method to match the new LogFile Name


Repeat Steps 1-10 for each model you want to deploy bios to.  When Complete, you should see something like this:
I can quick look at that, see all of the models I can deploy and which Bios Level it is at.  If a new Bios comes out, I just make those 3 changes listed above, and redistribute the content.

Moving forward, I’ll probably break this into two different Applications, Laptop / Desktops
Just to make the package contents smaller.

I’ve got 2 applications identical, except one (No Logged on User), I’ve changed the  user experience
Logon Requirement is set to “Only when no user is logged on”

I’ve done this so when I deploy it, it will not run if a user is logged on, even if the it reaches the deadline, it will not run if a user is logged on.  Since I force a reboot when the Bios update runs, I don’t want it to install and reboot when a user is logged on.

I created a collection to Deploy to, called “BiosUpdate – No Logged on User – Reboot” so I know exactly what I was using it for, then deployed the Bios Update to that Collection. (I like to make descriptive Names for things)


Every few days, I added one additional collection of computers (Model) that required bios updates



As computers would update their bios, and do a hardware inventory, it would show an updated bios version, and automatically be removed from those query based Bios level collections.  If computers remained in those collections, I would check to see if the update ran on them, typically what would happen is the bios update would fail, so I would create a ticket for the service desk to manually update the bios on the few that failed, and to resolve any other issues which might have caused the bios to fail.  Once the bios is resolved, they automatically drop out of the query based collections.


When new bios are released, I’d update the applications, update the query in the collections, and they would auto populate back into this deployment collection, get updated, then pull themselves out.  I LOVE QUERIES!

Updating the Queries and Applications can be time consuming, so typically I’ll only update to a bios level if it has a value in our environment, like fixing a specific issue.  On new models, it seems like bios are released monthly, so if it doesn’t fix an issue we’re seeing, I’ll typically wait for a couple extra months for another version or two to be released.  On older machines, bios releases are rare, so once you’ve set this up for older models, you’ll probably never have to touch those scripts / deployments again.

I hope I explained the process well, if you have any questions, please let me know.

2 thoughts on “Updating Dell Bios with ConfigMgr–Post 3–The Application Deployment”

  1. Hey GARYTOWN thanks a million – this is by far the most in depth and accurate method for approaching a BIOS upgrade I especially like what you did with device collections and queries I would have never guessed and its helping big time in managing my labs. I’ve used your detection method style with the log files, its my typical go through for these situations. Unfortunately we’ve got a strict no reboot policy around my environment so I added the -noreboot flag which causes my detection method to be read as “already compliant” after the user restarts, any other suggestions for a detection method? Thanks a million

    • Hi James

      So let me see if I understand you correct, you’re deploying the BIOS Update, but skipping the reboot. The Process creates the log file, which is the detection method.
      After a reboot and the BIOS applies, the Software Center says that it’s already installed because of the log file is present.
      This is ok if the BIOS update is successful, however, if it fails, the log file still exist, and doesn’t try again.

      Is that a good summary?
      Basically, you need to delete that log file from machines that failed, so it will try again?

      I ran into something similar, usually the % was so small, I didn’t care, or I just created Problem Tickets for the Service Desk to remote and run it manually.
      You could create a package that deletes the log file, so like a week after the deadline, if the machine is still in the old BIOS Version Collection (Assuming the Update Ran, created Log file, but didn’t actually flash bios), it runs the package resetting the Detection Method, so it will try again.
      I’d make sure you have both detection methods in place, both the Registry Key & Log File, so even if the machine did update successfully, but the Collections haven’t updated, The Application will see the BIOS did update and not try again, even if the log file is gone.

      IF Either Registry Key = New BIOS Version or Log File Exist, then Detection = True.


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.