image-forge.net

Capturing images

Turning a prepared machine into a stored, hashed, attributed image.

Source machine readiness

BOOT CLIENT
connect capture logs
capture win11-labdirect
PreflightBitLocker ok, Sysprep warning acknowledged
DISMstreaming to hidden Forge share
Finalizehashing and cataloging image
Direct capture streams to a one-time SMB share and then verifies/catalogs the image on the Forge.

The flow

  1. Boot the source machine from the ImageForge USB, sign in with a technician code, choose capture.
  2. Name the image, give it a description and category. The client identifies the source OS automatically (e.g. "Windows 10 Pro 22H2") and records it with the image.
  3. Preflight checks the source before anything runs (see below).
  4. Direct capture: the Forge creates a hidden, single-use SMB share; DISM streams the image straight to it. Local stores receive it in their incoming directory. A NAS-backed store uses an automatic local Forge spool, then transfers the completed image to the NAS. No staging disk is needed on the source machine.
  5. Finalize: the Forge verifies and SHA-256 hashes the whole image, catalogs it, and destroys the temporary share and account. Expect minutes of hashing on large images — the client shows elapsed time.

Capture preflight

CheckBlocksWarns
BitLockerVolume locked, or encryption/decryption in progress Encrypted but unlocked (suspend protection for clean captures)
Sysprep stateWindows marked undeployable mid-setup Not generalized — fine for one-off clones; broad deployment of a non-sysprepped image duplicates machine identity

Warnings can be overridden by typing CAPTURE — the confirmation exists so "I cloned identity into 40 machines" never happens by accident.

Direct capture requirements

When any of that is missing, the client says so and falls back automatically to the older path: capture to a local staging volume, then upload. Staging needs free space on the source machine roughly equal to the compressed image, so direct capture is strongly preferred.

NTLM-hardened domains — direct capture authenticates through a temporary local Windows account created on the Forge, and a local account can only ever authenticate over NTLM — a booting WinPE client isn't domain-joined, so it has no Kerberos ticket to offer instead. If your domain's group policy restricts incoming NTLM authentication (Network security: Restrict NTLM: Incoming NTLM traffic), that connection fails, and it typically surfaces as a generic logon failure rather than anything mentioning NTLM. This is expected, not a bug: the client falls back to staged capture exactly as it would for any other unmet direct-capture prerequisite, and staged capture doesn't depend on NTLM at all. Either exempt the Forge machine from the restriction if you specifically want direct capture on a hardened domain, or just keep using staged capture — both are fully supported day to day.
Safe staging — the client offers only NTFS, ReFS, or exFAT volumes with a conservative source-used-bytes plus 1 GiB free. It will not stage a WIM on the FAT32 boot USB. Staging on the offline Windows source volume itself is supported when it has enough room; DISM skips the open staging WIM.
Sizing — a used Windows install commonly produces a 30–80 GB WIM. For fast, repeatable demos and lab work, also keep a lean golden image (fresh install, 8–15 GB) — every deploy of it is minutes, not an hour.

Good golden-image hygiene