Coming into a new environment it’s fun to see all kinds of new errors and new ways that SCCM has difficulty with things. Moving from a small (~2000 computers) to a larger (~15000 computers) seems to make this even more interesting.
Here’s an example of something that we didn’t see in my previous environment.
Last night was the night that our first large test group had reboots forced upon them for this month’s Windows patches. The deployment went fairly well ~500 installed correctly, but there were still a few machines that need remediation ~100. Okay, from what I’m understanding it went as normal per their expectations, there were more failures than I expected.
A large number of the computers that failed ended up failing for the same reason. The error code was “0x87D00664 Updated handler job was cancelled.”
A quick web search comes up with a few good descriptions of what the error actually means (updates handler job was cancelled is just not that descriptive,) and how to fix it.
What actually happened
What the error is actually telling us happened is that SCCM timed out when trying to install the update, and because it hit the preset time out limit, it stopped installing. At that point it failed the process. So what can we do about it
Possibly unbeknownst to many people, each update that comes into SCCM has a maximum run time associated with it. That means if the update isn’t finished installing within that time it is considered failed and will stop installing. Microsoft assigns those runtimes and they are different for different types of updates. The two that were failing for us, cumulative updates for Windows 10 1607 and Windows 1703 were assigned a run time of 20 minutes.
To find this information go to the update in question in Software updates -> All software updates.
Right click on it and click properties. One of the tabs up above will be “Maximum Run Time”. Change it to something higher than it is currently set.
We let our installs run overnight, so giving these updates a runtime of 60 minutes should be fine. Your mileage may vary.
This seems to have taken care of the issues that we have had with updates. Just to be safe for the next couple of Cumulative Updates I might change the run times just to make sure this doesn’t happen on such a large scale again.
So why didn’t I see this in my earlier environment?
This is an interesting question. It doesn’t seem like this should be something that only happens in large vs small environments since it is the actual install running on the computers that it having the problem. I’m going to narrow it down to one of two things.
- This error is potentially having this problem everywhere. It’s possible that this update just takes a bit longer, and that’s why I’m seeing it now and haven’t seen it before.
- It could also be compounded by the fact that these are slower computers than I am used to having Windows 10 installed on. All of the computers that had Windows 10 installed in my previous environment were newer with fast SSD’s. It would be expected that those should install faster. Maybe it’s just slower hardware.
Anyway, things are working better now. It’s always fun to see what ConfigMgr throws our way.
Here are the resources I used to help with the remediation of this issue:
ConfigMgr Everyday 