Unintended Automatic Upgrade of Windows Server 2019/2022 to Windows Server 2025 via Windows Update
Microsoft inadvertently published the Windows Server 2025 upgrade package to Windows Update, causing Windows Server 2019 and 2022 systems with automatic or loosely controlled update policies to perform an unsolicited in-place major OS upgrade. Microsoft subsequently acknowledged and resolved the issue on their end. Affected servers report 'Windows Server 2025' in winver and System Properties after a routine patch cycle with no administrator approval. Rollback options include the 'Go back' recovery option (available within 10 days of upgrade), restoring from a pre-upgrade hypervisor snapshot or backup, or — where no rollback is feasible — assessing compatibility and licensing for retaining Server 2025. Immediate mitigation requires pausing automatic update approvals in WSUS, Windows Update for Business, or RMM tooling to prevent further upgrades across the fleet.
Indicators
- winver or System Properties dialog shows 'Windows Server 2025' on a host that was previously Server 2019 or 2022
- Get-ComputerInfo | Select-Object WindowsProductName returns 'Windows Server 2025' after a patch cycle where no upgrade was planned
- Patch management or RMM console shows Windows Server 2025 listed as the installed OS on previously Server 2019/2022 nodes
- Admins and MSPs report widespread unexpected OS upgrades appearing across managed endpoints following a Windows Update cycle
- Administrators report unsanctioned OS-level upgrade appearing in Windows Update history
Likely causes
- Microsoft inadvertently made the Windows Server 2025 upgrade package available through Windows Update channels, causing it to be delivered to Server 2019/2022 systems with automatic or uncontrolled update policies
- Patch management tooling (e.g., WSUS, RMM platforms) propagated the erroneous Server 2025 upgrade to managed endpoints without operator intervention because no upgrade-class approval gate was in place
- Absence of upgrade-blocking controls — Windows Update for Business upgrade deferral policies, WSUS explicit approval workflows, or RMM exclusion rules — allowed the major version upgrade to proceed without administrator action
Diagnostic steps
-
Run 'winver' or 'systeminfo | findstr /B /C:"OS Name"' on potentially affected servers to confirm whether the unexpected upgrade to Server 2025 has occurred.Confirms whether each system has been upgraded and establishes initial scope of affected machines.
-
Review Windows Update history via Settings > Windows Update > Update History, or run 'Get-WinEvent -LogName System | Where-Object {$_.Id -eq 19 -or $_.Id -eq 20}' to find recent update installation events.Identifies the specific update package that triggered the OS upgrade and the timestamp of the change.
-
Audit all servers via WSUS console, RMM platform, or Active Directory for OS version to determine the full scope of affected systems.Determines how many and which servers were upgraded unexpectedly, enabling prioritisation of remediation.
-
Check WSUS or patch management approval logs to determine whether the Server 2025 upgrade was auto-approved or bypassed the approval workflow entirely.Establishes root cause related to patch management configuration and informs prevention measures.
-
Inventory all managed servers via RMM or patch management console and filter for any nodes reporting Windows Server 2025 as the current OSScopes the full extent of the incident across the managed fleet before beginning remediation to avoid missing affected servers
Resolution path
- 1. IMMEDIATELY pause or suspend automatic Windows Update approvals for all Server 2019/2022 systems in WSUS, Windows Update for Business, or your RMM patch management tool to prevent additional unintended upgrades while the incident is contained.
- 1a. If the upgrade occurred within the last 10 days: check Settings > System > Recovery > 'Go back' to revert to the previous OS version — this preserves installed roles and data while reverting OS binaries (~1 hour). Confirm the window has not expired before attempting.
- 1b. After any rollback via 'Go back', immediately apply approved cumulative updates for the restored OS version to restore security posture, then validate all roles and services.
- 2. For servers where the upgrade has occurred AND a pre-upgrade hypervisor snapshot exists: restore from snapshot — this is the fastest and most reliable rollback path (30–60 minutes per server). Confirm OS version post-restore with: Get-ComputerInfo | Select-Object WindowsProductName
- 3. For servers without a snapshot but with a Windows Server Backup or third-party backup restore point predating the upgrade: restore from backup (1–4 hours per server). Validate all roles and services after restore.
- 4. For servers with no usable backup where rollback is not feasible: assess application and role compatibility with Windows Server 2025, validate licensing compliance (Windows Server 2025 requires separate licensing), and escalate to Microsoft Support citing the widely reported unintended upgrade incident. Re-imaging may be required (4–8 hours per server).
- 5. Monitor Microsoft's known issue tracker and BleepingComputer/vendor advisories for the official resolution or update retraction notice. Once confirmed, verify the offending upgrade package has been removed from the Windows Update catalog or declined/deleted in WSUS before resuming normal patching.
- 6. Re-baseline all Server 2019/2022 systems that were NOT upgraded: re-confirm OS version, re-enrol in approved update rings with explicit approval workflows, and document the incident in your change management system.
Prevention
- Configure WSUS or Windows Update for Business with explicit approval workflows requiring administrator sign-off before any feature upgrade or major OS version update is deployed to production servers — never enable automatic approval of upgrade-class updates
- Implement upgrade deferral policies via Group Policy (Computer Configuration > Administrative Templates > Windows Components > Windows Update) to prevent major version upgrades from being automatically downloaded and installed on servers
- Take hypervisor-level snapshots or verified backup restore points for all production servers immediately before each patch cycle to enable rapid rollback in the event of an unintended or breaking change
- Subscribe to Microsoft's known issue RSS feed, BleepingComputer, and vendor security advisories to receive early warning of erroneous updates before they reach production, enabling proactive blocking in WSUS or RMM
Tools
- winver — GUI OS version check
- systeminfo — command-line OS and patch level details
- Get-ComputerInfo / Get-HotFix — PowerShell OS and update inventory
- WSUS / Windows Update for Business — update approval and blocking
- CBS.log at C:\Windows\Logs\CBS\CBS.log — servicing and upgrade activity log
- Get-WindowsUpdateLog — generates human-readable Windows Update log
- RMM platform / patch management console — fleet-wide OS version inventory
- Hypervisor snapshot tool / Windows Server Backup — rollback
- Get-WinEvent / Event Viewer — Windows Update installation history review