BIOS Updates & Configuration using BigFix

I’d like to help create example BigFix content for BIOS Updates for every major computer vendor, but since I don’t have access to all possible hardware configurations, it will take some help from the community to validate the content. A bonus would be example content for configuring BIOS settings.

NOTE: Bitlocker generally must be suspended before doing BIOS updates

What vendor would you most like to see content for?

  • Acer
  • Apple
  • ASUS
  • HP
  • Lenovo
  • Toshiba

0 voters

Apple and Lenovo are kind of a given for my own use and I already have content for Dell systems.

I’d also be curious if anyone has large amounts of custom built systems that would have BIOS updates directly from the Motherboard vendor and what those vendors would be.


Dell

There is already example content for Dell systems for both updates and configuration:

There are lots of examples of using all of the Dell Command Utilities on BigFix.Me

I find the Dell Utilities to be very impressive and easy to work with, though they only really work for Dell enterprise models, and not the consumer hardware.

Dell Update Catalog:


IBM Servers


Lenovo

I only see examples for configuration, not updates:

Lenovo Update Catalog:


HP

Config tool: http://ftp.hp.com/pub/caps-softpaq/cmit/HP_BCU.html

Get current BIOS config with BigFix:

HP Update Catalog:


Related


Relevance Examples

BIOS Version

(it as string as trimmed string) of values "bios_version" of structures "bios_information" of smbioses

maxima of (it as version) of version strings whose(exists (it as version) whose(it as string contains ".") ) of bioses

bios_versions of bios_informations of dmis

string values of selects "SMBIOSBIOSVersion FROM Win32_BIOS" of wmis

values "BIOSVersion" of keys "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SystemInformation" of registries

BIOS Release Date

values "bios_release_date" of structures "bios_information" of smbioses

dates of bioses

bios_release_dates of bios_informations of dmis

(values "SystemBiosDate" of it; values "BIOSReleaseDate" of it) of (it; keys "BIOS" of it) of keys "HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System" of registries

All of the above combined in a cross platform way:

unique values of (it as trimmed string) of ( ( if exists properties whose(it as string contains "bios:") then dates of bioses else "" ) ; ( if exists properties whose(it as string contains "smbios:") then ( (it as string) of values "bios_release_date" of structures "bios_information" of smbioses ) else "" ) ; ( if exists properties whose(it as string contains "dmi:") then ( bios_release_dates of bios_informations of dmis ) else "" ) ; ( if exists properties whose(it as string contains "registry:") then ( (it as string) of (values "SystemBiosDate" of it; values "BIOSReleaseDate" of it) of (it; keys "BIOS" of it) of keys "HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System" of registries ) else "" ) )

This converts only 2 digit dates to 4 by assuming anything ending in “70” should be in the 2000’s:

maxima of ((it as date) of ( ((it as integer as string) of preceding text of last "/" of following text of first "/" of it ) &" " & (preceding text of first "/" of it as integer as month as three letters) & " " & ( (it as string) of ( /* if 2 digit date, assume anything before "1970" should actually be in the 2000's */ if it < 70 then it + 2000 else it ) of (it as integer) of following text of last "/" of it )) of it) of unique values of (it as trimmed string) of ( ( if exists properties whose(it as string contains "bios:") then dates of bioses else "" ) ; ( if exists properties whose(it as string contains "smbios:") then ( (it as string) of values "bios_release_date" of structures "bios_information" of smbioses ) else "" ) ; ( if exists properties whose(it as string contains "dmi:") then ( bios_release_dates of bios_informations of dmis ) else "" ) ; ( if exists properties whose(it as string contains "registry:") then ( (it as string) of (values "SystemBiosDate" of it; values "BIOSReleaseDate" of it) of (it; keys "BIOS" of it) of keys "HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System" of registries ) else "" ) )

Prefetches

prefetch unzip.exe sha1:e1652b058195db3f5f754b7ab430652ae04a50b8 size:167936 http://software.bigfix.com/download/redist/unzip-5.52.exe sha256:8d9b5190aace52a1db1ac73a65ee9999c329157c8e88f61a772433323d6b7a4a

prefetch Dell-Command-Update.exe sha1:0f341c5380428e0399dec6098a7e5e03b2701914 size:99786432 https://downloads.dell.com/FOLDER04358530M/1/Dell-Command-Update_X79N4_WIN_2.3.1_A00.EXE sha256:f322e74600468fd888183ec520e4e3a031fe8ab2b12a89c18b679dc589512254
5 Likes

I just added a fixlet to get the BIOS config from HP systems. The same tool can be used to set BIOS settings as well on HP systems, which could be done with some modifications to the fixlet.

1 Like

HP supplies bios_version in a very un-version friendly format

q: (it as string as trimmed string) of values "bios_version" of structures "bios_information" of smbioses
A: J61 v03.91
T: 0.864 ms
I: plural string

For my fixlets, to apply to a BIOS version less than 3.91 I’m using

not exists (system_bios_major_release of it as string & "." & system_bios_minor_release of it as string) whose (it as version >= version "3.91") of bios_informations of dmi

2 Likes
 (it as string as version) of values "bios_version" of structures "bios_information" of smbioses

So this doesn’t work? The as version inspector tries to parse a version number from the string, but it definitely doesn’t like many numbers within the string like that.

I’m working on a templating system for generating BigFix content:

1 Like

Sure enough, your smbios version query does work. I didn’t realize the ‘as version’ cast was so flexible.

q: values "bios_version" of structures "bios_information" of smbioses
A: J61 v03.91
T: 0.150 ms
I: plural smbios value

q: (it as string as version) of values "bios_version" of structures "bios_information" of smbioses
A: 3.91
T: 0.166 ms
I: plural version
1 Like

It tries very hard somehow to find a version number within a string of text.

See this demo:

(it as version, it) of (it as string) whose(exists it as version) of values "DisplayName" of keys of keys "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" of (x64 registries; x32 registries)

This pulls versions out of windows product displaynames which contain an apparent version string the version inspector finds parsable.

Well, HP foils all sense again. Here’s results from their DL160 Gen9 server, driving me back to system_bios_major_release and system_bios_minor_release

q: product_names of system_informations of dmis
A: ProLiant DL160 Gen9
T: 0.122 ms

q: bios_versions of bios_informations of dmis
A: U20
T: 0.129 ms

q:  system_bios_major_release of bios_informations of dmis
A: 2
T: 0.143 ms

q:  system_bios_minor_release of bios_informations of dmis
A: 30
T: 0.135 ms

q: values "bios_version" of structures "bios_information" of smbioses
A: U20
T: 5.976 ms

Also, this particular HP package (https://support.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7268998&swItemId=MTX_e7e6bc5900354bd1a885d7df56&swEnvOid=4184#tab2) to flash the BIOS doesn’t follow any of the same kind of logic as what I was using for HP workstation bios a couple of months ago. Now the package shows only a few options, none of which include how to pass in a BIOS password.

2 Likes

Is U20 a sensible version number for the BIOS? I know Dell often uses things like A18 and A19 to indicate BIOS versions. Or is 2.30 the only sensible bios version in this case?

I’ll try to confirm, but based on the release notes I don’t think U20 is sensible. I’m pretty sure my client reported U20 before the update, but the update itself references U20 so I think it’s a hardware identifier, not a bios version.

https://support.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7268998&swItemId=MTX_e7e6bc5900354bd1a885d7df56&swEnvOid=4184

1 Like

oh that is very frustrating!

Consider it confirmed.
Before flash:

q: bios_versions of bios_informations of dmis
A: U20
T: 0.153 ms

q: (system_bios_major_release of it as string & "." & system_bios_minor_release of it as string)  of bios_informations of dmi
A: 2.30
T: 0.201 ms

q: bios_release_dates of bios_informations of dmis
A: 09/12/2016
T: 0.165 ms

q: product_names of system_informations of dmis
A: ProLiant DL160 Gen9
T: 0.150 ms

After flash:

q: bios_versions of bios_informations of dmis
A: U20
T: 0.175 ms

q: (system_bios_major_release of it as string & "." & system_bios_minor_release of it as string)  of bios_informations of dmi
A: 2.54
T: 0.271 ms

q: bios_release_dates of bios_informations of dmis
A: 12/07/2017
T: 0.184 ms

q: product_names of system_informations of dmis
A: ProLiant DL160 Gen9
T: 0.271 ms
2 Likes

That is a real bummer when OEMs provide unreliable info.

It looks like Lenovo’s System Update tool might be workable:
https://support.lenovo.com/us/en/solutions/ht037099#tvsu

1 Like

We use that (the Lenovo’s Updater). It’s installed by default and part of our image. We just use BigFix to modify the regkey’s to check for critical updates each month, download, install, then prompt the user to reboot.

2 Likes

Making content to install, configure, and trigger all of the Update tools like I have already created for Dell Command Update is of interest to me as a part of the solution to this issue for sure.

Looking at DCU’s XML output, it looks like a fixlet that targets a specific package ID for just a BIOS update is possible. Has anyone poked at this?

1 Like

Yes, I have already automated the entire thing and it is already on BigFix.Me - part of it is linked in the original post above.

I did this before leaving PSU in 2015. I only used it some since then, but as long as the output of DCU hasn’t changed, then the creation of fixlets from DCU results for updating all Dell Enterprise BIOSes is automated.

This is an example result: https://bigfix.me/fixlet/details/3907

One thing that I’m hoping to do as an enhancement to this existing automation is to automate it by starting with the full catalog of available software and drivers from dell that DCU itself uses so I can go straight to the source instead of using DCU to get what updates are needed on systems first, then using those results to generate the content in bigfix.

I just realized, you had nearly the relevance I want in the analysis. :blush:

{node values of child nodes of child nodes whose(node name of it = "release") of parent nodes of parent nodes of xpaths "/updates/update/type/text()" whose(node value of it as trimmed string as uppercase = "BIOS") of xml documents of files "results_DellUpdate.xml" of folders "__BESData\__Global\Logs" of parent folder of client}

… pulls out the release tag for a BIOS update. From there it’s easy to target just a BIOS update:

parameter "theUpdate"="{node values of child nodes of child nodes whose(node name of it = "release") of parent nodes of parent nodes of xpaths "/updates/update/type/text()" whose(node value of it as trimmed string as uppercase = "BIOS") of xml documents of files "results_DellUpdate.xml" of folders "__BESData\__Global\Logs" of parent folder of client}"

waithidden "\path\to\dcu-cli.exe" /forceUpdate {parameter "theUpdate"} /silent /log "\path\to\file"
1 Like

This exits with code 3, and also if you use cmd:
waithidden cmd /C "\path\to\dcu-cli.exe" /forceUpdate {parameter “theUpdate”} /silent /log “\path\to\file”

1 Like