Geoff Chappell - Software Analyst
For many years, through a succession of articles in the Microsoft Knowledge Base such as How to use system files to create a boot disk to guard against being unable to start Windows XP, Microsoft has gone to some trouble to describe how a Windows system that is already installed on a hard disk can be booted from a specially prepared floppy disk. This is said to be useful when the installed system is healthy but does not get to start because of some problem early in the boot sequence.
Given that the problem was not uncommon, else Microsoft might not have troubled to keep writing about it, what is anyone who is faced with this problem to do about it nowadays when so many computers are not fitted with a floppy disk drive? One solution is to boot the local system from across the network. The “secret” is to configure a Remote Installation Services (RIS) server in a way that Microsoft seems not to document.
Of course, a significant detraction of this solution is that an RIS server is not installed with client editions of Windows such as Windows XP. In practice, the procedure described in this note is available only if the network has at least one machine that runs Windows 2000 Server or Windows Server 2003. For the following directions, I assume that you have such a machine set up as a domain controller and either this machine or another set up as an RIS server. I also assume that you have configured the target computer to boot from a network. This may require you to enter the BIOS setup to change the boot sequence and possibly also to enable the Pre-boot Execution Environment (PXE).
Broadly speaking, there are two steps. The first is to set up the RIS server with a directory that contains the files that would otherwise have been on a bootable floppy disk for the target computer. The second is to configure the Active Directory Services to recognise the target computer as needing to boot from those particular files on the RIS server. As with a bootable floppy disk, it helps to prepare all this in advance of needing it.
At the RIS server, in the directory that is shared as REMINST, create a new directory for simulated boot disks, e.g., RemoteBoot. Create a subdirectory for each computer that you might boot from the RIS server (or for each set of computers that may each be booted from the same files). To this directory, copy the following files from an installation image of Windows for at least the latest version that is on the target computer:
A suitable installation image may already be present at the RIS server. Otherwise, the files can be expanded from the installation CD for the latest Windows version that is on the target computer. They will not ordinarily be present already on the target computer. The difference between STARTROM.COM and STARTROM.N12 is that the former requires you to press F12 during a 3-second interval at startup if you want to proceed with booting from the network, but the latter proceeds automatically. In all that follows, you may substitute the one for the other.
To the same directory, add the following from the root directory of the boot partition of the hard disk that the target computer would ordinarily boot from:
Though NTDETECT.COM is present on the target computer, it is better taken from the same installation image that is used for STARTROM.COM and OSLOADER.EXE. The others are particular to the target computer. The BOOT.INI file is the record of what to show on the boot menu for the target computer. You need this even if there is ordinarily no boot menu to show. An NTBOOTDD.SYS driver is present only if the target computer’s hard disk does not have BIOS support, most likely because the disk is a SCSI device. There will be no BOOTSECT.DOS file unless the target computer has a multi-boot configuration that includes some other operating system, most notably a version of the sort of Windows that boots from DOS (i.e., Windows 95, Windows 98 or Windows Me).
Except for STARTROM.COM and the variation concerning NTLDR, these six files are the same as would be needed for a bootable floppy disk to use for the same computer.
To boot the target computer’s own Windows installations, it is necessary that a domain controller should recognise the target computer as needing to be booted from a particular set of files at an RIS server. It is not necessary that the target computer ever be joined to a domain. It just has to be pre-staged. In the language of Active Directory, this means that there must exist a Computer object with a netbootGUID attribute whose value is the target computer’s GUID.
The GUID is typically shown by the BIOS when trying to boot from the network. Some experimentation may be required to determine the byte ordering. For instance, the BIOS may report the GUID as
44454C4C 3800 1046 8042 B9C04F544331
but although this suggests the usual grouping of hexadecimal digits in a GUID, the GUID is actually {4C4C4544-0038-4610-8042-B9C04F544331}.
If the target computer has no GUID, derive one from the Media Access Control (MAC) address by padding to the left with null bytes. For instance, the MAC address 00-30-13-DA-77-9A becomes the GUID {00000000-0000-0000-0000-00003013DA779A}. The MAC address is typically shown by the BIOS when trying to boot from the network. On a running machine, it is shown as Physical Address in the output of the ipconfig /all command and in the Network Connection Details dialog produced by the Details button on the Support tab of the network connection’s Status.
If you cannot find the GUID or suspect that you do not have the correct GUID, enable the BINLSVC debug log at the server and see what GUID turns up in the log when you try booting the target computer. Directions are given by Microsoft, for a different purpose, in the article You cannot install a RIS image on a PXE client computer when your RIS server is also a DHCP server in Windows 2000 or Windows Server 2003.
The location of boot files for the target computer is determined by the same Computer object’s netbootMachineFilePath attribute. This is in two parts. The first, which is documented, is the fully qualified DNS name of the machine that hosts the RIS server.
The second part is an optional continuation. This is not documented, though it is hinted at by “Whistler: Can indicate the startrom that the client gets” in Microsoft’s documentation of netbootMachineFilePath in the Active Directory Schema. It is supported by BINLSVC.DLL version 5.0 and higher, i.e., starting from Windows 2000. The form is a backslash and then the pathame for the desired STARTROM.COM relative to the RIS server’s REMINST share.
Thus, if the RIS server is hosted on a machine named server in the domain domain and the boot files for the target computer are in a directory
\\server\reminst\RemoteBoot\computer
then netbootMachineFilePath must be set to
server.domain\RemoteBoot\computer\startrom.com
You can create the Computer object and set the netbootGUID and netbootMachineFilePath attributes using the ADSI Edit tool that Microsoft supplies with the Windows Support Tools.
Only one way is known to arrange all this through a user-interface tool that is ordinarily installed with Windows. The following steps assume that the target computer is not already known to Active Directory.
If the target computer is already listed in a Computers folder, e.g., because the computer actually is joined to a domain, then provided that the computer was set up as a managed computer, its Properties will have a Remote Install tab at which to take steps similar to 4 and 5 above.
When the target computer tries to boot from the network, it will download the designated STARTROM.COM. When this starts executing, it will prompt you to press F12 if you want to proceed with booting from the RIS server. If you don’t press F12, the target computer will abandon booting from the network.
If you do press F12, then you should see the boot menu that is expected for the target computer and you should be able to start whichever operating system configuration you select. The main difference from a normal boot sequence is that where files would have been loaded from the boot partition of a local hard disk or might have been loaded from a bootable floppy disk, they are instead downloaded from the RIS server across a network.
If you press F12 but see a welcome screen for installing a choice of operating systems, then the likely reason is that the target computer’s GUID has not been recognised and the download has instead gone as expected for a remote installation. Check the GUID, as described above.
The early stages of the ordinary booting of Windows from a hard disk are well known. The BIOS loads and executes the hard disk’s first sector, which is called the Master Boot Record (MBR). This sector has both some code and a very important table that describes how the hard disk is partitioned. The MBR code identifies one partition as the boot partition, then loads and executes this partition’s first sector, which is called a boot sector. Code in this sector, perhaps with help from more sectors near the start of the partition, knows enough of the file system to be able to find a file named NTLDR, and either load the whole file or at least load the file’s first sector having set up enough support that this first sector’s code can then load the rest of the file.
This NTLDR file is built in parts. The first few tens of KB are in assembly language. This part handles the execution in real mode and the transitions to and from protected mode. The remainder is a 32-bit Windows executable, i.e., with a PE header.
SOMETHING TO BE WRITTEN HERE SOME DAY
This note is based on inspection of the startup files for Windows XP SP1 and the BINLSVC.DLL from the original Windows Server 2003. (Yes, it took me something like five years to get round to writing this up.) I expect that the scheme allows any RIS server from any Windows 2000 Server or Windows Server 2003 to boot any Windows 2000, Windows XP or Windows Server 2003. Please note, however, that I have not checked all those possible combinations.
Booting Windows Vista is also possible, with different files and with an unfortunate limitation.
To the \\server\reminst\RemoteBoot\computer directory, copy the following:
These files can be extracted from BOOT.WIM on the Windows Vista CD. As for the directions above, you should extract from the latest version that is on the target computer.
To the \\server\reminst\Boot directory, copy the following from the Boot directory of the target computer’s boot partition:
Set netbootMachineFilePath to
server.domain\RemoteBoot\computer\pxeboot.com
This is enough to get the Windows Boot Menu displayed such that an installed Windows Vista can be started. It does not work for booting earlier versions of Windows.
The limitation is of course that there can be only one BCD. This is because BOOTMGR.EXE asks the RIS server for \Boot\BCD, with a leading backslash. Quite reasonably, the RIS sever interprets this as relative to the REMINST share, not to the directory implied by netbootMachineFilePath. There is not much to be done about this, short of patching the leading backslash out of BOOTMGR.EXE.