Configuration Manager OSD, Recovery Partitions and MBR2GPT

As I was preparing for my Midwest Management Summit 2017 session, Building the Ultimate Windows 10 UEFI Task Sequence, I did a full end-to-end run of the In-place Upgrade Task Sequence and started running into issues. This led me to discover a couple of issues around Configuration Manager (specifically the Format and Partition Disk step) and Windows 10 Recovery partitions. The version of this Task Sequence flips the machine from BIOS to UEFI using the new MBR2GPT utility. The high-level process goes something like this:
1. Deploy TS to current OS (can be Win7/8/8.1/10) running in Legacy BIOS mode
2. In-place Upgrade to Windows 10 (still in Legacy BIOS after upgrade)
3. Once upgrade is done, reboot into WinPE 1703
4. Run MBR2GPT (supported and recommend method is to run in this version of WinPE)
5. Flip firmware settings (if successful)
6. Reboot to Windows 10 running UEFI
Only one little problem, MBR2GPT was not able to convert the disk (and I even managed to make it crash, but that is another story). After inspecting the disk layout, I noticed that there were 4 partitions (MBR2GPT can only work with 3 or less since it needs to create the EFI partition). After further investigation, it appeared that there were now two Recovery partitions (which seemed a bit odd):

The test system was first built from the following Configuration Manager Windows 7 OSD Task Sequence:

The problem is with the highlighted Partition Disk 0 – BIOS step. Behind the scenes, it creates a diskpart answer file that it uses to partition and format the disk. The Recovery partition is getting set to type 7 instead of type 27 (hidden). When the Windows 10 Setup runs, it does not recognize (or use) the Recovery partition that was created by Configuration Manager and proceeds to create a proper 450 MB hidden Recovery partition after the Windows partition. This is why the system is ending up with four partitions. Even if the Recovery partition that Configuration Manager created was the correct type, it would need to have a certain amount of free space based on its size in order for the Windows 10 Setup to be able to use it (see BIOS/MBR-based hard drive partitions for details on the Recovery tools partition sizes). During the upgrade, what should happen is setup should either resize the existing partition or create a new one if needed (see /ResizeRecoveryPartition switch description from the Windows Setup Command-Line Options). In my testing, it never attempted to resize the partition and always created another Recovery partition after the Windows partition. This is still bad because we end up with 4 partitions and that does not work well for MBR2GPT.

Luckily, there are a few things that can be done to avoid both of these issues. When creating partitions for BIOS based systems, I still like to use the built-in Format and Partition Disk step for creating the System Reserved and the Windows partitions. The reason for this is that I can assign the Windows partition to an OSD variable (which can be useful later on in the Task Sequence). For the Recovery partition, I create this right after the Format and Partition Disk step using a diskpart script in a Package. Now this is what my Format and Partition Disk step looks like for BIOS systems:

On the Windows partition, I now set this to 100% of the remaining space on the disk and notice that OSDisk variable that gets assigned for later use. By leaving this to 99%, this leaves a lot of space for the recovery partition on really large disks when we only need about 499 MB. This Task Sequence step directly after this is a Run Command Line step that calls diskpart with an answer file (with the same conditions as the Format and Partition Disk step).

NOTE: this is statically set to Disk 0 (like the Format and Partition Disk step). If you have systems that the OS disk is showing up on Disk 1, then be sure to create multiple steps with conditions.

After selecting the disk number in my MBR_RecoveryPartition.txt file, the first thing I do is select the Windows partition (#2) and shrink it by 499 MB (to keep within the Recovery Partition parameters). Then simply create a new partition with the remaining space, format it and then set the partition type to 27 (hidden). I list the partition information before and after the commands so that the information gets picked up in the logs and status messages. Using this method, we now have a 499 MB hidden Recovery partition.

Windows 10 In-Place Upgrade

If we just leave this as-is, then chances are the Windows 10 Setup will still create another recovery partition (which is not what we want to happen). Since the previous Windows recovery partition will be replaced, we can create a step right before the Upgrade Operating System step that cleans the Recovery partition. This way, the Windows 10 Setup will use it since there is enough free disk space on that partition (which is exactly what we want so that MBR2GPT will run). This is also Run Command Line step that calls diskpart with an answer file.

NOTE: this is also statically set to Disk 0. If you have systems that the OS disk is showing up on Disk 1, then be sure to create multiple steps with conditions. In addition, only target systems where the third partition is the recovery partition or put a condition on this step that checks for a recovery partition. All data on this partition will be lost after this step executes.

When formatting this partition, the partition type gets reset to 7. The above diskpart script resets the partition type back to 27 (hidden) after the format. Windows 10 Setup will now use the third partition as the recovery partition and after the upgrade there will only be three partitions. This will now allow MBR2GPT to run correctly after the upgrade so that BIOS to UEFI can be done as part of the in-place upgrade to Windows 10.

Originally posted on https://miketerrill.net/

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/

How to open CMTrace in WinPE like a boss

If you have ever done OSD, then chances are you have had to open up CMTrace a time or two to look at the smsts.log file. CMTrace displays one of the most annoying pop up boxes of all times and it is usually hiding behind the running task sequence dialog window: “Do you want to make this program the default viewer for log files?”

01 Do you want to

The answer is yes for the millionth time! Wouldn’t it be nice if it just did this automatically and never asked you again? If I had to guess, I bet you are shaking your head yes. For this post, I am going to show you how to modify your boot images so that it never asks you this annoying question again while running in WinPE.

Several years ago (back in 2009) I developed a solution on how to automatically open CMTrace (called Trace32 back in those days) for a debug task sequence. I finally got around to blogging the solution a few years ago and it is called ConfigMgr 2012 OSD: Automatically Open SMSTS log. This contains the important registry keys that we need to set in order to bake this into our boot images (and thus eliminating these three steps for the WinPE phases).

  1. The first thing we need to do is create a directory that we can use to mount our boot images (for example, MD d:\mount).
  2. Next we need to mount the boot image. This can be done using dism (be sure to run it from an elevated command prompt that has dism in the path – like the Deployment and Imaging Tools Environment short cut under Windows Kits). Select the boot image you would like to modify, I am using the default x86 boot image (in this example Configuration Manager is installed in D:\Program Files\):
    Dism /mount-wim /wimfile:”D:\Program Files\Microsoft Configuration Manager\OSD\boot\i386\boot.wim” /index:1 /mountdir:D:\mount
  3. Now we need to load the DEFAULT registry hive from the WinPE image. In my other blog post, we are creating the key in the HKEY Current User, however, since this is an offline registry, we are going to set it in the HKEY User hive which is what HKCU loads defaults from:
    Reg load HKU\winpe d:\mount\Windows\System32\config\default
  4. Now that we have the offline registry loaded, we can create the entries that we need. We will create the following registry keys that causes CMTrace to launch that annoying pop up box if they don’t already exist:
    Reg add HKU\winpe\Software\Classes\.lo_ /ve /d Log.File /f
    Reg add HKU\winpe\Software\Classes\.log /ve /d Log.File /f
    Reg add HKU\winpe\Software\Classes\Log.File\shell\open\command /ve /d “\”x:\sms\bin\x64\CMTrace.exe\” \”%1\”” /f
    NOTE: I used to put CMTrace in the Windows\System32 directory, but this is no longer needed since x:\sms\bin\i386 (use this path above for 32-bit boot images) and x:\sms\bin\x64 are now in the path now and ConfigMgr places the proper architecture of CMTrace in these locations by default. Also, be careful of smart quotes if copying and pasting.
  5. Next, unload the WinPE registry:
    Reg unload HKU\winpe
  6. Now we need to unmount the WIM file and commit the changes:
    Dism /unmount-wim /mountdir:d:\mount /commit
  7. In the Configuration Manager Console, select the boot image and update the distribution points. Generate new boot media based on the modified boot image, boot up a system (or PXE boot) and test by opening up a command prompt and typing CMTrace.

If everything worked right, CMTrace will open up without asking you “Do you want to make this program the default viewer for log files?”, as it already knows the answer. Repeat for other boot images you would like to modify. Here is a link to a text file that can be downloaded and renamed to .bat.

If you think this should automatically be in Configuration Manager, head on over to User Voice and vote for Stop CMTrace from asking us if we want to use it as the default viewer for log files in WinPE.

Originally posted on https://miketerrill.net/

How to detect, suspend, and re-enable BitLocker during a Task Sequence

In this blog post, I am going to show some simple steps that you can add to your Task Sequences to be able to detect, disable, and enable BitLocker status. This can be useful (and necessary) when performing activities like flashing the BIOS, running the new MBR2GPT utility, or upgrading to a newer version of Windows. In Configuration Manager, there are a few Task Sequence steps that are for BitLocker configuration and management:

Disable BitLocker – this step will disable BitLocker encryption on the current operating system drive or one that you specify and runs in a full operating system (does not run in WinPE). It does not decrypt the drive, but it does leave the key protectors visible in clear text on the hard drive. This step only disables BitLocker for one reboot (if you would like to see this step updated, vote for my Configuration Manager Uservoice item Add Reboot Count functionality to the Disable BitLocker TS Step). This means that BitLocker will be enabled again after the restart. If you need BitLocker to be disabled for more than one restart, then you can use manage-bde with a Run Command Line step (see below). Also, if there are data drives encrypted, then they need to be disabled before disabling the operating system drive.

Note: before running MBR2GPT, BitLocker should be disabled. Also, for just a Windows 10 In-place Upgrade with BitLocker (not doing MBR2GPT), it is not required to disable BitLocker, however, there have been reports of BitLocker not being suspended long enough during the upgrade (see the link to Jonathan Conway’s blog below) .

Enable BitLocker – this step will enable BitLocker encryption on a drive. It only runs in a full operating system (in other words, it does not run in WinPE). If selected for use, the TPM must already be enabled, activated, and allow ownership prior to running this step. This step can be used to re-enable BitLocker if the drive is already encrypted with BitLocker but in a disabled state.

Pre-provision BitLocker – this step runs under WinPE (only) and is used to enable BitLocker during the WinPE phase of the Task Sequence. It also encrypts the used drive space, which makes encryption times faster. Once in the full operating system, use the Enable BitLocker step to apply the key management options. This step is generally be used in New Computer or Wipe-and-Load Task Sequences.

Manage-bde – this is a built in command line tool that allows for the enabling, disabling, updating and reporting on BitLocker. The Microsoft TechNet documentation on Manage-bde is a bit stale and has not been updated to reflect some of the new capabilities that have been added in the newer releases. The most important one is the ability to control the reboot count when the protectors have been suspended. There is a new parameter called -RebootCount or -rc that takes a value between 0 and 15, where 0 suspends the protection indefinitely. This can be useful if you have several reboots during a Task Sequence and you need to make sure that BitLocker stays suspended (optional method listed below).

Note: Jonathan Conway has a great blog on how to use Manage-bde with the Task Sequence called SCCM Windows 10 Upgrade Task Sequence: BitLocker PIN Protector Issues on Laptops.

Now, to disable BitLocker, you could place that step in the Task Sequence and allow it to ‘Continue on error’. If you like to only use ‘Continue on error’ in certain cases and definitely want to know if BitLocker was enabled (so that you can conditionally re-enable it later on in the Task Sequence), then this can easily be done with a Set Task Sequence Variable step. Create a new Group called Disable BitLocker and on the Options tab add the following:
Task Sequence Variable _SMSTSinWinPE equals “False”

Place a Set Task Sequence Variable step in the Disable BitLocker Group and call it Set OSDBitLockerStatus for the name. Enter OSDBitLockerStatus for the Task Sequence Variable and enter Protected for the Value.
On the Options tab, add the following:
WMI Namespace: root\cimv2\Security\MicrosoftVolumeEncryption
WMI Query: select * from win32_encryptablevolume where driveletter = ‘c:’ and protectionstatus = ‘1’

This will check the BitLocker status on the C: drive (which is hopefully the OS drive). Keep in mind that if there are other data volumes that are BitLocker encrypted, these will need to be detected and decrypted first. Those systems can be filtered out in the collection targeting or it can be built into the Task Sequence using the same logic as above.

Next, add a Disable BitLocker step (with the option set Current operating system drive).
On the Options tab, add the following:
Task Sequence Variable OSDBitLockerStatus equals “Protected”

Optionally (recommended if needing multiple reboots), instead of using the built in Disable BitLocker step, add a Run Command Line step:
Name: Disable BitLocker
Command line: manage-bde -protectors -disable C: -RC 0
On the Options tab, add the following:
Task Sequence Variable OSDBitLockerStatus equals “Protected”

 

To re-enable BitLocker later on in the Task Sequence, create another group called Re-enable BitLocker.
On the Options tab, add the following:
Task Sequence Variable _SMSTSinWinPE equals “False”
Task Sequence Variable OSDBitLockerStatus equals “Protected”

Next, add an Enable BitLocker step under the Re-enable BitLocker Group (with the option set Current operating system drive). Since the drive is already encrypted, this step will just re-enable the key protectors if they are currently disabled (like if you used managed-bde and specified a reboot count).

Remember that the built in Disable BitLocker step will only disable BitLocker for one reboot (similar to what happens when you suspend BitLocker from the Control Panel applet), but if you used manage-bde with -RC 0, you will need to re-enable BitLocker.

Keep this Task Sequence template handy so that you can easily copy and paste into other Task Sequences in the future. I will be referring to this template in upcoming blog posts.

Originally posted on https://miketerrill.net/

First look – Dell 64-bit Flash BIOS Utility

Dell Laptop

Update 2/14/2017: Dell has publicly posted a download link to the 64-bit BIOS Installation Utility (now called Flash64W.exe) and you can find it here: http://en.community.dell.com/techcenter/enterprise-client/w/wiki/12237.64-bit-bios-installation-utility

Now that the cat is out of the bag that Dell has a 64-bit Flash BIOS Utility, I can finally blog about it. Earlier this week, Warren Byle of Dell announced the following on Twitter:

So there you have it, the wait is over (of course, after you get off the phone with Dell support) and you can now flash the Dell BIOS in 64-bit. You are probably thinking ‘big deal, I could do that already – flash the BIOS on 64-bit Windows 10’. Yea, you are right since full 64-bit Windows has a 32-bit subsystem, but the real magic is being able to flash the BIOS under WinPE. If your system is running UEFI (or you have a UEFI conversion Task Sequence), then it needs to boot the native architecture (in this case 64-bit). By only having a 32-bit flash BIOS utility before meant that we were unable to flash under WinPE x64. The Dell 64-bit Flash BIOS Utility is a much welcome (and needed) addition to the IT toolbox (thanks Warren)!

Using the tool is pretty simple, you use it in addition to the BIOS exe that you have already downloaded. I’ll cover off how I use it in a Configuration Manager Package in another post, but for now, here is how you use it:

001-flashupdatewin64

I used the following command line under WinPE x64 to silently flash a Dell OptiPlex 7040 from version 1.4.5 to 1.5.4:

FlashUpDateWin64.exe /b=OptiPlex_7040_1.5.4.exe /s /f /l=1.5.4.txt

Which wrote the following output:

***BIOS flash started on 1/31/2017 at 18:38:32***
Command: F:\FlashUpDateWin64.exe /b=OptiPlex_7040_1.5.4.exe /s /f /l=1.5.4.txt

1.4.5 INSTALLED (Dell System OptiPlex 7040)
– Gigabit Ethernet : 0.8
– Intel Management Engine (VPro) Update : 11.0.18.1002
– System BIOS with BIOS Guard  : 1.4.5
1.5.4 UPDATE ( OptiPlex 7040)
– System BIOS with BIOS Guard  : 1.5.4
– Gigabit Ethernet : 0.8
– Intel Management Engine (VPro) Update : 11.0.18.1002
– System Map : 1.0.1
– PCR0 XML : 0.0.0.1

Exit Code = 2 (Reboot Required)
***BIOS flash finished at 1/31/2017 at 18:38:41***

I hope you are as excited as me about this new *SHINY* utility from Dell. Happy 64-bit BIOS flashing!

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:

001-1e-bios-to-uefi

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.

002-1e-bios-to-uefi

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:

003-1e-bios-to-uefi

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/