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 double-click Run ImageForge Capture Readiness.cmd; it asks for administrator rights itself. Choose the purpose, then work through its list. Many fixes it can make for you. A full report is saved to the USB when it is 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 pick the volume to capture.
Preflight checks the source before anything runs (see below) — before you type any image details, so a blocked source costs nothing.
Name the image and give it a description and category. A name is suggested: the PC's model and serial for a clone, the Windows edition for a deployment image, plus the date — press Enter to accept it. The client identifies the source OS automatically (e.g. "Windows 10 Pro 22H2") and records it with the image.
Review the capture plan and confirm. Nothing is written until you do.
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

Capture Readiness runs inside the Windows you are about to capture and tells you, in one list, whether the capture (and for a deployment image, Sysprep) will go through. It changes nothing unless you pick one of its fixes, and each fix asks first. Start it from the ImageForge USB; if it is not already running as administrator it restarts itself with the Windows administrator prompt.

Check	What it looks at
Windows	Edition, version and build, whether Windows is activated and how, and whether the PC has its own license in its firmware. Information only.
Source	That this is the running Windows installation, on NTFS.
BitLocker	Protection must be suspended, and encryption not mid-way, so WinPE can read the drive.
Disk health	Windows has not marked the drive as needing repair.
Windows Update	No update is waiting to finish (a hard stop: the image would be half-updated).
Pending restart	File changes Windows will make at the next restart — printer drivers, updaters, fonts. A warning: restart once so the image is not mid-change.
Sysprep	The state that matters for the purpose: a clone keeps its identity, a deployment image is generalized as the final step.
Sysprep apps, previous Sysprep	Deployment images only — see below.
File scan	Every file and folder on the drive (metadata only; nothing is downloaded) for cloud placeholders, provider-owned entries and encrypted files that would not survive a capture.
Image size	How much the files add up to and the biggest folders, plus leftovers worth removing first: `Windows.old`, upgrade leftovers, Windows Update's download cache and the Recycle Bin.
Final step	What to do once everything passes: run Sysprep for a deployment image, or restart to the boot menu and start the ImageForge USB for a clone.

The answer at the top is one of READY TO CAPTURE, READY WITH WARNINGS, NOT READY TO CAPTURE, READY FOR SYSPREP or FIX BEFORE SYSPREP. Below it is a numbered what to do list: blockers first, then warnings, then the final step, then optional tidying. One fix that clears several findings (a single restart finishes both updates and pending file changes) appears once.

Fixes it can make for you

When a fix is available, the list says ImageForge can do this: press 1. Each one explains what it will do and asks before doing it.

Remove the apps that would stop Sysprep — for every user, apps first and shared frameworks last.
Suspend BitLocker until the next restart — Windows turns it back on by itself after that restart.
Scan the drive for errors with chkdsk /scan, which runs while Windows keeps working.
Restart Windows to finish updates and pending file changes. Sign back in and run Capture Readiness again.
Run Sysprep (deployment image, once nothing else stands in its way). You type SYSPREP to confirm. If Sysprep stops instead of turning the PC off, Capture Readiness reads Sysprep's own log and tells you why.
Restart into the ImageForge USB (clone, once ready): restarts to Windows' boot options, where Use a device starts the USB. It is a full restart. With Fast Startup on, Shut down leaves Windows partly hibernated, which is not a safe state to capture, so readiness reminds you to use Restart.

After a fix, readiness checks again straight away, reusing the file scan when the fix cannot have changed its result; choose r for a full check.

The report

Each run saves two files next to the tool on the USB (or in the Windows temp folder if the USB is read-only): an HTML report to read, with the whole list, commands you can copy, every app that would stop Sysprep, examples of each kind of file problem and the size breakdown, and a JSON report for tools. Press o at the end to open the HTML report. Folders that running Windows keeps locked even from an administrator are listed as information, not warnings: ImageForge checks them again during the capture, and a stale report can never approve a PC that changed after it was checked.

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.

For a deployment image, Sysprep is the final step rather than a warning, because sysprep /generalize /oobe /shutdown must be the last thing that happens. Clear everything else first, run Sysprep, and then start the PC directly from the ImageForge USB or PXE. The capture itself refuses a deployment image that is not generalized.

Will Sysprep actually run? (deployment images)

Two extra checks run only for a deployment image, because only that purpose generalizes the source. They exist so readiness cannot report a machine as ready to capture while Sysprep is refusing to run on it.

Sysprep app readiness. Sysprep /generalize stops with 0x80073CF2 when a packaged app is installed for a user account but is not provisioned for all users. This is the most common Sysprep failure in the field, and it is entirely predictable beforehand. Readiness lists every such package and can remove them all for you; the report also has a single command that does the same, to run yourself.
Previous sysprep run. Readiness reads C:\Windows\System32\Sysprep\Panther\setuperr.log, reports whether the last attempt failed, when it failed, and translates the failure into the repair — a blocking packaged app, reserved storage still held by a servicing operation (0x800F0975), the activation rearm limit, or BitLocker. A Sysprep success recorded after the last failure clears the finding.

Removing preinstalled apps by hand is a common way into this. Removing an app's provisioning while it stays installed for the signed-in user produces exactly the state Sysprep rejects. Remove the app for the user as well, or re-provision it, before sealing the image. Removing apps from a stored image in the ImageForge console does not cause this — that works on the captured WIM, after Sysprep has already run.

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. A leftover staging file from an interrupted earlier capture is removed automatically, and a failed capture cleans up its own partial file.

A finished capture is never thrown away by a network blip. If the upload of a staged capture fails, the client offers to retry it — the captured image is intact, so nothing is captured again. If you decline, it can keep the WIM on the staging volume (renamed imageforge-kept-<name>-<date>.wim) for import later from Image library → Import WIM. Direct captures work the same way: if the Forge cannot finalize the image, you can retry finalizing without capturing again.

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).

Importing an existing WIM

The console's Image library → Import WIM adds a .wim (or .esd) you already have. When you choose the file, the console reads its metadata in the browser — without uploading — shows the Windows edition and architecture, and fills in the OS field for you.

Only Windows images are accepted. An ISO, VHD/VHDX, ZIP, or installer is refused up front, rather than becoming a library entry that fails later on a target whose disk has already been erased.
One edition per library entry. Microsoft's sources\install.wim holds one image per edition (Home, Education, Pro, …), and ImageForge deploys the first image of each entry. Such a file is refused with its editions listed, so it can never silently deploy the wrong one. Export the edition you want into its own WIM, then import that:
```
dism /Get-WimInfo /WimFile:install.wim
dism /Export-Image /SourceImageFile:install.wim /SourceIndex:6 /DestinationImageFile:win11-pro.wim /Compress:max /CheckIntegrity
```