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.
Direct capture's temporary SMB share is served by the Forge machine itself, backed by the store path — captures to a NAS-backed store transit the Forge.

Backup & restore

storage → backup downloads a zip of everything painful to recreate: server config, admin/technician credentials, license, TLS certificate, audit log, and all catalogs. It deliberately does not include image payloads — those are large, and the WIMs themselves are your recovery source for machines, not for the server.

Disaster recovery: install a fresh Forge, storage → restore the zip, restart, and point the store at your surviving image disk (adopt). Attribution, seats, license, and pinned fingerprints all come back.

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.

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.

Automatic updates

Turn manual servicing into a nightly chore nobody has to remember: images → automatic updates. Point it at a folder — a local path or a NAS/UNC share — where you drop .msu/.cab packages as they're released, pick a daily time, and check auto in the library on the golden images you want kept current. Nothing else is touched: images without auto checked are left alone, on purpose, so a frozen/legacy image never gets an update it wasn't meant to.

Each run only applies packages an image doesn't already have — it checks that image's own servicing history, not just what's in the folder, so dropping in the same file twice (or across many runs) never re-applies it. A package that failed last time is retried automatically the next run.

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.