Applying Windows Updates to a production server carries more risk than updating a PC — a failed update can take a server offline, and an unplanned restart during business hours causes real disruption. Done carefully, patching is safe and essential. Here is the right approach.
Before You Start
- Take a snapshot or backup first. If the server is a VM, take a snapshot before patching — this is a fast rollback option if an update causes problems. For physical servers, ensure a recent backup exists.
- Check for active users and services. Run
query sessionto see who is logged in. Check for running batch jobs, backups, or database operations that should not be interrupted. - Choose a maintenance window. Schedule patching during off-peak hours. Sunday night or early morning minimises disruption.
- Know your rollback plan. If the server does not come back cleanly, how will you recover? Snapshot, bare metal restore, or out-of-band console access — confirm which applies.
Applying Updates via Windows Update (GUI)
- Open Settings → Windows Update (or Server Manager → Local Server → Windows Update)
- Click Check for updates
- Review the updates listed — cumulative updates, .NET updates, and driver updates are standard. Be cautious about preview updates on production servers — these are optional and less thoroughly tested.
- Click Download and install
- Wait for downloads to complete, then click Restart now when prompted — or schedule the restart for a time that suits you
Applying Updates via PowerShell
The PSWindowsUpdate module is not built in but is the standard way to manage updates via PowerShell:
# Install the module (once)
Install-Module -Name PSWindowsUpdate -Force
# Check available updates
Get-WUList
# Install all updates
Install-WindowsUpdate -AcceptAll -AutoRebootThe -AutoReboot flag allows the system to reboot automatically if required. Remove this flag if you want to control the reboot timing manually.
For built-in tools (no extra module required):
# Start Windows Update and download/install via COM object
$updateSession = New-Object -ComObject Microsoft.Update.Session
$updateSearcher = $updateSession.CreateUpdateSearcher()
$updates = $updateSearcher.Search("IsInstalled=0")
Write-Host "Updates available: $($updates.Updates.Count)"Deferring Updates on Critical Servers
For servers where immediate patching is too risky, configure a deferral policy:
- Go to Settings → Windows Update → Advanced options
- Under Choose when updates are installed, set a delay (up to 35 days for quality updates)
This is also configurable via Group Policy at Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage end user experience. A staging approach — patch a test or dev server first, then apply to production a week later — is a sensible middle ground for most environments.
Checking What Was Installed
# List recently installed updates
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10 HotFixID, Description, InstalledOnAfter patching, compare this against Microsoft’s security update documentation for the month to confirm all critical updates were applied.
After the Restart — Verify Everything Is Running
Following a post-update restart:
- Check services:
Get-Service | Where-Object {$_.StartType -eq 'Automatic' -and $_.Status -ne 'Running'} - Check Event Viewer System log for startup errors
- Test the applications the server hosts — web server, database, line-of-business application
- Verify network connectivity if the server hosts network services
- Confirm uptime:
(Get-Date) - (Get-CimInstance Win32_OperatingSystem).LastBootUpTime
Failed Updates — How to Recover
If a server fails to boot or behaves incorrectly after patching:
- Rollback via snapshot (VMs): revert to the pre-patch snapshot immediately
- Uninstall the update: boot to the Advanced Startup Options (F8 or via recovery media) → Uninstall Updates, or use
wusa.exe /uninstall /kb:KBXXXXXXX /quiet /norestart - Windows Recovery Environment: accessible via boot media or PXE — use System Restore or Startup Repair
