Network boot (PXE)

No USB stick: machines boot straight into ImageForge over the LAN.

PXE prerequisites

Forge can see PXE client broadcasts on the same LAN/VLAN Network boot firewall ports are open Network boot media bundle downloaded from ImageForge support Media directory selected in the Forge console Correct bind interface selected in the console Secure Boot plan is known for UEFI network-booted clients

NETWORK BOOT

storage access network boot

PXE statuslistening

Interface192.168.10.5

Mediadata\pxeboot ready

RecentUEFI x64 requested boot.wim

The console should show listening with a ready media directory before testing a client.

The Forge can answer PXE boot requests directly, chaining a machine straight into the same WinPE + client a boot USB carries — nothing to plug in, nothing to walk around a site with. It runs as a ProxyDHCP responder: it answers PXE clients alongside your existing DHCP server rather than replacing it, so it's safe to turn on without touching your network's real DHCP configuration. Same security model as a USB boot: reaching the Forge over the network shows the technician login, not a loaded gun.

Turning it on

Download the ImageForge network boot media bundle from support or your customer portal. Keep it on the Forge server or on a storage path the Forge service can read.
Extract the bundle to a stable folder such as D:\ImageForge\pxeboot. The folder contains the WinPE boot image and the bootloader files needed by PXE clients.
Console → network boot: enable it, pick the network interface the Forge should answer PXE clients on, and confirm the media directory. Status flips to listening once all three services (ProxyDHCP, TFTP, boot HTTP) are bound — no Forge restart needed.
Point a test machine's boot order at network boot and power it on.

Installer — the "Enable network boot / PXE" firewall task is off by default during setup (unlike the other network tasks), since it opens broadcast-facing ports. Re-run the installer or ask your network administrator to allow the ports below if you skipped it.

How the chain works

iPXE loads first (over TFTP, the only thing a legacy PXE ROM can fetch), then hands off to HTTP for everything after — wimboot, then the same BCD/boot.sdi/boot.wim your USB media uses:

PXE ROM --DHCP--> Forge (ProxyDHCP)  --TFTP--> iPXE
iPXE --DHCP--> Forge (ProxyDHCP)  --HTTP--> wimboot -> BCD/boot.sdi/boot.wim -> WinPE

The Forge picks BIOS vs. UEFI automatically from the client's DHCP architecture option, and never hands out an IP address itself — that stays your real DHCP server's job.

Ports

Port	Purpose
UDP 67	ProxyDHCP responder
UDP 69	TFTP (serves only the iPXE binaries)
TCP 8969	Plain HTTP boot file server (script, wimboot, boot.wim, ...)

The boot file server is deliberately plain HTTP, not HTTPS: stock iPXE binaries have no TLS support. That's fine — the files served are the same content a USB stick already carries, and the technician login is still required once WinPE's client starts.

Known limitations

Secure Boot must be off for UEFI network boot. The stock ipxe.efi binary isn't Microsoft-signed, so a UEFI machine with Secure Boot enforced will refuse to run it. Disable Secure Boot for network-booted machines, or keep using signed boot media (USB/ISO) where Secure Boot needs to stay on.
One bind interface per Forge. On a Forge with more than one network adapter, pick the one facing the machines you want to network-boot in the console. Answering correctly on every adapter at once isn't supported.
Same LAN broadcast domain. Like any ProxyDHCP setup, the Forge needs to see the PXE client's broadcast traffic directly (no routing between the Forge and the target machines unless your infrastructure already relays PXE/DHCP across the boundary).