Deploying images

Wipe, image, drivers, identity — a machine that boots up finished.

The flow

1. Boot the target from the ImageForge USB, choose deploy, pick an image from the library (searchable, grouped by category). Each image shows its Windows architecture; one built for a different processor (an ARM64 image on an x64 PC) is marked will not boot on this PC and cannot be chosen.
2. Pick a deployment profile — or none for an unchanged image. ImageForge validates its credentials and resolves the exact computer name before showing the erase confirmation.
3. Choose the target disk. Each disk is listed by its model, size, and bus (NVMe, SATA, USB) with the volumes on it underneath — C: OS [Windows] rather than a bare number. The ImageForge boot media is marked and cannot be chosen. When exactly one internal disk exists it is offered as the default; with two or more, you type the number.
4. Review the deployment plan — image, Windows edition and architecture, download and installed size, profile and computer name, and the target drive — then confirm: type ERASE, then re-enter the disk number as a second, final confirmation. Both prompts name the physical drive and what it holds.
5. The client partitions UEFI/GPT, downloads the image with live rate/ETA, and verifies its SHA-256 against the catalog before applying — a corrupted or tampered download never reaches a disk.
6. DISM applies the image; matching driver packs inject; the profile applies (name, domain join, first-boot script); boot files are written.
7. Read the first-boot handoff and remove the USB. The PC restarts into Windows by itself after 60 seconds (press Enter to stay in ImageForge), so you can move on to the next machine. A profile can choose shut down instead, for machines being prepared to ship or store, or stay. If profile actions are pending, keep Ethernet connected and follow the sign-in/restart guidance shown.

Deploy again

After a successful deployment, the boot USB's main menu offers [l] deploy again with the same image and profile. On the next machine, that skips browsing and choosing: you go straight to the target disk, which is still chosen and confirmed twice. The computer name comes from the profile's template as usual (a new sequence number, this machine's serial), never from the previous machine. Each technician code repeats its own last deployment. If that profile has since been deleted, you are asked to choose one; if the image has been deleted, the option is not shown.

Assigning a deployment to a PC

When you already know what a machine should receive, set it up in advance in the console: Activity → deployment assignments. Choose the machine by serial number (or MAC address, for PCs whose firmware reports no real serial), the image, a deployment profile, and optionally the computer name and a note for the technician. The assign button on a fleet inventory row fills in the machine for you.

When that PC boots the ImageForge USB, the main menu shows the assignment first and offers [a] deploy the image assigned to this PC. The technician only chooses and confirms the target disk; both erase confirmations still apply. A computer name set on the assignment replaces the profile's name template, so it needs a profile to apply it.

• A PC has at most one waiting assignment: assigning it again replaces the previous one.
• A deployment that fails leaves the assignment waiting, with the reason shown in the console and on the PC, so the next attempt is offered again. A successful one marks it deployed, with the technician and the computer name it received.
• An assignment the PC cannot carry out explains itself on the PC instead of being offered: the image was deleted, it is built for a different processor, or its profile holds stored passwords this technician's code may not use.
• Assignments stay on the Forge where they were made and are not included in backups.

Resilience details worth knowing

• Interrupted downloads resume from where they stopped — a network blip in a multi-GB transfer costs seconds, not the transfer.
• Quiet phases stay visibly alive: applying the image shows ImageForge's own progress bar (not a raw Microsoft tool's), and hashing/verification shows elapsed time — a silent screen is never "maybe it crashed", even during phases where nothing is really quantifiable (file scans, integrity checks).
• Driver injection failures are deliberately non-fatal: the OS still boots, just without that pack. Each failure is listed again in the needs attention summary at the end, recorded in the audit trail, and shown in Activity — a machine that may be missing its network driver is never reported as a clean success.
• The Forge's Activity view follows a deployment all the way through, not just the download: the PC reports its own apply, driver injection, and boot-file stages back to the server, so you can watch progress from the console without standing at the machine. Reporting is best-effort — if the PC cannot reach the Forge, the deployment carries on regardless and only the remote view is affected.
• Every deploy is recorded in the audit trail with technician, machine serial, model, image, profile, duration, and result. The completed PE session log is uploaded before the reboot prompt.

Checks before anything is erased

These run while the target disk is still intact, so a deploy that cannot work costs nothing:

• Architecture. The image's own metadata records whether it holds x64 or ARM64 Windows. An image that does not match the PC (an x64 image on a Snapdragon device, for example) is refused: DISM would apply it without complaint and the PC would never boot. Images whose metadata cannot be read are not blocked.
• Free space. The disk must hold the downloaded image and the installed Windows at once. A certain shortfall stops; an estimated one asks you to confirm.
• Power. A laptop running on battery stops here until it is plugged in (or you type CONTINUE): a battery that dies part-way through the apply leaves a disk that boots nothing.
• Boot mode. If the PC started the boot USB in legacy BIOS mode, you are warned before erasing: deploy writes a UEFI layout, so switch the firmware to UEFI (turn off Legacy/CSM) and boot the USB again.

RAID, AHCI and NVMe storage modes

Deploy works with the firmware's storage mode set to RAID On (Intel RST/VMD), AHCI or plain NVMe, whichever mode the image was captured in. After the image is applied, the disk controller step adds the controller driver WinPE is using to the deployed Windows, and re-enables Windows' own storage drivers for the first start. Without it, an image captured in one mode stops with INACCESSIBLE_BOOT_DEVICE in the other. See troubleshooting if that step reports a problem.

Requirements and limits

• Targets boot UEFI; disks are partitioned GPT. Legacy BIOS/MBR targets aren't supported.
• The image is staged on the target volume itself during apply — no second disk needed — so the target disk must be larger than the image's expanded size.
• Deploy time is dominated by image size: a lean 10 GB golden image deploys in minutes; a 76 GB fat image can take the better part of an hour end to end.
• Multiple deploys can run at once. Their downloads share Forge network and storage, while verification and DISM apply run independently on each target. Plan the wave with the concurrent-jobs guide.