WSUS Configuration: Group Policy, Computer Groups, and Approval Rules

WSUS configuration is where most deployments stall. The server installs, the initial sync completes, and then nothing happens – because WSUS doesn’t push updates, and clients don’t find WSUS until Group Policy tells them where to look. The gap between “sync works” and “clients patch on a controlled schedule” – the core goal of any wsus configuration – is where the classic self-inflicted outages start: uncontrolled approvals, surprise reboots, Windows 11 clients pulling feature updates directly from Microsoft despite an active WSUS deployment.

This guide covers wsus configuration after initial sync: pointing clients at WSUS via Group Policy, designing computer groups and deployment rings, configuring approval rules, and understanding how WSUS approval deadlines actually work – which is different from what most guides describe. There’s also a section on scan-source behavior specific to Windows 10 and 11 that many WSUS configuration guides omit, and that silently breaks patch delivery in mixed-policy environments.

Assumptions and scope

WSUS is installed, the configuration wizard has run, and at least one sync has completed. The console opens and shows update metadata. If you’re not there yet, start with How to Install WSUS on Windows Server.

This article completes the wsus configuration process by setting up the deployment system. For what to do after it’s running – monthly cleanup, SUSDB maintenance, disk reclamation – see WSUS Maintenance: Cleanup, Disk Space, and SUSDB Optimization.

When clients are configured correctly but aren’t appearing in the console, that’s a separate diagnostic problem covered in a dedicated troubleshooting article in this cluster. This guide establishes the targeting; the troubleshooting article diagnoses when targeting doesn’t produce results.

For general Group Policy processing, inheritance, RSOP diagnostics, and gpresult troubleshooting, see Group Policy in Active Directory: How GPO Processing Works. This article covers only the WSUS-specific policy values.

How WSUS control works

Before touching any Group Policy setting, the mental model matters. WSUS has two distinct control planes that operators regularly confuse.

WSUS controls content and approvals. The WSUS 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 Windows Update clients where to look for updates, how often to check, how to behave when updates are found, and (optionally) which WSUS computer group to join.

Both must be configured. 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.

Step 1: Point clients to WSUS with Group Policy

The first step in any wsus configuration is creating a dedicated GPO for WSUS client settings. Don’t bolt these onto an existing GPO that handles other settings – isolating WSUS policy makes troubleshooting faster and reduces scope-of-change risk when you need to modify it.

Apply the GPO to the OU containing the computers you want to manage. Computers, not users – these are machine-level settings.

The WSUS location setting and the recommended automatic-update policy

The wsus configuration GPO path: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update

Specify intranet Microsoft update service location is the setting that directs the client to WSUS. Both fields – detection service and statistics server – should point to the same URL, using the FQDN of your WSUS server.

WSUS commonly uses 8530 for HTTP and 8531 for HTTPS; Microsoft also supports deployments using ports 80 and 443. Using a non-standard port produces connection failures that aren’t obvious from the client’s Windows Update log.

Configure Automatic Updates then controls installation and notification behavior. In this baseline, configure both, but understand that they perform different jobs – the location setting is what makes WSUS targeting work, the AU setting controls how the client acts on what it finds.

Options for Configure Automatic Updates:

• 2 – Notify for download and notify for install – client prompts the user for both steps. Rarely appropriate for managed environments.
• 3 – Auto download and notify for install – useful for servers where you want control over when updates apply.
• 4 – Auto download and schedule the install – the standard choice for workstations. Pair with a scheduled install time outside business hours.
• 5 – Allow local admin to choose setting – defeats the purpose of central management.

For servers: option 3 or 4 with a maintenance window schedule. For workstations: option 4 with a scheduled time. The scheduled day and time matters – set it during guaranteed-off-hours, not “2 AM” on the assumption users go home.

Verify applied policy

After gpupdate /force on a test client, check the registry:

Expected values:

• WUServer = your WSUS URL
• WUStatusServer = your WSUS URL (same value)
• UseWUServer = 1 (under the AU subkey)

If UseWUServer is 0 or absent, the client ignores WSUS. This is the most common wsus configuration mistake and produces clients that don’t appear in the console.

If the policy is set but registry values are empty, run gpresult /h report.html and verify GPO is applying to the machine. For inheritance troubleshooting see Group Policy in Active Directory.

Step 2: Control scan sources on Windows 10 and 11

Many wsus configuration guides omit scan-source behavior on modern Windows clients. This gap matters because it breaks patch delivery silently in environments where WSUS and Windows Update for Business policies coexist.

When mixed WSUS/WUfB policy causes problems

Dual-scan and scan-source problems appear when a device is pointed to WSUS while Windows Update for Business policies, deferrals, or other update-management settings are also applied. In that mixed configuration, some update classes can be scanned from Microsoft services rather than from WSUS unless the scan source is explicitly defined.

The result: clients appear in your WSUS console and get approved updates from WSUS, but also independently pull feature updates, quality updates, or driver updates directly from Microsoft. Your WSUS approvals don’t control what they get from the Microsoft path.

The old approach that no longer works

The legacy Do not allow update deferral policies to cause scans against Windows Update (DisableDualScan) policy is deprecated on Windows 11 and replaced on Windows 10 by the scan source policy. If you’ve configured DisableDualScan and moved to Windows 11 clients, it’s doing nothing.

Configure source service by update class

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 individual update categories independently – Feature Updates, Quality Updates, Driver Updates, and Other Microsoft Updates. For each category, choose: Windows Update, Windows Server Update Services, or Windows Update for Business.

For a pure WSUS environment with no WUfB: set all four to “Windows Server Update Services.”

Verify the registry state

After enabling the scan-source policy, verify that UseUpdateClassPolicySource is set to 1 in:

Treat a missing value as evidence that the policy did not apply correctly rather than as a reason to bypass Group Policy and configure the registry manually.

If you configure both the scan source policy AND Windows Update for Business deferral policies on Windows 10, you won’t receive updates from Windows Update. Don’t stack them.

Review legacy Windows Update policies

Windows 11 introduced a “Legacy Policies” subfolder under Windows Update in Group Policy, flagging policies that are no longer effective on modern clients. Microsoft’s recommendation: review and set stale deferral and notification policies to “Not Configured.”

Audit Update/Quality deferral policies from the WUfB era, notification behavior overrides, and shutdown/restart overrides that predate the deadline model. If these sit at their old values in a GPO applied to Windows 11 clients, they’re either doing nothing or interfering with deadline behavior.

Step 3: Configure computer groups and client-side targeting

Computer groups are a core part of wsus configuration – they control how you approve updates for subsets of machines. Every computer belongs to All Computers automatically. Beyond that, every computer can also belong to multiple custom WSUS groups – multiple membership is supported, but it can make approval behavior harder to reason about because a device receives the effective result of approvals assigned through any of its groups.

For a simple deployment-ring design, assign each device to one primary ring group unless there is a clear operational reason to use overlapping groups.

Server-side targeting

You manually move computers from “Unassigned Computers” into groups through the WSUS console (or via API/script). WSUS tells the client what’s approved based on where the server has placed it.

When it works well: small environments, when group membership maps to a role you control (servers vs workstations), when you want explicit human approval before a machine enters a ring.

When it gets painful: 200+ machines, frequent new deployments, environments where you want Group Policy to handle computer classification automatically.

Client-side targeting

A Group Policy setting tells the client which WSUS group to request membership in. The WSUS server must have “Use Group Policy or registry settings on computers” enabled under Options > Computers.

Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Update

Enable client-side targeting – enter the group name exactly as it appears in the WSUS console. A misspelled or nonexistent name is ignored until a matching group exists.

Traditional detection uses an approximately 22-hour cycle with randomization. A manually requested scan can shorten the wait, but reporting to the console is not instantaneous. If a device is still absent after a full day, begin troubleshooting policy application, connectivity, and Windows Update reporting rather than continuing to wait.

The machine should appear in the WSUS console and, when client-side targeting is configured correctly, be assigned to the requested group. If it remains in Unassigned Computers, verify the targeting mode, target-group name, and applied registry values.

Decision table

Step 4: Design deployment rings

Deployment rings are where wsus configuration produces real operational value – approving updates in stages rather than all at once. The canonical mistake is creating groups but approving to “All Computers” – which bypasses the ring entirely.

Ring 1 – Pilot / IT: 5-10 machines, IT staff and select early adopters. Updates approved first. Soak period: 5-7 days.

Ring 2 – Broad / Production: Remaining workstations. Updates approved after Ring 1 soak. No failures reported from Ring 1 before promoting.

Ring 3 – Critical Servers: Domain controllers, file servers, any system with a formal change window. Updates approved last, with explicit human decision. No broad deadline applied to this group.

Map each ring to a WSUS computer group. The promotion decision – moving from Ring 1 to Ring 2 – should be explicit, not a scheduled timer. Five days and no issues reported is a minimum; the actual signal is “nothing broke and we looked.”

Step 5: Configure approvals and automatic approval rules

Manual approvals

In the WSUS console: Updates > All Updates > filter by “Needed” and “Unapproved.” Select updates, right-click, Approve. Choose which computer groups and what action (Install, Remove, Not Approved).

The ring approach: approve to Ring 1 first. After soak period, approve to Ring 2. After another soak, approve to Ring 3. For security updates, the common SMB cadence is Patch Tuesday + 1-3 days for Ring 1, then Ring 2 one week later, Ring 3 two weeks later.

Automatic approvals

Automatic Approvals are configured under Options in the WSUS console. This is where wsus configuration decisions have the most risk. Rules run when WSUS syncs – if a rule matches, the update is automatically approved to the specified groups.

Useful for: Definition Updates (Windows Defender signatures should auto-approve to all groups immediately), Critical Updates and Security Updates to Ring 1 only.

Dangerous for: Upgrades. Per Microsoft’s deployment documentation, “When selecting the Upgrades classification, be aware that Windows feature updates that get published monthly are also classified as Upgrades. Automatically approving these updates could cause devices to upgrade their OS.” A Windows 10 workstation can be upgraded to Windows 11 by an Automatic Approval rule for the Upgrades classification. Don’t auto-approve Upgrades.

The Default Automatic Approval Rule

WSUS ships with a default rule that is disabled by default. Check it before enabling anything – the out-of-box default approves critical and security updates to All Computers, which bypasses your ring structure entirely.

Step 6: Understand WSUS approval deadlines and restart behavior

Deadlines are one of the easiest ways to cause an unexpected restart in a WSUS environment. The important distinction is that a native WSUS approval deadline is not the same mechanism as a Windows Update for Business compliance deadline.

A WSUS deadline is a fixed date and time

When approving an update in the WSUS console, you can assign a specific deadline – for example, July 15 at 02:00. At that time, the update becomes mandatory for computers covered by that approval.

This differs from Windows Update for Business deadline policies, which use relative values such as a number of days after an update is offered and an additional grace period. Recommendations such as a three-day quality-update deadline and a two-day grace period belong to that policy model, not to the fixed deadline entered in the WSUS approval dialog.

What happens when the deadline arrives

If the update has not yet been installed, the Windows Update client installs it when the deadline is reached. If completing the update requires a restart, the device can be forcibly restarted at the deadline.

A policy such as “No auto-restart with logged on users” should not be treated as protection from a WSUS approval deadline. The purpose of the deadline is to make installation mandatory by the specified time.

What happens to offline computers

An offline computer does not receive a new countdown when it reconnects. If the fixed deadline passed while the computer was offline, the approval is already overdue. The update can install shortly after the computer completes its next successful scan.

Workstation guidance

For workstations, deadlines can provide a compliance backstop after users have had a reasonable opportunity to restart normally. Choose a fixed date and time that accounts for devices that are frequently offline and for the business impact of a forced restart.

Server guidance

For servers, use approval deadlines only when the fixed time is intentionally aligned with an approved maintenance window. Otherwise, approve the update without a deadline and coordinate installation and restart through the server maintenance process.

This baseline does not apply Windows Update for Business compliance-deadline policies to WSUS-managed servers. Any native WSUS deadline is assigned as a fixed date and time when approving a specific update for a specific group.

Long-term wsus configuration: control database and content growth

What you subscribed to in the initial configuration wizard has ongoing consequences. The sync scope controls database growth, disk usage, and cleanup time.

Classifications: subscribe to less

Recommended for most SMB environments: Security Updates, Critical Updates, Definition Updates, Update Rollups.

Add Feature Packs and Service Packs only if you’re managing legacy OS versions that still receive them. Do not subscribe to the Drivers classification. Drivers published through WSUS are often outdated relative to manufacturer direct-download, and the Drivers classification adds thousands of entries to the database. SUSDB bloat correlates directly with driver sync enabled.

The Upgrades trap (repeated because it matters): auto-approve + Upgrades = unintended OS upgrades. Subscribe to Upgrades only if you’re deliberately managing Windows feature update rollouts through WSUS, and only with explicit approval per group.

Languages and products

Every language you subscribe to multiplies the content downloaded for each update. Subscribe only to languages present in your environment and review annually.

The product subscription list is where the biggest cleanup opportunities hide. Audit it when new products are added and when products are retired. Unsubscribing stops new updates from syncing but doesn’t clean up existing entries – that’s the cleanup wizard’s job, covered in WSUS Maintenance.

SMB baseline

The recommended SMB wsus configuration baseline uses two GPOs: one for workstations, one for servers. Different scheduling, different restart behavior, same targeting to the same WSUS server.

Workstation WSUS GPO – applies to the Workstations OU:

Server WSUS GPO – applies to the Servers OU:

No deadline policy on the Server GPO – any native WSUS deadline for servers is assigned as a fixed date and time at approval, not via blanket policy.

Verification checklist

On a test workstation after applying the GPO:

Confirm the result through the Windows Update operational log, the registry, and the WSUS console. If the device is still absent after a full day, begin troubleshooting policy application, connectivity, identity, and Windows Update reporting.

FAQ

What ports do WSUS clients use for wsus configuration?

WSUS commonly uses 8530 for HTTP and 8531 for HTTPS. Microsoft also supports deployments using ports 80 and 443. Firewall rules must allow TCP 8530 or 8531 from all WSUS-managed clients to the WSUS server. Using a non-standard port produces failures that aren’t obvious from the client side.

How long does it take for a client to appear after GPO is applied?

Traditional detection uses an approximately 22-hour cycle with randomization. After gpupdate /force and UsoClient StartScan, console appearance usually takes 15-30 minutes under normal conditions. If the device is still absent after a full day, begin troubleshooting rather than continuing to wait.

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

Server-side: you manually move machines in the WSUS console. Client-side: a GPO tells the machine which group to request. Client-side scales better and handles new machines automatically. Server-side gives more explicit control per machine. Most SMB environments with 50+ machines benefit from client-side targeting.

Can a computer be in multiple WSUS groups?

Yes. Multiple group membership is supported. The device receives the effective result of approvals assigned through any of its groups. For a simple deployment-ring design, assign each device to one primary ring group to keep approval logic predictable.

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

This appears in mixed WSUS/WUfB environments. The legacy DisableDualScan setting doesn’t work on Windows 11. Configure “Specify source service for specific classes of Windows Updates” via Group Policy, then verify that UseUpdateClassPolicySource = 1 in the registry. A missing value means the policy did not apply correctly.

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

A WSUS approval deadline is a fixed date and time. If the computer is offline when that deadline passes, the update is already overdue when the computer returns. After the next successful detection cycle, Windows can install the update as soon as possible and may restart the machine if the update requires it. The computer does not receive a new countdown.

Should updates be approved for All Computers or specific groups?

In any wsus configuration, approve to specific groups, not All Computers. Approving to All Computers bypasses your ring structure and delivers every approved update to every machine simultaneously. The exception: Definition Updates (Defender signatures) can reasonably be approved to All Computers automatically in any wsus configuration, as they’re released multiple times per week and don’t require a soak period.

Microsoft documentation

• Configure WSUS – Microsoft Learn
• Use Windows Update client policies and WSUS together – Microsoft Learn
• Deploy updates using WSUS – Microsoft Learn