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.
So, /tftpboot/images/freebsd_isos/FreeBSD-9.0-RELEASE-amd64-bootonly.iso exists correct?
LABEL FreeBSD 9.0 NO KS eth0
MENU LABEL FreeBSD9.0 AMD64
LINUX /memdisk
APPEND iso
INITRD /tftpboot/images/freebsd_isos/FreeBSD-9.0-RELEASE-amd64-bootonly.iso
This should work. It's of the format of what I have used.
Best Answer
If you can use the
wimbootutility from iPXE.org, you can do it. I made such an experiment with Windows PE 3.1.You would configure the PXE server to initially send any PXE bootloader that can load Linux kernels. Then you'd configure that to load
wimbootin place of a Linux kernel. In place of an initrd file, you would then have acpioarchive containing the following things from Windows installation media:I made a small Makefile that assumes that these files are placed into
./buildsubdirectory relative to the location of the Makefile itself:If you have the wimlib tools from wimlib.net you can use
make mountandmake umountto edit the contents of theboot.wim(e.g. to add drivers or tools) before runningmakeormake cpioto create the "initrd" .cpio file.As far as I know, there is no special "iPXE server". Any PXE server can, in principle, send the iPXE bootloader to a PXE client. For the PXE server, the iPXE bootloader is just a file the server must have accessible with TFTP, in the exact path specified in the DHCP options.
If you use my "
wimbootwithout iPXE" idea, be warned: loading the entireboot.wimover TFTP is slow. Sending the iPXE bootloader to the client first, and then proceeding over HTTP is much faster.