[MECM 2211] Software Updates stuck on Waiting to install

[CHiLL]

For a long time now and across multiple versions of MECM/SCCM, I've noticed that our servers and desktops will often get stuck trying to install software updates, specifically on the "Waiting to install" phase.

 

For example, I have a Server 2019 server which is stuck trying to install the 2022-12 Cumulative update for .NET and also the 2022-12 Cumulative update for Server 2019.

I have another server (Server 2022) that is currently stuck on "Waiting to install" the 2022-09 .NET update, as well as the 2022-12 updates for .NET and Server 21H2.

 

I have my SUP configured to check for updates monthly, every Wednesday after Patch Tuesday and the ADR is deployed to my server group. I also have a collection that contains all my server, with a maintenance window configured for Friday, Saturday and Sunday nights between 10pm and 7am.

 

This issue doesn't appear to be affecting desktops, though I'd need to confirm that. I can't see any configuration differences, aside from maintenance window time slots between the two configurations.

 

Does anyone know how to resolve this, or has anyone come across this before?

[Steve21]

For a long time now and across multiple versions of MECM/SCCM, I've noticed that our servers and desktops will often get stuck trying to install software updates, specifically on the "Waiting to install" phase.

 

For example, I have a Server 2019 server which is stuck trying to install the 2022-12 Cumulative update for .NET and also the 2022-12 Cumulative update for Server 2019.

I have another server (Server 2022) that is currently stuck on "Waiting to install" the 2022-09 .NET update, as well as the 2022-12 updates for .NET and Server 21H2.

 

I have my SUP configured to check for updates monthly, every Wednesday after Patch Tuesday and the ADR is deployed to my server group. I also have a collection that contains all my server, with a maintenance window configured for Friday, Saturday and Sunday nights between 10pm and 7am.

 

This issue doesn't appear to be affecting desktops, though I'd need to confirm that. I can't see any configuration differences, aside from maintenance window time slots between the two configurations.

 

Does anyone know how to resolve this, or has anyone come across this before?

 

Normally those kind of things happen as you mentioned regarding clashes in maintenance windows

 

I know for example it will look at the whole “possible” install time before comparing it to the Window

 

So for example if you have the server update set that it “can” run for 600 minutes before timing out, that then “needs” a 10 hour maintenance window; even if it takes 30 seconds to actually install

 

So in that scenario it’ll look on Friday and go, nah only 9 hours. Saturday window comes, nah on 9 hours repeat!

 

Do you have server updates set specifically for timeouts?

 

Steve

[CHiLL]

Normally those kind of things happen as you mentioned regarding clashes in maintenance windows

 

I know for example it will look at the whole “possible” install time before comparing it to the Window

 

So for example if you have the server update set that it “can” run for 600 minutes before timing out, that then “needs” a 10 hour maintenance window; even if it takes 30 seconds to actually install

 

So in that scenario it’ll look on Friday and go, nah only 9 hours. Saturday window comes, nah on 9 hours repeat!

 

Do you have server updates set specifically for timeouts?

 

Steve

Thanks for your reply. I've amended the rule to run for 12 hours (8pm - 8am) over weekends, so I'll see how that goes.

 

I can't seem to see any options regarding timeouts, like I usually see on app deployments. As for the software availablity and deadline, they're set to asap/7 days respectively.

[Steve21]

It’s set on the actual updates, so if you go to the software updates tab, and look at the properties of one, under max run time what’s it set to? (For one that isn’t installing)

 

If that’s showing high then check under admin-sites-site comp-updates-max runtime etc as to what you have set as the defaults

 

As a side note, even 12 could be an issue if it’s high, for example same scenario if it’s 600 mins (10hours), one update installs and takes 2hours 1 min, next update only has 9.59 left and goes nahhhh

 

But yeah check there first as might not be related!

 

Steve

[CHiLL]

It’s set on the actual updates, so if you go to the software updates tab, and look at the properties of one, under max run time what’s it set to? (For one that isn’t installing)

 

If that’s showing high then check under admin-sites-site comp-updates-max runtime etc as to what you have set as the defaults

 

As a side note, even 12 could be an issue if it’s high, for example same scenario if it’s 600 mins (10hours), one update installs and takes 2hours 1 min, next update only has 9.59 left and goes nahhhh

 

But yeah check there first as might not be related!

 

Steve

So the server with three pending updates (including the September .NET update) has these updates and run times:

KB5017501 has a maximum run time of 60 minutes (reported 96% comliance)

KB5021095 has a maximum run time of 60 minutes (reported 85% compliance)

KB5021249 has a maximum run time of 60 minutes (reported 85% compliance)

 

What's the best practise for maintenance windows and least disruption? Possibly a full 24 hour windows on Saturday?

 

Edit: The SUP is configured for:

Windows Windows feature updates: 120 minutes

Office 365 updates and non-feature updates for Windows: 60

All other software updates outside these categories: 10

Edited January 23, 2023 by CHiLL

[CHiLL]

It appears that this was caused due to an Orchestration Group, which was being used and I didn't realise. Assets and Compliance > Orchestration Groups. There was a group created which has apparently evolved from the Server Groups feature. This orchestration group has it's own timeout settings on the General tab, which were set to 60 minutes for individual servers and 120 minutes for the whole group by default for me. Since these timeout settings aren't linked to the SUP timeout settings, it meant that this time period was shorter than the time the updates needed to install. I've set those to 180 minutes for one server and 360 minutes for the group. By default, it should honour the existing maintenance windows. Once I configured those times in the orchestration group, the updates started installing over the next couple of hours.