Lenovo BIOS date in DriverAutomationTool packages don't match installed BIOS date

[MonkeyWorks]

Maybe I have missed some smart parameter I should have used as I now only use "-BIOSUpdate -Endpoint "xxx"", but I have this problem:

The Lenovo release/issue dates on web and in readme don't match the date on the installed BIOS for the same version. Since the DriverAutomationTool add release date to the ConfigMgr model BIOS-package, and the Invoke-CMDownloadBIOSPackage.ps1 script match date in description on that package and from the installed BIOS, it will allways detect the same BIOS-version as a new available BIOS. This results in the task sequence executing BIOS-update and trying to roll back to the currrently installed BIOS.

This is from earlier testing when BIOS on laptop and package was on 1.50 (currently its 1.52), from the ApplyBIOSPackage.log:

Match found for same version 1.50:

BIOS date on laptop:

BIOS date in readme on web:

There is a new BIOS detected, since the date don't match, while both package and bios is 1.50.

From the BIOS-update log. It fails because rollback is not allowed in BIOS (luckily). (EDIT: This is 4 August and not 8 april as in BIOS)

If I alter the date in description on package to match the date on BIOS in laptop, the task sequence exits after it detects the BIOS-version to be the same. This is not a huge problem, but it is resulting in an unnecessary boot for all the Lenovo machines/models with the problem to turn on Bitlocker again (as I have set up my TS).

I guess its some history behind it, but I don't understand why it match the release date and not the actuall BIOS-version instead?

[Ginolard]

Yup, I second this. It's been particularly annoying for us as the Task Sequence we have will only suspend Bitlocker if it "detects" a new BIOS version to install. So, even though many of our Lenovo laptops now have an up-to-date BIOS it's still suspending Bitlocker every time the TS runs even though the BIOS update is not actually required

However, it's largely because Lenovo use some stupid, unconventional way of versioning their BIOS numbers over various models.

Take the L14 Gen2 models, for example. The BIOS version of the package is 1.57.1.47 whereas the SMSBIOSVersion attribute is 1.57. As opposed to, say, the L13 model where the package version format and SMSBIOSVersion format are the same (e.g. 1.35)

You could fix this fairly easily by extracting the version number between the brackets and comparing the versions as you do with Dell and HP models

$FullBIOSVersion = (Get-WmiObject -Class Win32_BIOS).SMBIOSBIOSVersion
$CurrentBIOSVersion = $FullBIOSVersion.Substring($FullBIOSVersion.IndexOf('(')+1,4).Trim()

if ([System.Version]$AvailableBIOSVersion -gt [System.Version]$CurrentBIOSVersion) {
	# Write output to task sequence variable
	if ($Script:PSCmdlet.ParameterSetName -notlike "Debug") {
		$TSEnvironment.Value("NewBIOSAvailable") = $true
	}
	Write-CMLogEntry -Value "A new version of the BIOS has been detected. Current release $($CurrentBIOSVersion) will be replaced by $($AvailableBIOSVersion)." -Severity 1
}