WSUS or Intune for a network without cloud access?

If computers cannot reach Microsoft's cloud services, Intune cannot manage their updates. For a genuinely isolated environment, the choice comes down to WSUS or a larger on-premises management system that uses WSUS as its metadata source. This is an architectural constraint, not a question of an administrator's convenience or habit.

For a fleet of 300 machines, I would not choose a product by device count. Both approaches can handle that volume. First define the permitted network connections precisely, then specify the evidence required for installation, and only then count servers, licenses, and working hours. Organizations often use "without cloud access" for three different operating modes, only to discover after procurement that everyone approved a different one.

First define exactly what is prohibited

If the organization prohibits storing corporate data in the cloud but allows workstations to make outbound HTTPS connections to Microsoft services, Intune is technically possible. The cloud service will process policies and device status, while computers will normally get Windows packages directly from Windows Update. This is cloud management even if local files and business systems stay inside the organization.

If any exchange of management data with a public cloud is prohibited, Intune is out. A proxy with an address allowlist does not change the substance: the device enrolls in the service, receives policy, and sends status over the internet. Microsoft Learn's documentation for update rings states directly that devices need access to Intune and Windows Update endpoints. Windows Autopatch also requires access to its own endpoints.

The third mode is stricter: the segment has no direct internet access, but its rules permit signed packages to pass through an intermediate zone or removable media. WSUS works here with a source server in the external zone and an autonomous WSUS server inside. Administrators transfer content and metadata between them. If transfer is also prohibited, neither WSUS nor Intune can create updates out of thin air. The organization needs a separate procedure for admitting files into the environment.

Write the mode in one testable sentence. For example: "Clients in the production VLAN make no outbound connections; updates come only from a local HTTPS node; transfers between zones are inspected and recorded in a request." That wording immediately rules out Intune and defines requirements for WSUS. "We do not use the cloud" says nothing about routes, telemetry, or permitted transfers.

WSUS fits a closed environment even though development has stopped

WSUS provides a local point for synchronizing, approving, and distributing Microsoft updates. Clients learn the server address through Group Policy, scan its catalog, download approved packages inside the network, and report results back. An administrator can divide machines into groups and approve one update on different dates.

In September 2024, Microsoft deprecated WSUS. People often misread that word. Microsoft is not adding new features, but the role remains in supported Windows Server versions, including Windows Server 2025, and receives fixes under the product lifecycle. There is no need to shut down an existing installation in a hurry. At the same time, nobody should design a new ten-year architecture on the assumption that WSUS development will resume.

For a closed network, that status creates an awkward but rational choice. Microsoft's recommended cloud services do not meet the isolation requirement, while the supported local component does. WSUS can therefore be accepted as controlled technical debt: record a review date, automate maintenance, retain the configuration, and do not attach responsibilities that it cannot perform.

WSUS manages updates for Microsoft products available through Microsoft Update. It does not become a complete endpoint management product. Inventory of third-party software, deployment of arbitrary applications, remote actions, and complex orchestration need other tools. Blending the Windows patch delivery question with the complete workplace management question may look convenient in a presentation, but it harms a real design.

Another boundary separates WSUS from Microsoft Configuration Manager. Configuration Manager uses a software update point tied to WSUS, but adds collections, maintenance windows, deployments, richer reporting, and content distribution. For 300 ordinary office PCs, volume alone rarely justifies such a system. In regulated production or where the infrastructure already exists, Configuration Manager requirements can justify it regardless of fleet size.

WSUS infrastructure is small, but its upkeep never stops

A single local WSUS server is normally enough for 300 clients if sites have reliable connectivity and one server outage will not breach a mandatory installation period. The server needs the WSUS role, IIS, either Windows Internal Database or SQL Server, and content storage. Nobody can give an honest disk size without knowing the products, languages, drivers, and update file types. Selecting "download everything" makes the estimate useless very quickly.

Start with a matrix of what is actually installed: Windows releases, Windows Server, Microsoft 365 Apps, languages, and architectures. Enable only the products and classifications you need. Drivers through WSUS need a separate decision because their catalog and lifecycle can greatly increase storage and maintenance. I normally keep drivers in the hardware model management process instead of automatically approving the entire class.

Installing the role takes less time than making it operational. You need to configure TLS, IIS bindings, a proxy or upstream server, computer groups, client GPOs, the synchronization schedule, approval rules, backup, and monitoring. A branch office on a narrow link may need a downstream WSUS server, a cache, or a transfer schedule. The number 300 does not tell you whether the machines occupy one building or thirty remote rooms.

The SUSDB database needs regular cleanup and reindexing. Microsoft's WSUS maintenance documentation warns that cleanup duration depends on server resources, selected products, classifications, and accumulated debris. The first cleanup of a neglected database can take a long time. Maintenance should therefore be a scheduled job with a result log, not a button someone presses after a complaint about the console.

The minimum operating set looks like this:

• check the latest synchronization and download errors every day;
• decline superseded and expired updates each month under an approved rule;
• clean SUSDB and unused content on a schedule;
• back up the database and retain the IIS and GPO configuration;
• monitor free space, the IIS queue, and the share of clients without a recent report.

Windows Internal Database suits a small standalone WSUS server, but it does not eliminate maintenance. SQL Server is more convenient when the organization already has a standard SQL backup and monitoring platform. Buying SQL solely for 300 clients usually makes no sense. The choice depends on existing skills, not on an attempt to make WSUS look more "enterprise" with an expensive license.

An isolated segment turns updating into logistics

An offline network needs a WSUS server with internet or controlled access in the external zone and a second WSUS server inside the closed segment. A few settings must match on both servers: languages, storage options, and selected file types. Administrators transfer the metadata catalog, license terms, and update files from the external server. Files alone are insufficient, and so is a database export by itself.

Microsoft documents metadata export and import with WsusUtil. A working package sequence looks like this:

cd "$env:ProgramFiles\Update Services\Tools"
.\wsusutil.exe export export.xml.gz export.log
# После контролируемого переноса пакета на автономный сервер:
.\wsusutil.exe import export.xml.gz import.log

The export.xml.gz file contains metadata, not all binary packages. You must transfer the WSUSContent directory separately before importing metadata. After the operation, inspect export.log and import.log, the download state in the internal console, and applicability on a test client. A successful command does not prove that the required package reached disk and was approved for the right group.

For individual fixes from Microsoft Update Catalog, the old WSUS import button is no longer usable because it depended on ActiveX. Microsoft replaced that path with the PowerShell script ImportUpdateToWSUS.ps1, which accepts an UpdateID. The documented command format looks like this:

.\ImportUpdateToWSUS.ps1 -WsusServer wsus-gateway -PortNumber 8531 -UseSsl -UpdateIdFilePath C:\Transfer\UpdateIDs.txt

That script reaches the catalog, so run it on the side where such access is permitted. It imports selected updates into WSUS, but the offline environment still needs the approved transfer of content and metadata. You cannot simply import an .msu file downloaded from the catalog into WSUS as an approval object. Other tools can install it, but that creates a separate channel with separate reporting.

In practice, the command is not what consumes the most time. Transfer control does: who assembled the set, who checked signatures and scanned it for malware, which media was used, which hashes were recorded, who admitted the package, and what happened on pilot machines. In an organization with a formal cross-domain gateway, this is a complete monthly process. Compare its labor with a cloud subscription instead of calling WSUS free because the role comes with Windows Server.

Approval and an installation deadline are different things

WSUS answers "which groups should receive this update" well, but approval alone does not guarantee installation by a particular hour. A client may be off, unable to contact the server, waiting for a maintenance window, or pending a restart. A "Needed" report describes a different situation from "Installed pending reboot," and both differ from a client that has not reported for a long time.

The deadline consists of four moments: detection, download, installation, and completion after restart. The operating standard needs a criterion for each stage. If security requires a vulnerability to be closed within seven days, a report showing the number of approved updates proves nothing. You need a list of devices where the fix applies but is not installed or has not completed its restart.

Windows Update policies can define deadlines for quality and feature updates, a grace period, and restart behavior. Microsoft explains that after the effective deadline Windows may force a restart regardless of active hours. That is a useful control but dangerous for a checkout, medical workstation, or production operator. Divide devices by permitted downtime before assigning a deadline.

You can check where a particular client gets updates and which settings it received without opening the WSUS console:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate' |
  Select-Object WUServer,WUStatusServer,TargetGroup
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU' |
  Select-Object NoAutoUpdate,AUOptions,ScheduledInstallDay,ScheduledInstallTime

The expected output from the first command contains the local WSUS address in WUServer and WUStatusServer, plus the group name in TargetGroup when client-side targeting is enabled. Empty values or an old server address explain many cases where "WSUS cannot see the computer." The second command shows the received automatic update configuration, but compare the resulting policy with gpresult because conflicting GPOs can overwrite those values.

I do not recommend letting users postpone a restart indefinitely. The setting is popular for an obvious reason: the help desk gets fewer calls in the first few days. The outcome is worse because the fleet can sit pending restart for weeks while an installed-package report creates false reassurance. Give users a reasonable grace period, warn them, and finish installation with a mandatory restart in an agreed window.

Intune removes the server but requires cloud connections

Intune stores management policies in the cloud and applies Windows update rings to device groups. An administrator sets deferrals, deadlines, active hours, notifications, and restart options. Separate policies can pin a feature update version, expedite a quality fix, and manage drivers. Clients get content from Windows Update, not from a local Intune server.

The statement "Intune has no local server" is therefore true only in an accounting sense. The infrastructure moves into dependencies: Intune licenses, device enrollment, user and device identity, permitted endpoints, DNS, TLS inspection, proxies, and stable internet. If the network security team is not prepared to maintain Microsoft's changing address set, the savings on one Windows Server quickly disappear into cross-team approvals.

Microsoft requires internet access for devices managed by Intune. Update rings need at least Intune and Windows Update services, while individual features add their own addresses. Allowing one IP address is not a sustainable design because cloud addresses and service tags change. The organization needs an owner for the allowlist and a process for changing firewall rules.

Intune makes policy assignment to dynamic groups easier and suits laptops that rarely appear on the office network. The administrator does not need to clean SUSDB or store packages. Reporting still depends on client connectivity and correct telemetry. A Pause command arrives only after the device next checks in; Microsoft specifically warns that a machine may install its scheduled update before it receives the pause.

Calculate licensing under the current Microsoft agreement, not from a table copied out of an old project. Microsoft Intune Plan 1 is the base prerequisite for update rings, but bundle contents and entitlements change. For an honest comparison, ask the supplier for a licensing line covering all 300 managed devices or users and mark separately any functions that need other subscriptions.

If policy permits cloud MDM but prohibits every package from crossing the external link independently, consider Delivery Optimization and Microsoft Connected Cache in an allowed design. They can reduce duplicate content transfer. They do not turn Intune into an offline product: clients still need cloud management connections, and the cache still needs design and support.

For 300 machines, the process determines labor, not scale

Three hundred devices fit in one console, but heterogeneity can make a small fleet difficult. Two hundred and eighty identical office PCs at one site are easier than twenty laboratory stations with different windows, languages, and restart prohibitions. Count servicing variants, sites, and exceptions, not merely directory records.

With WSUS, recurring work centers on the server and content. The administrator checks synchronization, reviews new updates, approves the pilot, watches downloads, cleans the database, and investigates clients without status. A closed environment adds export, inspection, physical or gateway transfer, and import. Most of it can be automated except admission decisions and the response to a pilot failure.

With Intune, SUSDB, IIS, and the local catalog disappear. Rings, assignments, policy conflicts, reports, disconnected devices, and restart tickets remain. Licensing, enrollment, cloud roles, and network addresses become new work. If those processes already exist for Microsoft 365 and Entra, the marginal workload is low. If the organization introduces them only to patch 300 stationary PCs, the project will be much broader than update configuration.

To estimate effort, ask the administrator to run one monthly cycle on a pilot and record operations that require a human decision. Do not measure package installation time while a server works by itself. Measure fault investigation, exception approval, transfer preparation, report checking, and communication with system owners. Those are the tasks that recur in production.

The table does not declare a winner. It shows where the work moves. If security requirements already pay for a transfer procedure, WSUS uses an existing process. If the organization already manages devices through Intune, a separate WSUS server adds a second control plane and another set of failures.

Both approaches need rings

Whatever the product, do not send the monthly update to all 300 machines at once. I would begin with 10-15 IT devices, expand the pilot to 30-50 workplaces covering hardware models and important applications, then release the update to the rest of the fleet after an observation period. This is a design starting point, not a universal rule. Adjust group sizes after several cycles based on actual failures.

A pilot must differ by timing, not by the quality of the test. It should include real users and real peripherals: printers, scanners, cryptographic devices, VPN, security software, and line-of-business applications. Five identical virtual machines can test whether Windows boots, but they will not find a token driver failure on an accountant's workstation.

In WSUS, create IT-Pilot, Business-Pilot, and Production groups, approve sequentially, and do not mix automatic approval with immediate production installation. You can automatically approve security intelligence definitions or another agreed class, but monthly cumulative updates should pass through a short observation period. Treat Windows feature updates as a separate project because their risk and installation time differ.

In Intune, the same waves use rings and assignment groups. Do not overlap several rings on one device without a clear priority because conflicting settings make the result difficult to explain. Use a separate policy to set the target feature update version, and use the ring to manage installation and restart behavior. That lets the administrator distinguish "which version we offer" from "when the device must complete installation."

Write the promotion criterion between rings in advance. For example: no blocking boot or business application failure, every available pilot device has reported, and owners of critical systems have confirmed testing. An installation success percentage is weak by itself if the remaining failure affects the only station controlling expensive equipment.

You also need a stop criterion. If an update causes trouble, WSUS lets you remove approval for later groups, but machines that already installed it will not roll back automatically. Intune can pause a ring, but the command depends on the device's next connection to the service. A recovery plan must exist before deployment: package removal, image recovery, workstation replacement, or a temporary application workaround.

A report must prove the result for every machine

A neat "95% successful" figure does not tell an auditor or process owner exactly which computers remain exposed. For every mandatory update, you need the in-scope device list, detection, installation, and restart status, the last contact time, and a recorded exception. Never count a device with a stale report as patched.

WSUS shows states by update and computer, but its reports require discipline. Remove or exclude stale objects, watch for duplicates after imaging, and set a threshold for an old contact time. For client investigations, use Windows Update logs and the actual package history. The command below lists the latest installed fixes, but it does not prove that a missing package applies:

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 15 HotFixID,InstalledOn,Description

That distinction matters: inventory of installed KBs and compliance assessment are not the same. A cumulative update may supersede an older KB, so a simple check for one number sometimes reports a false violation. WSUS or the Windows Update service evaluates applicability using release, architecture, and supersedence. For audit purposes, retain the rule that the system used to call a device compliant on the report date.

Intune gathers status centrally and presents a distributed fleet more conveniently, but a cloud report cannot fix a powered-off computer. Define an acceptable age for the last check-in. Track devices under repair, in storage, and on extended leave separately so they do not disappear into an overall percentage. When such a machine returns, it should enter an expedited update process before reaching work data.

The expiry date of an exception matters more than an elegant comment. If an application is incompatible with a fix, name an owner, a compensating measure, and a review date. "Do not install until further notice" becomes a permanent hole because nobody owns the next notice. For an isolated network, attach the transfer identifier and checksums of the admitted set to the report.

The network boundary decides the choice

If all 300 computers have permitted direct access to Microsoft services and the organization accepts cloud management, Intune usually reduces local operating work. The difference is especially visible for laptops outside the corporate network and where Entra ID, Intune, and licensing processes already exist. Buying and implementing Intune only for one closed VLAN makes little sense.

If clients may not communicate with the public cloud but a local server can synchronize through a controlled proxy, choose WSUS. It keeps content inside, supports approvals by group, and does not require cloud enrollment of clients. The architecture remains clear for 300 machines if database maintenance and useful reporting are in place.

If the segment is physically or logically isolated, use an external and internal WSUS pair with governed export, transfer, and import. Include the cost of that procedure in the labor estimate from the start. For strict maintenance windows, complex reporting, and third-party software deployment, assess Configuration Manager or another on-premises management system, but do not describe Intune as an offline option.

Before procurement, test on 10-20 varied machines. For WSUS, verify scan, download, reporting, the deadline, and recovery from a bad package. For Intune, verify enrollment through the production proxy, access to every required endpoint, policy receipt, content download, and report completeness. The pilot must use the same network rules as production.

As a system integrator, GSE.kz can help design local infrastructure and supply servers for this environment without binding the design to one component vendor. The WSUS or Intune decision still begins with a signed data-flow diagram. Without it, any estimate for 300 machines will be an exact answer to the wrong question.

My choice for the stated condition "without cloud access" is simple: WSUS, if the condition truly prohibits cloud connections. I would also record its deprecated status as a risk, appoint a maintenance owner, and review available local options every year. If the customer actually permits limited internet access and cloud enrollment, reopen the comparison: Intune then becomes stronger, especially for mobile devices, but that is a different trust boundary.