Driver packs

One golden image across a qualified hardware fleet — drivers meet the machine at deploy time.

There are two separate driver stories in ImageForge, solving two different problems:

1. Driver packs in the Forge (for deployed Windows)

Upload a pack in the console's drivers view and scope it with model match rules. During deploy, the client reads the target's SMBIOS model string and injects every pack whose rules match — before first boot, into the applied image. One golden image stays clean; hardware-specific drivers arrive only on the hardware that needs them.

What you can upload

Uploads are checked immediately: anything that is not a usable pack is refused with an explanation, rather than being accepted and then silently installing nothing during a deployment. The packs table shows how many drivers each pack contains.

Converting a vendor EXE

Most Dell packages are self-extracting and accept a silent-extract switch. Run it on any Windows machine, then zip the result:

<package>.exe /s /e=C:\drivers
Compress-Archive -Path C:\drivers\* -DestinationPath C:\pack.zip

For a CAB you would rather expand yourself:

expand -F:* <pack>.cab C:\drivers

Matching

• Match rules are case-insensitive substrings of the model: Latitude 74 matches Latitude 7420 and 7480.
• * matches every machine — use it for universal packs.
• Injection failures are non-fatal; the machine still boots and the miss is logged.

2. Drivers in the boot media (for WinPE itself)

The boot client needs its own NIC/storage drivers before it can reach the Forge. Production media uses a small signed bootstrap set inside boot.wim and a larger signed depot outside the WIM at \ImageForge\BootDrivers\<amd64|arm64>. When a device is missing, the client records its hardware/compatible IDs and attempts only exact INF matches from the local depot. After a successful drvload, it rescans PnP, initializes WinPE networking again, and renews DHCP. Only then does it try the installed Windows DriverStore as a last-chance source. PXE releases also embed the depot in their WIM: an offline PE NIC cannot download the driver it needs to become online.

What the media is guaranteed to bring online

Every release is checked against a published list of network adapters before it can be built. The list names each adapter by the hardware ID Windows actually reports, and each one is marked either first boot (a driver is inside boot.wim, so the adapter comes up during the normal boot) or recovery (the driver is in the depot beside the WIM, and the client loads it after boot if it is needed). If a build cannot cover something on that list, the build fails and no media is produced — a release cannot quietly ship without support for a machine it claims to support.

The current list covers Intel I217 through I219 (including 2024's Meteor Lake laptops), Intel I225/I226 2.5G, Intel I210/I211/I350, Realtek RTL8111/8168 through RTL8127, Broadcom NetXtreme and NetXtreme-E (the usual Dell PowerEdge and HPE ProLiant onboard NICs), Aquantia and Marvell multi-gigabit, Qualcomm/Atheros and Killer, and the Realtek and ASIX USB Ethernet families used by nearly every USB-C dongle and by Dell, HP and Lenovo docks.

Testing in a VM

All four common hypervisors are covered, and each release verifies it:

ethernet0.virtualDev = "vmxnet3"

Proxmox, KVM and QEMU guests using virtio networking are not supported. Set the guest's network device to e1000 instead, which is covered.

Diagnosing a machine that won't network

The client's diagnostics view shows every physical network device and its state — including devices with no driver at all (these have no device class, which hides them from naive listings). The connect screen distinguishes the three cases for you:

Plugging in an adapter after boot

The boot-time search runs once, against whatever hardware was attached at that moment. If you plug in a USB Ethernet adapter or seat the machine in a dock afterwards, choose [r] search for drivers again on the network recovery prompt. That rescans for new hardware and repeats the whole driver search, so you do not have to reboot. [d] retry DHCP only renews the address on an adapter that already works.

Adding a driver for an adapter the media doesn't cover

When the client reports hardware IDs it has no driver for, add that adapter to the depot and rebuild the media. From the winpe folder, give it the vendor's driver pack and the ID from the screen:

.\Add-OEMNICDrivers.ps1 -Path C:\packs\vendor-driver-pack.cab `
    -HardwareId 'PCI\VEN_8086&DEV_57A0' -Name my-model

Only the drivers that actually claim that ID are taken, so a large OEM pack contributes a few files rather than hundreds of megabytes. Folders, .zip, .cab and vendor .exe packages all work; an .exe is unpacked, never run. Paste the hardware ID exactly as the client printed it — the long form with SUBSYS and REV is understood.

For HP machines, the pack can be fetched and checked automatically. HP does not publish a WinPE driver pack, but it does publish a catalog with a checksum for every per-model pack, so naming the model's SoftPaq is enough:

.\Add-OEMNICDrivers.ps1 -HPSoftPaq sp157241 -Name hp-elitebook-840-g11

Wireless drivers are skipped, since WinPE cannot use them. Anything staged must be validly signed: WinPE enforces driver signatures, and a release build refuses an unsigned depot.

To check what a driver set covers without building anything, run .\Get-NICCoverageReport.ps1 -Detailed. It lists every adapter on the guarantee list and says whether it binds at first boot, comes from the depot, or is missing.