Servers "missing" their Maintenance Windows to install Software Updates.

Question

In my current place of work, we utilise monthly ADRs to automate the deployment of updates to our servers - this happens on the 1st of each month. The servers are grouped and have their own 4 hour maintenance windows on Sunday mornings.

From reviewing this month's deployments approximately 40% of servers are in the pending state of waiting for the next MW. I've checked a few of these servers and cannot really piece together why they are not executing the installs. The servers have downloaded the update binaries into CCM Cache well in advance of the MWs.

So taking this server for example, it has a MW on the third sunday of the month which is 15th Nov 2020 from 01:00 - 05:00

The events in the Updates Deployment log doesn't make too much sense to me:

Currently in Software Center it is in the "Waiting to Install" state:

Any guidance is appreciated.

Answer 1

@CS82

Thank you for posting in Microsoft Q&A forum.

As we mentioned that 40% of servers are in the pending state of waiting for the next MW,does this mean that the remaining 60% on our server succeeded?If so,this phenomenon is really weird,from the situation from our description,our mw is recognized. Have we compared the difference between the failed one with successful one?

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hi @Fiona Yan-MSFT ,

I have not made any objective comparisons between a successfully patched server and one of the "pending" servers, I checked the relevant settings/configuration on the actual server in question so feel it is somewhat moot to check a working server, if that makes sense? Our overall setup is fairly straight forward; servers have one recurring maintenance window, deployments are available at the beginning of the month so often weeks elapse before the servers' MW (so can't really say it was insufficient time for synchronising/downloading binaries, etc).

Answer 3

Hi,

The MW takes into every CI state into account. This includes downloading, installing and reboots. If the total duration exceeds, the trigger will wait for next window to be available that is large enough to accommodate the run time. Try reducing the number of updates or increasing the MW window.

Answer 4

@Rahul Jindal [MVP] - It is literally just a single cumulative update for this month, the update is over a gig in size but was downloaded into CCMCache way before the MW even kicked off.

The MW is four hours long, the update has a max runtime of 60 minutes.

Answer 5

Hi,

That is not what the log says. According to the log you shared, ciStateDownloading triggered when the MW kicked in at 0100. That is the correct and expected behavior for a MW. As for the number of applicable updates is concerned, CU shouldn't require 4 hours to install. I am with you on that. However, it is not clear how many updates were actually scanned as applicable. As far as I know there are multiple Server 2016 updates released in Nov'20. Unless you are certain that you deployed only 1. Also, what is the OS composition for the remaining 60% of the servers? Are they also all Server 2016?