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

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:

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:


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 :
– 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 :
– System Map : 1.0.1
– PCR0 XML :

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

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

Create multiple partitions on ANY USB Flash Drive

I have seen a few blog posts lately that talk about splitting large WIM files in order to get them to fit on a USB flash drive that is formatted as Fat32. I am not exactly sure why you would want to do that when you don’t have to, as it sounds like extra work to me (but hey, if you like extra work then be my guest).

In my previous post, USB Flash Drives, UEFI and large WIMs, I showed how you can create multiple partitions on certain USB Flash Drives that were either already set as a fixed disk or could have the removable bit flipped using a special utility. Having multiple partitions is useful when you need to boot a UEFI system off the USB Flash Drive and install an operating system. UEFI needs a Fat32 formatted partition in order to boot. The problem with Fat32 is that it has a maximum file size limit of 4GB. Custom images (WIMs) can easily exceed 4GB in size (even the install.wim for Windows Server 2016 is larger than 4GB), which prevents them from being copied to a Fat32 formatted partition. In order to over come this, you would need either need to split the WIM or install it from a file share (provided you have network connectivity) or from another NTFS formatted partition/drive.

Starting in the Windows 10 Insider Preview build 14965, Diskpart now allows you to create multiple partitions on ANY USB Flash Drive – even ones that have the removable bit set.


The following two USB Flash Drives were ones that I could not flip the removable bit nor get multiple partitions on them previously (note that they both still show as Removable):

SanDisk Ultra:




In order to copy files to the second partition, you will need to use the Windows 10 Insider Preview build 14965 (or later). Windows 10 1607 cannot read the second partition (yet), which means that current Windows setup (Server 2016 or Windows 10) might have an issue reading it (in other words I haven’t fully tested that part yet).  Now time to experiment more with this and the new WinPE found in the Windows ADK Insider Preview

Originally posted on

USB Flash Drives, UEFI and large WIMs

If you have already started working with UEFI devices, then you have probably figured out a few of the gotchas when it comes to booting these devices. First, you need to boot the device using the native architecture. So, if the device you are attempting to boot is a 64-bit device, then it needs to boot with a 64-bit boot image. Second, if you are using a USB Flash Drive, then you probably have realized that UEFI devices will not boot from a NTFS formatted flash drive. The flash drive needs to be formatted using FAT32 in order to boot UEFI. That is all fine and dandy, but what happens if you have a large WIM file (one that is greater than 4GB, like the Windows Server 2016 install.wim that is 4.38GB) that you need to copy onto the flash drive? The short answer is that you can’t, at least on the FAT32 partition. You can always split the WIM, but what fun is that? Plus, it sounds like extra work to me. Lucky for you, with the right USB flash drive and the information in this blog post, I will show you have you can fit that 4+GB WIM on your flash drive and still boot UEFI (because if you are still using BIOS, stop reading now and switch your system to UEFI).

The trick is to create multiple partitions on your flash drive, just like you do (or like Windows setup does for you) when you install Windows in UEFI mode. The problem is a limitation for creating multiple partitions on removable media. By flipping the ‘removable bit’ on the flash drive, you can then use diskpart to create a bootable FAT32 partition (large enough to fit all of the boot files) and then a second NTFS partition that contains the large WIM file (along with the other setup files that are needed. There are a few utilities out there on the Internet, like BootIT from Lexar (although I could not get it to work on some new Lexar USB flash drives that I just bought), that may or may not do the trick for you (NOTE: this does not work on all USB flash drives and you might toast your flash drive so use at your own risk). There are also some other tools that you might come across if you search long enough (and on some sketchy sites), but once again – use at your own risk. Hopefully one day soon, Windows will allow us to partition removable media since eventually most devices will be class 3 UEFI and WIM files are getting larger, not smaller.

Lucky for me, the SanDisk Ultra 16GB (Model SDCZ45-016G), which I bought at Costco several years ago, already shows up as a basic disk type (in other words, not removable), and allows me to create multiple partitions so that I can make it bootable in a UEFI configured system and still have the ability to copy large WIM files onto it.


It also looks like these are still available on Amazon (although I cannot guarantee that they are like the Costco model apart from the matching characters on the model number).

The process:

  1. Plug in the flash drive and open up an elevated command prompt. Run the following commands:
    list disk
    select disk x (where x is the disk # of your flash drive)
    clean (this is a destructive process, so be sure you have the correct drive and have backed up anything you want to keep)
    create partition primary size=500
    format fs=fat32 quick
    create partition primary (this creates the second partition)
    format fs=ntfs quick
  2. For this example, we will use the Windows Server 2016 ISO (you could also do the same with Configuration Manager OSD Media). Mount the ISO (in this example, it is on drive E:) and copy the subfolders boot and efi and files bootmgr and bootmgr.efi to the fat32 drive that was created above (in this example, it is on drive F:).
  3. On the fat32 drive create a subfolder called sources.
  4. On the Windows Server 2016 ISO drive, navigate to the sources directory. Locate the boot.wim and copy it to the fat32 drive in the sources subfolder.
  5. Copy the entire contents of the Windows Server 2016 ISO drive to the ntfs drive (in this example, it is on drive G:).
  6. Optionally name the partitions on the USB flash drive for easy identification.

Now you should be able to boot right up using the USB flash drive in UEFI mode and in this case proceed to install Windows Server 2016.

Originally posted on

PXE Booting in the Real World

At the Midwest Management Summit today in the 7 AM OSD Birds of a Feather session, there was a lot of discussion around troubleshooting PXE booting issues. A reference was made to a session that Troy Martin and I gave at the 2014 Midwest Management Summit called PXE Booting in the Real World. Troy put together some nice SQL queries that help with the troubleshooting process:


/* Get list of devices and their Last PXE boot for (a) required deployments */
SELECT * FROM [CM_PS1].[dbo].[LastPXEAdvertisement] order by MAC_Addresses
/* Get item key for unknown records */
select * [CM_PS1].[dbo].[UnknownSystem_DISC]
/* Is device known and a valid client on the site */
Use CM_PS1
exec NBS_LookupPXEDevice N'45A74041-2F02-4A5E-B413-CD35DDE47123',N'1E:1E:1E:1E:1E:B1'
exec NBS_LookupPXEDevice N'2DCFD0F8-9134-44A3-84BB-0BFC114ADD87',N'1E:1E:1E:1E:1E:B2'
/* Get list of deployments for device */
Use CM_PS1
exec NBS_GetPXEBootAction N'16777278',N'2046820352',N'45A74041-2F02-4A5E-B413-CD35DDE47123',N'1E:1E:1E:1E:1E:B1',N''
exec NBS_GetPXEBootAction N'16777279',N'2046820353',N'2DCFD0F8-9134-44A3-84BB-0BFC114ADD87',N'1E:1E:1E:1E:1E:B2',N''

Here is a link to the slide deck that contains more information and a bunch of useful references.

Originally posted on

How to create a HP BiosConfiguration Utility Package in ConfigMgr

01 HP Logo

HP has a utility that is similar to the Dell’s Command | Configure utility (see How to create a Dell Command-Configure Package in ConfigMgr) called the HP BIOS Configuration Utility that allows for reading and setting BIOS/UEFI values on HP systems. The latest release (version at the time of this blog post) can be found on the HP Client Management Solutions page in the Download Library. The HP BIOS Configuration Utility can be used to enable and standardize BIOS/UEFI settings automatically across the enterprise, yielding a consistent, standard environment. Now that Windows 10 is here, organizations are going to want to configure UEFI as the default so that they can leverage features like Secure Boot, Device Guard and Credential Guard.

The HP BIOS Configuration Utility is only command line (in other words, there is not a GUI component like Dell’s Command | Configure utility). However, the HP BIOS Configuration Utility can output an answer file that can then be used to apply to other systems. For this post, I am going to show you how to create a basic ConfigMgr Package that can be used as part of an OSD Task Sequence

The first thing you need to do is download it from the HP Client Management Solutions page (or search on HP BIOS Configuration Utility) and install it on a HP system.

Next, create a directory on your ConfigMgr Package repository share where you store the source files for your ConfigMgr Packages (for example \\ContentSource\Packages\HP\BIOS Configuration Utility-WinPE\

Locate the install directory and copy the contents of the installation directory (minus the link to the User’s Guide) to the Package share. On a x64 system, the default install location is C:\Program Files (x86)\Hewlett-Packard\BIOS Configuration Utility.

01 Default Install Directory

Create a file in the root of the Package directory called BCU.cmd. Use the following for the contents of the file:


set cmdline=%*

ECHO == Seting BIOS Settings ==
REM Determine Arch
SET BCU="BiosConfigUtility64.exe"
SET BCU="BiosConfigUtility.exe"
ECHO --Running command %BCU% %CMDLINE%
EXIT /B %errorlevel%

This file handles the logic to run the correct exe based on the currently detected platform. The final Package source directory should look like the following:

02 HP BIOS Config Package Source Directory

Create a Package in ConfigMgr like you normally would and distribute it to the Distribution Points. A Program is not required, so that can be skipped.

In a future post, I will show how this can be used in an OSD Task Sequence.

Originally posted on