image-forge.net

Pilot runbook

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 adminRuns server setup, license, storage, access, 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

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.
  2. Boot the source machine. Use ImageForge media, sign in with the technician code, and run diagnostics/readiness first. Record 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

Server setupStand up the Forge and create technician access. Boot mediaBuild or download the media used during the pilot. CaptureUnderstand preflight, direct capture, and image hygiene. DeployUnderstand wipe safety, hash verification, drivers, and profiles. TroubleshootingUse logs and diagnostics when the field gets lumpy. Resource hubDownloads, admin references, ports, logs, and evidence checklist.