Windows · Patch Management

Windows Server Update Services (WSUS)

WSUS gives an organisation one internal source for Windows updates instead of every machine pulling straight from Microsoft, and computer groups plus approval rules are what turn that single feed into a controlled, staged rollout rather than every device installing everything the moment it is published.

By K Shankar R Karanth Windows Active Directory

Quick idea: WSUS downloads updates from Microsoft once, to one internal server, and then holds them until an administrator approves them for specific computer groups. Nothing installs organisation-wide just because Microsoft published it.

Computer Groups

Named targets that control which machines receive which approved updates, and when.

Approval

An update does nothing on a client until it is explicitly approved for that client’s group.

Synchronization

The scheduled process that pulls new update metadata and files from Microsoft into WSUS.

What Is WSUS?

Windows Server Update Services is a Windows Server role that acts as an internal proxy and staging point for Microsoft’s updates. Instead of every workstation and server in an environment reaching out to Windows Update individually, one or more WSUS servers synchronise update content once, and clients pull from that internal server instead.

Think of WSUS as a warehouse with a loading dock and a shop floor kept deliberately separate. Updates arrive at the loading dock during synchronization, but nothing moves to the shop floor — where clients can actually install it — until someone approves that specific shipment for that specific department.

A WSUS deployment has four moving parts: the WSUS server role itself (built on IIS), a database that tracks update metadata, approvals, and client reporting data (either the Windows Internal Database, WID, or a full SQL Server instance for larger deployments), a content store on disk holding the actual update files, and the Windows Update Agent already built into every Windows client, which WSUS redirects toward the internal server instead of the public internet.

Important: WSUS is a deprecated Windows Server role — Microsoft has stated it is no longer adding new features. It remains fully supported for production use, however, and continues to receive security and quality updates as part of the normal product lifecycle. It is not being removed; it simply will not gain new capability.

Why WSUS Instead of Direct Windows Update?

Letting every machine in a fleet pull updates directly from the internet works fine for a handful of devices. It breaks down as an organisation grows, for reasons that have nothing to do with the updates themselves.

Bandwidth

One internal synchronization instead of hundreds or thousands of machines each downloading the same files from the internet.

Control

Nothing deploys until it is approved — a bad update can be caught in a pilot ring before it reaches production.

Visibility

Centralised reporting shows exactly which computers have which updates, and which ones are failing.

None of this requires Configuration Manager or a third-party patch tool — WSUS is included with Windows Server, and for organisations that only need approval control, staged rollout, and reporting without the rest of a full endpoint-management platform, it remains a legitimate, supported option.

Why Change Control Cares About WSUS

A Windows update that installs everywhere the moment Microsoft ships it is a change-control failure waiting to happen, particularly for feature updates and cumulative updates that touch drivers, group policy client-side extensions, or authentication components. WSUS is what turns “Patch Tuesday” from an uncontrolled event into a staged rollout: a pilot ring gets an update first, production gets it a week later once nothing broke, and every step is visible in WSUS reporting.

WSUS also depends directly on two other systems covered on this site: Group Policy, which points clients at the internal WSUS server and can automatically assign them to computer groups, and Active Directory security groups, which client-side targeting maps onto WSUS deployment rings. A WSUS deployment that is not backed by a deliberate Group Policy and AD group design tends to end up with most machines sitting in Unassigned Computers, getting no targeted approvals at all.

Installing the WSUS Role

WSUS installs as a Windows Server role, either through Server Manager or PowerShell:

# Install the WSUS role and its management console, restart if required
Install-WindowsFeature -Name UpdateServices -IncludeManagementTools -Restart

The role installer does not finish the job on its own — a post-install step configures the database and content directory. Run it from an elevated Command Prompt in the WSUS Tools folder:

# Windows Internal Database (WID), small to medium deployments
WsusUtil.exe postinstall CONTENT_DIR=D:\WSUS

# Full SQL Server instance, larger or clustered deployments
WsusUtil.exe postinstall SQL_INSTANCE_NAME="SQLSRV01\WSUS" CONTENT_DIR=D:\WSUS

Practical rule: Choose the content directory deliberately before running postinstall — it holds every update binary WSUS downloads and grows continuously. Point it at a dedicated volume with real headroom, not the system drive.

WSUS listens on port 8530 for HTTP and 8531 for HTTPS by default — the older ports 80 and 443 are also supported but 8530/8531 are the current defaults for new deployments. Clients need this port open to the WSUS server, and the WSUS server itself needs outbound HTTPS to Microsoft’s update endpoints to synchronise.

Computer Groups and Targeting

Every computer that contacts WSUS is automatically a member of All Computers, and sits in Unassigned Computers until it is explicitly placed elsewhere. Computer groups can be nested — approving an update for a parent group automatically deploys it to every child group beneath it as well as the parent itself. A computer can also belong to more than one group; if an update is approved for more than one group a machine belongs to, WSUS still only deploys it once.

There are two ways to populate groups, and a WSUS server must be configured to use one or the other — they are mutually exclusive per server:

Method	How It Works	Best For
Server-side targeting	An administrator manually moves computers into groups from the WSUS console — select, right-click, Change Membership.	Small environments, or one-off exceptions in an otherwise client-side-targeted deployment.
Client-side targeting	A Group Policy setting on each client tells WSUS which group to join automatically, based on the computer’s own configuration.	Any environment with more than a handful of machines — scales without manual console work.

Before client-side targeting will work, the WSUS server has to be told to accept it: in the WSUS console, go to Options > Computers, and select Use Group Policy or registry settings on computers. Then configure the client side through Group Policy:

# GPO path (Group Policy Management Editor):
Computer Configuration > Policies > Administrative Templates >
  Windows Components > Windows Update > Enable client-side targeting

# Set the policy to Enabled, then in "Target group name for this
# computer" type the exact name of an existing WSUS computer group,
# e.g.:
Ring 3 Broad IT

Key rule: The target group name in the GPO must match a computer group name that already exists in WSUS, character for character. If the group does not exist yet in WSUS, the policy setting is silently ignored until you create it — the client does not error, it just never joins a group. If WSUS supports multiple target groups, you can list more than one name separated by semicolons.

Pointing Clients at WSUS

Client-side targeting only decides which group a computer joins — a separate policy tells the client where WSUS actually is, and a third controls how aggressively it installs what gets approved. All three live under the same Group Policy path:

Policy	Purpose
Specify intranet Microsoft update service location	Sets the WSUS server URL clients use to detect and download updates, e.g. `https://wsus01.corp.example.com:8531`.
Enable client-side targeting	Assigns the computer to a named WSUS computer group automatically (see above).
Configure Automatic Updates	Controls whether and how updates are downloaded and installed once approved — five numbered options, covered below.
Automatic Updates detection frequency	How often the client checks WSUS for new approvals — defaults to roughly 22 hours if left unconfigured.

Configure Automatic Updates is the setting that decides client behaviour once an update is approved, and it is worth getting right rather than accepting whatever a machine’s local default happens to be:

Option	Behaviour
`2` — Notify for download and auto install	User is notified updates are ready; must manually run Windows Update to download and install.
`3` — Auto download and notify for install	Default setting. Downloads happen silently in the background; user is notified once ready to install.
`4` — Auto download and schedule the install	Fully automatic on a schedule (default 3:00 AM daily if unspecified); restarts automatically if required.
`5` — Allow local admin to choose setting	Local administrators pick their own configuration, but cannot disable automatic updates entirely.
`7` — Auto download, notify to install, notify to restart	Windows Server 2016 and later only. Downloads and notifies for both install and restart, giving the admin explicit control over both steps.

Approving Updates

Synchronization brings update metadata into WSUS; it does not deploy anything on its own. A newly synchronised update sits inert until it is approved for at least one computer group.

Manual approval from the console: open Updates, select the update or updates to approve, right-click and choose Approve, then pick the target computer group and set the action to Approved for Install. The same thing from PowerShell, useful for approving in bulk or scripting a rollout:

# Approve every unapproved, needed-or-failed update for a specific group
Get-WsusUpdate -Classification All -Approval Unapproved -Status FailedOrNeeded |
    Approve-WsusUpdate -Action Install -TargetGroupName "Ring 2 Pilot"

# Check what's currently approved and pending for a computer group
Get-WsusComputer -ComputerTargetGroups "Ring 2 Pilot" -IncludedInstallationStates NotInstalled,Failed

For updates that should always be approved without a human clicking through the console every month, Automatic Approval Rules (under Options > Automatic Approvals in the console) apply criteria — classification, product, target group, and an optional install deadline — every time synchronization completes.

Production note: An automatic approval rule only evaluates updates newly seen at each synchronization — clicking Run Rule manually re-evaluates it against everything currently in WSUS, which can approve old updates you did not intend to push, including large feature upgrades. Use Run Rule deliberately, not as a routine step.

One more rule worth knowing before scripting bulk approvals: approving more than one feature update for the same computer at the same time can produce a client-side error. Feature updates should be approved one at a time per target group, not batched with other feature updates in the same pass.

Scripts / Commands

The UpdateServices PowerShell module — installed automatically with the management tools — covers day-to-day administration without opening the console:

# Connect to the local WSUS server
$wsus = Get-WsusServer

# List computer groups configured on this server
$wsus.GetComputerTargetGroups() | Select-Object Name, Id

# Check synchronization status and history
$wsus.GetSubscription().GetSynchronizationStatus()
$wsus.GetSubscription().GetSynchronizationHistory() | Select-Object -First 5

# Find computers that have not reported in recently — a common sign
# a client's WSUS-pointing GPO isn't applying
Get-WsusComputer -FromLastReportedStatusTime (Get-Date).AddDays(-14) |
    Select-Object FullDomainName, LastReportedStatusTime

# Run the same cleanup the console's Cleanup Wizard performs
Get-WsusServer | Invoke-WsusServerCleanup `
    -CleanupObsoleteComputers -CleanupObsoleteUpdates `
    -CleanupUnneededContentFiles -CompressUpdates `
    -DeclineExpiredUpdates -DeclineSupersededUpdates

Healthy output: A computer that is correctly targeted and reporting shows a recent LastReportedStatusTime — anything older than roughly your configured detection frequency plus a day or two means the client is not checking in, which is a GPO or connectivity problem, not a WSUS server problem.

Troubleshooting Cheat Sheet

Symptom	Likely Cause	Fix
Client never appears in WSUS at all	The `Specify intranet Microsoft update service location` GPO has not applied, or the client cannot reach the WSUS server on its configured port.	Confirm the GPO is linked and scoped correctly with `gpresult /r` on the client, then verify port 8530/8531 connectivity to the WSUS server.
Client sits in Unassigned Computers indefinitely	Client-side targeting is misconfigured, or the WSUS server is still set to server-side targeting.	Check Options > Computers on the WSUS server is set to Use Group Policy or registry settings, and confirm the target group name in the GPO matches an existing WSUS group exactly.
Approved update never installs on target computers	`Configure Automatic Updates` is set to a notify-only option (2 or 3), so installation needs a user action, or the client has not checked in since the approval.	Set the GPO to option `4` for a fully scheduled install if manual notification is not intended, and confirm the client’s detection frequency against how recently it last reported.
Update approved for a group has no effect on a subgroup’s computers	The computer is not actually a member of the subgroup you expect — group hierarchy only cascades downward from where the approval was made.	Confirm the computer’s actual group membership with `Get-WsusComputer`, and approve at the correct level in the hierarchy rather than assuming inheritance upward.
WSUS console is slow, or the WID database is very large	Obsolete updates, superseded revisions, and unneeded content files have accumulated without regular cleanup.	Run `Invoke-WsusServerCleanup` with the obsolete-computer, obsolete-update, and content-file options, then reindex the database — a SQL reindex after a large cleanup meaningfully improves console responsiveness.
Content directory disk filling up	Superseded and declined updates are still holding their downloaded files.	Run `Invoke-WsusServerCleanup -CleanupUnneededContentFiles -DeclineSupersededUpdates` on a schedule, not just when the disk is already critical.

Final Thoughts

WSUS is deceptively simple to describe — one internal update source, groups, and approvals — and most of the operational pain in real deployments comes from skipping the group design rather than from the tool itself. A WSUS server with no deliberate computer group hierarchy and no client-side targeting GPO ends up as an expensive, unmanaged mirror of Windows Update, with every machine sitting in Unassigned Computers.

Treat the group hierarchy and the Group Policy settings that populate it as the actual design work, and treat approvals — manual or automatic — as the mechanism that enforces whatever staged rollout that hierarchy is meant to represent.

Key takeaway: Nothing WSUS synchronises reaches a client until it is approved for that client’s computer group, and a client only ends up in the right group if client-side targeting’s GPO-specified group name matches an existing WSUS group exactly. Get those two facts right and the rest of WSUS administration is mostly reporting and cleanup.

Next in this series

Next, we can look at the Windows Update for Business and cloud-managed alternatives to on-premises WSUS — where the same computer-group and staged-rollout concepts show up again, minus the server to maintain.