Optional: network boot

One setup choice lets machines boot ImageForge directly from the LAN.

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 assigning addresses itself. The existing DHCP/WDS boot policy still matters: use either the lease-only ProxyDHCP topology or the integrated DHCP values below. Reaching the Forge over the network shows the technician login, not a loaded gun.

Guided setup

1. During server setup, select the single Enable network boot (PXE) option. Setup downloads and verifies the version-matched x64/ARM64 bundle, opens the four required firewall ports, and prepares the active deployment interface.
2. Open Console → network boot. Confirm the selected interface and click Enable network boot if setup left confirmation pending. A ready Forge shows boot files ready and listening; bind interface and media directory live under Advanced settings. Open the displayed deployment-LAN health URL from a device on that network before testing firmware. Keep the default secure mode unless a recorded Secure-Boot-off compatibility test requires direct mode.
3. Choose Network Boot in the target PC's one-time firmware boot menu. ImageForge reads the firmware architecture and serves the matching x64 or ARM64 set automatically.

Choose the UEFI boot mode

Manual or air-gapped setup

1. Download the network-boot bundle from the Downloads page and verify it against its SHA-256 file. One bundle carries both the x64 and ARM64 boot environments.
2. Extract the bundle into the media directory shown under Console → network boot. Keep amd64\ and arm64\ separate.
3. Open Advanced settings only if you must change the bind interface or media directory, then use the same Enable network boot action and confirm listening.

How the chain works

In secure mode, UEFI starts with an ImageForge-pinned iPXE shim signed under Microsoft Corporation UEFI CA 2011 (the Microsoft third-party UEFI CA). The shim retrieves and verifies the pinned iPXE payload. In direct compatibility mode, firmware starts that payload itself and the shim step is absent. Both modes then remain inside the selected architecture directory while HTTP carries wimboot and the same BCD/boot.sdi/boot.wim as USB media:

secure: UEFI --TFTP--> amd64|arm64/ipxe-shim.efi --TFTP/verify--> ipxe.efi
direct: UEFI --TFTP--> amd64|arm64/ipxe.efi  (Secure Boot off)
both:   iPXE --HTTP--> same-arch wimboot -> BCD/boot.sdi/boot.wim -> WinPE

DHCP option 93 values 7/9 select amd64; value 11 selects arm64. IA32 UEFI (value 6) and unknown architectures receive no offer rather than a loader that cannot run. Legacy BIOS, when deliberately retained, uses amd64\undionly.kpxe. The Forge never hands out an IP address itself — that stays your real DHCP server's job. ImageForge PXE is IPv4-only.

Network boot has a five-second escape window: once iPXE loads, ImageForge WinPE starts automatically after five seconds. Press Esc during that window to exit network boot and continue the firmware's normal boot order into the local OS. This makes WinPE reachable even on firmware that does not pass ordinary keypresses cleanly to iPXE. Loading WinPE never starts a capture, wipe, or deployment by itself; those operations still require their normal technician authentication and confirmation. A WinPE download failure also falls back to local boot.

Ports

Prove the path before booting a PC

From a Windows device on the deployment VLAN, open the health URL shown in Console → network boot, or run:

Invoke-RestMethod http://FORGE-IP:8969/healthz
Invoke-WebRequest -Method Head http://FORGE-IP:8969/boot/amd64/boot.wim

/healthz returns HTTP 200 plus the ready architectures and boot-script URLs. HTTP 503 means the listener is reachable but no validated media set is ready. A successful HEAD request proves TCP 8969, routing, and the selected architecture's WIM path without downloading the WIM. Replace amd64 with arm64 when appropriate.

The console's latest diagnosis turns the newest real client event into a status and next action. The healthy order is ProxyDHCP → UDP 4011 boot server → TFTP request and completion → HTTP boot.ipxe and assets → boot.wim. Read the first missing transition:

The boot-file stage uses plain HTTP because the pinned iPXE build has no general TLS trust store. Keep PXE on a controlled deployment VLAN. The production shim/iPXE/wimboot files are version-, signer-, architecture-, and SHA-256-pinned at publication; the exact boot WIM and its ImageForge build manifest are bound to each other. The ImageForge client still authenticates the HTTPS Forge separately: it uses either an optional site-baked identity pin or the technician access code to prove the observed certificate automatically. The code is not sent until the client reconnects with that certificate pinned; PXE users never need to copy a fingerprint.

DHCP and WDS topology

Choose one of these configurations. The Forge remains a boot-information server and never assigns the IPv4 lease.

ProxyDHCP coexistence

The normal DHCP server must supply a lease only. Its effective ACK must contain no BOOTP boot file, no next-server/siaddr, no options 66/67, and no WDS/SCCM/MDT policy that supplies those values. No other PXE responder may answer the deployment clients. ImageForge ProxyDHCP supplies the boot server and architecture-specific filename. If existing WDS settings cannot be removed or scoped away, use a dedicated deployment VLAN or the integrated policy below.

Integrated authoritative DHCP

Set the ACK's actual next-server/BOOTP siaddr to the Forge's selected deployment IPv4 address. If the DHCP product exposes only option 66, capture an ACK and confirm that siaddr is also populated; the signed shim reads that field for its second-stage TFTP address. Select the boot filename by client architecture:

For a deliberate direct compatibility test, keep the same Forge next-server and replace only the UEFI filenames with amd64/ipxe.efi or arm64/ipxe.efi. Secure Boot must be off. Scope these policies to deployment clients; do not replace a production WDS policy globally without an approved change.

Recognizing the signed-shim redirect

The signed shim gives a boot file in the normal DHCP ACK precedence over ProxyDHCP when it chooses the server and directory for its second-stage ipxe.efi. A client may therefore download ImageForge's shim successfully and then show:

Fetching Netboot Image boot\x64\ipxe.efi
Unable to fetch TFTP image :00000067
start_image() returned 00000067

If the Forge records a completed ipxe-shim.efi transfer but no matching tftp-rrq for the displayed second-stage path, that request went elsewhere. Check server-, scope-, reservation-, and policy-level DHCP settings plus every WDS/PXE responder, then cold-boot the client. A new TFTP alias on ImageForge cannot fix a packet that never reaches it. Direct compatibility mode bypasses this second request, but only with Secure Boot off.

Booting machines on a different subnet/VLAN

The Forge doesn't need to share a broadcast domain with the machines you're booting. Point your router's/L3 switch's DHCP relay (often called ip helper-address) at the Forge's IP in addition to your real DHCP server's IP — the same technique WDS and SCC/MDT deployments use. The Forge answers a relayed request exactly like a local one; the relay agent forwards the reply back onto the client's subnet. Permit UDP 67 and 4011 and TCP 8969 between clients and the Forge. TFTP sends its RRQ to UDP 69 and then uses a server-selected dynamic UDP transfer port, so use stateful/TFTP-aware inspection or permit the matching bidirectional dynamic UDP traffic; a stateless destination-69-only ACL will fail after the RRQ. The lease-only versus integrated-DHCP rules above still apply across a relay.

Qualification before fleet use

A VM pass is useful regression coverage, but it does not prove a physical NIC ROM or firmware implementation. Record the selected boot mode, Secure Boot/third-party-CA state, effective DHCP policy, firmware version, client screen, Forge request trail, and WinPE boot report for each row.

Known limitations

• Current secure mode depends on the retiring 2011 third-party trust chain. Network boot starts through a signed ipxe-shim.efi with pinned payload hashes; the shim requires the Microsoft third-party UEFI CA 2011 to be enabled in the target's firmware independent of the boot image's own Secure Boot profile. A 2023-only firmware trust store requires qualified PCA2023 USB media until ImageForge can publish a separately trusted PXE first stage. Direct mode instead requires Secure Boot off.
• PXE is IPv4-only. IPv6 PXE and native UEFI HTTP Boot clients are not served.
• IA32 UEFI is unsupported. x64 and ARM64 UEFI are separate complete media sets; unsupported or unknown option-93 values are intentionally ignored.
• 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.
• Running the Forge as a VM (vSphere, Hyper-V, etc.) works the same way. The console's interface picker lists each adapter by name alongside its IP, so on a VM with more than one vNIC — for example a management NIC plus a separate NIC on the PXE/deploy VLAN — pick the one attached to the port group the target machines actually boot on.