image-forge.net

Run a first job

A first real-world ImageForge test that proves the workflow without turning into a mass deployment.

Recommended first test

Keep the pilot small and evidence-rich.

Use one Forge, one prepared source PC, one wipe-safe target PC, one technician code, one captured image, and one destructive deploy. Add a second or third hardware model only after the core path works.

1Forge server
1source image
1+wipe-safe targets
ACTIVITY
dashboard activity images machines
pilot evidenceexportable
Capture okpilot-lab-win11
Deploy okDell Latitude 7420
Inventoryserial, model, MAC recorded
End every pilot with evidence from diagnostics, image library, activity, inventory, and logs.

Who should be in the room

RoleResponsibility
Pilot ownerDefines success criteria and decides whether ImageForge moves forward
Forge adminInstalls the server and manages license, storage, access, optional network boot, backup, and support evidence
Bench technicianBoots machines, runs diagnostics, capture, deploy, and collects logs
Network/admin contactConfirms firewall, VLAN, DHCP, storage, and PXE details if used
RecorderCaptures screenshots, timings, blocker notes, and the final outcome

Pre-pilot checklist

Keep the media choice obvious. Use the x64 ISO for Intel and AMD PCs and the ARM64 ISO for Snapdragon and other ARM PCs. PXE uses the network-boot bundle, not an ISO.

Before the test window starts

Runbook

  1. Start the Forge. Install as a service for production-like testing, or run foreground elevated for debugging. Open https://localhost:8967, set the admin password, activate the license, create a technician code, record the TLS fingerprint, and confirm storage. If testing optional PXE, use the installer option and confirm listening in the console.
  2. Boot the source machine. Use the Rufus-written USB, or the verified network-boot bundle when PXE is part of the test. Sign in with the technician code and run diagnostics/readiness first. Record the media choice, model, serial, MAC, volumes, Forge reachability, and TLS fingerprint status.
  3. Capture the source. Use a clear image name such as pilot-lab-win11-2026-07. Record direct capture vs. staging fallback, BitLocker/Sysprep warnings, duration, image size, SHA-256, and any warnings.
  4. Prepare driver packs or profiles if needed. Upload driver ZIPs, scope model rules, and create a deployment profile only if those are part of the success criteria.
  5. Deploy to the wipe-safe target. Run diagnostics first, choose the image and profile, confirm the target disk, type ERASE, and wait for download, hash verification, DISM apply, drivers, profile, and boot files.
  6. Verify Windows and console evidence. Confirm first boot, hostname/profile effects, driver behavior, activity feed, inventory, storage state, and uploaded session logs.
  7. Decide the outcome. Mark pass, conditional pass, blocked, or fail. Record blockers, fixes, safe public hardware claims, and what should wait for more testing.

Pass criteria

PassCapture and deploy complete on pilot hardware; Windows boots; audit and logs explain what happened.
Conditional passThe workflow works with setup fixes such as adding WinPE drivers or opening a firewall rule.
BlockedA hardware, network, storage, boot media, or permission issue prevents a fair test. Fix and retest.
FailThe agreed workflow cannot complete after blockers are resolved and evidence is collected.

Evidence bundle

Collect enough proof for someone who was not in the room.

Closeout questions

Related docs

Install serverStand up the Forge, create technician access, and choose optional network boot. Create boot USBChoose an official qualified ISO and write it with Rufus. CaptureUnderstand preflight, direct capture, and image hygiene. DeployUnderstand wipe safety, hash verification, drivers, and profiles. TroubleshootingUse logs and diagnostics when the field gets lumpy. Downloads & resourcesRelease status, admin references, ports, logs, and evidence checklist.