Force Windows Server 2008 to use legacy BIOS bootloader instead of EFI

Solution 1:

Microsoft won't let you achieve your step; so address your goal instead.

Microsoft erroneously conflates has an EFI partitioned hard disc with has EFI firmware. This is, of course, clearly wrong. It's quite possible — and indeed is becoming ever more desirable these days — to have an EFI partitioned disc on a machine that has old non-EFI firmware. You actually — although it took over a fortnight for people here to wring the goal out of you rather than the step — want the converse. You want to have an old PC/AT-style MBR partitioned disc on a machine that has EFI firmware. (EFI firmware itself has no problem with either partition table format, and is indeed required by the EFI specification to understand both. It's Microsoft that makes this error.) And you want this because someone else's software cannot understand the EFI partition table.

One of the several consequences of Microsoft's error is that the Windows NT 6.1 installer has to be invoked from an install medium that has in turn been bootstrapped from old PC98 firmware, in order for it to accept the idea of installing Windows NT 6.1 to a disc partitioned with the old PC/AT MBR partitioning scheme. Unfortunately, if the Windows NT install disc is bootstrapped in the new EFI way the installer will think that there's EFI firmware, and so declare that it cannot be installed to non-EFI partitioned hard discs.

As Weaver has pointed out, and as the Microsoft documentation explains, the installation CD-ROM is in fact dual-boot. As Rod Smith further explains, one therefore can manually construct a Windows NT 6.1 install disc that bootstraps in the old PC98 way. The Windows NT 6.1 installer will then allow installation to an old PC/AT MBR partitioned hard disc.

However, on systems lacking a compatibility support module, as you say your system does, this will not help one whit. Your system will require the EFI version of Microsoft's Boot Manager, installed on the EFI System Partition, because that's how your firmware will try to bootstrap the operating system. But when the Windows NT 6.1 installer is started on non-EFI firmware, it installs the non-EFI version of Microsoft's Boot Manager and won't create an EFI System Partition. Such an installation will not actually bootstrap on your machine, and you won't even be able to complete the installation procedure. Indeed, because you lack a CSM you won't even be able to begin the installation procedure, because you won't even be able to bootstrap the installation disc in the old PC98 way. Microsoft won't let you achieve your step, two times over.

So focus on your goal, instead. Your goal is to enable your customer to deploy Windows Server 2008 onto machines that have EFI firmware from a system image. Therefore the correct question that you should be asking — of the software vendor — is how to get that old/broken disc imaging software fixed so that it has no trouble with the EFI partition table.

Solution 2:

In short, yes and no for a few different reasons. If Windows is booting from a GPT disk, it must be from UEFI. Windows boot manager and loader cannot boot to MBR disk from native UEFI. However, if the UEFI is configured for legacy BIOS boot mode then an MBR disk can be used for booting. This stems from the Windows boot mode (BIOS with MBR or UEFI with GPT) being contingent on the environment in which it is envoked.

Read on for a little tech --

The physical hardware (or virtual hardware, but hardware nonetheless) firmware (BIOS/UEFI) provides the initial operating environment (boot related data structures and conventions) and firmware services available to subsequent stages of the operating system boot process.

BIOS/MBR

In the case of BIOS/MBR boot the first sector of the first bootable disk -- the master boot record (LBA 0) contains a handful of x86 (16 bit 8088) assembly, then the partition table, then a signature). The BIOS loads this sector into memory and begins executing -- the BIOS relinquishes its own program code control as soon as the MBR gets involved.

http://mbr.adamsatoms.com/

http://www.ata-atapi.com/hiwmbr.html

x86 assembly (Intel 8088 in most MBR's) in the MBR parses the partition table, searches for an active partition, and jumps to the first sector in that partition -- called the volume boot record. The volume boot record contains an x86 assembly jmp, a BIOS parameter block (not used by the system BIOS at all, so confusing name), and a bunch more x86 assembly that ultimately loads the operating system's boot loader (NTLDR or BOOTMGR in Windows environments) from the boot volume/partition itself.

NTLDR or BOOTMGR flip the CPU to protected mode, consult their boot-time configuration (boot.ini or the BCD respectively, both on the boot volume/partition), and load NTOSKRNL where the rest is history.

http://technet.microsoft.com/en-us/library/cc781134%28WS.10%29.aspx

http://en.wikipedia.org/wiki/Windows_NT_startup_process

http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/bios-parameter-block.html

UEFI/GPT

First let me state that I do not have much active experience with UEFI/GPT. However, as I have used it and understand it to operate -- the big difference (as it relates to our conversation) is that executable control is not transferred to the MBR.

Instead the UEFI firmware contains its own boot manager. This boot manager scans disks and media, -- glosses over the protective MBR of GPT formatted disks, arrives at the GPT header, and then dives into the EFI System Partition (ESP) where it looks for EFI executable programs -- which are supposed to be operating system boot loaders booting the OS directly, however as we have seen with the latest MS and Apple EFI executables, they are in fact boot managers adding another layer to th process and complexity.

http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html

http://msdn.microsoft.com/en-us/windows/hardware/gg463525#X-201104111922443

Conclusion/TL;DR

The point to take away from this is that there is an expected environment in which the operating system's boot manager and boot loader expect to run. From firmware level services available (BIOS/UEFI interrupts), data structures (variables, stack conventions, etc), and even disk formatting conventions. Cannot be changed at runtime -- at least not the way I understand it.

Your options?

Pre-install you can control the install by using BIOS/MBR or UEFI in legacy BIOS boot with MBR or UEFI with GPT.

Post-install -- there may be some interesting possibilities with changing the disk format (MBR to GPT and GPT to MBR) offline, then booting to a recovery console (in appropriate UEFI or BIOS mode) and working with bcdboot and bcdedit to get Windows boot manager set straight.

Update 2011.09.09

@MikeyB

Listing options as I understand them to be, not actually making any formal suggestions.

Nevertheless, after doing a little more research on UEFI (recall that I don't have much active experience with it) I have discovered a few interesting tidbits about the UEFI boot manager and support for CD/DVD booting.

The El Torito Boot Specification, from '95 is still around today and is used with bootable CD/DVD's. A single CD/DVD may have to boot on several architectures -- and while ISO 9660 is rather platform independent, executable code is not. As such, the El Torito Boot Specification allows for multiple boot entries/images.

These entries/images contain a Platform ID, intended to indicate whether an entry is for PC, PowerPC, and other architectures so that architecture's BIOS (or firmware) can choose the right boot entry.

Standard x86 PC's with a BIOS has an El Torito Platform ID of 0x00. UEFI capable Platform ID is 0xEF -- rather creative.

Standard x86 PC BIOS's ignore all other entries except 0x00. UEFI firmware's that have legacy BIOS support (known as Compatibility Support Module (CSM)) -- while able to boot 0x00, will prefer a 0xEF native boot entry from the catalog.

The Windows 2008, 2008 R2, and 7 DVD media contain a multiple image El Torito catalog with both 0x00 and 0xEF. The 0x00 is the default, but a UEFI will gloss over it if a 0xEF exists and choose the 0xEF entry -- as it is native.

What is possible -- is to craft media that only contains the preferred Platform ID in the El Torito boot catalog. Instead of a multi-entry catalog, create a single entry catalog with a 0x00 Platform ID. This should force the UEFI firmware, if in fact it supports legacy BIOS boot, to choose the 0x00 Platform ID and boot the legacy BIOS boot entry on the Windows media.

How to do it?

Using Oscdimg it is possible. Below are several examples of people creating UEFI only media to get around the limitations in Apple's UEFI implementation. Note that this is the opposite of what we are trying to do -- we want to create a BIOS only, leaving out the UEFI boot entry from the catalog.

UEFI Only (Opposite) 1

UEFI Only (Opposite) 2

The process to create BIOS only media is similar with changes to the -b and -p arguments to the following

-bC:\path\to\Etfsboot.com -p0x00

A great resource that shed some excellent light on Microsoft's chosen madness on the Windows install media is the UEFI Support and Requirements for Windows Operating Systems document.

Solution 3:

One simple method would be to simply perform a base install of Windows on a machine that doesn't support EFI, capture it with your image software and restore it to the real hardware.

A good choice might be to build your base install in a VM. In earlier versions (ver < 6) of Windows didn't adapt well to be moved from one type of hardware to another. With recent versions Windows as long as the storage controller is supported on the image Windows will do a pretty good job at adapting to the new hardware.

The Windows install (ver >=6) disk basically usually include a wim file which is basically just an image of the operating system.