Capturing images

Save an intentional replacement clone or a reusable generalized deployment image.

The flow

While still signed in to the source Windows installation, open the ImageForge USB and run Run ImageForge Capture Readiness.cmd as Administrator. Choose the intended purpose, then resolve every BLOCK. The report is saved to the USB when writable.
Boot the source machine from the ImageForge USB or PXE, sign in with a technician code, choose capture.
Choose replacement clone or deployment image, then name the image and 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.
Preflight checks the source before anything runs (see below).
Cache exclusions: the client always excludes Office update-download staging and enumerates every user profile's packaged-app LocalCache directories and supplies exact paths to DISM through a temporary WimScript.ini. These disposable caches are recreated by their apps and can otherwise contain virtualized file metadata that captures successfully but cannot be restored during deployment. If DISM encounters a missing entry in another explicitly approved disposable-cache root, ImageForge removes the incomplete WIM and retries once with that exact root excluded. Unknown paths always fail closed.
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.
Validate and finalize: the client makes DISM reopen index 1 before upload or cataloging. The Forge then 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.

Run Capture Readiness before rebooting

The live-Windows companion on each architecture-matched USB/ISO performs the checks that are most accurate while Windows and its filesystem providers are still running. It checks elevation, the source volume and NTFS dirty bit, BitLocker, pending servicing/reboots, purpose-specific Sysprep state, EFS encryption, and then walks the complete source metadata tree.

The deep scan blocks cloud placeholders and provider-owned or unknown reparse tags instead of silently omitting user data. That catches OneDrive Files On-Demand as well as comparable Dropbox, iCloud, projected-filesystem, WSL-special-file, and future provider entries by their filesystem metadata rather than a folder-name blacklist. Normal Windows junctions, symbolic links, Compact OS/WOF files, and application-execution aliases are recognized separately.

Cloud data is never blanket-excluded. Confirm the provider says sync is complete and protect an independent copy first. Then unlink/convert the source to ordinary NTFS files, or use a separately reviewed explicit exclusion when the cloud service is the authoritative copy. A clone tool must not silently turn a sync problem into data loss.

If the blocker is the OneDrive/Dropbox/iCloud root itself: downloading every file is only the first step. The root can retain cloud-provider reparse metadata even when every child shows a green local icon, and that metadata can make a WIM capture successfully but fail when applied.

Mark the complete tree Always keep on this device (or the provider's equivalent), wait for Up to date, disconnect networking temporarily, and open representative files.
Verify an independent backup. Quit and unlink the sync client, and keep it unlinked until the ImageForge capture finishes.
Use the exact robocopy command printed by Capture Readiness to copy the hydrated content into C:\ImageForge-LocalData\.... That command copies data, attributes, and timestamps without deliberately copying the provider relationship.
Verify counts and important files. Move the original provider tree off the Windows capture volume (or remove it only after both backups are proven), put the ordinary copy in the desired local location, and rerun readiness. cloud_entries must be zero.

The tool emits READY, READY WITH WARNINGS, or NOT READY, plus a local JSON report containing exact paths, an ordered next_steps repair plan, commands where a safe command is possible, and a verification condition for each result. Protected live-Windows paths count as warnings rather than being hidden; ImageForge repeats them strictly in WinPE before capture, so a stale desktop report cannot approve a source that changed after it was checked.

For a deployment image, a normal running installation reports the required Sysprep seal as a warning because sysprep /generalize /oobe /shutdown must be the final action. Clear all other blockers first, run Sysprep, and then boot directly into USB or PXE WinPE. The offline preflight will block the capture unless Windows is generalized.

No metadata scanner can promise every future third-party provider or DISM behavior. Server reachability and store capacity are checked when capture begins; target capacity and hardware drivers are checked during deployment. The readiness tool is deliberately conservative and fails closed when it cannot classify or enumerate an entry.

Replacement clone or deployment image?

Purpose	Preserves	Sysprep policy	Use it for
Replacement clone	Windows files, installed apps, settings, users, and machine identity	A normal completed Windows installation is expected	Replacing a failed/smaller drive, migrating one machine, or making an intentional copy
Deployment image	A reusable generalized Windows installation	`sysprep /generalize /oobe /shutdown` is required	Deploying a maintained baseline to multiple independent machines

Clone means Windows-volume clone, not raw disk clone. ImageForge recreates the UEFI boot layout on the target and does not preserve sector positions, deleted space, page/hibernation files, or disposable caches. A replacement clone should not normally be booted alongside its source on the same domain because it preserves machine identity.

Capture preflight

Check	Blocks	Warns
BitLocker	Status cannot be inspected, volume is locked, or encryption/decryption is in progress. A volume BitLocker reports as not a BitLocker volume at all has never been encrypted, so it is treated as safe and does not block.	Encrypted but unlocked
Filesystem	NTFS dirty bit is set	Dirty-bit status could not be read
Pending servicing	Windows Update/CBS requires a reboot or `pending.xml` exists	Offline servicing state could not be fully inspected
Sysprep state	Windows marked undeployable; deployment image is not generalized	Replacement source is already generalized or its state could not be read
Filesystem portability	Cloud placeholder, provider-owned/unknown reparse tag, unreadable tree, or EFS data in a deployment image	EFS data in a replacement clone

Warnings can be overridden by typing CAPTURE. Blocks cannot: repair or finish the source state first. The selected purpose is stored with the image and shown during deploy.

Direct capture requirements

Forge running elevated or as the service (it creates the share and one-time account).
Direct capture selected during Forge installation, TCP 445 reachable on the Forge, and Windows Server service running. The installer creates a dedicated ImageForge rule limited to the local subnet on Domain and Private profiles. Routed imaging VLANs require an administrator-reviewed custom scope; do not enable the entire Windows File and Printer Sharing firewall group.
For a NAS store, local Forge free space at least equal to source-used bytes plus 2 GiB reserve. The preflight declines direct capture before DISM starts if that conservative bound does not fit.

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.

Parallel capture — multiple direct or staged captures can run together. They share Forge network, storage, and hash capacity; NAS-backed direct captures also share the local spool. Use the concurrent-jobs guide to size the wave and account for aggregate spool space.

Good source-image hygiene

For a replacement clone, finish updates and reboot, but do not generalize unless you intentionally want Windows to specialize/OOBE on its next boot.
Build the reference machine, install apps and updates, then run sysprep /generalize /oobe /shutdown before capturing for fleet use.
Suspend BitLocker before capture (manage-bde -protectors -disable C:).
Recapture after Patch Tuesday, or patch stored images in place with offline servicing (console: images → service).