Storage & backup

Where images live, how to move them, and what disaster recovery looks like.

Storage planner

Estimate the store before capture day. The recommendation adds growth, 25% working headroom, and a reserve for updates/backups.

Images now Average image size (GB) Expected new images Reserve (GB)

The image store

The store holds image payloads (.wim), driver packs, profiles, and their catalogs. It is relocatable: a local disk or a NAS/UNC path both work. Location precedence: -store flag → saved console setting → data\store default.

Size it honestly — Windows images run 15–80 GB each. A store on the system drive fills it and takes the Forge (and captures mid-flight) down with it. Point the store at a dedicated disk from day one.

Moving the store

Console → storage → change location. Two modes:

Migrate copies everything to the new location and only then removes the old copies — a failed migration loses nothing.
Adopt points the Forge at a location that already contains an ImageForge store (a previous store on a reattached disk, a replicated NAS copy).

Storage changes are refused while a direct capture is in flight.

NAS notes

Use a UNC path (\\nas\imageforge), not a mapped drive letter — letters don't exist for services.
The Forge service runs as LocalSystem, which authenticates to the NAS as the computer account. Grant that account access, or run the service under a dedicated account with NAS rights.
NAS-backed direct capture uses a local spool. Windows cannot re-share a directory that is itself on a network path, so the Forge automatically receives the temporary WIM under its local data\capture-spool directory. After capture, the Forge hashes it, transfers it into the NAS store, commits the catalog, and removes the local copy. Before creating the share, the client reports source usage and the Forge conservatively requires that amount plus 2 GiB of local reserve. Older boot clients that do not report usage always use source-PC staging because capacity cannot be proven. If the capacity check, spool, or SMB sharing is unavailable, the client falls back to staging instead of risking a full Forge system disk.

Domain-joined Forge: service account & permissions

A domain-joined Forge is actually the easier case, not the harder one. Running as LocalSystem means the Forge reaches the NAS as DOMAIN\FORGEHOSTNAME$ — the computer account — and in a domain that's a real Active Directory security principal you can grant permissions to directly, the same way you'd grant a user or group. Add DOMAIN\FORGEHOSTNAME$ to the share and NTFS permissions on the target folder (Modify is enough; the store writes catalogs, driver packs, and image payloads under it) and direct capture and offline servicing both work with no further configuration.

A standalone workgroup NAS has no such principal to grant — it cannot recognize or trust a Windows computer account it isn't joined to, which is the actual shape of the workgroup-NAS problem: not a permissions typo, but no shared identity for either side to grant access to at all. Domain membership removes that problem entirely.

If your policy prefers a named service account over a bare computer account — easier to audit, or your NAS's ACL tooling expects a person/service identity — run the Forge under one instead: Services console → ImageForge → Properties → Log On tab → This account, enter a domain service account, and grant that account NAS permissions instead of the computer account. Give it the Log on as a service right if the Services console doesn't grant it automatically, and treat its password with normal AD service-account hygiene (rotation, no interactive login) since it's a standing credential on the Forge machine from then on.

Backup & restore

storage → backup & restore → download backup builds and verifies a backup-format-v2 zip before sending it to your browser. Its MANIFEST.json lists every included file with its byte count and SHA-256 checksum. The archive contains the server configuration, admin and technician credentials, license, audit and revocation records, image/driver/profile catalogs, encrypted-profile store key, any configured webhook signing secret, and the TLS certificate and private key. Restoring that TLS identity preserves the server fingerprint already pinned by boot media and technicians.

Metadata backup is not a payload backup. Image WIMs, driver-pack ZIPs, and rollback-lineage WIMs are deliberately excluded. Copy or snapshot the complete image-store directory separately; without those payloads, restored catalog entries alone cannot deploy, inject drivers, or roll back an image.

Automatic backups

Under storage → backup & restore, choose an absolute local path or UNC share, a daily time (the Forge server's local time), and how many archives to retain. Enable the schedule and click save schedule. Back up now runs the identical checksummed-and-verified archive path immediately, even when the daily schedule is disabled. ImageForge removes only its own oldest scheduled-backup files when retention is exceeded.

Use an independent, protected destination. Prefer a different disk or a secured network share, not a folder inside the live data or image-store directories. The console warns when the destination is inside ImageForge storage or on the same volume. These archives contain credential hashes, private keys, and profile-decryption material, so restrict the destination's ACLs and include it in your normal off-host backup policy.

Restoring safely

On a replacement Forge, attach or restore the full image-store copy and use storage → adopt to select the location that this server will keep using.
Choose the metadata backup zip under backup & restore and click restore. ImageForge bounds and stages the upload, validates its manifest, checksums, JSON catalogs, TLS key pair, and encryption-key dependencies, then creates a pre-restore recovery archive under data\restore-recovery.
The metadata files are replaced as one transaction. If any replacement fails, the transaction rolls back. The restored configuration is pinned to the currently adopted store path, so an old path recorded on another server cannot redirect this Forge away from the catalogs it just restored.
Restart the ImageForge service immediately after a successful restore. The running process deliberately blocks further writes until restart so stale in-memory settings cannot overwrite restored state.

Older ImageForge backup zips remain accepted with explicit warnings when they lack the v2 manifest or newer identity files. Keep the automatically created pre-restore archive until the restored Forge and its store have been verified.

Technician seats

Each technician access code consumes one licensed seat; the access view shows N of M in use. Revoking a code frees its seat immediately.

ImageForge server software updates

The dashboard's ImageForge server software panel can check the published release version daily or in manual only mode. Check now runs the same fail-open check immediately and shows when the last attempt and last successful check occurred. This is notification-only: ImageForge never downloads or executes a server installer. When an update is available, use the signed download link and run the installer on the Forge machine; settings, license, backups, and the image store remain in place.

Offline image servicing

images → service patches a stored image in place: upload a ZIP of Windows update packages (.msu/.cab); the Forge mounts the WIM, applies them, and commits. The image's version bumps and its hash/size refresh on success; any failure discards the mount, so a bad package can never corrupt a stored image. Golden images stay current without recapturing.

The Forge needs servicing tools at least as new as the images it services. Windows requires the DISM doing the work to be the same Windows release as the image being worked on, or newer — this applies to updates and bloatware removal. The common case that trips it is servicing a Windows 11 24H2 (or newer) image: 24H2 introduced checkpoint cumulative updates that older DISM cannot process at all, so the apply would run for many minutes and then fail with an opaque error (0x80070228 / a PSFX component error). The Forge now detects this before it starts and refuses with a clear message instead of grinding to that failure.

Two ways to satisfy this, needed on the Forge machine only (never on technician or target PCs):

Install the matching Windows ADK on the Forge. Download the Windows ADK for Windows 11, version 24H2 (or the version matching your images, or newer) from Microsoft; during setup you only need the Deployment Tools feature, which includes DISM — the rest can be unchecked. Restart the ImageForge service afterward. The Forge automatically prefers the ADK's newer DISM over the operating system's built-in one, so no OS reinstall is needed even on an older Forge host.
Or run the Forge on a Windows host of that release or newer (for example a Windows 11 24H2 machine for 24H2 images), so its built-in DISM already matches.

Automatic updates

Point the Forge at a folder — a local path or a NAS/UNC share — and drop .msu/.cab packages into it as they're released, or configure feed URLs to fetch them automatically on a daily schedule. Nothing here is ever applied to any image automatically — this step only gathers a shared pool; picking what to slipstream, and into which image, always happens on the updates page itself.

Why a folder, not Microsoft Update or WSUS — there's no official Update Catalog API to pull from reliably, and WSUS assumes infrastructure most IT shops running ImageForge don't have. A folder works the same whether it's a local disk or a share on an air-gapped VLAN, matching how the rest of the product runs offline.

Getting update packages

By default there is nothing to set up. Select an image, click check for updates, and the Forge detects the image's exact Windows version and architecture from the WIM itself, asks the Microsoft Update Catalog for the latest cumulative update and the latest .NET Framework cumulative for that exact version, and downloads them straight into the pool — Windows 10 and Windows 11, x64 and ARM64 alike. Windows 11 24H2's checkpoint-update chain is handled automatically: the catalog supplies the checkpoint package alongside the latest cumulative, and both land in the pool together so applying just works. Preview and out-of-band releases are skipped — only shipping updates are selected.

The sources below are alternatives for sites that want more control over where packages come from; all of them feed the same folder and the same per-image apply flow.

Your WSUS server — Windows 10 and 11

Configure this if you want updates limited to what your own WSUS infrastructure tracks, instead of the catalog directly. When a WSUS server URL is set, it takes over as the fetch source for check for updates.

If your site runs a WSUS server, that's the best source: it tracks current releases, including every Windows 11 version. Setup:

Make sure your WSUS server syncs the product category matching what you image (Windows 11 and/or Windows 10) — no metadata synced, nothing to find.
Install the WSUS administration console on the Forge machine (Server Manager → RSAT → Windows Server Update Services Tools, or the Rsat.WindowsServerUpdateServices.Tools optional feature on Windows 10/11) — ImageForge talks to WSUS through it.
In the console, updates → update source: set WSUS server URL, e.g. http://wsus01:8530 (or https://…:8531).
Select an image and click check for updates. ImageForge detects the image's real OS, version, and architecture via DISM, asks your WSUS server which current (non-superseded) updates match, and downloads them into the pool.

The WSUS server supplies the catalog; the package files themselves download from Microsoft's CDN, so the Forge needs outbound internet for the download step. Windows 11 ARM64 images are supported through this path. Microsoft deprecated WSUS in 2024, but it remains included and fully functional in current Windows Server — existing deployments keep working.

WSUS Offline Update — Windows 10 era only

WSUS Offline Update is a free tool that downloads update packages with no server and no Microsoft account — but be aware of its status: development ended in 2021 (the community edition's last release covers through Windows 10 22H2), and it cannot download Windows 11 updates. ImageForge knows this: pointed at a Windows 11 image, check for updates reports it plainly instead of fetching Windows 10 packages by mistake. For Windows 10-era images it still works fine:

Extract WSUS Offline Update somewhere the Forge can reach; set WSUS Offline Update install path to that folder.
Set source folder to <that path>\client.
Select an image and click check for updates.

You can also run the tool yourself on any schedule and just keep source folder pointed at its output — ImageForge scans the whole tree recursively either way.

Hand-picked catalog links

The feed URLs box accepts direct download links from the Microsoft Update Catalog — useful when you want a specific package the automatic selection doesn't cover (a servicing stack update, an optional component, a driver), or want the daily scheduled sync to keep fetching a fixed set you chose yourself.

Air-gapped Forge? Every fetch path above needs internet on the machine doing the fetching — the built-in catalog fetch needs outbound HTTPS from the Forge itself. With no outbound access at all, download packages on a connected machine and copy them into the source folder by hand — the per-image pending/apply flow works identically regardless of how files arrived.

Applying updates to an image

The updates page is where servicing actually happens: pick a stored image and it shows exactly which packages from the pool it doesn't already have — checked against that image's own servicing history, so a package already applied is never offered again (one that failed last time stays offered, so you can retry it). Each package is listed with its full path inside the source folder, not just its filename — if you're pointed at a WSUS Offline Update download, that subfolder name (w100-x64, w63-x64, and so on) is the only indication of which Windows version and architecture a given package targets, so check it before picking anything for an image running a different OS/architecture. Check the ones you want, optionally note why, and apply. The Forge mounts the image, applies just your selection, and commits — the exact same mount/apply/commit machinery as a one-off manual package upload, just sourced from the shared pool and scoped to your selection instead of an ad hoc ZIP.

Store on a NAS? Handled automatically: Windows can't service an image mounted from a network share, so when your store lives on a UNC path the Forge stages the image to local disk, services it there, and writes it back only once servicing fully succeeded — a failure or cancel anywhere along the way leaves the stored image exactly as it was. The Forge machine needs free local disk at least the size of the image during the operation, and the extra two copies across the network add real time on large images — the progress bar shows each stage, including the copies.

Checking what's really installed

The pending list is fast because it trusts ImageForge's own record of what it has applied to an image — but that record doesn't know about packages a captured golden image already had baked in, or anything patched outside ImageForge entirely. Check for updates goes deeper: it mounts the image read-only and asks DISM directly what's actually installed, catching anything the fast list would have wrongly offered again, and fetches applicable packages for that image's real, detected OS/architecture in the same click (from the Microsoft Update Catalog by default, or your configured WSUS source). Mounting a large image isn't instant and a fetch is a real download, so this can take a few minutes; the checklist refreshes automatically once it's done. A progress bar under the button shows each stage live (mounting, downloading with real byte counts, applying, committing), and a running check or apply can be cancelled from the same spot — a cancelled operation always cleans up after itself, so the stored image is never left half-modified.

Removing bloatware

The debloat page (console key [B]) removes preinstalled apps from a stored image before you deploy it, using the same provisioned-app mechanism Windows itself uses to install an app for every new user account on a machine. Removing a provisioned app from the image means it never installs on any PC deployed from it — this is a one-time change to the golden image, not a per-deployment cleanup step.

Select an image and click scan for removable apps. The Forge mounts the image read-only and asks DISM which apps are provisioned on it; nothing is changed by a scan.
Review the checklist. Common consumer apps — Xbox, Weather, Skype, Solitaire, and similar — are pre-checked and marked recommended. Everything else DISM found, including OEM-installed extras (Dell/HP/Lenovo bundleware), is listed unchecked but still selectable. A handful of framework/runtime packages (VCLibs, .NET Native, the Store app itself, App Installer) are marked protected and can't be selected at all — removing one of those can silently break the Store or other provisioned apps on every machine this image is ever deployed to, with no DISM error at removal time to catch it.
Adjust the selection, optionally note why, and click remove selected. The Forge mounts the image read-write and removes each checked package individually, then commits. Removal isn't all-or-nothing: each app is independent of the others, so if DISM rejects one (a stale or already-gone package, for example), that doesn't block the rest — whatever succeeds is kept, and the result names exactly which apps failed and why. If nothing at all succeeds, the mount is discarded and the stored image is left untouched, same as any other failed servicing operation.

Scope: this removes provisioned AppX apps only. Windows Capabilities (legacy optional features and language packs) are a separate mechanism and aren't covered yet.

Version history and rollback

Every servicing run — manual, automatic, or a debloat removal — keeps a snapshot of what the image looked like right before it, so a bad change is never permanent. Open images → service, updates, or debloat and pick an image to see its full version history; any entry still marked with a rollback button has a snapshot on disk. Rolling back doesn't erase anything: it applies going forward as a new version, and the version you rolled back from gets its own snapshot too, so you can always go either direction again.

3 versions are kept per image by default; older snapshots age out automatically as new ones are taken. Change this under storage → rollback retention — lowering it reclaims space for every image right away, not just on the next update. Each snapshot is only ever taken once per version, so retrying a cancelled or failed update never re-copies a snapshot that's already on disk.