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. 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 is opt-in per machine: once iPXE loads, it shows “Press any key to boot ImageForge WinPE (local boot in 5 seconds)”. No keypress means the machine exits network boot and continues its normal boot order into the local OS — so leaving PXE first in the boot order (or enabled fleet-wide) never strands restarting PCs in the imaging environment. The same fallback applies if the WinPE download fails partway.

Ports

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 requires either a site-baked HTTPS identity pin or explicit technician fingerprint verification before it sends an access code.

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

• Secure mode needs one firmware option on targets. 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 (a standard Secure Boot setting on business PCs), independent of the boot image's own Secure Boot profile. 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.