How to Manage Windows Server Updates: Manual, Automatic, and WSUS

Overview

Windows updates patch security vulnerabilities, fix bugs, and occasionally introduce new features. On a production server, managing those updates carelessly can cause downtime, driver conflicts, or broken applications. This article covers how to handle Windows Server updates properly — whether you’re patching a single VPS manually or rolling out patches across multiple machines using WSUS (Windows Server Update Services).

Most server outages I’ve seen from updates come down to one thing: updates applied without a maintenance window, without a snapshot, and without knowing what’s actually being installed. This guide is designed to fix that habit.

It applies to Windows Server 2016, 2019, and 2022. Some PowerShell syntax differs on 2016 — I’ll call those out where relevant.

Prerequisites

• Administrator or Local Administrator access to the Windows Server instance
• PowerShell 5.1 or later (built into Windows Server 2016+)
• Internet connectivity from the server, or access to a WSUS server on your internal network
• A recent backup or snapshot of the server before applying updates — non-negotiable on production
• For WSUS setup: a separate Windows Server instance with at minimum 10 GB free disk space for the update catalogue (40–80 GB is more realistic in practice)
• Outbound access to windowsupdate.microsoft.com and update.microsoft.com on port 443 if not using WSUS

Method 1: Manual Updates via Windows Update Settings

This is the right approach for a single server or a quick one-off patch. It’s straightforward but gives you full visibility over what’s being installed.

1. Open Server Manager, then click Local Server in the left panel.
2. Find Windows Update in the properties panel. Click the linked status text next to it (e.g. “Not configured” or “Last checked…”).
3. In the Windows Update settings window, click Check for updates.
4. Review the listed updates before installing. Pay attention to anything marked as a cumulative update or feature update — those take longer to install and almost always require a reboot.
5. Click Install now once you’re ready. Schedule the reboot for your next maintenance window if prompted.

📝 Note: On Windows Server Core (no GUI), this method isn’t available. Use PowerShell instead — see Method 2.

Method 2: Managing Updates with PowerShell

PowerShell gives you more control and is essential for Server Core deployments or automation. The PSWindowsUpdate module is the most reliable way to handle this — it’s a community module but it’s been widely used in enterprise environments for years and is actively maintained.

Step 1: Install the PSWindowsUpdate module

Install-Module -Name PSWindowsUpdate -Force -Scope AllUsers
Import-Module PSWindowsUpdate

📝 Note: You may need to set your execution policy first. Run Set-ExecutionPolicy RemoteSigned in an elevated PowerShell session if the install fails with a script restriction error.

Step 2: Check available updates

Get-WindowsUpdate

This lists all available updates with their KB numbers, size, and titles. I’d always run this before installing so you know exactly what’s queued.

Step 3: Install all available updates

Install-WindowsUpdate -AcceptAll -AutoReboot

⚠ Warning: The -AutoReboot flag will reboot the server immediately after updates finish — without prompting. Only use this during a scheduled maintenance window. Drop that flag if you want to control the reboot manually.

Step 4: Install only security updates (recommended for production)

Install-WindowsUpdate -Category 'Security Updates' -AcceptAll -AutoReboot

Limiting updates to security patches reduces the risk of a cumulative update pulling in changes you haven’t tested. In my experience, this is what most sysadmins do on production boxes — security patches on a regular cycle, feature/cumulative updates tested first in staging.

Step 5: Check update history

Get-WUHistory | Select-Object -First 20 | Format-Table Date, Title, Result

Method 3: Setting Up WSUS for Centralised Patch Management

If you’re running multiple Windows servers — whether on a Dedicated Server environment or across a cluster — WSUS lets you approve, schedule, and audit updates from a single console. Clients pull updates from your WSUS server instead of hitting Microsoft’s servers directly, which also reduces outbound bandwidth.

Step 1: Install the WSUS role

Run this on the server you want to act as your WSUS host. Replace D:WSUS with your chosen content directory — make sure the drive has plenty of space.

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools
& 'C:Program FilesUpdate ServicesToolsWsusUtil.exe' postinstall CONTENT_DIR=D:WSUS

Step 2: Open the WSUS console and run the configuration wizard

1. Open Server Manager → Tools → Windows Server Update Services.
2. The configuration wizard launches automatically on first run. Click through to Choose Upstream Server.
3. Select Synchronize from Microsoft Update unless you have an upstream WSUS in a larger hierarchy.
4. On the Choose Products screen, select only the Windows Server versions you’re actually running. Selecting everything massively inflates disk usage.
5. On Choose Classifications, at minimum select Critical Updates and Security Updates. Add Definition Updates if you’re running Windows Defender on your servers.
6. Set a synchronisation schedule — daily at an off-peak time works well for most setups.
7. Click Begin Initial Synchronization. This first sync can take several hours depending on how many products you selected.

Step 3: Point client servers at WSUS using Group Policy

On each client server (or via a GPO applied to an OU), configure the following registry settings. Replace http://wsus-server:8530 with your actual WSUS server hostname and port.

$wsusServer = "http://wsus-server:8530"

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
  -Name "WUServer" -Value $wsusServer -Type String

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate" `
  -Name "WUStatusServer" -Value $wsusServer -Type String

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU" `
  -Name "UseWUServer" -Value 1 -Type DWord

Restart-Service wuauserv

Step 4: Approve updates in the WSUS console

WSUS doesn’t auto-approve updates by default — you need to explicitly approve them for each computer group. In the WSUS console, go to Updates → All Updates, filter by Unapproved, review the list, right-click and select Approve. Assign to the relevant computer group and set the deadline.

📝 Note: Create separate computer groups for staging and production. Approve to staging first, wait a few days, then approve to production. This one habit has saved me from rolling back a broken update more than once.

Deferring Updates on Windows Server

If you need to delay a specific update without disabling Windows Update entirely, you can configure deferral periods via Group Policy or registry. On Windows Server 2019 and 2022:

# Defer quality updates by 7 days
Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU" `
  -Name "DeferQualityUpdates" -Value 1 -Type DWord

Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU" `
  -Name "DeferQualityUpdatesPeriodInDays" -Value 7 -Type DWord

⚠ Warning: Deferring updates is a short-term tool, not a long-term strategy. Servers left unpatched for weeks become a real liability, especially on public-facing infrastructure.

Common Issues & Troubleshooting

Windows Update stuck at 0% or hangs during download

This is usually a corrupt update cache. The fix is to clear the SoftwareDistribution folder, which forces Windows Update to re-download fresh metadata.

Stop-Service wuauserv
Stop-Service cryptSvc
Stop-Service bits
Rename-Item -Path C:WindowsSoftwareDistribution -NewName SoftwareDistribution.old
Rename-Item -Path C:WindowsSystem32catroot2 -NewName catroot2.old
Start-Service wuauserv
Start-Service cryptSvc
Start-Service bits

After running this, check for updates again. The old folders can be deleted once updates are working.

Error 0x80072EFE or 0x80072EE2 — cannot connect to Windows Update

These are network connectivity errors. Check that the server can reach windowsupdate.microsoft.com on port 443. If you’re behind a firewall, the outbound rule may be blocking it. Also check that your DNS is resolving correctly — a misconfigured DNS server is a surprisingly common cause of this on newly provisioned machines.

Test-NetConnection -ComputerName windowsupdate.microsoft.com -Port 443

WSUS clients not appearing in the console

After pointing a client at WSUS, it can take up to 15 minutes to check in. If it still doesn’t appear, force a detection cycle manually on the client:

wuauclt /detectnow
# On Windows Server 2016+ this is more reliable:
UsoClient StartScan

Also double-check the UseWUServer registry value is set to 1 and that the WSUS service is running on the server.

Update fails to install and rolls back

Check the CBS (Component Based Servicing) log for the actual error. It’s far more useful than the generic Windows Update error code.

Get-Content C:WindowsLogsCBSCBS.log | Select-String "FAIL|ERROR" | Select-Object -Last 50

A common cause is a corrupted system image. Run this before retrying the update:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

WSUS disk fills up unexpectedly

WSUS accumulates superseded updates that are no longer needed. Run the built-in cleanup wizard regularly: in the WSUS console go to Options → Server Cleanup Wizard and run all cleanup options. On large deployments I’d schedule this monthly via PowerShell:

Invoke-WsusServerCleanup -CleanupObsoleteUpdates -CleanupUnneededContentFiles -DeclineExpiredUpdates -DeclineSupersededUpdates