Windows remote-boot quick guide

Contents

Introduction

A remote-boot computer is a computer that does not relies on local ressources (such as its hard disk) to start, but uses centralized remote ressources (through the network) instead.

In the context of remote-booting, Windows can be used at both end : as a remote-boot server or as a remote-boot client. This document will describe each of these two alternatives, beginning with the client-side.

Windows as a remote-boot client

The simplest way to remote-boot a Windows client is to let the bootstrap program download an image of bootable floppy disk, install it as a ramdisk and boot it. This is the traditional configuration for diskless PC.

Of course, this is not the most efficient way of doing it. If your Windows client is disk-based (i.e., if there is a hard-disk in your Windows client), you can do many operations on it before starting Windows, and use it as a cache to reduce network load. But let’s start with simple case : just booting a ramdisk.

Disk-less configuration

Booting a Windows ramdisk means loading the ramdisk content, installing a ramdisk driver, loading the boot sector at the proper memory location and jumping into it. Early bootroms did not even use a bootstrap program to do it — they had the code built-in. However, in order to be able to add new features, it is wiser to leave this code out of the bootrom, and have it at a place where it is easier to upgrade.

As the size of the ramdisk is limited (typically to the side of a floppy disk), you will have to carefully decide what to put on it, and leave the rest on a file server that you will access through your favorite network software (such as Netware, LAN Manager or NFS). However, to get access to the network, your client will need to get some host-specific network parameters. The only way to do it is to configure the network software to discover these from itself, for instance using the DHCP protocol.

Several tools are available for remote-booting disk-less Windows clients. Incom/Bootix and Lanworks sell two different proprietary bootroms that can handle simple ramdisks without a separate bootstrap program. However, if you want more flexibility and advanced features, you should rather consider buying a PXE-compliant bootrom, and freely choose your favorite fully-featured bootstrap loader listed below.

Intel offers a free bootstrap program for remote-booting a DOS ramdisk (known as the Intel PXE PDK for Windows) . BpBatch can also do that, along with many other nice features.

Disk-based remote-boot

When the client computer has a hard-disk (as it is almost always the case nowadays), there is much benefit to take from it in the context of remote-booting. And in opposition to a wide-spread credence, a properly configured disk-based remote-boot client is as safe and robust as a disk-less client.

There are three ways to safely use a hard disk for remote-booting Windows, that can be freely combined :

1. as a cache for the ramdisk images
2. as a cache for a networked filesystem
3. as a giant «ramdisk» (that is, as a volatile storage media that is entirely refreshed at each boot).

To be safe, a disk-based cache has to be validated by some kind of hash function, in order to ensure that the data it holds is valid and up-to-date. The only remote-boot package that currently supports caching ramdisk images is BpBatch.

Remote filesystem caching for DOS and Windows has been extensively developped by Measurement Techniques, Inc under the name Shared Lan Cache (SLC). It is a good commercial software.

Using a hard-disk as a volatile storage media involves either blindly rewriting it completely at each boot, or verifying each file by a hash function. BpBatch uses the first approach, and is able to completely rewrite a ready-to-use FAT filesystem within a few seconds (for a small Windows 3.1 image) or a few dozens of seconds (for a full Windows 98 image). We do not know of any other package that has this capability.

Windows as a remote-boot server

Windows NT can be used as the server for remote-boot clients by providing DHCP and TFTP services to bootroms. Installation and configuration of services for operation with PXE bootroms will be discussed in this section.

BOOTP/DHCP server

We strongly recommend to use the built-in DHCP server preinstalled in Windows NT server. If DHCP does not seem to be installed on your Windows NT server, go in the «services» tab of the network control panel and add the Microsoft DHCP service. Once installed, use the DHCP manager tool (Administrative Tools) to configure the DHCP server.

The first step of the installation is to create a DHCP scope. A scope is a range of addresses reserved for DHCP (i.e. the DHCP server can use any of the addresses contained in this scope for DHCP clients requesting an IP address).
The DHCP server will dynamically allocate addresses to clients requesting address. If you want to statically bind a specific host with a specific IP address, you must create a reservation (Scope menu).

A PXE bootrom requires specific DHCP parameters. If these parameters are not present in the DHCP reply, the PXE bootrom will display an error message and will halt. Here is the list of required DHCP parameters :

• Basic IP information: IP address, default gateway, subnet mask.
• Bootrom information: the server IP address and a boot filename.
  The bootrom will load the specified filename using TFTP on the given server IP address. This filename will then be executed.
• PXE-specific information: vendor class set to «PXEClient» and a valid set of encapsulated options (TAG 43)
  Encapsulated vendor options describe PXE-specific parameters. You can find a list of these parameters in the Intel PXE PDK documentation.

Setting up Basic IP information is straightforward. IP address and subnet mask are defined by the scope itself, and the default gateway can be set by adding the «Routers» options to the scope.

The boot filename is defined by the DHCP option 67 (overloaded bootfilename) because the DHCP server does not give access to the standard DHCP bootfilename field. Server IP information cannot be changed. The DHCP server always set its own IP address in this field. The TFTP service must therefore be located on the same computer as the DHCP server.

To setup PXE-specific information, you will have to add a new option tag (menu options/default) for the vendor class. Set the name of this new option to «ClassID», its type to «String» and its identifier to 60. You will then be able to add this new option to the scope and set its value to «PXEClient».
Vendor encapsulated options are defined by option 43. If you do not want to specify PXE specific options, set this value to the following array of bytes, preserving the ordering: 01,04,00,00,00,00,ff.
Note: if you are using the Intel PXE PDK for Windows (for TFTP), you can disable the ProxyDHCP service. This service is only used when the DHCP server cannot provide PXE-compliant information. To disable the ProxyDHCP service, stop and disable the «Intel boot services» in the service control panel.

Note for BpBatch users: BpBatch gets its arguments from the DHCP option 135. To specify a value for this option, you must first create it (menu options/default). Use the name «BpBatch arguments», type «String» and identifier 135.
If you plan to use DHCP site-specific options in your script, please note that you can only use options 128 to 134. Other options are not processed by PXE bootroms.

TFTP server

TFTP is the protocol used by bootroms in order to get files from the server. Any TFTP server could be used for PXE bootroms, but we recommend you to use an enhanced server, supporting large blocks transfers. This will speed up large TFTP downloads. Enhanced servers also support MTFTP, a multicast variant of the TFTP protocol, used to reduce the amount of traffic generated.

Two enhanced TFTP servers are available for Windows NT: Incom/Bootix TFTP server and Intel TFTP server. We recommend you to use the Intel TFTP server. This server is included in the PXE PDK for Windows.

Configuration of the TFTP server is done by changing keys in the registry. You can get a list of all the keys in the PXE PDK documentation. If you need to store files available by TFTP in a different location, you will have to change the following key:

Additional information about Intel TFTP server can be found in the PXE PDK for Windows documentation

Remote network boot windows

Copyright © 2003 Herbert Hanewinkel, Neuried

Overview

Many people mailed me questions about network booting a PC using my haneWIN DHCP Server. This short guide should give you a starting point and an example.

You can not create a copy of your preferred OS in a file and hope that the BOOT-ROM in a client can download and understand it. As in the real world both parties must speak the same language (protocol) to understand each other.
But there is no common standard for remote booting a PC over a network. It exists a least a commercial proposal called PXE and a public proposal called Netboot.

The PXE specification was setup by Intel but is no longer supported by them. PXE implementations sometimes use non standard DHCP options and protocols (Some PXE BOOT ROMs seem to require a special PXE server, a DHCP server running on another port).

There are two projects based on the Netboot specification: Etherboot and Netboot itself.
Etherboot and Netboot differ only in the way a BOOT-ROM is created.

Because the remote boot solutions are targeted for creating diskless Unix clients, the solutions require an Unix OS for creating the boot images. This makes sense for remote booting Linux, FreeBSD, . but not for remote booting a DOS client from Windows.

This step-by-step guide is an example of how to create a network bootable DOS image using the Etherboot solution. It does not require an unix system for creating the boot image. For details about the Etherboot/Netboot specification and the mknbi tools please read the documentation of the mknbi software and visit the Etherboot web site.

Remote booting Windows is NOT as easy because there is no network file system that can be easily used during the booting process for accessing and loading further files from a network file server.
Qualystem LiteNET PC offered a solution to boot a Windows 9x diskless client from a Windows server. It is based on loading a realmode NDIS2 driver, making networking available before Windows is loaded. The client needs a PXE BOOT ROM or floppy.

If you find some interesting links about remote booting solutions let me know.

If you have an ethernet card supporting PXE you can make use of Etherboot as well. With the Etherboot BOOT-ROM code available from ROM-O-MATIC as PXE download image, you can setup a two stage boot loader.

1. The PXE code in ROM downloads the Etherboot ROM code for your network card in PXE format.
2. The Etherboot code is executed in RAM and downloads the desired Etherboot OS image.

The boot file is selected by the DHCP server based on a vendor class identifier. The PXE ROM code includes the vendor class identifier «PXEClient» and the Etherboot code includes the vendor class identifier «Etherboot».

Requirements

The Etherboot/Netboot solution normally uses Linux for preparing the images, but with a few modifications mknbi can run under Windows as well. You need:

• a PC with a network card that has a BOOT-ROM socket.
  For testing the ROM code, BOOT-ROM emulations on a floppy disk are available.
• a DHCP and TFTP server for Windows. The haneWIN DHCP Server for Windows has a built-in TFTP server. No extra TFTP server is required
• to generate the Etherboot image you need Perl for Windows. I use ActivePerl build 517 from ActiveState under Windows 98 and Windows XP.
• the modified Etherboot mknbi tools and fdimage.exe from this zip archive for creating Etherboot images under Windows.

Creating bootable images

Etherboot and Netboot use the same specification for remote booting. They differ only in the way a BOOT-ROM is created.

Netboot:
More or less all ethernet cards are delivered with a DOS PacketDriver.
Netboot uses this PacketDriver to give you a chance to create a BOOT-ROM even for an exotic network card. While it sounds fine in the first moment, at a closer look a problem shows up. PacketDrivers of modern network cards are really huge and even using data compression it is hard to get the size of the ROM code including the PacketDriver below the standard BOOT-ROM size of 32K.
Therefore I prefer Etherboot.

Etherboot:
Etherboot uses ethernet drivers available for Linux and because of ROM-O-MATIC it is very easy to get a BOOT-ROM for an ethernet card. Exotic networks cards may be not supported, but it is easier, faster and cheaper to replace the network card than to build your own BOOT-ROM.

Step 1: The BOOT-ROM code

For testing the ROM code with your network card ROM-O-MATIC provides a BOOT-ROM emulation on floppy disk. I recommend to use this feature for testing your configuration.

Go to the ROM-O-MATIC web site to generate and download the floppy disk emulation of a BOOT-ROM for your network card. (Extension: zdsk)
For the following DOS example you don’t need to set any ROM options offered by ROM-O-MATIC. But if you want to boot e.g. FreeBSD later using the same BOOT-ROM goto the options page and set the appropriate option. Setting options will increase the size of the BOOT-ROM, therefore make sure the resulting ROM code fits in a supported ROM size of your ethernet card.

If you start with the floppy disk emulation copy the BOOT-ROM image to a floppy disk:

fdimage -f 1.44M xyz.zdsk a:

Test the ROM code with your network card. e.g. try to boot the floppy with the ROM code.
Loading ROM image. should appear on the top of screen and the PC should start sending out DHCP requests. If the computer fails to execute the ROM code, the ROM image is not appropriate for your network card.

Step 2: Create a bootable DOS image

• Create a bootable DOS or FreeDOS floppy disk.
• As long as you have space you can add any program you like to the disk.
• Copy the whole floppy disk to an image file:

fdimage -f 1.44M a: image.a

This requires my modified fdimage.exe or you can use the enhanced diskcopy.exe from FreeDOS.

Step 3: Create an Etherboot image

The perl script mknbi.pl converts the disk image into a bootable etherboot image. mknbi-1.4.1-win is a modified version of mknbi-1.4.1 to get it running under ActivePerl on Windows. There is no need to recompile the mknbi software. If you want to recompile the sources of the header files you must install the mknbi software under Linux or FreeBSD.

This step differs for MSDOS and FreeDOS:

copy a:kernel.sys
cd mknbi-1.4.1-win
mknbi.pl --format=nbi --target=fdos ..\kernel.sys ..\image.a >..\dos.bin
cd ..

cd mknbi-1.4.1-win
mknbi.pl --format=nbi --target=dos ..\image.dos >..\dos.bin
cd ..

I created mkimage.bat for the command sequence.

Step 4: Setup of DHCP Server

• Install and start the haneWIN DHCP server.
• Copy the created Etherboot image dos.bin to the TFTP servers root directory and enable the TFTP server.
• Set up a configuration profile for your client(s). You must at least specify an IP address range for the clients or use a static entry for the client.
• In the Boot tab of the configuration profile specify the name dos.bin as the boot file name for your client.

Step 5: Boot the client

The client should remote boot by downloading the image in a RAM disk and start DOS from the RAM disk.

Step 6: For PXE clients, get the PXE code

Go to the ROM-O-MATIC web site to generate and download a PXE image of the BOOT-ROM for your network card. (Extension: zpxe)

• Copy the downloaded image xyz.zpxe to the TFTP servers root directory.
• In the Boot tab of the configuration profile specify the name xyz.zpxe as the alternate boot file name if the Vendor Class Id matches «PXEClient»

Step 7: For non PXE clients, create a BOOT-ROM:

Go to the ROM-O-MATIC web site to generate and download the binary BOOT-ROM code for your network card. Copy it on a EPROM or EEPROM for your network card.