I’ve previously written a post on this topic, demonstrating a custom method that could be used before ConfigMgr had native support for the BIOS to UEFI conversion. However, that post should now be deemed obsolete (or until you’ve upgraded your environment to ConfigMgr Current Branch version 1610). In order to be able to take advantage of many of the security improvements witih Windows 10, running your systems in UEFI mode instead of BIOS (also referred to as Legacy) is a requirement.

As for this topic, I decided to split it up in separated parts as where this introduction covers the changes made in ConfigMgr 1610 and how it can be leveraged in general, and the upcoming parts will go into details per manufacturer:

Native support for BIOS to UEFI conversion

With the release of ConfigMgr 1610, we can now in a native way perform a BIOS to UEFI conversion during a Windows 10 deployment (bare metal or refresh, not supported for in-place upgrade). In the past, the problem that many encountered by attempting to make the switch, not only that it requires a hard disk table layout change from MBR to GPT (which requires a complete format and re-partitioning), was that when the task sequence engine attempting to stage the Windows Pre-installation Environment (WinPE) as it was about to restart, it would not do so properly. When the system came back up after the restart, it failed to boot into WinPE and the task sequence broke.

What’s improved with 1610, is the fact that the task sequence engine can now prepare the system for a restart between BIOS and UEFI. This allow us to continue the task sequence after the restart, and not have to perform any potentially unsupported modification of built-in task sequence variables or re-starting the sequence all over (like I did in my previous custom solution). What happens behind the scenes is that the reboot code in the task sequence engine will prepare a boot system for UEFI, and completely ignore the current firmware mode (BIOS) which was how it worked in the past for version prior to ConfigMgr 1610. In order to circumvent issues where the engine might not detect any suitable drive for the UEFI boot system, you configure the exact disk and partition that should be prepared by pointing out a FAT32 partition (with GPT) and assign that partition a variable that allows for the reboot code to prepare the boot system properly for a BIOS to UEFI switch and restart.

It’s important to mention that this conversion process that’s now natively supported in ConfigMgr Current Branch, does not handle the different OEM conversion steps that’s required. You’ll still have to add those into your task sequence for the conversion to take place.

Task Sequence configuration

Since this post is about the improvements and general configuration of how this can be implemented (see Part 1-3 for specific configuration per manufacturer), what’s shown below should not be seen as the explicit configuration for your specific needs. It’s more of a general overview of the steps required and that you need to be aware of when implementing them into your task sequence intended for deploying Windows 10, and dealing with the conversion from BIOS to UEFI.

BIOS to UEFI Conversion
Type Group   221_2
Condition Task Sequence Variable:
_SMSTSBootUEFI equals FALSE
Restart in WinPE
Type Restart Computer   221_4
Selection The boot image assigned to this task sequence
Condition Task Sequence Variable:
_SMSTSInWinPE equals FALSE
OEM Conversion
Type Run Command Line / Install Package / Run PowerShell Script   221_3
Description This step should be replaced with the appropriate steps necessary to perform the BIOS to UEFI conversion on a per manufacturer basis
Format and Partition Disk
Type Format and Partition Disk 221_5
221_6
221_8
Disk selection Disk number: 0
Disk type: GPT
Volume Volume 1:
Partition type: Primary
Size: 500 MB
File system: FAT32
Quick format: Yes
Variable: TSUEFIDriveVolume 2:
Partition type: Primary
Size: Use percentage of remaining free space (100%)
File system: NTFS
Quick format: Yes
Restart Computer
Type Restart Computer 221_7
Selection The boot image assigned to this task sequence

MDT Integration

Up until now, we’ve gone through how to place the different steps and configure them for a native ConfigMgr task sequence. However, there’s a high usage of the MDT integrated task sequence out there, so below is a suggestion for how you could potentially add the BIOS to UEFI conversion in your MDT integrated task sequence, to support both the New Computer and Refresh scenarios.

221_9

Summary

I’d suggest that you test out what works in your specific environment and task sequence in terms of what steps are required in what order. No task sequence is like another, so it’s important that you properly test and validate the required steps necessary for a successful BIOS to UEFI conversion. In the upcoming blog posts I’ll cover how you can configure the conversion on a more detailed level per manufacturer, starting with Dell.

Nickolaj Andersen
Principal Consultant and Enterprise Mobility MVP. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows deployments and Automation. In 2015 Nickolaj was awarded as PowerShell Hero by the community for his script and tools contributions. Author of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService and a frequent speaker at user groups.

(3614)

comments
  • Zander Wheels
    Posted at 22:12 December 21, 2016
    Zander Wheels
    Reply
    Author

    I might be mistaken but shouldn’t the Format and Parttiton step and Restart computer step not have the condition of _SMSTSInWinPE = False?

    I am having issues with this after the upgrade to 1610. I it fails on the reboot after partition step with “creating a new temporary UEFI boot system” with 80070002. TSUEFUDrive does = c: I am waiting for your continuation of this blog for the HP’s to see if I can get this fixed. I did have to upgrade the ADK and MDT after the 1610 was installed to get updated boot images. Not sure if that has something to do with the error.

  • Mark
    Posted at 13:32 December 22, 2016
    Mark
    Reply
    Author

    Great blog post, I’m looking forward to the other parts. You mentioned that this isn’t supported for an in-place upgrade. Do these same steps still work for an in-place upgrade or do you have other recommendations to covert to UEFI via an in-place upgrade.

  • Carl
    Posted at 22:53 December 22, 2016
    Carl
    Reply
    Author

    Hi Nickolaj, have you tried this process on a Dell Optiplex 990? Other Dell models work fine, but the 990 fails on the restart with no boot device found.

  • Frank Trout
    Posted at 15:38 December 23, 2016
    Frank Trout
    Reply
    Author

    Zander – I’m not sure about the Format and Partition step (I don’t use the condition there), but you add the _SMSTSInWInPE = False to the Restart step so the TS doesn’t reboot into WinPE when it is already in WinPE.

  • Jonathan
    Posted at 18:08 December 28, 2016
    Jonathan
    Reply
    Author

    Haven’t tried this yet, but In the “Format and Partition Disk” step, why is the TS variable condition ‘_SMSTSInWinPE equals FALSE’? Wouldn’t this cause the step not to run since we are in PE?

    • Nickolaj
      Posted at 23:11 January 1, 2017
      Nickolaj
      Reply
      Author

      You’re absolutely right, copy and paste error which have been corrected now. Thanks for pointing it out!

      Regards,
      Nickolaj

  • Blaf
    Posted at 06:15 February 1, 2017
    Blaf
    Reply
    Author

    Hi Nickolaj,
    Thank you for great post.
    When we can expect second part how to configure BIOS to UEFI on HP.
    Which OEM conversion tools is HP using?
    Thanks

  • Kevin
    Posted at 21:27 February 2, 2017
    Kevin
    Reply
    Author

    I have a Dell 5570. The disk is wipe using dispart, so there are no partitions.
    I created a TS just like you have so after i PXE boot, i can see that it goes through all my steps (after the first RESTART, I have all my CCTK things i need it to do) then it partitions the disk. The issue with this step is that it creates a C and a D.
    It then does not restart the machine it just gives me an error:

    0x80070490

    In SMSTS Log the only errors i see are that it failed to save environment to (80070057)

    The log files get saved to D:

    It fails everytime.

  • Brachus
    Posted at 20:52 February 15, 2017
    Brachus
    Reply
    Author

    Waiting for the DELL specific commands to see how you handle boot order.
    Some systems are booting to the newly created UEFI partitions and continuing the task sequence, others are booting back to the USB drive and starting the TS wizard all over again.

    • Jason
      Posted at 20:44 March 14, 2017
      Jason
      Reply
      Author

      Brachus, have you figured out why it does that? It appears my Restart Computer step happens later (after the Operating System and Drivers are applied), then restarts and starts the TS wizard all over again. For some reason, I thought this initially worked on the system (OptiPlex 3040). I tried resetting BIOS, but still no luck. If you have any feedback or follow-up, please post. Thanks!

  • Brachus
    Posted at 16:23 February 20, 2017
    Brachus
    Reply
    Author

    ALSO – Try your Task Sequence with a BLANK AND EMPTY harddrive.

    Since the OEM conversion takes place BEFORE the drive format, the packages it relies on fail to download, and the task sequence bombs out.

  • Sven
    Posted at 08:48 April 10, 2017
    Sven
    Reply
    Author

    Great post, Nickolaj. Thanks for your contribution. I remember a previous post about “detecting admin presence” on Dell machines. It appears that the old post has been deprecated by this post. Too bad that the old information regarding the “Dell Command configure PS Provider” isn’t added to this post. Any idea if you’re going to re-upload this information? Thx!

    • Nickolaj Andersen
      Posted at 21:09 April 10, 2017
      Nickolaj Andersen
      Reply
      Author

      Hi Sven, I wasn’t aware that the Admin password was actually being used. I’ll see if I can get that posted again for the Dell part.

      • Mike
        Posted at 21:09 May 24, 2017
        Mike
        Reply
        Author

        I have to 2nd Sven’s request. This is definitely something I could use as well as we seem to have an abundance of bios passwords around here as each tech area likes to use their own.

  • Leave a Reply