{"id":1026,"date":"2026-11-04T02:38:53","date_gmt":"2026-11-04T02:38:53","guid":{"rendered":"https:\/\/windows-vps.org\/blog\/?p=1026"},"modified":"2026-11-04T02:38:53","modified_gmt":"2026-11-04T02:38:53","slug":"wsus-offline-patching-wsusutil-airgap","status":"publish","type":"post","link":"https:\/\/windows-vps.org\/blog\/wsus-offline-patching-wsusutil-airgap\/","title":{"rendered":"Offline Windows Patching on an Air-Gapped VPS: Exporting and Importing with wsusutil"},"content":{"rendered":"\n

An air-gapped VPS has no route to Microsoft Update, and WSUS cannot synchronize its catalog without one. The workable answer is to carry the update metadata and binaries across the gap on removable media using wsusutil export<\/code> on a connected upstream server and wsusutil import<\/code> on the isolated downstream. The mechanics are simple; the disk space math is what trips people.<\/p>\n\n\n\n

The export package is not just the .cab payloads. It contains the WSUS database content minus the log files, expanded to a folder on disk before being packed, so peak usage during export is roughly twice the final package size plus the SQL database itself. On a VPS with a 100 GB data disk and a 60 GB WSUS content store, that peak easily exceeds the volume.<\/p>\n\n\n\n

Plan the sizing before you run the command, not after. A useful starting number: content store \u00d7 2 + database size + 20 GB working headroom. For a Windows VPS used as an offline update point<\/a>, that usually means attaching a temporary second volume for the export stage and detaching it once the media is written.<\/p>\n\n\n\n

Preparing the upstream server<\/h2>\n\n\n\n

Decline nothing casually. Every declined update is excluded from the export, so the isolated side will never receive it. On the connected upstream, approve updates for the exact products and classifications the air-gapped estate needs, let synchronization finish, and confirm that content has actually downloaded \u2014 approved but not downloaded updates appear in the catalog but fail at install with error 0x80244019.<\/p>\n\n\n\n

# On the connected upstream\n& \"$env:ProgramFiles\\Update Services\\Tools\\WsusUtil.exe\" export D:\\export\\wsus-2026-11.cab D:\\export\\wsus-2026-11.log\nGet-ChildItem D:\\export | Select Name,@{n='GB';e={[math]::Round($_.Length\/1GB,2)}}\n\n# On the isolated downstream\n& \"$env:ProgramFiles\\Update Services\\Tools\\WsusUtil.exe\" import E:\\media\\wsus-2026-11.cab E:\\media\\wsus-2026-11.log<\/code><\/pre>\n\n\n\n
Stage<\/th>Disk needed (GB)<\/th>Duration at 150 MB\/s<\/th><\/tr><\/thead>
Content store (mirrored)<\/td>60<\/td>baseline<\/td><\/tr>
Temp expand during export<\/td>60<\/td>7 min<\/td><\/tr>
Output .cab<\/td>55<\/td>6 min<\/td><\/tr>
Log file<\/td>1\u20132<\/td>< 1 min<\/td><\/tr>
Total working set<\/td>~180<\/td>15\u201325 min<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
The log file is worth attention. WsusUtil writes one line per update exported, and on a catalog of 60,000 updates it grows past a gigabyte. It is also the only record of which updates made it into the package, so archive it with the media rather than deleting it to save space.<\/p>\n\n\n\n
What the export does not include<\/h2>\n\n\n\n
The package carries the update metadata, the binary payloads, and the approval state at export time. It does not carry computer group membership, target group assignments in a form the downstream will honor unconditionally, or the WSUS server’s own configuration \u2014 port, SSL settings, content path, and product list all have to match on the receiving side or the import will complete but clients will not see the updates.<\/p>\n\n
It also does not carry the synchronization schedule or the server certificate. If the downstream uses SSL with a self-signed certificate, deploy the certificate to clients separately; an imported catalog over HTTPS with an untrusted certificate produces client-side errors that look like missing updates.<\/p>\n\n\n\n
The import on the isolated side<\/h2>\n\n\n\n
Import is a database merge, not a replacement. Updates already present are updated; new ones are added; nothing is deleted. That is useful for incremental monthly packages but means an old package applied after a new one will not roll anything back. Sequence imports by date and keep the media labeled with the export date and the upstream sync timestamp.<\/p>\n\n\n\n
The import runs as a single database transaction, so a 60 GB package can hold the WSUS database locked for 40\u201390 minutes on modest hardware. Schedule it outside the approval window, stop the WSUS service during the operation if your version permits, and take a database backup first with wsusutil.exe backupAll<\/code> \u2014 a failed import mid-way is rare but recovery without a backup is a rebuild.<\/p>\n\n\n\n
Content path and hash verification<\/h2>\n\n\n\n
The common failure after a successful import is content that exists in the catalog but not on disk. WsusUtil reports success based on the database, and the binaries land under the configured local content folder \u2014 C:\\WSUS\\WsusContent<\/code> by default. Confirm the content folder has the expected file count and total size before letting clients scan.<\/p>\n\n\n\n
Hash mismatch is the other one: media copied over USB with a generic copy tool can lose a block silently. Always compare SHA-256 of the .cab before import, and on the downstream run a client-side wuauclt \/resetauthorization \/detectnow<\/code> on one test machine to confirm it reports updates rather than error 0x80244022 or a pending install that fails on hash validation.<\/p>\n\n\n\n
Check<\/th>Pass criterion<\/th>Tool<\/th><\/tr><\/thead>
Package integrity<\/td>SHA-256 matches source<\/td>Get-FileHash<\/td><\/tr>
Catalog count<\/td>Within 1% of upstream approved<\/td>WSUS console counts<\/td><\/tr>
Content folder<\/td>Size equals upstream content store \u00b13%<\/td>Explorer \/ du<\/td><\/tr>
Client scan<\/td>Test host sees the latest CU<\/td>wuauclt \/detectnow<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
Keeping packages small<\/h2>\n\n\n\n
Full content store exports become unmanageable after a year. Use incremental exports: run the export monthly with only newly approved updates still in the “not yet exported” state, which WsusUtil tracks on the upstream server. A monthly incremental for a typical 200-server estate is 2\u20136 GB; the initial full package is 50\u201380 GB. Keep the full package on the shelf as a rebuild artifact.<\/p>\n\n\n\n
Decline superseded updates before each export. Microsoft supersedes cumulative updates on a fixed cadence, and declining the old one removes its binaries from the content store and shrinks the next incremental. Run the cleanup wizard with “unused updates and update revisions” monthly, but never with “unneeded update files” on a server you export from \u2014 it deletes payloads an unexported update still needs.<\/p>\n\n\n\n
Pilot approval and rollback<\/h2>\n\n\n\n
Approve each imported package to a pilot group of three to five machines for 48 hours before promoting it. An air-gapped estate cannot pull a replacement update on demand, so a bad patch is fixed by importing a superseding package on the next media run \u2014 typically a week later. The pilot window is what prevents a fleet-wide outage with a one-week recovery tail.<\/p>\n\n\n\n
Keep the previous two approved cumulative updates unapproved rather than declined, so a rollback via wusa \/uninstall \/kb:<number><\/code> works if a pilot finds a regression. Declining removes the payload from content and makes the uninstall fail with 0x800f0906.<\/p>\n\n\n\n
A repeatable monthly routine<\/h2>\n\n\n\n