1

Hello,

I created a software update group to push Windows XP patches/updates to over a hundred workstations. Our XP machines haven’t been patched/updated in a while so the number of patches/updates were fairly large for these workstations.

The push went as planned, but about half of the workstations had at least one patch/update failure where the patch/update couldn’t be installed for some reason. This push was required, so SCCM keeps trying to push these failed patches/updates day after day without success. The users of these workstations are becoming annoyed because it keeps trying and prompting them with the progress and such.

What is the best way to deal with this at this point? I could disable the software update group for these, but I would like to keep it enabled so that if any other XP machines join our domain (hopefully not) they would get these patches pushed to them also (I have my deployment groups split by OS, and a query will automatically put them into the correct group). If I change the user notifications on that software update group so that it hides all notifications for the users, how would that behave? It would keep trying to push right? If so would it be hidden from the users? I could then work with the clients to try and get these patches/updates rectified on a one-on-one basis then.

Could I handle this on a more granular basis where I could disable the select (failed) updates for the specific workstations?

I am just looking for how you would handle this. It seems like there are a few ways to go about this, but which way is right? Is there other ways to deal with it?

Thank you

1 Spice up
2

If you have XP machines that “haven’t been patched/updated in a while”, then I don’t find it particularly unusual at all that you’d experience a high failure rate on half the workstations. Such is the nature of trying to deploy months of updates simultaneously.

The best way to deal with machines in this state of disrepair is one batch of smaller updates at a time. I would recommend one month at a time if at all possible. But if that’s not possible, then deferring some updates in preference to others has shown to have a high degree of success.

For example:

  • NEVER deploy .NET Updates on a machine that does not have a fully patched Operating System. In my experience this will result in failures of .NET Updates almost 100% of the time.
  • Deploy .NET updates in chronological order… one month at a time as suggested above.
  • Deploy SECURITY and CRITICAL updates before non-Security/Critical updates. Why clog the patch stream with non-critical updates and risk the possibility that one of those non-critical updates interferes with the whole process.
  • TEST TEST TEST – if you’ve not deployed a batch of updates to a test machine to verify they actually will co-install together, don’t do it to hundreds of unsuspecting workers who are trying to actually get work done.
  • DO NOT deploy months and months of updates during working hours. In fact, it’s probably even risky to do that overnight.
  • In combination with the above two points… have a ROLLBACK plan so that you can restore functionality to the workers disrupted by the fact that updates/patches have been ignored for so long. In the words of an old adage: It will never take less effort to get out of a mess than it took to get into it. Expect to invest some effort in this endeavor.

Having said all of that… as a starting point:

  • Yes, remove any .NET updates from those deployments.
  • Remove any updates that are causing problems.
  • Also… pay particular attention to whether you’ve tried to deploy SUPERSEDED updates. (You may be deploying hundreds of updates, but really only need to be deploying dozens.)

Finally… be especially aware that the Windows Update Agent does not install updates in any predictable order, and this is why it’s absolutely necessary to control the order of deployment from the patch management system, not depend on individual clients to deal with it.

1 Spice up
3

Awesome response Lawrence. It makes sense and I learned a lot from it. I really appreciate it, and I am going to use your direction for my upcoming patch deployments.

Thanks