Forum Discussion
RDS stops responding after Sept. 2026 security updates
Hi All,
I have one last Windows Server 2012 R2 ESU VM in PROD, used for a legacy SQL Server / Video / Audio solution.
- Since installing KB5123066:
- RDP cannot connect to the VM
- The Windows Desktop is unstable
- File Explorer is unresponsive
- Windows Update services will not start
As per: https://learn.microsoft.com/en-us/windows/release-health/resolved-issues-windows-8.1-and-windows-server-2012-r2#4981msgdesc
Since Windows Update services won't start, we can't deploy the fix (KB5129243) through normal means.
Attempts so far:
- KIR (Known Issue Rollback) via GPO — deployed the Windows 8.1 and Windows Server 2012 R2 KB5123066 260911_18477 Known Issue Rollback.msi, scoped a GPO to the VM with the corresponding policy set to Disabled, ran gpupdate /force. No change in behavior.
- Uninstall KB5123066 in Safe Mode with Networking — fails, Windows rolls back to KB5123066.
- Install KB5129243 in Safe Mode with Networking — fails, Windows rolls back.
- Offline DISM servicing from WinPE (booted from Server 2012 R2 ISO):
- DISM /Image:C:\ /Get-Packages shows several RollupFix package versions in inconsistent states — one Superseded, one Install Pending, one Staged, all dated the same day — suggesting a stuck servicing transaction from the repeated rollback attempts.
- DISM /Image:C:\ /Cleanup-Image /RevertPendingActions completes successfully and queues a revert for next boot.
- On reboot, the VM sits at "Getting Windows ready / Don't turn off your computer" and eventually returns to the same symptoms — no change.
- Re-running Get-Packages afterward returns Error 3017: The requested operation failed. A system reboot is required to roll back changes made — the offline image is apparently now stuck mid-transaction and won't let us query or modify it further.
- A second full boot cycle triggers the same "Getting Windows ready" screen again, but symptoms remain unchanged afterward and error 3017 persists.
We do have backups of the VM prior to KB5123066, but it is not a straightforward rollback due to SQL Db/Transaction log restores as well for the AV solution (which is out of support).
Given the CBS transaction now appears stuck (error 3017 not clearing even after two full boot/revert cycles), I suspect further offline DISM attempts risk making things worse rather than better.
Before we escalate to Microsoft Support for Business as the KB suggests, has anyone resolved this same stuck-transaction state, or found a way to clear error 3017 on an offline 2012 R2 image without a pre-patch backup to fall back on?
Thanks in advance.
Steve
Your symptoms match Microsoft’s documented September 2026 RDS issue from KB5123066, and Microsoft lists KB5129243 as the resolution. However, the repeated rollback plus DISM error 3017 means the machine now has an incomplete servicing transaction; it is no longer just an RDS configuration problem. Do not delete pending.xml, rename WinSxS, or force package removal, because those unsupported edits can make recovery harder. Preserve a VM checkpoint or backup and copy SQL backups and transaction logs to separate storage. Then open a Microsoft support case and provide CBS.log, DISM.log, the package-state output, rollback timestamps, and the release-health reference. Since this is a production Server 2012 R2 ESU system, the safest recovery path may be restoring the pre-update VM in isolation, applying the resolved update there, validating RDS and the application, and then recovering SQL data using the database procedure. KIR will not repair a servicing stack already stuck mid-transaction.
1 Reply
Your symptoms match Microsoft’s documented September 2026 RDS issue from KB5123066, and Microsoft lists KB5129243 as the resolution. However, the repeated rollback plus DISM error 3017 means the machine now has an incomplete servicing transaction; it is no longer just an RDS configuration problem. Do not delete pending.xml, rename WinSxS, or force package removal, because those unsupported edits can make recovery harder. Preserve a VM checkpoint or backup and copy SQL backups and transaction logs to separate storage. Then open a Microsoft support case and provide CBS.log, DISM.log, the package-state output, rollback timestamps, and the release-health reference. Since this is a production Server 2012 R2 ESU system, the safest recovery path may be restoring the pre-update VM in isolation, applying the resolved update there, validating RDS and the application, and then recovering SQL data using the database procedure. KIR will not repair a servicing stack already stuck mid-transaction.