To patch Windows servers on an air-gapped network, you run a connected WSUS server to download and approve updates, then transfer the metadata and content files to an offline WSUS server using removable media. The offline WSUS then serves those updates to your isolated endpoints. The catch most guides miss: the export moves metadata only, not the update files or your approvals.<\/p>\n
We have set this up for offline environments in banks and manufacturing plants. The mechanics are not hard. The traps are what cost teams days.<\/p>\n
This guide walks through the full process and the mistakes that break it.<\/p>\n
Air-gapped network \u2014 a network physically isolated from the internet and all external connections.<\/p>\n
A normal Windows server pulls updates straight from Microsoft. An air-gapped server cannot reach Microsoft at all. So the updates have to be carried in by hand.<\/p>\n
That hand-carry process is called sneakernet. You download on a connected machine, copy to a USB drive or one-way gateway, and import on the offline side.<\/p>\n
Skipping patches is not an option. Insider threats, infected USB drives, and zero-day bugs still hit isolated networks. Compliance rules like RBI, ISO 27001, and NIST all expect current systems.<\/p>\n
People mix these three up constantly. They are not the same tool.<\/p>\n
WSUS (Windows Server Update Services) \u2014 Microsoft’s server role for approving and distributing updates from a local server.<\/p>\n
WSUS Offline Updater is a separate free community tool, now continued as “UpdateGenerator.” It downloads updates into a portable repository you run from a USB drive or share. It suits small or standalone setups with no WSUS server.<\/p>\n
SCCM (now Configuration Manager) is Microsoft’s full enterprise suite. It runs WSUS under the hood for the update role and adds inventory, deployment, and reporting. It is heavier and licensed.<\/p>\n
For most air-gapped server environments, two WSUS servers with export and import is the standard approach. This guide focuses on that method.<\/p>\n
You need two WSUS servers. One connected to the internet, one inside the air gap.<\/p>\n
You also need removable media large enough for the content, and a malware-scanning step in between. Many teams scan the drive on a tool like OPSWAT before it touches the offline side.<\/p>\n
One important note on WSUS itself. Microsoft deprecated WSUS in September 2024. Deprecation means no new features, but existing functionality stays and updates keep flowing through the WSUS channel. Microsoft has committed to support it for the duration of the Windows Server 2025 lifecycle, which runs to around 2035. For offline networks it remains the standard tool, because the recommended cloud replacements cannot reach an air gap.<\/p>\n
A common worry: systems have not been patched in months, so which updates do you actually need?<\/p>\n
You do not guess, and you do not download the entire catalog blindly. Let the clients tell you what they need.<\/p>\n
First, get update metadata onto the offline WSUS. Then point clients at it and let them scan. Each client reports exactly which approved updates it is missing.<\/p>\n
You then pull only those specific update files on the connected side and carry them over. This is far smaller than mirroring Microsoft’s whole catalog.<\/p>\n
Here is the full workflow from the connected side to the offline endpoints.<\/p>\n
On your internet-connected WSUS, sync updates from Microsoft as normal. Then approve only the updates you actually want.<\/p>\n
Approving selectively matters. Approving everything pulls a giant content folder you will have to carry every month. Curate first.<\/p>\n
Open a command prompt as administrator on the connected WSUS. Navigate to the tools folder.<\/p>\n
cd \"C:\\Program Files\\Update Services\\Tools\"\r\nwsusutil.exe export C:\\WSUSExport\\export.xml.gz C:\\WSUSExport\\export.log<\/code><\/pre>\n<\/div>\n<\/div>\nThis creates a metadata package. Here is the trap: this export contains metadata only. It does not include the actual update files, and it does not include your approvals.<\/p>\n
Step 3 \u2014 Copy the Content Files Separately<\/h3>\n
The real update binaries live in the WsusContent folder. You must copy them by hand<\/p>\n
\n\nSource: D:\\WSUS\\WsusContent\\\r\nTarget: same path on the offline WSUS<\/code><\/pre>\n<\/div>\n<\/div>\nCopy this folder to your removable media alongside the metadata package. Without it, your offline WSUS will know about updates it cannot actually deliver.<\/p>\n
Step 4 \u2014 Scan the Media<\/h3>\n
Before the drive touches the air gap, scan it for malware. This is your one bridge between two worlds, so treat it as the highest-risk step.<\/p>\n
A failed scan stops here. Do not carry an unscanned drive into an isolated network.<\/p>\n
Step 5 \u2014 Import on the Offline WSUS<\/h3>\n
Carry the media to the offline WSUS. Copy the WsusContent files into the same path first. Then import the metadata.<\/p>\n
\n\ncd \"C:\\Program Files\\Update Services\\Tools\"\r\nwsusutil.exe import C:\\WSUSImport\\export.xml.gz C:\\WSUSImport\\import.log<\/code><\/pre>\n<\/div>\n<\/div>\nCopy content before you import metadata. If you import first and approve updates whose files are missing, WSUS gets stuck showing thousands of updates “needing files.”<\/p>\n
Step 6 \u2014 Re-Apply Your Approvals<\/h3>\n
Your approvals did not travel with the export. You have to reproduce them on the offline side.<\/p>\n
The cleanest way is to export approved update IDs from the connected WSUS using PowerShell, carry that list over, and re-approve by ID.<\/p>\n
\n\nImport-Module UpdateServices\r\nGet-WsusUpdate -Approval Approved -Status Any |\r\n Select-Object UpdateId, Title |\r\n Export-Csv \"E:\\WSUS\\approved.csv\"<\/code><\/pre>\n<\/div>\n<\/div>\nThis single step is what most teams forget. It is the difference between a working offline WSUS and a console full of unapproved updates.<\/p>\n
Step 7 \u2014 Point Clients and Deploy<\/h3>\n
Configure your offline servers to use the local WSUS through Group Policy. Set the WSUS server URL and let clients scan against it.<\/p>\n
Clients then report what they need, pull approved updates, and install on your schedule.<\/p>\n
Patching Third-Party Apps Offline (Chrome, Adobe, Java)<\/h2>\n
Most attacks target third-party apps, not Windows itself. Chrome, Adobe Reader, Java, and Zoom are common entry points.<\/p>\n
Plain WSUS does not patch these. It handles Microsoft products only. This is the single biggest gap teams hit on offline networks.<\/p>\n
The fix is third-party patching tools that publish updates into WSUS using your local signing certificate. You publish on the connected WSUS first, then export and import like any other update.<\/p>\n
One key detail: the WsusContent folder must travel to the offline side. Third-party updates are signed with your WSUS certificate, so the offline clients need that content to install them.<\/p>\n
If you skip third-party patching, you leave your most-exploited software unpatched. Plan for it from the start.<\/p>\n
Common Mistakes That Break Offline Patching<\/h2>\n
A few errors come up again and again. Knowing them saves days.<\/p>\n
The first is the metadata-only trap. Teams export, import, and assume they are done, then find no update files arrived.<\/p>\n
The second is missing approvals. The export never carried them, so the offline console looks empty.<\/p>\n
The third is the “needing files” lockup. This happens when you approve updates before their content is in place.<\/p>\n
The fourth is carrying everything monthly. Without curation, the content folder grows huge and the sneakernet routine becomes unmanageable.<\/p>\n
Why Offline Teams Stay on WSUS<\/h2>\n
Microsoft now points users to cloud tools: Windows Autopatch and Intune for clients, and Azure Update Manager for servers. None of these work on a true air gap, because they all need a connection to Azure.<\/p>\n
There is also a cost angle. Azure Update Manager runs around $5 per server each month, which adds up fast across hundreds of servers. For offline, cost-sensitive environments, WSUS plus sneakernet remains the practical path.<\/p>\n
How Long Air-Gapped Patching Takes<\/h2>\n
Expect real time investment, especially the first cycle. The initial content sync and transfer can run several hours depending on how many updates you approve and your media speed.<\/p>\n
Monthly cycles are faster once you only carry new approved content. For a network under 500 endpoints, a practiced team can run a monthly cycle in a few hours of active work.<\/p>\n
The manual steps are where time and risk pile up. Each transfer is a chance for human error.<\/p>\n
Reducing the Manual Burden<\/h2>\n
The WSUS method works, but it is heavy on manual steps. Every export, copy, scan, and re-approval is done by hand each cycle.<\/p>\n
Some teams reduce this with managed offline patch tools that automate the transfer, approval syncing, and reporting inside the air gap. Anakage is one option worth considering here, built for offline and air-gapped enterprise networks where manual sneakernet does not scale. It suits compliance-heavy Indian environments, though smaller teams comfortable with manual WSUS may not need it.<\/p>\n
Whatever you choose, the goal is the same: current systems, clean audit reports, and fewer chances for human error.<\/p>\n
Frequently Asked Questions<\/h2>\n
Q: How do you patch Windows servers without internet?<\/strong><\/p>\nA: Use two WSUS servers, one connected and one offline. Download and approve updates on the connected server, then transfer the metadata and content files to the offline server by removable media. The offline WSUS serves updates to your isolated endpoints.<\/p>\n
Q: How far back do I need to go if systems are months behind?<\/strong><\/p>\nA: Do not download the whole catalog. Load update metadata onto the offline WSUS, point clients at it, and let them scan. Each client reports the exact updates it needs, so you only carry those files across.<\/p>\n
Q: Does wsusutil export include update files?<\/strong><\/p>\nA: No. The wsusutil export creates a metadata package only. You must copy the WsusContent folder separately, and your approvals do not transfer either. This is the most common reason offline patching fails.<\/p>\n
Q: Can WSUS patch third-party apps like Chrome and Adobe offline?<\/strong><\/p>\nA: Not on its own. WSUS handles Microsoft products only. You need a third-party patching tool that publishes updates into WSUS with your signing certificate, then export and import them with the WsusContent folder like any other update.<\/p>\n
Q: What is the difference between WSUS and WSUS Offline Updater?<\/strong><\/p>\nA: WSUS is a Microsoft server role for approving and serving updates. WSUS Offline Updater is a separate free community tool that builds a portable update repository you run from a drive or share. The community tool suits small or standalone setups without a WSUS server.<\/p>\n
Q: Why does my offline WSUS show updates “needing files”?<\/strong><\/p>\nA: This happens when you approve updates before their content files are in place. WSUS expects to download missing content from Microsoft, which it cannot do offline. Copy the WsusContent folder before approving updates.<\/p>\n
Q: Is WSUS still supported for air-gapped patching?<\/strong><\/p>\nA: Microsoft deprecated WSUS in September 2024, but it still works and still receives updates through its channel. Support runs through the Windows Server 2025 lifecycle, to around 2035. It remains the standard tool for offline Windows patching today.<\/p>\n
Q: How do you transfer update approvals to an offline WSUS?<\/strong><\/p>\nA: Approvals do not move with the export. Export the approved update IDs from the connected WSUS using the UpdateServices PowerShell module, carry the list across, and re-approve by ID on the offline side.<\/p>\n
Patching an air-gapped network comes down to moving two things correctly: the metadata and the content, in the right order, with approvals rebuilt on the offline side. Get that sequence right and the rest is routine.<\/p>\n