Upgrading the BIOS Part 2

In Upgrading the BIOS Part 1, I gave some very important reasons why you should be proactive about upgrading the BIOS on supported systems in your environment. In this blog, I want to discuss the approach to flashing the BIOS along with some lessor understood caveats as it relates to BitLocker, BIOS passwords and UEFI 64-bit systems.

Any solution that I create and implement, I like it to be as modular as possible so that I can get maximum use out of it (it is the engineer in me and probably the reason that I still enjoy playing with Legos at my age). When flashing the BIOS, we need to be able to do it under two different operating systems – a full operating system like Windows 7/8.1/10 and a lightweight operating system called WinPE. This will allow us to handle existing clients that are already deployed and also bare metal/break fix scenarios. After all, it would not make much sense to have to boot into a full operating system just to flash the BIOS. Other solutions that I found relied on Configuration Manager Applications and Package/Programs. While these may work for specific scenarios, they cannot cover all scenarios. The Install Application and Install Package task sequence steps only run under a full operating system and not WinPE, so those methods eliminate the bare metal scenarios. Sure, we could create another task sequence or a duplicate package that just does bare metal, but now we have twice as much to manage, update and maintain – no thanks!

Now, there is a slight disclaimer that I need to put out there for the time being. Because of certain limitations with some vendor systems, plus the fact that Configuration Manager can only have one boot image assigned to a task sequence and that you need to use the correct boot image architecture to boot a UEFI system, then you will need to have a separate task sequence to handle the bare metal/break fix scenarios (or better yet, pressure the vendor into supporting 64-bit WinPE). The problem is some vendor models currently only support a 32-bit flash utility. If a system is configured for UEFI (or we are doing BIOS to UEFI in a single task – yes, this is possible now), then you need to use the corresponding boot image architecture. This is going to be 64-bit for modern PC systems (within the last four years or so). Long story short, be sure to check with the vendor of the models that you currently support in order to handle those exceptions (or get rid of them and buy something you can support).

Another important point, both the HP and Lenovo flash BIOS utilities require the WinPE-HTA component to be included in the WinPE boot image. Do not ask me why, I just know that it does not work without it. Just make sure that component is included and things should work just fine. Now Dell, HP and Lenovo do supply 32-bit and 64-bit flash BIOS utilities (with certain models being the exception), so you only need one task sequence if you have these vendors (and supported models). These are the only three vendors that I will be covering, but I will gladly take donated test systems of other vendors you would like me to test.

BIOS Passwords can be tricky. Usually you password protect something in the first place in order to make it secure. However, the flash BIOS utilities will take the password as a command line parameter or in some cases (HP) a bin file. Neither one of these methods are ideal for automation with Configuration Manager. A bin file is downloaded to the cache (or TS working directory) at some point in the process and you do not need the password in order to make changes (including clearing the password) as long as you have the bin file. Command lines get logged and there is nothing like having a password in clear text sitting in a log file. If you would like to see better handling/log file suppression, then head on over to UserVoice and vote up Secret task sequence variable value Exposed. I am not advocating to not use BIOS passwords, you should absolutely be using them in order to lock down settings that should not be changed (like Boot Order). You may have to get clever and write a compiled exe that masks the password(s) in your environment (yes – I know that even this can be cracked depending on how it is done, but at least it is more secure than clear text log files or bin files). Lastly, if dealing with multiple passwords, most of the vendors allow three tries before requiring a reboot and attempting again. If you have multiple passwords in the environment, have a group in the Task Sequence that removes the password before flashing the BIOS. You typically only get one shot specifying a password when flashing the BIOS, so this is a way to overcome this limitation.

When it comes to BitLocker, it will need to be suspended before flashing the BIOS (which is one of the reasons I like using a Task Sequence). If it is not suspended prior, BitLocker will detect a change to the system, and then be prepared to enter the BitLocker recovery key upon restart. It is easy to suspend BitLocker but keep in mind the native Configuration Manager step only suspends BitLocker for one restart. Newer Windows operating systems will allow BitLocker to be suspended for x number of reboots or indefinitely. See my previous blog, called How to detect, suspend, and re-enable BitLocker during a Task Sequence, for more information and examples. For 3rd party disk encryption you are on your own. Your best bet is to contact the vendor on how they support flashing the BIOS. If they do not understand what you are asking, then start seeking alternative disk encryption products (like BitLocker).

So, here are my tips and tricks in a nutshell when flashing the BIOS:

  • Use a task sequence for total control.
  • Incorporate flashing the BIOS into your OSD process for Refresh/In-place Upgrade/New Computer/Break-Fix.
  • Suspend BitLocker!!! (or be prepared to enter the BitLocker recovery key)
  • Disable/re-enable BIOS passwords or use it in the command line of the flash utility (just be careful not to have passwords in clear text in log files or command lines).
  • Dell requires a utility called Flash64w in order to flash in WinPE x64 (see First look – Dell 64-bit Flash BIOS Utility).
  • HP and Lenovo system work on WinPE x64, but requires WinPE-HTA to work.
  • Test, test, test!
  • Baseline and document supported configurations (including how each setting is configured), current BIOS version and release date (this part is key).

In an upcoming blog series, I will be covering off some of my tips and tricks on how to deploy BIOS updates in a modular, dynamic fashion during a Task Sequence (bonus – the same method can be used for drivers as well).

Originally posted on https://miketerrill.net/

Upgrading the BIOS Part 1

Operating systems and software are not the only thing that needs to be upgraded these days. It is really important that the BIOS firmware gets updated as well. Lately, I have been talking to a lot of IT Pros at conferences and user group meetings and I have discovered that not too many people upgrade or ‘flash’ the BIOS on systems after they have already been deployed (or even ever – sometimes they are sent out with the version they came with from the vendor). It is really important to change this going forward. I recommend developing standard versions that you support so that all systems are running your minimum standard version or newer. Periodically, a review of BIOS releases should be done to see if a later version should become the new minimum standard.

So why even upgrade the BIOS in the first place? There are a few reasons that I can think of that answer this question. The first reason is Windows 10 support. Believe it or not, the hardware vendors test the latest operating systems on the models that they currently support. Take the Lenovo ThinkPad T450, looking in the BIOS release history, you can see that Windows 10 support was added for version 1.17:

<1.17> 2015/09/07
– (New) Added win10 support.
– (New) Enabled N25Q128 SPI ROM support.
– (New) Added security fix addresses LEN-2015-002 SMM “Incursion” Attack.
– (New) Included security fixies.
– (New) Added new incompatibility bit for Back Flash Prevention.

Now this does not mean that Windows 10 will not work on versions lower than version 1.17. It means that this is probably the version that they validated and tested Windows 10 against. If you happen to run into an issue running Windows 10 on a version lower than 1.17 and you call in for support, chances are they will have you upgrade the BIOS to the latest version to see if that addresses your issue.

The second reason to upgrade the BIOS is to get fixes. It makes sense to start off on one of the latest releases than it does to start off with a version that is a year or more behind in fixes. By not upgrading to a recent version as part of the deployment process, you are potentially wasting everyone’s time – the end user, help desk, desk side (and your time if the problem comes back to you). Save the hassle and be proactive. Looking at a newer BIOS release version for the same Lenovo ThinkPad T450, we see that there is even a ‘SCCM’ fix listed in version 1.19:

<1.19>
– (New) Updated verbtable for noise.
– (New) Changed Haswell + N16s Tolud.
– (New) Updated Winuptp & Winuptp64.
– (Fix) Fixed an issue that srsetupwin fails to install pop/hdp with clearing SVP.
– (Fix) Fixed an issue related to SCCM 80070490 error when HDP is set.
– (Fix) Fixed an issue related to silent install auto restart issue.

The third reason to upgrade the BIOS is to get security related fixes. Yes, they find and fix security fixes in the BIOS firmware just like they do in operating systems and software. Do your security team (and yourself) a favor and deploy versions that contain these security fixes. Looking at the BIOS release history for the HP EliteBook Folio 9470m, we can see some of these security fixes listed in this version:

Version:F.60 A (20 Jan 2015)
Fixes
– Fixes an intermittent issue where enabling the LAN/WLAN switching feature in the F10 BIOS settings causes the system to stop functioning properly (hang) at POST after a warm boot.

Enhancements
– Provides improved security of UEFI code and variables. HP strongly recommends transitioning promptly to this updated BIOS version which supersedes all previous releases.

NOTE: Due to security changes, after this BIOS update is installed, previous versions cannot be reinstalled.

Pay close attention to the note at the end of the release text – it states that previous versions cannot be reinstalled. What this means is that you can no longer ‘flash’ back to an earlier BIOS version. This is important when it comes to deploying BIOS and how we detect what systems need to be updated, but more on that later.

The fourth reason that comes to mind is has to do with manipulating the BIOS settings programmatically. I have written blogs and talked on the topic of using the vendor utilities to programmatically change the BIOS settings (like BIOS to UEFI) using a Configuration Manager task sequence. Just as it is important to standardize on the BIOS versions, you should also develop standards on how each BIOS setting should be configured in order to maintain consistency and ensure devices are configured accordingly. By running on the latest BIOS version, you will ensure that these utilities will work correctly and configure the settings correctly.

I am sure I can think of many more reasons why you should start baselining and upgrading the BIOS versions for the supported systems in your environment, but hopefully I have identified the top four reasons and have convinced you that this needs to be done on a regular basis. In the next blog, Upgrading the BIOS Part 2, I will discuss the approach to flashing the BIOS along with some lessor understood caveats as it relates to BitLocker, BIOS passwords and UEFI 64-bit systems.

Originally posted on https://miketerrill.net/