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.
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:
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.
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:
From a Windows perspective, there are some specific benefits that result:
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.
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 http://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 http://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 http://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.)
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:
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.)
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):
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):
(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):
And finally, time to resume from hibernate (with no applications running, from powered off to the lock screen appearing):
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…
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.