Blue View Imaging

PXE and DHCP

Blue View Imaging can run its own DHCP service, but on most networks DHCP already lives somewhere else — a Windows Server, a router, or a network appliance. In that case PXE booting works by adding two DHCP options that tell client firmware where to find the imaging server, without Blue View Imaging touching DHCP at all. This page explains those options, why a single global setting breaks on a fleet with mixed firmware, and how to verify the result. The steps are written for any DHCP server; a Windows Server example is included because it is the most common case.

The two options

Option 66 — Boot Server Host Name tells the client which TFTP server to contact. Set it to the imaging server's IP address, not its hostname. PXE firmware implementations resolve names inconsistently before the network stack is fully up, so an IP address is the reliable choice.

Option 67 — Bootfile Name tells the client which file to request from that TFTP server. This is the actual PXE loader binary — the first thing client firmware executes over the network, before anything from Blue View Imaging itself runs.

Why one global option 67 is not enough

A UEFI machine handed a BIOS boot file fails to boot, and a legacy BIOS machine handed a UEFI boot file fails the same way — the binaries are built for different firmware and neither will execute on the other. A single global option 67 can only name one file, so it can only serve one of the two populations. Any fleet with even a handful of older BIOS machines mixed in with newer UEFI ones needs a way to hand out a different filename depending on which kind of client is asking.

DHCP servers that support this read a value the client sends on every PXE request — the vendor class identifier — and match it to decide which boot file to hand back. On Windows Server this mechanism is called a DHCP policy; other DHCP servers call it a vendor class, a class expression, or a conditional filename, but the underlying idea is the same everywhere: match the client's architecture, then answer with the file that architecture can actually execute.

PXEClient architecture IDs

Every PXE client identifies itself with a vendor class string of the form PXEClient:Arch:XXXXX, where the five digits are an architecture ID. The ones you will see on an ordinary Windows/Intel fleet are:

Both 00007 and 00009 show up on UEFI x64 hardware depending on the vendor and firmware revision; treat them the same way. A policy that matches only one of the two will silently miss some UEFI machines on the network.

Which bootfile goes with which firmware

Blue View Imaging's TFTP tree ships these loader binaries (confirmed present under the imaging server's TFTP directory):

Firmware Bootfile
Legacy BIOS (arch 00000) undionly.kkpxe
UEFI x64 (arch 00007, 00009) snponly.efi

snponly.efi uses the firmware's own network driver (UEFI's Simple Network Protocol) rather than a driver built into iPXE. That is the default Blue View Imaging serves to UEFI clients. An alternative binary, ipxe.efi, is also present in the TFTP tree — it carries iPXE's own network drivers instead of the firmware's. If a UEFI machine's PXE loader appears but the network never comes up (the chain loads, then stalls), that is usually the firmware's own network driver misbehaving; switching that machine's policy to ipxe.efi works around it. Start with snponly.efi and reach for ipxe.efi only for machines that need it.

Before you touch anything: record the current values

Whatever DHCP server currently handles this network almost certainly already has options 66 and 67 set — pointing at whatever imaging or deployment system you're replacing. Write down the exact current values for scope option 066, scope option 067, and any existing vendor-class policies before changing anything. This is your rollback: if the cutover to Blue View Imaging does not work as expected, restoring these values returns the network to its previous state. PXE clients pick up DHCP changes on their next boot, so no DHCP service restart is needed to roll back.

Worked example: Windows Server DHCP

  1. Record the existing values first. In the DHCP console, open the scope's options and note the current 066 and 067 values, and check Policies for anything already configured.

  2. Set scope option 066 to the imaging server's IP address:

text Scope Options → 066 Boot Server Host Name → 192.0.2.10

  1. Define the vendor classes, if they don't already exist, under IPv4 → Define Vendor Classes. Add one class matching each architecture string from the PXEClient vendor class above (PXEClient:Arch:00000 for BIOS, PXEClient:Arch:00007 and PXEClient:Arch:00009 for UEFI x64).

  2. Create scope-level policies, one per architecture, each setting option 067:

  1. Leave the scope's default/global option 067 unset, or point it at the BIOS file, so a client that doesn't match either policy still gets something bootable rather than nothing.

If every machine on the network is UEFI and none are legacy BIOS, a single global option 067 set to snponly.efi is sufficient on its own — policies exist to solve the mixed-fleet case, and add complexity you don't need if that case doesn't apply to you.

Verifying the change

Test with one machine from each firmware type before considering the cutover complete:

Only after both firmware types boot cleanly, and the rollback has been proven to work, should DHCP for the wider network be pointed at Blue View Imaging.

More from Blue View

Blue View OSThe AI you control.An agentic AI operating system. Use the model you want, keep the data you own, and prove what happened with a tamper-evident audit trail.PapertrailYour home file cabinet, intelligently organized.Imports, classifies, and indexes your documents so you find anything in seconds.VAMPProgram management for school districts.Create a program, take enrollments through custom forms, and move each one through an approval workflow.Read2MeYour reading list, read to you.Save a link or a document and have it summarized, archived, and queued into a listening playlist.