Windows 10 BIOS to UEFI In-place Upgrade Task Sequence using MBR2GPT

At the Midwest Management Summit 2017, I gave a session called Building the Ultimate Windows 10 UEFI Task Sequence. In this session, I covered both types of BIOS to UEFI Task Sequences – Wipe-and-Load and In-place Upgrade. This blog is going to cover the In-place Upgrade version of the BIOS to UEFI Task Sequence. This Task Sequence will use variables that I previously wrote about in the blog posts: BIOS and Secure Boot State Detection during a Task Sequence Part 1 & Part 2, as the goal is to have a single Task Sequence that covers the various scenarios. In addition, this blog also replaces the original blog I wrote, Using MBR2GPT with Configuration Manager OSD, when I first discovered MBR2GPT in one of the Windows Insider builds.

NOTE: See my blog Configuration Manager Dynamic Drivers & BIOS Management with Total Control Part 2 for a downloadable Task Sequence Template for the following Task Sequence.

When converting from BIOS to UEFI, it is best to do this after the system has been upgraded to Windows 10. The version of Windows 10 does not matter, although, it should be a version that is still supported. Also, even though MBR2GPT will run in the full OS (starting with Windows 10 1703), it is a best practice recommendation to run it from WinPE (version 1703 or later). The reason for this is that there can be other applications on the system that use filter drivers for disk access (antivirus, antimalware, 3rd party disk encryption and other 3rd party p2p solutions). These applications could interfere with the disk conversion and potentially cause a failure, therefore, always run MBR2GPT in WinPE for best results.

Typically, a Boot Image is not assigned to an In-place Upgrade Task Sequence. However, since we are going to use WinPE as part of our Task Sequence, a WinPE 1703 (or later) Boot Image should be assigned to the Task Sequence. Also, it is important to use the 64-bit Boot Image when running on a 64-bit UEFI System.

The basic flow goes like this after the OS has been upgraded:
Disable BitLocker
Set BIOS and Secure Boot Variables
Restart into WinPE (if running Legacy BIOS)
Run MBR2GPT (if running Legacy BIOS)
Configure BIOS Firmware Settings
Restart into Windows
Re-enable BitLocker

If you are not using BitLocker, then you can skip the two BitLocker groups. Also, even though this process works with BitLocker using earlier algorithms, if you are coming from a version of Windows before Windows 10 1511 (like when coming from Windows 7), then you might want to consider the new encryption type AES-XTS (see the blog BitLocker: AES-XTS new encryption type for more information). Moving to the new encryption type will require decryption/re-encryption of the drive.

Disable BitLocker

The reason for putting this Group in after the OS has upgraded is to cover the scenario when coming from Windows 7. As I mentioned in my blog How to detect, suspend, and re-enable BitLocker during a Task Sequence, the built in Disable BitLocker Task Sequence step on suspends BitLocker for one reboot. Therefore, I run this Group one more time just incase BitLocker was re-enabled after the In-place Upgrade.

Set BIOS and Secure Boot Variables

I cover these steps in detail in the two blogs mentioned above, but the two variables that get used in the BIOS to UEFI Group are BIOSMode and SecureBootState.

Restart into WinPE (if running Legacy BIOS)

On this step, we only need to reboot if the system is running in Legacy BIOS Mode. If it is running in UEFI Hybrid or UEFI Native without Secure Boot, the disk will already be configured for GPT. On the Options tab, add the condition: Task Sequence Variable BIOSMode equals “LegacyBIOS” (Note: you could also use _SMSTSBootUEFI equals FALSE, but having LegacyBIOS is easier to find in log files, status messages and is easier for help desk personal to understand). Also add the hardware manufacturers that you want to support. This is important because you cannot convert BIOS to UEFI on a GEN 1 Hyper-V VM and you will probably want to test the rest of the Task Sequence on a VM outside of the BIOS to UEFI steps.


On this Group, we only need to perform BIOS to UEFI or BIOS Firmware Settings if the system is running Legacy BIOS, UEFI Hybrid or UEFI Native without Secure Boot. On the Options tab, add the condition: Task Sequence Variable SecureBootState not equals “Enabled”. Once again, also add the hardware manufacturers that you want to support.

MBR2GPT (if running Legacy BIOS)

I like to run this step prior to configuring the BIOS settings. Secure Boot can be programmatically enabled, however per the specification it cannot be programmatically disabled. If you enable Secure Boot prior to running converting the disk and MBR2GPT is not able to convert the disk for some reason (like too many MBR partitions, see my blog Configuration Manager OSD, Recovery Partitions and MBR2GPT), then the machine will require a desk side visit to reset the BIOS settings and manually disable Secure Boot.

This step will run under WinPE. MBR2GPT can be called directly using a Run Command Line step since it is in the path in WinPE. If dealing with systems that do not install the OS on disk 0, then you will need to create multiple steps and put the necessary conditions on each. MBR2GPT will generate useful log files and I like to save them in the Task Sequence log directory (_SMSTSLogPath). This way they will be available after the Task Sequence runs. On the Option tab, add the condition: Task Sequence Variable BIOSMode equals “LegacyBIOS. This will ensure that this step only runs under this condition. Note: we could have also used and/or added _SMSTSinWinPE equals “TRUE”. Also enable Continue on error. This is important because we do not necessarily want the entire In-Place Upgrade to fail just because MBR2GPT was not able to run. If it is a hard failure, then the Task Sequence will definitely not continue as the system will probably no longer boot up.

Configure BIOS Firmware Settings

In the Firmware Settings Group, you will add your own BIOS settings commands, utilities or tools. These commands, utilities and tools can run in a full OS or WinPE. If you use Dell systems, please see my previous blog post Automating Dell BIOS-UEFI Standards for Windows 10 for the commands (and order) of switching the UEFI settings using the Dell CCTK (aka Command Monitor). On the Option tab, add the condition: Task Sequence Variable _SMSTSLastActionSucceeded equals “TRUE”. This will ensure that this group is only entered if the previous step that runs was successful. In the case of a Legacy BIOS system, if MBR2GPT is not successful, we want the Task Sequence to continue, but we do not want to flip the BIOS settings to UEFI and enable Secure Boot. In the other case of a system running UEFI Hybrid or UEFI Native without Secure Boot, it will run if the previous non-skipped step was successful. NOTE: It is important to be running the latest BIOS version and BIOS utilities for best results. Also, be sure to account for BIOS passwords if used in your environment. It is best to disable the BIOS passwords and then re-enable them at the end of the process.

Restart into Windows

After the Firmware Settings are changed, a system reboot is required for them to be applied. This restart will boot the system back into Windows 10.

Re-enable BitLocker

Once the system has been configured for UEFI Native with Secure Boot and booted back up into Windows 10, it is time to re-enable BitLocker. The Re-enable BitLocker Group will run in a full OS and only if the OSDBitLockerStatus equals “Protected”. This variable gets set earlier in the Task Sequence before the operating system is upgrade. For more information, see my blog How to detect, suspend, and re-enable BitLocker during a Task Sequence.

MBR2GPT and BitLocker

If you read the Microsoft documentation for using MBR2GPT, they only tell you that you need to delete the existing protectors and recreate them (they don’t mention that you need to reset the Windows Recovery Environment to generate a new reagent.xml and update the bcd). They do not really give any clear guidance on how to do this.

Reset Windows Recovery Environment

Resetting the Windows Recovery Environment only needs to be done when using MBR2GPT with BitLocker. On the Option tab, add the condition: Task Sequence Variable BIOSMode equals “LegacyBIOS”.

I have seen some forum posts on the internet that talk about deleting the ReAgent.xml file (found in C:Windows\System32\Recovery). Windows will re-create this file on the next reboot and it should modify the bcd file accordingly. However, I prefer to update it (and the bcd) by simply disabling WinRE and re-enabling it. I also display the status after re-enabling it. Each of these commands will pipe output to the smsts.log and also CM Status Messages. For clarity they are split in three different steps.

Reset BitLocker Protectors for MBR2GPT

Just like Resetting the Windows Recovery Environment, resetting the BitLocker Protectors only needs to be done when using MBR2GPT with BitLocker. On the Option tab, add the condition: Task Sequence Variable BIOSMode equals “LegacyBIOS”.

Now we just need to delete the BitLocker protectors. This can be done by running the following command: manage-bde -protectors -delete c:

It is extremely important to perform a restart after deleting the BitLocker protectors and before enabling BitLocker. If it is not done in this order, the system will prompt for the BitLocker recovery key on the next reboot.

Enable BitLocker

The last thing to do in the Re-enable BitLocker Group is to enable the BitLocker protectors. This can be done using the native Enable BitLocker Task Sequence step. Since the operating system drive is already encrypted, just the BitLocker protectors are being created and/or enabled (depending on the scenario).

In summary, this approach will cover multiple upgrade scenarios, including BIOS to UEFI, when performing an in-place upgrade to Windows 10.

Originally posted on

Using MBR2GPT with Configuration Manager OSD


[Update 4/5/2017] This post was based on the MBR2GPT that was released with the Windows Insider build 15007. There are a few things that have changed since then – the /silent switch has been replaced with the /convert switch. Also, it is highly recommended to run MBR2GPT from WinPE 1703 (this is required for earlier versions of Windows 10 – 1507, 1511, 1610). Look out for a new post on using this tool with Configuration Manager (including how to use it with BitLocker systems).

In my previous post, Getting Started with MBR2GPT, I showed a first look at the MBR to GPT conversion utility that is going to be released with the upcoming Windows 10 Creators Update. In this post, I am going to show how it can be integrated with a Configuration Manager OSD Task Sequence. In this test, I reset my test machine back to Legacy BIOS and disabled Secure Boot. Next, I installed build 15002 of the Windows 10 Enterprise Insider Preview, joined it to my test domain and installed the Configuration Manager 1610 client.

Starting off simple, the goal was to see if I could run MBR2GPT in a simple Task Sequence and automate what I did manually in the previous post. The first thing I did was add MBR2GPT.EXE to my 1E BIOS to UEFI OEM Toolkit Package – since I need to change the BIOS settings, it made sense to just add it to this package. The next step was to create a custom, simple Task Sequence – one that I can later just copy into a Windows 10 In-place Upgrade Task Sequence. The end result looks like this:


For the Options on this Group, I put the following Conditions:


I only want to run this on a Dell, HP or Lenovo that is currently running Legacy BIOS (no need to run it if the system is already UEFI).

The next step is to run MBR2GPT. This is the same command that I ran manually, but I added the /silent switch so that it would run without prompting for input:


Next, I run my 1E BIOS to UEFI OEM step (available to 1E Nomad customers) to configure the necessary BIOS settings. In this case I want to enable Secure Boot as well. The nice thing about this step is that conditions can be added so there can be multiple configuration – for example, one with Secure Boot and maybe one without Secure Boot (for systems that might have conflicts with Secure Boot because of bad video card drivers).


The last thing to do is reboot after running both of these steps in order for the configurations to take effect.


Running this Task Sequence on my test system yielded the following in the smsts.log where we can see that MBR2GPT ran successfully:


Adding this into an in-place upgrade Task Sequence might look something like this:


Keep in mind that this is only part of the Windows Insider release right now and should not be used in production, but initial tests seem to show promising results. Also, there are still some blockers for being able to use in-place upgrade like I mentioned in the previous post. Have a plan on how you plan on handling applications that need to be uninstalled, upgraded and replaced. In other words, just because you can do in-place upgrade, do you still want that old version of Office on your shiny new Windows 10 OS? In addition, Windows 10 content is going to have a massive impact to your network. Not just the Feature Updates, but the Quality Updates (i.e. security patches) are likely to have the biggest impact (especially if you have to patch multiple versions of Windows 10). Look into using a peer to peer solution (like 1E Nomad) sooner rather than later. Lastly, chances are, you are going to have to support multiple deployment methods in your environment – make sure the tools (and vendor) you choose is capable of handling all of them seamlessly (don’t settle for cheap knock offs – you get what you pay for and can open up your network to unwanted security vulnerabilities). Baremetal for new computers and break/fix, hardware refresh/replacement, wipe-and-load, and in-place upgrade.

Originally posted on

Getting Started with MBR2GPT


In my previous post, BIOS to UEFI made easier with Windows 10 Creators Update, I uncovered a hidden gem in the 15007 build of the Windows 10 Enterprise Insider Preview called MBR2GPT. The benefits of this MBR to GPT conversion utility is that it makes it easier to convert systems from BIOS to UEFI and be able to take advantage of all the security features that comes in Windows 10 like Secure Boot, Device Guard and Credential Guard (to name a few). Currently, in order to stay supported by Microsoft, the hard disk needs to be completely repartitioned and formatted when switching from MBR to GPT. This is a destructive process and requires the user data to be backed up off of the hard drive, applications to be re-installed and then the user data restored once the new OS is up and running. Without the proper tools (shameless plug – see the 1e Windows 10 Now Solution), this can be a cumbersome task.

You still want to put some thought into applications as it relates to an in-place upgrade. There will be some applications that will be upgrade blockers (mainly 3rd party antivirus that is not compatible with the Windows 10 in-place upgrade process or 3rd party disk encryption) and need to be uninstalled prior to the in-place upgrade. There will also be applications that you will want upgraded – do you really want to run Office 2003 which may have been your standard on Windows 7 on Windows 10 or would you like to uplift it to Office 365 as part of the process? You might also want to replace an application with a less costly application (like swapping an expensive FTP client with a less expensive one). And lastly, you might want to uninstall applications that are not used in order to reduce your security foot print and eliminate unnecessary patching. These are things to consider when venturing down the in-place upgrade deployment method.

Applications aside for now, let’s get back to MBR2GPT…

You are probably wondering what are the options for using this utility – well, I can tell you if you have already deployed Windows 10 to BIOS systems you are fortunately in luck. Also, if you have not even started your Windows 10 upgrade, you are also in luck. The basic upgrade process will look like the following:

Windows* running on BIOS > In-place upgrade to Windows 10 (probably Creators Update) – still running BIOS at this point > MBR2GPT > Vendor BIOS Settings > Reboot > Windows 10 running UEFI.

Where Windows* is any version that supports upgrading to a Windows 10 version that supports MBR2GPT (like Windows 7 SP1 x64, Windows 8/8.1 x64 and previous versions of Windows 10-1507/1511/1607).

Now that we have that covered, let’s see how this tool actually runs. Below, I have an Insiders build of Windows 10 Creators Update (note that this is build 15002 and that MBR2GPT is in 15007). As you can see, BIOS Mode is Legacy and there is a single hard disk with Master Boot Record(MBR) volume:


I have copied the MBR2GPT utility from a 15007 build on to the C: drive of this system. Running MBR2GPT.exe /? displays the following help output:


First thing I want to do here is test it using the /validate switch to see if it is actually going to work and what kind of output is going to be displayed by running:

MBR2GPT.EXE /disk:0 /validate /allowFullOS

This results in the following on-screen output:


And the following output is logged in %windir% in the setupact.log:


Now, I am going to run the command without the /validate switch. Notice the additional output on the command line and refreshing the disk volume properties shows it to be GUID Partition Table (GPT):


Next, this is where we would run the vendor tool to change the correct BIOS settings (we will do that later in a Task Sequence when we automate the process), but for now I am going to reboot and hit the proper key to get into the BIOS settings.

After making the necessary changes (and I even enabled Secure Boot), notice that System Information displays the BIOS Mode as UEFI with Secure Boot State set to On:


This first look at the MBR2GPT conversion utility looks very promising. Hopefully in the coming months as we get closer to the release of Windows 10 Creators Update we will start to get more information on it as well as what versions of Windows 10 will support it.

In my next blog, Using MBR2GPT with Configuration Manager OSD, I am going to show how we can integrate MBR2GPT into an OSD Task Sequence.

Originally posted on

BIOS to UEFI made easier with Windows 10 Creators Update


Back in December, Microsoft published a blog (Windows 10 Creators Update advances security and best-in-class modern IT tools) where they mentioned a conversion tool for making the conversion to UEFI:

“In-place UEFI conversion

We’ve heard from our customers that they want to take advantage of new Windows 10 security investments like Device Guard on their existing modern hardware, but many of these new features require UEFI-enabled devices. For those customers who have already provisioned modern Windows PCs that support UEFI but installed Windows 7 using legacy BIOS, converting a device to UEFI required an IT manager to repartition the disc and reconfigure the firmware. This meant they would need to physically touch each device in their enterprise. With the Creators Update, we will introduce a simple conversion tool that automates this previously manual work. This conversion tool can be integrated with management tools such as System Center Configuration Manager (ConfigMgr)* as part of the Windows 7 to Windows 10 in-place upgrade process.”

I disagree with their statement that you need to physically touch each device in the enterprise in order to make the conversion to UEFI, as I have engineered the process that we have been using at 1E in our Windows 10 Now solution since last year. However, in order to do the conversion and to be supported (which the 1E Windows 10 Now Solution is 100% supported) you need to completely format and partition the in order to change it from MBR to GPT. This presents other challenges, such as backing up and restoring user data and re-installing applications. There are other unsupported solutions out there (like GPTGen) that I know other vendors use that enable you to switch the disk layout from MBR to GPT without formatting and partitioning the disk, but I would steer clear of these solutions (and vendors) in order to continue to be supported by Microsoft.

In the Microsoft blog, they only made a mention of the ‘simple conversion tool’ and did not provide any details about it (like when to expect it, how to use it, etc.). Well, there was a nice little surprise that showed up in build 15007 of the Windows 10 Enterprise Insider Preview called MBR2GPT.EXE


This looks like the conversion utility that the blog post mentioned. Other than the MBR2GPT help, there is not much information about the utility and what versions of Windows 10 that will be supported. With this tool, more machines will qualify for an in-place upgrade (like machines that are currently running BIOS). There are still some in-place upgrade limitations out there, like 3rd party disk encryption (unless the vendor now supports in-place upgrade) or changing between architectures or base OS languages, that will still require a wipe-and-load approach (see Johan’s post Windows 10 Upgrade Limitations for a few others).

The other thing that needs to be done when using MBR2GPT is to set the correct vendor specific BIOS settings changes so that the system will boot UEFI after converting the disk layout. The order of the settings does matter and settings can vary among models from the same vendor. I have previously blogged about (Automating Dell BIOS-UEFI Standards for Windows 10) how to do this for Dell (they have the most consistent BIOS settings out of everyone). We also have a BIOS to UEFI tool that only comes with Nomad that abstracts all of the vendor settings that I have blogged about (Getting Started with 1E BIOS to UEFI) that has a slick UI in the form of a Task Sequence step.


(Yea, I know, I have heard from many of you that 1E should offer this as a stand alone tool – feel free to let them know at

In my next post, Getting Started with MBR2GPT, we will talk a look at this tool in action and keep in mind that this is pre-release software for now so do not use it in production yet!

Originally posted on

Using PowerShell to Create a BCD File

Recently, I was curious to see if I could get 1E PXE Everywhere (included with 1E Nomad) to boot a MDT Lite Touch boot image.  Since PXE Everywhere integrates with System Center Configuration Manager, it automatically creates the necessary BCD files based on the ConfigMgr boot images.  So that left me with using the command line utility bcdedit to generate the BCD file that I needed for the MDT Boot Image.  Not that there is anything wrong with bcdedit, it just requires a bit of typing out long commands.  It returns a GUID when the OSLOADER is create that then needs to be used in some of the follow up commands.  This is where I thought it would be nice to have a simple PowerShell cmdlet to do it for me – the only problem is one does not currently exist.  So after a bit of playing around with the syntax, I came up with the following function below.  It still calls bcdedit, but because of the way PowerShell uses certain characters, it is necessary to use various escape techniques.

This is a quick script to get the job done, so there is not any type of error handling or logging.  Also, I follow the PXE Everywhere naming convention of boot.xxxxx.bcd, so feel free to modify the script to your needs or preferences.

#Author: Mike Terrill
#Version 1.0

#Your use of these example scripts or cmdlets is at your sole risk. This information is provided “as-is”, without any warranty, whether express or implied, of accuracy,
#completeness, fitness for a particular purpose, title or non-infringement. I shall not be liable for any damages you may sustain by using these examples, whether direct,
#indirect, special, incidental or consequential.

#Create-BCD Name Platform TFTPBlockSize
#Create-BCD LiteTouchPE x64 8192
#Will create a BCD file called boot.LiteTouchPE_x64.bcd with a TFTPBlockSize of 8192

function Create-BCD {
    param (

    $ImageName = $Name + "_" + $Platform
    $BCDFileName = "boot.$ImageName.bcd"
    bcdedit /createstore $BCDFileName
    bcdedit /store $BCDFileName /create "{bootmgr}"
    bcdedit /store $BCDFileName /set --%{bootmgr} description "Boot Manager"
    bcdedit /store $BCDFileName /set --%{bootmgr} fontpath \Boot\Fonts
    bcdedit /store $BCDFileName /create --%{ramdiskoptions} /d "Windows PE"
    bcdedit /store $BCDFileName /set --%{ramdiskoptions} ramdisksdidevice boot
    bcdedit /store $BCDFileName /set --%{ramdiskoptions} ramdisksdipath \boot.sdi
    #Grab the output that contains the GUID
    $x = bcdedit /store $BCDFileName /create /d "$ImageName" /application OSLOADER
    $GUID = $x|%{$_.split(' ')[2]}
    bcdedit /store $BCDFileName /default $GUID
    cmd /c "bcdedit /store $BCDFileName /set {default} device ramdisk=[boot]\Images\$ImageName\boot.$ImageName.wim,{ramdiskoptions}"
    cmd /c "bcdedit /store $BCDFileName /set {default} osdevice ramdisk=[boot]\Images\$ImageName\boot.$ImageName.wim,{ramdiskoptions}"
    bcdedit /store $BCDFileName /set --%{default} systemroot \WINDOWS
    bcdedit /store $BCDFileName /set --%{default} winpe Yes
    bcdedit /store $BCDFileName /set --%{default} detecthal Yes
    cmd /c "bcdedit /store $BCDFileName /set {ramdiskoptions} ramdisktftpblocksize $TFTPBlockSize"

Using the example inputs will generate the following output (bcdedit /store boot.LiteTouchPE_x64.bcd /enum all):

Windows Boot Manager
identifier              {bootmgr}
description             Boot Manager
fontpath                \Boot\Fonts
default                 {default}

Windows Boot Loader
identifier              {default}
device                  ramdisk=[boot]\Images\LiteTouchPE_x64\boot.LiteTouchPE_x64.wim,{ramdiskoptions}
description             LiteTouchPE_x64
osdevice                ramdisk=[boot]\Images\LiteTouchPE_x64\boot.LiteTouchPE_x64.wim,{ramdiskoptions}
systemroot              \WINDOWS
detecthal               Yes
winpe                   Yes

Setup Ramdisk Options
identifier              {ramdiskoptions}
description             Windows PE
ramdisksdidevice        boot
ramdisksdipath          \boot.sdi
ramdisktftpblocksize    8192

And if you were wondering if I got 1E PXE Everywhere to boot a MDT LiteTouch boot image – the answer is absolutely!

Originally posted on