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.

Concurrent NAS captures need aggregate spool space. The capacity check protects one new capture at a time; it does not reserve space against other sessions already running. Before starting a wave, total every source machine's used bytes and add 2 GiB per capture. NAS final copies are serialized, so also allow extra completion time. See Concurrent captures & deployments.

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

Select service on an image to keep it current and clean without recapturing: add Windows updates on the Windows updates tab, remove preinstalled apps on the App removal tab, and run both together. A run works on a copy of the image, so the stored image is never modified in place — if anything fails or you cancel, it stays exactly as it was. When a run succeeds the image gets a new version, and the previous one is kept for rollback.

Each run, in order: removes the apps you picked, adds the updates you picked, removes the component-store copies the updates replace, and then compacts the image. Windows keeps replaced data inside a WIM every time it is changed, so without that last step every servicing run made the image bigger; now a run usually leaves it smaller, and a smaller image also deploys faster. The version history shows the size before and after each run.

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 and click check for updates. The Forge reads the image's exact Windows build from the image itself (for example 26100.4652) — no mount, so it takes seconds — asks the Microsoft Update Catalog for the newest cumulative update and .NET Framework update for that exact build, and downloads them into the pool. Windows 10 and Windows 11 (through 26H2), x64 and ARM64 alike.

Nothing the image already has is downloaded. If the image is already at the newest cumulative update's build, the check says so instead of fetching several gigabytes.
Windows 11 24H2, 25H2 and 26H2 share their cumulative updates. The Forge matches each image to its own build, and a file already downloaded for one of them is reused for the others rather than downloaded again.
Checkpoint updates are handled for you. The catalog supplies the checkpoint package alongside the cumulative that needs it, and the two are always applied together.
Windows 10 gets every .NET variant for the month (for .NET 4.8, 4.8.1, or both): which one fits depends on what the image has installed, so all are offered and Windows applies the matching one. The rest show as skipped in the history, not as failures.

Preview, out-of-band, hotpatch and Dynamic Update releases are never selected — only shipping updates.

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 reads the image's Windows version and architecture from the image itself, 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 Windows updates tab lists, for the selected image, only the updates worth applying to it. The newest updates for its exact build are pre-selected. Everything else in the pool is under not offered, with the reason:

already in this image — the image is at or past that update's build.
replaced by newer updates — an older month's update when a newer one is in the pool.
for other Windows versions — a different Windows version or architecture, for example a Windows 10 update in a pool shared with Windows 11 images. The Forge refuses to apply these.

A package the Forge can't place (a file you added by hand with an uninformative name) is offered but not pre-selected. If Windows finds an update doesn't apply to the image, that update is skipped and recorded, and the rest of the run carries on — one wrong package no longer throws the whole run away. A run where every update was skipped changes nothing and keeps the image's version.

Remove the components updates replace is on by default: it can save gigabytes, but the added updates can no longer be uninstalled from the image. The previous version is kept for rollback either way.

Store on a NAS? Handled automatically: Windows can't service an image mounted from a network share, so the Forge copies it to local disk, services it there, and writes the result back only when it has fully succeeded. The previous version stays where it is as the rollback copy rather than being copied across the network a second time. The Forge machine needs free local disk for the working copy and for compacting it (about twice the image's size); the run checks this before starting.

Updates can also be added from a ZIP of .msu/.cab packages under manual package upload; that runs through the same process.

Removing bloatware

The App removal tab removes preinstalled apps from a stored image before you deploy it. It removes the app's provisioning — the mechanism Windows uses to install an app for every new user account — so the app never appears for anyone who signs in to a PC deployed from the image.

Replacement clones keep apps for existing users. A clone already has user profiles, and removing an app's provisioning doesn't uninstall it from accounts that already have it. It only stops new accounts getting it. On deployment images (generalized with Sysprep) this is exactly what you want.

Select an image and click scan for removable apps. The Forge mounts the image read-only and lists what's provisioned; nothing is changed by a scan.
Review the checklist.
- recommended apps are consumer apps nearly every IT department removes (Xbox, Clipchamp, Weather, News, Solitaire, Bing Search, Dev Home and similar) and are pre-selected.
- Apps usually kept are labelled with why and never pre-selected: media codecs, core Windows apps (Photos, Notepad, Paint, Snipping Tool, Terminal and so on), Quick Assist, and Teams for work or school.
- Parts of Windows itself are protected and can't be selected: frameworks and runtimes, the Store and App Installer, Windows Security, Edge, and the Entra ID sign-in component. Removing any of them breaks every PC deployed from the image, with no error at removal time to warn you.
- Everything else, including manufacturers' extras, is listed unselected.
Click run. Updates selected on the Windows updates tab go in the same run, so an image is mounted once for both. Each app is removed independently: one Windows refuses doesn't stop the rest, and the result names any that didn't come off and why.

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 that changes an image keeps the version it replaced, so a bad change is never permanent. Pick an image on either servicing tab to see its version history: each entry shows the version it produced, what it added and removed, anything skipped, and the image size before and after. An entry with a restore button can be undone — the button restores the version just before that change. Rolling back doesn't erase anything: it applies going forward as a new version, and the version you rolled back from is kept 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.