How to Configure WSUS with Group Policy and Approval Rules

A working WSUS server doesn’t deploy anything until clients receive an update-service policy and updates are approved for their computer groups. Configure one machine-side GPO that sets the WSUS service URLs and Automatic Updates behavior, then choose one WSUS targeting mode, create separate workstation and server deployment rings, and approve updates through a pilot path before production.

On modern Windows devices, also audit Windows Update client policies. In mixed environments, use the scan-source policy to choose Windows Update or WSUS for each update class. Don’t approve broadly, set deadlines, or block internet update locations until the intended source, group, installation, and restart behavior have been verified on pilot systems.

How WSUS Configuration Control Works

WSUS controls content and approvals. The server decides which updates exist, which are approved for which computer groups, and what deadline applies – it doesn’t push anything, it makes updates available.

Group Policy controls client behavior. GPO tells the client where to look for updates, how to behave when found, and which WSUS computer group to join.

Operations controls promotion and change windows. Neither WSUS nor GPO decides whether a pilot succeeded or a server change is approved – that’s a process: which update moves from pilot to production, emergency exceptions, maintenance-window timing, rollback ownership, and monitoring. WSUS and GPO are not a complete governance system on their own.

All three layers need to be working. A WSUS server with perfect approvals delivers nothing to clients that haven’t been pointed at it; clients pointed at WSUS with no approved updates install nothing; and even correct WSUS/GPO configuration doesn’t decide when a change is actually safe to promote.

Step 1: Point Clients to WSUS with Group Policy

A dedicated GPO for WSUS client settings is a strong operational recommendation because it simplifies rollback, scoping, and troubleshooting – it isn’t a technical requirement. Don’t add WSUS settings to Default Domain Policy or Default Domain Controllers Policy; use a dedicated or clearly scoped update-policy GPO instead, applied to the OU containing the computers you want to manage. Computers, not users – these are machine-level settings.

GPO path: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update. Specify intranet Microsoft update service location directs the client to WSUS – both fields (detection service and statistics server) should point to the same URL in a normal single-server deployment:

Supported port pairs are 8530/8531 or 80/443 – don’t invent an arbitrary custom pair, and match the URL to your actual deployment. Microsoft allows separate detection/statistics values when the two services are intentionally split; verify the design before treating a difference as an error.

Configure Automatic Updates controls installation and notification behavior – a separate job from the location setting, which only makes WSUS targeting work.

Verify applied policy

After gpupdate /force on a test client:

UseWUServer = 1 is expected when policy-driven Automatic Updates should use the intranet service. Treat 0 or absent as evidence the effective policy is incomplete or another policy is overriding it – not automatically “the” universal mistake. If values are empty, run gpresult /scope computer /h C:\Temp\wsus-gp.html /f and check winning/denied GPOs and security filtering; see the Group Policy and GPO Not Applying guides linked in the scope note above for inheritance, RSoP, and processing diagnostics. If a security group scopes this GPO, confirm the computer account still has Read and Apply Group Policy – removing Authenticated Users can silently remove required Read access.

Step 2: Automatic Updates and Restart Profiles

Options for Configure Automatic Updates:

• 2 – Notify for download and notify for install – rarely appropriate for managed environments
• 3 – Auto download and notify for install – useful where installation should stay manual
• 4 – Auto download and schedule the install – doesn’t make the configured clock the only installation mechanism; Automatic Maintenance, active hours, restart policies, and approval deadlines also affect final behavior
• 5 – Allow local admin to choose setting – legacy, not available on Windows 10+, don’t use it in a modern baseline
• 7 – Notify for install and notify for restart (Windows Server 2016+) – installation and restart both stay operator-controlled

On Windows Server, Microsoft’s documented registry default for this setting is option 3 – not shown in the GPO editor – and setting the policy to Not Configured can still result in automatic download/install behavior. Don’t treat Not Configured as a safe “manual only” server baseline; set it explicitly.

Don’t present option 4 alone as the workstation standard – it needs a complete policy set:

• Profile A – notification-first pilot: option 3, users/admins notified after download, useful while verifying policy and ring behavior, no assumption that a schedule alone produces compliance.
• Profile B – controlled automatic install: option 4, an approved maintenance schedule, Maintenance Scheduler settings where required, active-hours policy, restart notification/grace behavior, validated against native WSUS deadlines. Use for mature workstation management, as a complete set – not option 4 alone.

For servers, option 7 is the strong operator-controlled default on Server 2016+; option 3 is an acceptable alternative when automatic download is desired, installation stays manual, and restart ownership is documented.

Step 3: Scan Source in Mixed WSUS/Windows Update Policy

Many guides omit this, and the gap breaks patch delivery silently wherever WSUS and Windows Update client policies coexist. Each update class routes to either the Windows Update endpoint or the configured WSUS server – Windows Update for Business is the policy layer managing content received from Windows Update, not a third source endpoint. When a device is pointed at WSUS while Windows Update client deferral/policy settings also apply, some classes can scan from Microsoft services instead of WSUS unless the source is explicitly defined – clients then appear in your console and get WSUS-approved updates, but also independently pull feature, quality, or driver updates directly from Microsoft.

The legacy DisableDualScan policy is unsupported on Windows 11 and replaced/not recommended on Windows 10. Don’t configure it together with the newer scan-source policy – Microsoft documents that combination as blocking the device from Windows Update content entirely.

Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Server Update Service. Specify source service for specific classes of Windows Updates routes Feature Updates, Quality Updates, Driver Updates, and Other Microsoft Updates independently. Document all four classes deliberately rather than leaving one or two implicit in a mixed-policy environment.

The public WSUS/WUfB guidance targets Windows 10/11, while the current Policy CSP lists 10.0.20348.371 and later for server – validate the exact build and ADMX rather than a generic “verify against build.”

Before routing all classes to WSUS, verify whether your managed versions receive Features on Demand and language-pack content through on-premises UUP, media, or Microsoft Update, and test .NET 3.5, RSAT, language packs, and optional features on a pilot device first.

Verify all four values, not just the master switch:

0 = Windows Update endpoint, 1 = WSUS, missing = not explicitly configured. UseUpdateClassPolicySource = 1 alone doesn’t prove all four classes are actually routed correctly – check each value against the intended design, and don’t hand-edit these keys directly; fix the GPO instead.

Step 4: Choose One Targeting Mode

Under WSUS Options -> Computers, the mode is either-or: Use the Update Services console, or Use Group Policy or registry settings on computers. Enabling client-side targeting means computers send their requested group names, and manual membership changes through the console become unavailable until the mode is switched back.

Server-side targeting – manually move computers from Unassigned Computers into groups through the console (or API/script). Fits small environments, exceptions, or explicit manual placement; the “under 50 machines” comfort zone is a field example, not a documented limit.

Client-side targeting – a GPO tells the client which group to request; the WSUS server needs “Use Group Policy or registry settings on computers” enabled first. Navigate to the same Windows Update path and use Enable client-side targeting, entering the group name exactly as it appears in the console – a misspelled or nonexistent name is ignored until a matching group exists. Semicolon-separated multiple groups are supported, but overlapping groups complicate effective approval and deadline behavior – use one primary ring per device unless a documented cross-cutting group is necessary, and test overlapping approvals before production.

Verify through Windows Update operational events, WSUS Last Contact and Last Status Report, group membership, and update applicability – not through a single command’s return. UsoClient StartScan is sometimes observed to trigger a scan on current builds, but it’s undocumented for administrator automation and returns no reliable completion or error status; treat it as a non-authoritative fallback, not the primary method.

Step 5: WSUS Configuration for Deployment Rings

Deployment rings are where this work produces real value – staged approval instead of all at once. The canonical mistake: creating groups, then approving to All Computers, which bypasses the ring entirely. Workstation promotion and server criticality are different axes – don’t model critical servers as simply the third stage of the workstation ring.

Workstation rings: Pilot (IT and representative business devices, small diverse hardware/app sample) -> Broad (normal production workstations, promoted after pilot evidence) -> Exception (documented hold or special workflow, not a permanent dumping ground).

Server rings: Server Pilot (low-risk representative servers, validates server-specific behavior) -> Server Production (application/file/infrastructure servers, approved through change process) -> Critical Infrastructure (domain controllers, identity, database clusters, core network services – separate maintenance windows and dependency checks).

Promotion should be evidence-based – successful installation, restart, service health, application checks, monitoring, help-desk signal – calendar time is only one input, not the decision. Emergency path: a small validation group, documented risk acceptance, an explicit supersedence/applicability check, post-deployment monitoring, and a rollback/mitigation plan – still through a small group, not straight to All Computers, even when the standard soak periods are inappropriate for an actively exploited vulnerability.

Step 6: Manual Approvals

In the console: Updates > All Updates, filter Needed and Unapproved, select, right-click, Approve to the pilot group first, then promote after evidence. Before approving: confirm product, classification, architecture, language, and supersedence, and review known issues and restart requirements. Approve only one applicable feature update per device. Remove is available only for updates that support removal; Not Approved is not the same as Declined. Document who approved the update and the intended maintenance window.

Step 7: Automatic Approvals and Their Hazards

Configured under Options > Automatic Approvals – this is where configuration decisions carry the most risk, since rules run at sync time and auto-approve anything matching. Review every existing rule before enabling or creating new ones; an old disabled rule scoped broadly or to All Computers can bypass your ring structure the moment it’s re-enabled without review.

Don’t create broad, product-agnostic Upgrades auto-approval rules. Microsoft supports narrowly scoped feature-update rules that specify the intended product, computer group, and deadline – a broad one can upgrade applicable Windows 10 devices to Windows 11. Two hazards that don’t get enough attention: Run Rule processes existing matching updates too, not just new ones – for Upgrades that can approve older feature updates and trigger large downloads, so review the matching set before running manually. Automatic rules also don’t approve updates whose EULA hasn’t been accepted on the server – a matching rule can leave some updates unapproved silently. On the Advanced tab, review whether new revisions of approved updates auto-approve, and whether updates auto-decline when a revision expires – this is separate from the normal product/classification rule.

Definition Updates are often suitable for automatic approval to the groups that actually use WSUS for Defender intelligence – don’t make All Computers a universal exception without confirming the product and endpoint-management design first.

Step 8: WSUS Approval Deadlines

A WSUS approval deadline (server-side, fixed) is a different system from the Windows Update compliance deadline (modern client policy, relative). Manual approvals let you pick a specific date/time; automatic rules calculate one from a relative offset and time of day. Either way, the result is a concrete deadline – not the Windows Update client’s separate relative-plus-grace-period model.

If the update hasn’t installed when the deadline arrives, the next successful contact can trigger installation as soon as possible, with a forced restart if required – an offline device gets no fresh countdown, the approval is simply already overdue when it reconnects. Don’t rely on “No auto-restart with logged-on users” as complete protection for critical systems; a deadline exists specifically to make installation mandatory by that time. When a device belongs to multiple WSUS groups, don’t assume only the intended group’s deadline is effective – avoid overlapping deadline-bearing approvals, or validate the actual effective behavior before production.

For workstations, a deadline is a compliance backstop after users had a reasonable window to restart normally. For servers, use a deadline only when it’s intentionally aligned with an approved maintenance window – otherwise approve without one and coordinate installation through the maintenance process.

Product, Classification, and Language Governance

The sync scope from the initial wizard has ongoing consequences for database growth, disk usage, and cleanup time. Start with Security Updates, Critical Updates, and Updates; add Definition Updates if WSUS distributes Defender intelligence. Subscribe to Upgrades only when deliberately managing Windows feature rollouts through WSUS, with explicit per-group approval – the same auto-approve hazard from Step 7 applies here. Leave Drivers narrowly scoped unless a defined WSUS-based driver process exists; driver metadata substantially increases sync time and SUSDB load. Match languages to what managed devices and downstream servers actually need, and review annually. Unsubscribing a product stops new sync but doesn’t clean up existing entries – that cleanup wizard mechanics live in WSUS Maintenance (linked in the scope note).

SMB WSUS Configuration Baseline

Separate source configuration from install/restart behavior across three GPOs, rather than duplicating the WSUS URL into every policy:

GPO 1 – common WSUS source (all WSUS-managed computers): intranet update-service and statistics URLs, common TLS/port design, any internet-location policy after impact review.

GPO 2 – workstation behavior (Workstations OU): Automatic Updates profile (A or B above), maintenance/active-hours/restart settings, workstation targeting group, scan-source policy where supported and required.

GPO 3 – server behavior (Servers OU): option 7 or an approved option 3 baseline, server targeting group, no blanket native deadline, no scan-source settings on Server 2016/2019 – apply scan-source only on Server 2022+/2025 after validating the current build/ADMX and testing the resulting four values.

Verify the WSUS Configuration End to End

On a test client, confirm effective policy first:

Check the winning GPO, denied GPOs, security filtering, WSUS URL, AU mode, targeting, scan-source policy, and restart policy in the report. Then confirm the registry state:

Trigger detection through the documented API, then verify asynchronously – not from the command’s return:

Confirm WSUS Last Contact and Last Status Report changed, the requested target group is present, the expected update becomes Needed/Installed, scan source matches the intended class, no direct Windows Update feature upgrade appears unexpectedly, and restart behavior matches the test profile. If the device is still absent after a full day, start troubleshooting rather than continuing to wait, using the WSUS Client Not Reporting guide linked in the scope note.

Finally, run a pilot approval test: approve one low-risk applicable update only to the pilot group, and verify there’s no approval on All Computers, correct download/install behavior, maintenance-window timing, restart, application/service health, and reporting after restart.

FAQ

What ports do WSUS clients use?

Commonly TCP 8530 (HTTP) and 8531 (HTTPS); Microsoft also supports the 80/443 pair. In a TLS-enabled deployment, clients need both 8531 (protected WSUS service traffic) and 8530 (update payloads) – not one or the other.

What’s the difference between client-side and server-side targeting?

Server-side: you manually move machines in the console. Client-side: a GPO tells the machine which group to request. The two modes are mutually exclusive – enabling client-side targeting disables manual console membership until switched back. Client-side scales better for larger environments; server-side gives more explicit per-machine control.

Why are my Windows 11 clients installing updates directly from Microsoft despite WSUS?

Usually a mixed WSUS/Windows Update policy environment where the legacy DisableDualScan setting (which doesn’t work on Windows 11) was relied on instead of the scan-source policy. Configure “Specify source service for specific classes of Windows Updates” and verify all four SetPolicyDrivenUpdateSourceFor... values, not just UseUpdateClassPolicySource.

What happens if a computer is offline when a WSUS approval deadline passes?

It gets no new countdown. The approval is already overdue when it reconnects, and the update can install after the next successful detection cycle – with a forced restart if the update requires one.

Should updates be approved for All Computers or specific groups?

Specific groups, not All Computers – approving broadly bypasses your ring structure and delivers every approved update everywhere at once. Definition Updates are the reasonable exception, since they’re frequent and low-restart-risk, but confirm the product and endpoint-management design first rather than treating it as universal.

Microsoft Documentation

• Configure Group Policy settings for Automatic Updates
• Use Windows Update client policies and WSUS together
• Deploy updates using WSUS
• Approve and deploy updates in WSUS
• WSUS update operations and automatic approvals
• Update Policy CSP
• IAutomaticUpdates::DetectNow
• Modern Windows Update policy recommendations