We have UEFI servers and have come across a situation where we need to force Windows Server 2008 to boot via the legacy BIOS method instead of through UEFI.

Is there a way to tell Windows Server 2008 (either during install or post-install) to ignore the fact that it's installing onto an EFI machine and instead install and use the legacy BIOS bootloader?

I've tried a few suggestions which didn't help:

Format disks as MBR partitions before installing Windows

Nope, Windows refuses to install:

Install Windows, migrate the partition to an MBR disk, repair system

Nope, the system repair console refuses to load. It complains that it doesn't recognize the version of Windows I'm attempting to repair.

Disable UEFI

If I could disable UEFI and make the system legacy-only, I would have. However, the particular systems I'm using (IBM HS22, x3690X5) are UEFI-only with legacy support. You can't just disable UEFI on them. That would require a complete BIOS implementation.

The Solution!

As JdeBP points out, the sole method Windows uses to determine whether to use the EFI/GPT or BIOS/MBR bootloader is the method which was used to boot the install CD.

Combining this with Weaver's suggestion to craft a .iso image without the 0xEF boot catalog entry (far easier to do by hex-editing rather than remastering the image, by the way) leads us to a nice, concise answer:

Force the install media to boot via BIOS, not via UEFI as this is the only differentiator Windows Installer uses to determine which boot scheme to use.

This is going to be hardware specific. It may help if you mention the equipment and model. Some vendors provide an option for BIOS-compatability mode in the setup screen or as a boot option.
–
Tom WillwerthSep 6 '11 at 19:28

The reason I didn't mention hardware in the question was a deliberate choice. I want to make this change on the Windows side by telling it to use a different bootloader. My IBM x3690X5 already has BIOS compatibility turned on, so any BIOS loaders will work. The problem is telling W2K8 to not use its UEFI bootloader.
–
MikeyBSep 6 '11 at 19:32

@tegbains: $BIGCUSTOMER has an imaging environment which uses a product that does not properly support GPT.
–
MikeyBSep 13 '11 at 18:58

1

If it hadn't taken a fortnight to wring this very important piece of information out of you, we could have saved Weaver a lot of grief. I suggest that you edit your question to reflect the actual goal, because what is in the title is the step X that you cannot get to work and your question is highly misleading.
–
JdeBPSep 15 '11 at 15:08

3 Answers
3

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.

Oh my system doesn't lack a compatibility mode, that's not a problem. So you're saying that the only way the Windows installer detects whether the system is EFI is via the method which was used to bootstrap? That's new and critical information - I'll try that out.
–
MikeyBSep 15 '11 at 15:53

Ahah! It works! That's the critical piece of information that I needed: "Force the install media to boot via BIOS, not via UEFI as this is the method Windows Installer uses to determine which boot scheme to use."
–
MikeyBSep 20 '11 at 20:04

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.

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.

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.

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.

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.

"Pre-install you can control the install by using BIOS/MBR or UEFI in legacy BIOS boot with MBR or UEFI with GPT." OK, so how do you tell Windows: "Install to a MSDOS-style partition table."?
–
MikeyBSep 9 '11 at 16:38

@MikeyB Boot the Windows installation media in a computer system with a traditional BIOS. Or -- boot the Windows installation media in a computer system with UEFI set in legacy BIOS boot mode. Note that your UEFI must support a legacy BIOS boot mode.
–
WeaverSep 9 '11 at 19:58

You're suggesting I install Windows onto a completely different computer then move the disks over? Not a good idea at all. Also, when you set a UEFI computer to 'legacy BIOS mode', it just enables the legacy BIOS hooks for booting legacy MBR disks. It doesn't turn off UEFI, so Windows still says "Is this a UEFI system? Yup."
–
MikeyBSep 9 '11 at 21:00

@MikeyB Added updates to the original answer.
–
WeaverSep 10 '11 at 1:27

1

I've seen something similar with server 2008, in the process of learning about BIOS and MBR disk size limits. I built a server with 2008 R2 and enabled legacy BIOS mode due to the fact it wouldn't install with USB media (an MS bug) however I found it then used MBR rather than GPT because BIOS isn't capable of loading GPT (unless you have a boot loader of some sort). In short, switching to legacy mode definitely installs in legacy mode, the proof will be in disk manager where you'll see MBR not GPT disks.
–
Alex BerrySep 13 '11 at 8:30

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.

That's exactly what I was going to suggest. Run the Windows setup on another (BIOS/MBR) system, then move the disk or its image to the destination server. If it boots, then PnP will ensue and it will happily run on the different hardware.
–
MassimoSep 15 '11 at 5:48