Automate BIOS to UEFI for secure Windows 10

Our recent webinar on automating the switch from BIOS to UEFI generated a huge amount of interest and we had an unprecedented number of questions in the Q&A session at the end. Some of the questions were answered live, but we didn’t have time to answer them all in the session. This blog answers the questions specifically relating to the 1E BIOS to UEFI technology. We’ve published a separate blog to answer the questions that were raised about the Peer Backup Assistant feature that was also introduced in this webinar. Miss the live broadcast? You can watch the webinar on-demand here.
Q: What hardware vendors are supported by the automated BIOS to UEFI process?
A: We currently support Dell, Lenovo and HP. We’ve validated it on a number of Dell and Lenovo models and a few HP models to date. We will be publishing a KB on our support portal that lists the specific models we have tested it on and we encourage customers to let us know how they get on with their specific models so we can keep the KB updated. If there are other vendors you need to support, let us know. If they have tools to configure their firmware settings, we should be able to incorporate them into our solution at a later date.
Q: Is the tool just a roll-up of the OEM tools or is it proprietary magic?
A: The solution has two parts. One uses the OEM tools behind the scenes to make the configuration changes, but we’ve done the hard work for you in working out what settings need to be changed and automating this through a single Task Sequence step. The step will determine which tool or commands need to be executed according to the device it’s running on. The second part enables us to make the change to the disk partitioning (from MBR to GPT) in a single Task Sequence without needing external boot media or PXE. That part is proprietary magic!
Q: Can you go into any details about how the BIOS to UEFI step is implemented?
A: This is our unique and sought-after technology, so we can’t share how we are doing it. It is important to state however that we are not using disk conversion tools to convert from an MBR disk to a GPT disk – such an approach is fraught with issues and is not supported by Microsoft. As you would have observed in the demo, the disk is re-partitioned and formatted using the standard Task Sequence steps.
Q: How do we get it, and when?
A: We’ll be releasing the BIOS to UEFI solution in Q3. We’ll publish more details closer to the release.
Q: Will this process work with MDT, or is Configuration Manager required?
A: At present this will only be supported in Configuration Manager Task Sequences. We may extend this to MDT in a future version as the request has come up a lot.
Q: Will this process work with disk encryption?
A: It depends on the type of disk encryption, file based or full disk. The single task sequence process will work with file-based encryption provided certain file/folder exclusions are permitted. It can also work with full disk encryption as long as the necessary filter drivers are available in WinPE (e.g. BitLocker). If neither are the case, you can use two task sequences (the first does the User State Backup in the old OS. The second is initiated from a PXE boot and does a ‘bare-metal’ build, including the BIOS to UEFI and disk partitioning).
Q: Can existing Windows 10 computers be reconfigured for UEFI using this tool without reinstalling the OS?
A: Switching from BIOS emulation to UEFI requires the disk partitioning system to be changed from MBR to GPT. If Windows 10 was previously installed with BIOS emulation enabled, the disk will be using MBR, so the OS will need to be reinstalled to a GPT disk. You can of course use the 1E BIOS to UEFI technology to do this, just as you would when migrating a Windows 7 OS on MBR to Windows 10 on GPT.
Q: Does migrating from UEFI Hybrid to UEFI Native require re-partitioning?
A: No, if you have PCs running UEFI hybrid (with the Compatibility Support Module / Option ROMs) they will already be using a GPT disk so no re-partitioning is required. As recommended in the webinar, if you are still deploying new devices with Windows 7 and are able to use the 64 bit edition, enable UEFI with CSM on the new devices before you install the OS. It will then be installed on a GPT disk and you can use an in-place upgrade (or a wipe-and-load with user state retained through hard links) when you come to migrating to Windows 10 with no re-partitioning or formatting required.
Q: Should we consider flipping Secure Boot on at a specific interval after Windows 10 deployment in case we need to revert back to Windows 7?
A: No – if you are using UEFI in Windows 10, enable Secure Boot. If you need to revert back to 64-bit Windows 7, you can use our Task Sequence steps to revert to UEFI hybrid (which would disable Secure Boot). Reverting to 32-bit Windows 7 would require the firmware to be reset to BIOS emulation and the disk re-partitioned as MBR, so you’d need to use our Task Sequence steps again to do a full wipe-and-load.
The following questions were asked relate to 1E Nomad rather than the BIOS to UEFI technology.
Q: For security reasons we don’t allow peer-to-peer connections. Is that a problem?
A: By default Nomad uses a file share to share content with peers. The peers establish an SMB connection with the dynamically elected ‘master’. If File and Print Sharing has been disabled, you have the option of using connectionless mode that uses UDP to transfer content from the master to the peers. Connectionless is much slower than the standard SMB transfer, so should only be used where file sharing is disabled.
Q: How do we get peers to download the OS, applications and packages for the Task Sequence without actually running the Task Sequence?
A: The Nomad Pre-cache feature (introduced in v6.0) enables you to simply right-click a Task Sequence in the Configuration Manager console, select Pre-cache content using Nomad and then select the Collection of machines you want the content to be downloaded on. Nomad will then transfer all the reference content in the Task Sequence to the Collection members in the background.
Q: Does Nomad require all peers to be on the same subnet?
A: By default Nomad locates content on peers using a broadcast, which is contained within the local subnet. You can implement the Single Site Download feature that enables an administrator to define which subnets make up a ‘location’. Nomad is then able to obtain content either from peers in the local subnet or in adjacent subnets included in the same location.
Q: How does this work with home-based or mobile systems that have no local peers?
A: At present you can’t use this process to migrate systems that don’t have any local peers. Those scenarios would require a USB drive to store the user state and to install the new OS and applications. But we like a challenge here at 1E, and this is one that comes up a lot…watch this space 🙂