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:

– (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 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.

– 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/

BIOS and Secure Boot State Detection during a Task Sequence Part 2

In BIOS and Secure Boot State Detection Part 1, I talked about the various states a system can be in for the BIOS Mode and Secure Boot state. Having these states defined as OSD variables can be useful in determining what actions need to be performed in order to switch a system to UEFI Native with Secure Boot enabled. Depending on how you perform the vendor firmware changes, you may or may not need to define the difference between UEFI Hybrid and UEFI Native. UEFI Hybrid is when the system is running UEFI and the Compatibility Support Module (CSM) is enabled (this is how you can run Windows 7 in UEFI mode – yes, really). In order to enable Secure Boot, the CSM needs to be disabled first. Also, for Secure Boot state, you may or may not need to define all of the possible options. If the goal is to get to Secure Boot enabled, that may be good enough to just test for that. However, Secure Boot disabled may be a nice to have in the case you have systems that do not play well with Secure Boot being enabled.

I start off by creating a group called Set BIOS and Secure Boot Variables. For a Windows 10 In-place Upgrade Task Sequence, I place this group after the Install Updates step in the Post-Processing group (but more on that in another post). This way, the system is already running Windows 10, which is a Secure Boot capable operating system (unlike Windows 7, which is not capable of running Secure Boot). The first Task Sequence variable I like to define is called BIOSMode, I set this to LegacyBIOS on the condition that _SMSTSBootUEFI equals FALSE.


We could just use the _SMSTSBootUEFI variable, however it is not as intuitive to other administrators if they need to read or edit the Task Sequence or read Status Messages and/or log files.

Next, add another Task Sequence variable called SecureBootState with the value Enabled. The condition on this is going to be based on the registry value:  HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State\UEFISecureBootEnabled = 1.



Now add another Set Task Sequence variable step with the same name, SecureBootState, but this time set the value to Disabled. The condition on this is going to be based on the registry value:  HKLM\SYSTEM\CurrentControlSet\Control\SecureBoot\State\UEFISecureBootEnabled = 0.



There is also the Secure Boot state of unknown or NA, but for the time being I do not use this one in any of my Task Sequences. I also do not use the condition where SecureBootState = Disabled currently, but I figured it would be handy to have it in the future if needed. I have also created an item on uservoice so that maybe one day we will see a variable like this as part of the product: Create an OSD variable for Secure Boot – _SMSTSSecureBootState.

Feel free to download my exported Set BIOS and Secure Boot Variables Task Sequence here (created on Configuration Manager Current Branch 1702). Stay tuned on how to use these variables in a BIOS to UEFI Task Sequence…

Originally posted on https://miketerrill.net/

BIOS and Secure Boot State Detection during a Task Sequence Part 1

With all of the security issues and malware lately, BIOS to UEFI for Windows 10 deployments is becoming a pretty hot topic (unless you have been living under a rock, UEFI is required for a lot of the advanced security functions in Windows 10). In addition, with the Windows 10 Creators Update, Microsoft has introduced a new utility called MBR2GPT that makes the move to UEFI a non-destructive process. If you have already started deploying Windows 10 UEFI devices, it can be tricky to determine what state these devices are in during a running Task Sequence. The Configuration Manager Team introduced a new class called SMS_Firmware and inventory property called UEFI that helps determine which computers are running in UEFI in Current Branch 1702. This can be used to build queries for targeting and reports, but it would be nice to handle this plus Secure Boot state (and CSM) during a running Task Sequence. We do have the Task Sequence variable called _SMSTSBootUEFI that we will use, but we need to determine the exact configuration in order to execute the correct steps.

There are three different BIOS modes that a system can be running:
Legacy BIOS – also known as BIOS emulation, this requires a MBR partitioned disk in order to boot. Most Windows 7 systems are running this configuration.
UEFI Hybrid – this mode is when a system is running in UEFI, but with the Compatibility Support Module (CSM) (also known as Legacy ROMs) enabled. Unlike Legacy BIOS, this mode requires a GPT partitioned disk in order to boot. Windows 7 can run in this configuration and before there was MBR2GPT, this was the recommended mode to deploy Windows 7 in so that it could be easily upgraded to Windows 10 at a later date without repartitioning the disk.
UEFI Native – this mode is when a system is running in UEFI without the CSM. It also requires a GPT partitioned disk in order to boot. Windows 7 cannot run on a system that is configured for UEFI Native.

Now let’s talk about Secure Boot. Secure Boot and CSM are incompatible – if the CSM is enabled, then you cannot enable Secure Boot. When Secure Boot is enabled, you cannot enable the CSM. Based on this information, we know that Secure Boot will be unsupported in Legacy BIOS and UEFI Hybrid modes (Note: When I say unsupported, I am not talking about if the device is capable of running Secure Boot. Secure Boot requires a device running UEFI 2.3.1 Errata C or later and an operating system capable of running Secure Boot). Configuration Manager currently does not have out of the box functionality for reporting on Secure Boot, but the feature has showed up in the Technical Preview 1703 release. In the meantime, see my blog called Inventory Secure Boot State and UEFI with ConfigMgr on how to extend hardware inventory in Current Branch 1702 or older in order to collect this information.

From this information, we can create a handy chart to help visualize the configuration options:

NOTE: For UEFI Hybrid, Secure Boot State is unsupported if the CSM is enabled, however, an operating system that supports Secure Boot will show that status as Off (Disabled) in System Information.

Now, with this information and MBR2GPT, we should be able to create a single Windows 10 Feature Update Task Sequence for clients Windows 7/8/8.1/10 and it should not matter if they are already running UEFI or Legacy BIOS. The actions that we need to perform do matter and this is where we can set some Task Sequence variables to help with the logic on the various steps. But first, let’s see what needs to be done based on the four configurations above. We already said that Legacy BIOS is the only configuration that uses a MBR partitioned disk. Therefore, this will be the only configuration that we need to run MBR2GPT. When we run MBR2GPT, we also need to configure the device’s firmware settings for UEFI and enable Secure Boot (the Microsoft solution does not do this for you, you are on your own to use the vendor methods to do this piece).

If you are one of the few that took last year’s recommendation and started deploying Windows 7 in UEFI mode, then those systems will be running UEFI Hybrid. We do not need to run MBR2GPT on these systems since they are already running a GPT partitioned disk. We simply need to turn off the CSM (or Legacy ROMs) and enable Secure Boot (once again, the Microsoft solution does not do this for you).

For systems that are running UEFI Native but Secure Boot is not enabled, we simply need to enable Secure Boot. Lastly, for systems that are already running UEFI Native with Secure Boot enabled, we do not need to do anything additional for these systems. Adding these actions to our chart, it makes it very clear what actions need to be done under each scenario:

In a follow blog post, I will go into more detail on how we can use this logic in a single Windows 10 In-Place Upgrade Task Sequence, what the steps look like and where each of them go.

Originally posted on https://miketerrill.net/

Getting Started with 1E BIOS to UEFI

1E BIOS to UEFI is a component of the 1E OSD Solution Accelerator that comes with 1E Nomad and enables administrators to create a true Zero Touch BIOS to UEFI Task Sequence method. This enables enterprises to get to secure Windows 10 by enabling feature like Secure Boot, Credential Guard and Device Guard to name a few, without requiring a high-touch and costly manual process.

The Challenge

There are two challenges when it comes to converting a system from BIOS to UEFI during an OSD Task Sequence. The first part of the problem is manipulating all the necessary BIOS settings that are required on class 2 UEFI devices to make them boot up in UEFI mode (class 3 UEFI devices like Surface Books only have the option of running UEFI). Fortunately, most of the major vendors, like Dell, HP and Lenovo, provide methods and tools that allow this to be done programmatically on their enterprise class systems. The downside is that this often needs to be scripted and getting the right combination to work on all your supported models can be tricky and time consuming. Some settings can vary even between models from the same vendor (some vendors are worse than others). Also, the order in which the settings are applied is important. The utility or method might return a success on a setting change but not actually change the setting because of a dependency on another setting. The second part of this problem is to be able to get the Task Sequence to reboot successfully and continue the Task Sequence after the BIOS/UEFI changes take effect. Microsoft is addressing this problem starting in the Configuration Manager 1610 release. For more information on this step, see the Task sequence steps to manage BIOS to UEFI conversion. Also, my good friend Nickolaj has written a blog called Convert from BIOS to UEFI during Windows 10 deployments with ConfigMgr Current Branch – Introduction, where he talks about what is happening with the new Task Sequence variable called TSUEFIDrive.

The Solution

1E BIOS to UEFI contains two simple Task Sequence actions that overcomes both challenges and can be used with any version of Configuration Manager Current Branch (1511, 1602, 1606, as well as the recently released 1610), and Configuration Manager 2012 SP2/R2 SP1. The first task sequence action is the 1E BIOS to UEFI step. I call this the magic step (which drives 1E Marketing crazy). The reason I call it the magic step is because it was the first solution to address the BIOS to UEFI problem in a single reboot (and no, we aren’t doing anything dodgy like flipping read-only variables). Microsoft now includes this capability in the 1610 release, but this step is still beneficial to older versions. Maybe someday I will blog on what is happening behind the scenes, but that will need to come later since there are certain companies that take an interest in my work and like to copy it (and no, I am not talking about Microsoft).

This clever step has no configuration and only needs to be placed twice in the Task Sequence as seen below:


The other custom action is called 1E BIOS to UEFI OEM. This step is the one that everyone loves as it has buttons and check boxes that can be set. This step works on Dell, Lenovo and HP enterprise class systems.


This step calls the right commands in the correct order for the make and model it is running on. Simple, right? That was the goal – to be able to abstract all the commands that need to be run (and the order they need to be run) from the administrator so that he/she can go on with more important thing (like deploying Windows 10 in UEFI). Before getting into the details of the settings, you are probably wondering what the OEM Toolkit Package is that is referenced at the bottom of the step. Well, when installing the 1E BIOS to UEFI solution, you have the option of the installer automatically downloading the vendor utilities, creating a Configuration Manager Package and distributing it to a Distribution Point Group so that you can get on with your Task Sequence. In other words, it automates the process and you do not have to follow some step-by-step document and manually create a toolkit package.

Now that we have that covered, let’s talk about the settings. The most important is the UEFI Configuration. Here we provide three options – 1: UEFI Native with Secure Boot 2: UEFI Native without Secure Boot 3: UEFI Hybrid with CSM. Here are the use cases for each one:

1: UEFI Native with Secure Boot – this will configure the BIOS/UEFI settings so that the system boots native UEFI and has Secure Boot enabled. NOTE: This is the only way currently to switch to UEFI on Lenovo systems as they do not provide a separate Boot Mode setting (at least one that pertains to UEFI).

2: UEFI Native without Secure Boot – this is the same as above but Secure Boot will not be enabled. You might be wondering ‘why would you not enable Secure Boot?’ Some low level drivers that get loaded at boot time might not be signed properly and if Secure Boot is enabled, then the system is not going to boot. Since Secure Boot can only be programmatically enabled (and not disabled), then someone needs to physically disable Secure Boot by going into the BIOS/UEFI settings. So, if you have a tricky system that has bad drivers then you can simply put a condition on this step so that Secure Boot is not enabled on these systems. Hint: once the issue is resolved you can use this step again to programmatically enable Secure Boot down the road.

3: UEFI Hybrid with CSM – you are probably thinking ‘what the heck is this and when would I use it?’ Well, for those of you that did not know this, Windows 7 does support running in UEFI mode. Still not getting it? If you are still deploying Windows 7 (which I bet most of you still are), you could have been deploying it in UEFI mode all this time. What this means is that you could have taken advantage of the fancy Windows 10 in-place upgrade and not had to worry about apps and user data. Since the disk will already be GPT there is no need to format and partition.

The last setting worth mentioning is the UEFI PXE setting. What this does is enable PXE in the UEFI network stack (which is not the same as PXE in the legacy BIOS). This is important as Configuration Manager will format and partition the disk based on the how the system was booted (Hint: look up _SMSTSBootUEFI).

Lastly, we continue to certify this step on all kinds of hardware models from each of the three vendors (that is how I know about all of the setting differences between models). Also, we have tons of ideas and features planned for this step. In fact, there were other tabs that originally showed up on early releases but got cut for the initial release – but that is top secret for now.

Configuration Manager 1610

So the burning question is ‘do I still need this if I have Configuration Manager 1610?’ Well, like I mentioned above, 1610 does take care of the magic step. However, you are on your own for handling the vendor settings. So that makes the 1E BIOS to UEFI OEM step still a valid component when it comes to doing BIOS to UEFI.

Here is the Microsoft Task Sequence that contains the new Task Sequence variable mentioned above along with the 1E BIOS to UEFI OEM step:


In summary, the 1E BIOS to UEFI solution is extremely useful, even with the new ability to format a disk for UEFI while still booted in BIOS mode in Configuration Manager 1610.

Originally posted on https://miketerrill.net/