Change in Windows Update Installation behavior affecting Sever 2022, 2025
Hi, I have always configured our Windows servers to install updates on the fourth Sunday of each month, followed by a restart policy to finish the installation. Lately, however, Windows fails to install all pending updates in a single run. Instead, only one…
Hi, I have always configured our Windows servers to install updates on the fourth Sunday of each month, followed by a restart policy to finish the installation. Lately, however, Windows fails to install all pending updates in a single run. Instead, only one update is installed at a time (e.g., only the Malicious Software Removal Tool), while the cumulative updates for Windows and .NET remain pending until the next scheduled maintenance window. This behavior only affects Windows Server 2022 and Server 2025; older versions are updating without any issues. Has anyone else experienced this? It is currently affecting two different client environments I manage.
Collected discussion
I don't know if it's always been the case, but this was called out in one of the update articles, there are 2x reboots required due to the .NET update. Ref: Windows 11's biggest updates may need multiple reboots, but that's normal, don't force shutdown Windows Server 2022 and 2025 Update Issues - Microsoft Q&A
Sounds like you're using SCCM. You have issues with the size of your maintenance window not fitting the "maximum run time" of the updates in question. 2026-07 Cumulative Update for Microsoft server operating system version 21H2 for x64-based Systems (KB5099540) has a maximum runtime of 60 minutes. 2026-07 Cumulative Update for .NET Framework 3.5, 4.8 and 4.8.1 for Microsoft server operating system version 21H2 for x64 (KB5102206) has a maximum runtime of 60 minutes. Windows Malicious Software Removal Tool x64 - v5.143 (KB890830) has a maximum runtime of 420 minutes. I believe SCCM may install starting with the longest runtime--not sure about that. But regardless, after the MSRT finishes, if there is less than 60 minutes left in the maintenance window, it won't start the remaining updates. If you're going to run the MSRT, put it in its own collection and run it outside of maintenance window, because it doesn't require a reboot.
I haven't personally, but I also do updates using PS.
Moving it out of your main patch collection is the cleanest fix.. The Server 2025 behavior is a separate issue. Microsoft changed the update servicing model with Server 2025 to use checkpoint cumulative updates. Some updates now stage to a temporary location and require a reboot before the main install payload can execute. That means a single monthly run can require two complete reboot cycles to fully apply. Very annoying. This only shows up on the Desktop Experience install. Core doesn't have the same issue, which is why you may see it on some machines and not others if your environment is mixed. A few ways people are handling it are to extend your maintenance window to accommodate two reboot cycles and chain them. Or do what picklednull mentioned and pull Server 2025 out of your WSUS-driven policy entirely and handle it with PSWindowsUpdate, which manages sequential installs and auto-reboots without you having to engineer the window timing manually. A lot of shops managing mixed 2022/2025 environments have split their approach, WSUS for older servers, PS script for 2025.
This has been happening since RTM on Server 2025, but I've never seen it occur on 2022. And it only happens on SAD ("Server and Desktop") Edition, not Core. I replaced the WSUS policies with a PowerShell script that handles patching for Server 2025.
My question is why do you run the malicious removal tool in servers? I assume you already have an active mdr/antivirus