How PXE Initiated Windows XP RIS Deployment

Deploying Windows XP over a local area network using Remote Installation Services (RIS) relied on the Preboot Execution Environment (PXE) standard to bootstrap bare-metal client hardware without physical media. This article explains the step-by-step process of how PXE firmware communicated with network services—including DHCP, TFTP, and the Boot Information Negotiation Layer (BINL)—to authenticate users, load installation environments, and execute the automated setup of Windows XP.

1. PXE Firmware Initialization and DHCP Discovery

The deployment process began when the client computer powered on with network boot selected in the BIOS. The network interface card (NIC) executed its PXE ROM code, which broadcasted a standard DHCPDISCOVER packet across the local subnet. This broadcast contained specific PXE vendor class identifiers (Option 60) signaling to network infrastructure that the client required PXE boot instructions alongside an IP address.

2. Network Service Handshake and BINL Response

The network responded through a coordinated exchange involving standard DHCP services and Microsoft’s RIS-specific Boot Information Negotiation Layer (BINL):

  • The standard DHCP server allocated an IP address, subnet mask, and default gateway via a DHCPOFFER.
  • Concurrently, the RIS server's BINL service detected the PXE extension tags in the request.
  • The RIS server responded with the network bootstrap configuration, supplying its own IP address as the boot server (DHCP Option 66) and pointing to the initial bootstrap program, typically startrom.com (DHCP Option 67).

3. Loading the Network Bootstrap Program via TFTP

Once the client accepted the IP lease and boot configuration, the PXE client switched protocols to Trivial File Transfer Protocol (TFTP). The client queried the RIS server’s TFTP service to download startrom.com into memory.

Upon execution, startrom.com evaluated whether an automated installation was mandatory or required user consent. It typically displayed the message: "Press F12 for network service boot." If the user pressed F12 within a designated timeout window, startrom.com fetched the secondary loader, setupldr.exe, from the RIS server via TFTP.

4. Client Installation Wizard (OSCHOOSER)

setupldr.exe took control of the client machine, initialized basic display drivers, and launched the Client Installation Wizard (CIW), also known as OSCHOOSER.

  • OSCHOOSER presented a sequence of text-mode screens generated by .osc files hosted on the RIS server.
  • The user entered Active Directory credentials to verify deployment permissions.
  • The BINL service processed the client's globally unique identifier (GUID) against Active Directory to ensure the computer was either prestaged or authorized for auto-naming and domain join.

5. Hardware Interrogation and Image Selection

After authentication, the user selected a target Windows XP image (either a clean CD-based flat image or a customized RIPrep image).

Before launching the Windows installation kernel, the BINL service analyzed the client’s PCI vendor and device IDs (specifically the network adapter). BINL cross-referenced these IDs against driver repository folders on the RIS server. When a match was confirmed, the appropriate mass storage and network drivers were mapped directly into the boot configuration to prevent setup crashes.

6. Transition to Windows XP Text-Mode Setup

With drivers identified and image settings verified, setupldr.exe downloaded the Windows XP kernel (ntoskrnl.exe), hardware abstraction layer (hal.dll), and required boot drivers into client RAM via TFTP.

The system then exited the PXE/TFTP phase entirely. The Windows XP kernel assumed control of client hardware, initialized the network adapter using the injected drivers, and mounted the RIS server's installation directory over Server Message Block (SMB/CIFS). From this point forward, the standard Windows XP text-mode setup proceeded to partition disks, format storage, and copy installation files directly across the LAN.