Network Booting: PXE, NBP, Boot Chain and Enterprise Deployment

Network booting starts a computer from a server over the network instead of using local storage. This method is widely used for diskless workstations, thin clients, labs, and large-scale deployments where centralized management, rapid reimaging, and consistent updates are required. The most common mechanism is the Preboot eXecution Environment (PXE), which typically uses DHCP for addressing and TFTP or HTTP for transferring boot files.

Overview & scope

This article provides a practical, compact introduction to PXE-based network booting: the core components, the PXE boot flow, the role of the NBP (Network Boot Program), practical tips from common tooling (for example Serva, iPXE and netboot.xyz), and short enterprise notes (Microsoft SCCM/WDS). It also includes a BIOS/UEFI checklist showing what to look for on a motherboard when enabling network boot.

Why use network booting?

Network booting reduces manual work when you must install or reimage the same system many times, manage mixed OS environments (Windows and Linux), and centrally control images and updates. It’s particularly useful for labs, classrooms, repair/maintenance workflows, diskless servers in data centers, and automated provisioning pipelines.

Core components

• PXE client firmware – PXE (or iPXE) firmware on the NIC that can initialize a minimal network environment before an OS loads.
• DHCP server – assigns IP leases and can deliver PXE-related options (e.g., option 66/67 or next-server/bootfile-name).
• File transfer server – TFTP (classic), HTTP/HTTPS (faster, used by modern UEFI), iSCSI, NFS or other protocols to deliver the boot files and images.
• NBP (Network Boot Program) – the first executable the client downloads and runs; it chains to other loaders or installers.
• Optional: Proxy DHCP – a software proxy that supplies PXE-specific DHCP options (useful when a home or simple router lacks option support).

Compact iPXE / Serva / netboot.xyz notes (from Vanderpool transcript)

iPXE is an advanced open-source network bootloader that extends PXE with additional drivers and protocols. Tools such as Serva (a user-friendly Windows package) and netboot.xyz (a prebuilt iPXE menu and collection of installers) make it feasible to run PXE environments in home labs or small offices. Serva provides an easy on-ramp for home users because many domestic routers lack DHCP options 66/67; Serva and similar projects can act as a proxy DHCP and provide the missing bootfile/server information.

DHCP: options 66 and 67, next-server, bootfile-name

PXE clients request network configuration from DHCP. The DHCP server must supply:

• next-server (or option 66) – the IP or hostname of the TFTP/HTTP server.
• bootfile-name (or option 67) – the NBP filename to fetch (for example undionly.kpxe, bootx64.efi, wdsnbp.com, or an iPXE script).

If your router’s DHCP UI is basic (home routers), you can run a proxy DHCP service (Fog Project, Serva, or a Windows/Linux DHCP server) to supply those values.

PXE boot flow (compact)

Client (PXE NIC) 
  → DHCP (get IP + PXE options) 
  → Download NBP (TFTP / HTTP / iPXE) 
  → Execute NBP in memory 
  → NBP chains to kernel/installer or further payloads 
  → OS installer / image deployment

During this flow the client typically obtains: IP address, gateway, subnet mask, PXE server (next-server) and the NBP filename. The NBP then boots and can present menus, load drivers, or fetch a full OS image over HTTP/S for speed.

Boot chain — what it is and why it matters

The boot chain is the ordered sequence of files responsible for bringing the machine from powered-off to a running OS. The PXE/NBP stage is the network portion of that chain: the NBP is the first network-delivered file; it loads subsequent stages (bootloaders, kernels, installers). Common first-stage filenames by environment:

• UEFI Windows: bootmgfw.efi
• UEFI Linux: grubx64.efi (or EFI Linux bootloaders)
• Microsoft WDS/MDT NBP: WDSNBP.COM, boot.sdi (MDT Light Touch variants like LiteTouchPE_x64.wim)
• Generic PXE iPXE: undionly.kpxe, ipxe.efi, or an iPXE script

Understanding each stage in the chain simplifies troubleshooting: if PXE stops before the NBP downloads, the issue is DHCP/TFTP/visibility; if NBP runs but image fails, the problem is in the NBP script, drivers, or HTTP/TFTP transfer.

NBP (Network Boot Program) — role & examples

The NBP is the first payload transferred to the client and executed in memory. It can be:

• a tiny menu/loader that presents OS/tool choices (netboot.xyz),
• a program that downloads a full installer (Windows PE or Linux initramfs),
• a bootstrap that loads drivers and then additional files from HTTP/TFTP/NFS.

Vendor-specific NBP names vary (Microsoft, Serva, Linux distros). The exact filename is less important than verifying the DHCP bootfile-name points correctly to a compatible NBP for the client’s firmware (BIOS vs UEFI).

Protocol choices: TFTP vs HTTP/HTTPS

TFTP is simple and widely supported (classic PXE), but slow and unauthenticated. Modern UEFI HTTP(S) boot is faster and supports larger files securely. For large-scale deployments (full OS images, Windows or Linux ISOs) prefer HTTP/S or network block protocols; for simple bootloader transfers TFTP is still common.

Enterprise: Microsoft SCCM / WDS (short)

Microsoft deployment tooling (SCCM / Configuration Manager, and legacy WDS/MDT) integrates tightly with network boot flows:

• WDS provides PXE/TFTP-based network boot for Windows deployment and can host boot images (WinPE) and install images.
• SCCM (ConfigMgr) extends enterprise deployment with imaging, drivers, task sequences, and uses PXE to start WinPE-based task sequences. SCCM commonly relies on WDS or PXE responder services to supply the NBP and initial WinPE boot image.

When using SCCM/WDS, ensure DHCP options and server roles are configured correctly (SCCM can co-exist with existing DHCP if you configure PXE responder or a dedicated DHCP scope with the next-server & bootfile-name values). Enterprise deployments often use secured HTTP or signed boot loaders to support secure boot and trust chains.

Networking & scaling considerations

• Bandwidth: Reimaging many clients concurrently requires high throughput—use HTTP and caching, or stagger deployments.
• Server capacity: Image servers may be clustered or load-balanced for heavy loads; small labs can use a single server or Raspberry Pi for light usage.
• VLANs and Layer 2: Ensure PXE traffic is allowed across VLANs—proxy DHCP or IP helper (DHCP relay) may be required to forward DHCP/PXE requests.
• Security: Never expose TFTP servers to the public Internet. Use HTTPS for large images and signed boot files for Secure Boot environments.

BIOS / UEFI checklist — what to look for on a motherboard

When preparing hardware for PXE, check the firmware settings and NIC features. Common items to enable or verify:

• Network/PXE Boot or Pre-boot Network enabled (option may be named “PXE”, “Network Boot”, “Preboot NIC” or similar).
• UEFI HTTP Boot support (if available and you plan to use HTTP boot).
• Wake on LAN / PME event support (useful for remote boot and power management).
• Secure Boot (verify if you need to disable during installation, or supply signed bootloaders for Secure Boot environments).
• Onboard NIC firmware / option ROM enabled (some NICs expose a separate option ROM toggle).
• MAC address visibility (useful for MAC-based bootfile assignment).
• For servers: dedicated management interfaces (iDRAC, iLO) are separate—avoid mixing management NICs and client NICs for PXE traffic unless intended.
• Check documentation for consumer motherboards—PXE support may be present but sometimes needs enabling in firmware menus.

Practical troubleshooting tips

• If the client never gets an IP: verify DHCP reachability and DHCP server scope, or check DHCP relay/IP helper on routers.
• If DHCP responds but no bootfile is provided: check DHCP options 66/67 (or next-server/bootfile-name) and proxy DHCP conflicts.
• If the NBP fails to download: confirm TFTP/HTTP server reachability and firewall rules (UDP 69 for TFTP; TCP 80/443 for HTTP/S).
• If NBP runs but images fail: check NBP script, drivers for NIC, and Secure Boot/signed-boot compatibility.

Compact advice: home users vs enterprise

Home routers often lack DHCP option features; to run PXE at home you can use Serva, Fog Project, or a small Linux/Windows DHCP server with proxy DHCP support. Enterprise environments prefer dedicated DHCP and image services (SCCM/WDS/HTTP infrastructure) with security controls (signed images, HTTPS, authentication).

Quick PXE boot diagram (ASCII)

Client NIC (PXE) 
  │ DHCP Discover (request PXE options)
  ▼
DHCP Server ──► returns IP + next-server/bootfile
  │
  ▼
Client fetches NBP from next-server (TFTP / HTTP)
  │
  ▼
NBP executed in memory → NBP chains to kernel / WinPE / installer
  │
  ▼
Installer downloads image (HTTP/HTTPS) → OS install / imaging

Summary

PXE network booting is a powerful, flexible method for remote OS installation and maintenance. Key elements are a PXE-capable NIC, DHCP with correct options, and a file server delivering a compatible NBP. Modern deployments benefit from HTTP(S) boot and tools such as iPXE and netboot.xyz; enterprises typically use SCCM/WDS for orchestrated deployments. Verify BIOS/UEFI settings, plan for network capacity, and secure boot flows appropriately for production use.

If you want, I can: add configuration examples (MikroTik DHCP snippets, example dhcpd.conf entries, or a sample iPXE script), insert code blocks for WDS/SCCM config, or produce screenshots and a small diagram image for the article.