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/

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.

imageimage

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.

image

image

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.

image

image

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/

Using MBR2GPT with Configuration Manager OSD

devices-windows-10-creators-update-banner

[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:

001-using-mbr2gpt

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

002-using-mbr2gpt

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:

003-using-mbr2gpt

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).

004-using-mbr2gpt

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

005-using-mbr2gpt

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

006-using-mbr2gpt

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

007-using-mbr2gpt

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 https://miketerrill.net/

Getting Started with MBR2GPT

devices-windows-10-creators-update-banner

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:

001-getting-started-mbr2gpt

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:

001-mbr2gpt

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:

002-getting-started-mbr2gpt

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

003-getting-started-mbr2gpt

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):

004-getting-started-mbr2gpt

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:

005-getting-started-mbr2gpt

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 https://miketerrill.net/

BIOS to UEFI made easier with Windows 10 Creators Update

devices-windows-10-creators-update-banner

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

001-mbr2gpt

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.

003-1e-bios-to-uefi

(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 info@1e.com.)

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 https://miketerrill.net/