In this post I will be going over how to adequately deploy Dell BIOS Updates via the Application Model in Configuration Manager.  Utilizing the Application Model allows us to specify a Detection Method and, thus, allows for the Deployment to retry until those criteria are specified.

Here are a few links to reference as we move forward:

1. Dell Support Page
2. Dell Update Packages | Exit Codes for CLI
3. Command-line Switches for Dell BIOS Updates

Assumptions as we move ahead:

1. Utilizing Configuration Manager Current Branch
2. Previous knowledge on creating Applications in ConfigMgr
3. Basic knowledge of WMI
4. Knowledge of Global Condition creation (Optional)
5. Downloads of Dell BIOS Update executable(s) for requisite Model(s)
6. BIOS password is being utilized (Optional)

 

Application Creation

The Application(s) that we will create can be created for each individual Model or, like I have done, you can create one Application called ‘Dell BIOS Update’ and have separate Deployment Types for each Model.  As with everything in ConfigMgr, there are many ways to do things.  I will go over a single Deployment Type here and you can extrapolate from there.

Referencing Dell’s Command-line Documentation we will be utilizing the ‘/s’ ‘/f’ and ‘/p’ switches.  If you do not have a BIOS Password you can omit the ‘/p’ switch.  We will not be utilizing the ‘/r’ switch because we do not want it to automatically reboot the machine.  Instead, we will add the necessary Exit Codes to the Deployment Type to allow the ConfigMgr Client handle the Reboot process and thus evaluate the Detection Method properly after the Reboot.

For the ‘Detection Method’ we will be referencing the Registry.  As you would note, this value will not change until after the Reboot and the BIOS Update applies properly.  Having the ConfigMgr client handle the Reboot ensures that the Detection Method isn’t evaluated until after the Reboot.  If we didn’t follow this process, the Application Deployment would fail as the Detection Method wasn’t fulfilled and then it would eventually show as compliant when the ‘Application Evaluation Cycle’ runs assuming the Reboot happened somewhere in that process.  The following Value will refer to the BIOS Update Version:

The ‘User Experience’ tab will remain rather default as many other Applications I deploy:

Once we get to the ‘Requirements’ tab you have some options.  Now, I specified the ‘Operating System’ requirement as I do that for all Deployment Types.  This particular model ONLY has Windows 10.  I also make a habit of specifying this in case it would ever be deployed in a Context that has a small chance of targeting Servers.  Also, it’s a good idea to specify the requirements for criteria you’ve tested on.  You test your stuff in production, right?  Good.

I also added a Custom ‘Requirement Type’ that references a Global Condition for this particular model.  Again, you can omit this if you are creating an Application for each individual model.  I chose to utilize one Application with multiple ‘Deployment Types’ that referenced the different Dell models in my environment.  If you wish to utilize the ‘Global Condition’ method I will provide that information later in the post.

Now we get to the importance of the ‘Return Codes’ tab.  For this you will want to reference the ‘Exit Codes’ that Dell provided for the Dell Update Packages CLI.  Outside of the default ‘Return Codes’ that ConfigMgr provides I will be adding ‘2’ for ‘Reboot Required,’ ‘1’ for ‘Failure,’ and ‘4’ for ‘Hard Error.’ I do not specify ‘3’ as the ‘/f’ switch overrides Soft Dependencies.  I also did not specify ‘5’ as that shouldn’t pertain to this because we are specifically targeting the proper models but you can add it if you’d like.

Here is a screenshot of my ‘Deployment Types’ in my Dell BIOS Update Application:

In terms of Deployment, one needs to consider the following situations when the Deadline is reached if it is a Laptop or other Mobile Device:

1. Device is running on Battery (install will fail based on Exit Codes – Hard Dependency)
2. Device is on AC (install will succeed)
3. Device is on AC during install, but on Battery upon reboot (install will fail because of Detection Method)

This is largely the reason I utilized the Application Model because it will retry until it is successful.  I have also tested all of the different iterations of these series of events and have never had a device get ‘bricked.’  If the update does install and the device reboots on Battery there will be a screen upon boot stating to insert an AC Adapter and a few seconds after that it will boot into the OS and the end-user will be oblivious.  Again, though, test in your environment with your BIOS configurations.

Global Condition Creation

Go to the model of machine you are targeting and bring up an Elevated Command Prompt and type in the following:

‘wmic csproduct get name’

Note: These steps are from a different model than our Deployment Type previously but the process would be the same.

You can now utilize this information to create a Custom ‘Global Condition.’  Specifying this as a ‘Requirement Type’ for your ‘Deployment Type’ will ensure that DT only applies to that particular model.  If you create an Application for each Model and then target to a Collection with just that Model you can go without this but I feel it is better automated this way and it ensures we are deploying the right BIOS to the right Model.

You can also leverage this when creating your Model Collections.  With using multiple ‘Deployment Types’ as well as the Custom ‘Global Conditions’ you wouldn’t necessarily need to create multiple Collections based on Model but for right now I like to proceed slowly in smaller chunks.  This will most likely change in the future with Phased Deployments coming to Applications.