MDT 2012 Beta 1: UEFI Support

One of the new features that has been added to Lite Touch Installation in MDT 2012 Beta 1 is support for deploying 64-bit Windows to machines configured to use UEFI.  So what exactly does that mean?  That’s no simple question.

What is UEFI?

The “Unified Extensible Firmware Interface” (UEFI) specification, created by an industry consortium that includes many influential companies from the PC industry, including Intel, AMD, Apple, Microsoft, Lenovo, Hewlett-Packard, Dell, IBM, American Megatrends, Phoenix Technologies, and Insyde.  What common interest do those companies have?  They either make firmware for PCs, create operating systems for PCs, or use firmware and operating systems on PCs.

Today, most computers use firmware called the BIOS, the “basic input output system”.  This has been around since the original IBM PC.  Although hardware has advanced quite a bit, today’s BIOSes still have some serious limitations, including:

• 16-bit code (where most OSes are now 32-bit or 64-bit)
• 1MB of addressable memory (regardless of how much the computer actually has)
• Slower option ROM initialization
• 2.2TB boot disk limitation (an MBR limitation)

UEFI addresses all of these, so it’s only a matter of time before these “legacy BIOSes” make way for UEFI replacements.  In fact, many computers have already move to UEFI, including all the latest laptops from Dell, HP, and Lenovo, most Dell and IBM servers, etc.  But if these computers (which many of you are probably using today) already have moved to UEFI, how are they still working?  Simple, they include a “compatibility support module” (CSM) that enables UEFI firmware to emulate a “legacy BIOS”.  With this in place, the operating system can’t even tell the computer supports UEFI.

On most of the UEFI-enabled computers shipping today, “native” UEFI (running without the CSM) is disabled through the configuration of the machine, so you typically need to turn it on in order to get the choice to install using “native” UEFI or “legacy” BIOS emulation.

To make matters a little more confusing, you’ll see references to “UEFI BIOSes” and “BIOS configuration” even with UEFI-enabled computers.  It’s not really a “BIOS” any more, but since everyone is used to calling it that, it is bound to happen.

What benefits do you get from UEFI?

As you can probably gather from the list of limitations above, UEFI is designed to eliminate the limitations of today’s “legacy” BIOS.  It provides:

• Full memory access (32-bit or 64-bit)
• CPU independence (enabling UEFI on x86, x64, ia64, and even ARM computers)
• Faster initialization
• Support for larger boot disks (larger than 2.2TB)

From a Windows perspective, there are some specific benefits that result:

• Faster initial boot times, because the operating system can use large IOs to read the operating system files (instead of using the 16-bit Int13 interrupts)
• Faster resume from hibernate (since it can read data faster from the hibernation file, again because of large IOs instead of Int13 calls)
• Multicast boot, because WDS can send down processor-independent UEFI bytecode to be executed to perform the multicast receiving (although this does require that the UEFI implementation in the PCs supports PXE for the NICs, many don’t currently support this)

As we move forward, you will likely see more UEFI-only Windows features.  Also, don’t be surprised if some future PCs are UEFI-only, providing no BIOS compatibility model at all – once that happens, you must use “native” UEFI.

One additional note:  Today, Windows only supports UEFI for 64-bit installations of Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2.  32-bit installs, and older OSes, must continue to use the “legacy” BIOS support.

What is different about the UEFI deployment process?

There are a few differences that need to be taken into account to deploy Windows to a computer running “native” UEFI.  First, there is a different disk layout, shifting from the master boot record (MBR) structure to the new GUID partition table (GPT) structure.  GPT supports much larger boot volumes (up to 9.4 zettabytes, or 9.4 billion terabytes) and up to 128 partitions (whereas MBR had a limit of 4).

Next, there is also a different recommended disk layout, as described at https://technet.microsoft.com/en-us/library/dd744301(WS.10).aspx, that involves three partitions:

The “EFI System Partition” (ESP) is roughly equivalent to the small boot partition typically used with Windows 7 today, holding the boot files needed to “bootstrap” the loading of the operating system.  Interestingly enough, this partition is formatted as a FAT32 volume because that’s required by UEFI – it can’t read NTFS-formatted volumes.  What would you expect to find on this partition?  Think of it like the old OEM partitions:  It can contain boot loaders (like the ones used to load Windows), OEM firmware utilities, etc.  But instead of each OEM using a different setup, all can share this volume.  (There are even specific subdirectories that each vendor has agreed to use, see https://www.uefi.org/specs/esp_registry.)  There are even “EFI shells” that can be loaded onto this partition (for configuration, browsing, or whatever other creative uses you might find).

There is one thing that you won’t find on the EFI System Partition:  a BCD file.  When booting from a “legacy” BIOS, the Windows boot loader (bootldr) reads the boot configuration data from the \BOOT\BCD file on the active partition, but with UEFI that information is stored in and read from non-volatile RAM (NVRAM) on the motherboard.  The same BCDEDIT.EXE utility that is used to manipulate the BCD file also knows how to manipulate the NVRAM – not surprisingly as the BCD structure was built in anticipation of UEFI.

The next partition, the Microsoft Reserved (MSR) partition, reserves some disk space for Windows to use for certain operations (e.g. converting a basic disk to a dynamic disk).

Overall, these partitions are fairly small, with the ESP at 100MB and the MSR partition at 128MB, so there isn’t much overhead here.

The next challenge then involves bootable CDs and DVDs.  Today, you would typically set up an ISO using the El Torito specification, specifying the ETFSBOOT.COM boot sector for the “legacy” BIOS to call to initiate the CD/DVD boot process.  With UEFI, there is a new boot sector called EFISYS.BIN.  This isn’t an “either-or” proposition though, as you can actually configure a bootable CD or DVD to have both ETFSBOOT.COM and EFISYS.BIN at the same time.  (See https://support.microsoft.com/kb/947024 for an example of the OSCDIMG command line syntax to do that.)  If the computer supports UEFI and “native” UEFI is enabled, then it will typically choose the UEFI boot sector by default (or prompt and ask which one you want to use), while computers that don’t support UEFI or those that don’t have “native” UEFI enabled will revert to the ETFSBOOT.COM “legacy” boot sector.

The final challenge then is USB media.  As with CDs and DVDs, you probably want them to support both “legacy” BIOS and UEFI booting.  This is pretty simple to do, formatting the USB media using FAT32 (so it can be read by UEFI) and setting up both “legacy” BIOS and UEFI boot files.

One other complication to mention:  What if you have a computer that supports UEFI, but it is currently running an operating system (e.g. Windows XP or Windows 7) through the legacy BIOS compatibility module (CSM), and you want to move it to UEFI.  Can you perform a typical “refresh” operation?  No, because the “refresh” process can’t even see that the machine supports UEFI when running in compatibility mode, plus there is no way to convert an MBR disk to a GPT disk while preserving the data.  So in order to do this type of migration, you need to move the user data off of the disk, then boot from UEFI-enabled media, reformat the disk as GPT, install the new OS, and then restore the user data.

It’s also worth noting that you may need to upgrade any imaging or disk partitioning tools that you are using today to versions that understand GPT disk structures.  (This isn’t an issue with Windows AIK and ImageX, as ImageX uses file-based images that don’t care about MBR vs. GPT.)

What about MDT 2012?

All of that background information and we still haven’t really talked about what MDT 2012 does in regards to UEFI.  So let’s quickly review what MDT 2012 does to enable UEFI support:

• MDT will build all ISOs and media folders with both “legacy” BIOS and UEFI boot files.  (It’s up to you to make sure you copy the media content to USB devices that are formatted as FAT32, if you expected UEFI to be able to read them.)
• MDT will build all ISOs with dual “legacy” BIOS and UEFI boot sectors.
• MDT is able to detect when a computer is running in “native” UEFI mode (see the “IsUEFI” property – it’s set to false when running in “legacy” BIOS compatibility mode, true if in “native” UEFI mode).
• MDT will automatically format the boot disk using GPT (even if the task sequence says MBR) so that you can use the same task sequences with both “legacy” BIOS and UEFI computers.
• MDT will automatically create the needed ESP and MSR partitions when running in “native” UEFI mode.
• MDT can refresh a computer running an OS in “native” UEFI mode to a new OS in “native UEFI” mode (but not “legacy” to “native” or “native” to “legacy”).

In the end, that means that this becomes sort of a “ho-hum” exercise:  It should just work, as soon as you figure out how to enable UEFI “native” mode in the firmware (BIOS) settings and then boot in “native” mode.  That’s not always as simple as it seems, as the UEFI firmware available today isn’t terribly obvious.  (I’ve tried it with Dell and HP laptops.  The Dell machine isn’t too hard to figure out, but getting the HP to boot in “native” mode is a little more challenging.  See below for more details.)

Can you really tell the difference?

Some computers will benefit more from UEFI than others, due to the specific hardware, the UEFI firmware being used, etc.  So I’ve run a few timings with an HP EliteBook 8440p laptop to illustrate the differences on a typical machine.  First, let’s compare the Windows PE boot time, reading the same boot image from a USB key using “legacy” and “native” boot options (stopping the timer once the initial MDT wizard is displayed):

• Legacy boot:  50 seconds (to initial MDT wizard)
• Native boot:  40 seconds (to initial MDT wizard)

The next test then is operating system installation (measuring how long from finishing the MDT deployment wizard until the summary wizard appears in Windows 7 SP1 x64):

• Legacy boot:  14 minutes, 40 seconds
• Native boot:  13 minutes, 55 seconds

(Note that both of these times should be one minute shorter, but due to a bug in the task sequencing engine there is an extra minute of “nothing going on” added to the end of the deployment process, before the summary wizard is displayed.  We’re still working to get that fixed.)

Now let’s compare the “cold boot” time (from powered off to the logon prompt appearing):

• Legacy boot:  30 seconds
• Native Boot:  27 seconds

And finally, time to resume from hibernate (with no applications running, from powered off to the lock screen appearing):

• Legacy boot: 17 seconds
• Native boot:  14 seconds

So it’s not a huge difference, at least with the current UEFI revision on this machine, the USB key performance, and the SATA (non-SSD) hard drive in the system.  Imagine though if you were using an SSD…

Caveat Lector

It was interesting using UEFI on the HP EliteBook 8440p, not nearly as “refined” as I would have expected.  First, when you enable UEFI in the BIOS, you get an interesting warning:

The “UEFI Boot” option on this system is provided for development purposes only and is currently NOT fully supported or warranted by HP.  Preboot Authentication and Drive Lock are currently NOT supported under UEFI Boot mode.  HP strongly recommends disabling Preboot Authentication and Drive Lock before enabling UEFI boot on this system.

Then (ignoring the warning), the UEFI firmware doesn’t seem to be able to detect UEFI-bootable USB keys, so you have to browse to the “bootx64.efi” file on the USB key and explicitly tell the machine to boot from that.

You would think that this “temporary boot choice” would only apply for this single boot (so that when the computer reboots after Windows is installed it will boot from the hard drive), but that’s not the case:  It keeps booting from the USB key if you leave it inserted.  So I’ve gotten used to pulling the USB key every time the computer reboots, then reinserting it before MDT wants it back so it doesn’t pause and prompt.

And as mentioned previously, there is no UEFI PXE support provided on this computer.  (I hope it will work as expected with a dual-boot CD/DVD, offering a choice, but I didn’t have one handy to try.)

I have previously tried this on a Dell Latitude E6410 laptop, which seems to be a little better behaved (although it doesn’t seem to support UEFI PXE boot either).  Your mileage may vary, based on computer manufacturer and model, UEFI firmware version, etc.

Comments

• Anonymous
  January 01, 2003
  The IsUEFI variable in MDT is cool, though there seems to be a problem with the "Install operating system" step. In my case MDT keeps trying to install in Disk 0 partition 1. But before this step the formatting step has formatted the drive in multiple (uefi supported) partitions, so it should install in partition 3. Have experienced this?See question asked in MDT forum:http://social.technet.microsoft.com/Forums/en-US/6284045a-3b05-4ebb-b11a-fbe4d07f0648/mdt-config-uefi-specific-disk-and-partition?forum=mdt

• Anonymous
  January 01, 2003
  Yes, we make a Windows API call (GetFirmwareEnvironmentVariable) to determine if the machine is running UEFI.  If that calls succeeds, we will set IsUEFI to true.

• Anonymous
  January 01, 2003
  MDT does automatically set a task sequence variable, IsUEFI, to indicate whether UEFI is present.  This will only be true when not running in compatibility mode - if it is in compatibility mode, there's no way to tell the machine is UEFI-capable. So the variable really indicates that the machine is running UEFI right now.

• Anonymous
  January 01, 2003
  Very informative article. Thanks! Question: If the media has to be FAT32 to be read by UEFI, how can MDT deploy WIM files that are bigger than 2GB? Is network deployment the only option in this case?

• Anonymous
  January 01, 2003
  FAT32 does support up to 4GB files, so you have a little more "breathing room".  But you are right, after you exceed that size with a single WIM, you will run into issues.  There are a few solutions to that, some of which you might not immediately think of, such as partitioning the media into FAT32 for boot files and NTFS for everything else.

• Anonymous
  January 01, 2003
  USB drives are set up as "dual boot" by default.  There's no real "boot sector" to worry about with USB. However, the UEFI BIOS support for this is rather inconsistent and not always clear either.  For example, on a Dell laptop, you have to know to choose the rather obtusely-named entry in the boot menu, rather than the "boot from CD" entry higher in the list.  And that's the easy one - on an HP laptop, you have to navigate to the bootx64.efi file using a text-based file browser... -Michael

• Anonymous
  August 03, 2011
  The comment has been removed

• Anonymous
  August 22, 2011
  This article opened my eyes to UEFI -- something I've heard about but never gave attention to. Thanks!

• Anonymous
  December 03, 2011
  Is there a command, when boot in the winpe, to check whether the firmware was set to UEFI or BIOS?

• Anonymous
  December 04, 2011
  Michael, thank you for the information. Out of curiosity, I checked IsUEFI in the MDT script (ZTIGather.wsf) and its originated from microsoft.bdd.utility.dll.

• Anonymous
  December 22, 2011
  Do anyone successful boot PXE on efi shell 64 bit? Can i know steps to configure and boot in UEFI(Host is Linux(AMI bios) and client is efi shell bios.send email to kjsuraj2000@yahoo.com

• Anonymous
  March 27, 2012
  I had to deal with UEFI compatibility issue with MDT 2010 today (particularly with Lenovo V570) and your MDT 2012b2 saved my day. With MDT2010U1, I got the following error on Installing Windows screen: "Windows cannot be installed to this disk. The selected disk has an MBR partition table. On EFI systems, Windows can only be installed to GPT disks." But after I update the MDT 2010 share to MDT2012b2, it works like a charm. Thanks again, Michael!

• Anonymous
  February 25, 2013
  I am using MDT2012, hosted on a Windows 2012 Server. I have native UEFI devices PXE booting correctly. However, when I cut the LiteTouch_x86.iso to a DVD, the UEFI devices don't boot. ON any device that is BIOS/UEFI mixed the DVD works, I beLeive that is due to the backward compatibilty of the mixed environment. The Native UEFI devices don't boot. Am I missing something?

• Anonymous
  November 02, 2013
  Hi Mike, Just a question about how to deploy Windows 8.1 images to UEFI based Computers. I remember that MDT will automatically detect the System and install UEFI if UEFI is detected. Is it important that the Windows 8.1 Image must be UEFI formated? I am not looking through this concept. Thanks for your answers.

• Anonymous
  April 21, 2016
  For Legacy mode systems, I copy the deploy container to the internal drive and have LTI run all from the hard drive. Works great. How could this be done with UEFI systems?