Deploying images
Wipe, image, drivers, identity — a machine that boots up finished.
Destructive by design — use at your own risk. Deploy erases the
target disk, permanently and irreversibly. It only runs inside WinPE (never on a running
Windows) and requires two separate confirmations naming the exact disk: type
ERASE, then re-enter the disk number itself as a final check. These
confirmations reduce mistakes; they do not make the operation reversible or shift
responsibility for selecting the correct disk away from the technician.Target machine readiness
DEPLOY
image
disk
apply
front-office-win11erase confirmed
Downloadresume supported, hash verified
DriversLatitude 74* pack matched
ProfileACCT-007, first-boot script staged
The flow
- Boot the target from the ImageForge USB, choose
deploy, pick an image from the library (searchable, grouped by category). - 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.
- Confirm the target disk: type
ERASE, then re-enter the disk number as a second, final confirmation. - 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.
- DISM applies the image; matching driver packs inject; the profile applies (name, domain join, first-boot script); boot files are written.
- Read the first-boot handoff, remove the USB, and reboot into Windows. If profile actions are pending, keep Ethernet connected and follow the sign-in/restart guidance shown.
Image purpose matters. A replacement clone restores the
saved Windows installation, applications, settings, and machine identity as captured. Use it
to replace a failed drive or move one machine to another drive. Do not run the original and
its clone together on the same domain. A deployment image must be Sysprep-generalized
at capture time and is the right choice for rolling one prepared image out to multiple PCs.
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.
- 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.
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.