I've traditionally configured our Windows servers to install updates on the fourth Sunday of each month, followed by an automatic restart to complete the process. Recently, some Server 2022 and Server 2025 systems have stopped installing all pending updates during the same maintenance window. For example, the Malicious Software Removal Tool installs, but the Windows and .NET cumulative updates remain pending until the next scheduled window. Older Windows Server versions are not affected. This is occurring in two separate client environments. Has anyone else seen this behavior, and what is the best way to handle it?
4 Answers
It may also be worth reconsidering whether the Malicious Software Removal Tool needs to be included in the server maintenance window. If the servers already have comprehensive antivirus or managed detection coverage, some administrators deploy that tool separately so it cannot prevent the cumulative updates from starting.
If you’re using Configuration Manager, check the maintenance window against each update’s maximum runtime. The current cumulative Windows and .NET updates may each have a 60-minute maximum runtime, while the Malicious Software Removal Tool can have a much longer limit. If the removal tool runs first and consumes most of the window, Configuration Manager won’t start the remaining updates. A practical fix is to move the removal tool into a separate deployment or collection and run it outside the normal patch window, since it doesn’t require a restart.
Server 2025 has an additional servicing complication. Its checkpoint cumulative update model can stage parts of an update and require a reboot before the main payload is installed, so completing one monthly patch cycle may take two reboot stages. This has been especially noticeable with the Desktop Experience edition; Server Core may behave differently. Extending the maintenance window and allowing chained restarts can help, but mixed Server 2022 and 2025 environments may be easier to manage with separate patching policies.
I’ve seen this behavior on Server 2025 since its initial release, mainly on the Server and Desktop installation rather than Core. We ended up replacing the usual update policy for those machines with a PowerShell-based process that installs updates sequentially and handles the required reboots. Keeping Server 2025 separate from the older server patching workflow may be the cleanest option.
That matches what I’m seeing. I’m also going to make sure the updates are downloaded several hours before the maintenance window, since download time appears to count toward the allowed runtime.