In the case of a Lenovo X1 Carbon (model 20HR002MUK) with Win10 10.0.16299.192 (1709), we had a user run Windows Update manually and was surprised to learn that it detected a BIOS upgrade for Meltdown/Spectre. It downloaded and installed it on reboot. I don’t think I have ever seen BIOS upgrades detected via WU before.
The install itself took about a minute and the computer beeped during the process…increasing in frequency until it was a solid tone.
Any chance of IBM doing that if it makes any sense?
This is interesting. This is typical for Microsoft Surface devices when using “Microsoft Update” but not typical for Lenovo devices. I do know that it is possible for drivers to be delivered through “Microsoft Update” / Windows Update in general.
I don’t know that this is a stream of content that is typically generated in BigFix but this is something that could be explored. One issue is testing of this type of content is very difficult.
I used Dell Command Update to automate the installation of drivers and bios updates through BigFix in previous jobs, as well as extending that to automate the creation of content in BigFix to do the same.
One issue I have is I don’t have the hardware to test most of these things, which is a real struggle. I am willing to help make the content where I can, but I’d have to rely on the community to do most of the testing.
My short term goal is to come up with example BIOS updates for as many vendors as possible, my long term goal is to make it easier to automatically generate the content.
One factor that makes this much more complicated is generally BitLocker must be suspended before doing BIOS updates. There is a real risk of data loss if you aren’t certain you have the most recent recovery key from the system escrowed and don’t do this correctly.
I think a responsible update would [have the option to] suspend BitLocker, update, and then re-enable. Or have a set of actions that can be chained together. (ServerAutomation?) A difficult problem to be sure. I haven’t even begun to think about solving that.
You can suspend bitlocker in such a way as to have it come back after next reboot automatically, so we have researched a solution that does not require re-enable.
At first, we might release content that only works if bitlocker is not enabled for testing, then add the option to suspend bitlocker automatically.
I wonder if the BIOS updates themselves are suspending bitlocker in this case, or if the BIOS updates didn’t change something fundamental that would cause an issue.
I have definitely had Dell BIOS updates not suspend bitlocker and put bitlocker into recovery mode. Not fun.
Hmmm. The process of powering down the OS should suspect BitLocker. Perhaps the Dell install at the time was more forceful in its shutdown process; not allowing the OS time to full do its thing. Statistically, we have about 6,000 endpoints with BitLocker, all default PCR’s, and have little issue.
I don’t actually have experience using or managing BitLocker myself, but my understanding is that when BitLocker is in a “Supsended” state, that means that the hard drive is still encrypted, but a key is temporarily stored which makes the hard drive technically decryptable and the protections like BitLocker verification of the BIOS and similar are disabled temporarily. I thought that this did not happen when the OS was shutdown, only when BitLocker is told to switch to the Suspended state.
A Suspend is like telling it to forget what it knows about your hardware. Then when it activates again, shortly after a reboot, it take that hardware foot print again… that becomes its new comparison to make sure the system wasn’t tampered with.
