Patch Management Solution

If I were deloying a Windows patch, I would like to pilot test the new superseding patch on a small scale. From my understanding this is not possible in the default configuration. (or how others usually configured)

I find this behaviour a little troubling because I can't do anything if the new patch is causing issue but now I can't continue to deploy the superseded one.

Is this easily achievable in 7.5 without much overhead in deleting the superseded patches when I start to rollout the new ones and how?

Thank you.

You're correct.  If you do a staggered patch deployment (test computers THEN production computers, for example) you will likely run into this issue with the monthly IE cumulative updates, Flash Player updates, etc.

This remains an issue in 7.5 and the only way around it at this time it to disable the option to automatically supersede updates.

I have raised this as an issue with the product management team and I'll forward your comments to them as well.

And to be clear if you have Patch configured to automatically supersede then every time the PMimport runs it will supersede old bulletins, even if you re-enable them.

If you want to maintain the ability to deploy superseded patches then you need to disable the option.

Hi,

Thanks for your reply. I've unchecked "Disable all superseded Software Updates". However, the Windows compliance by update report still removes the superseded updated and I can't tell whether those patches are actually stil being push down. Is there any way ensure this or to report the status as usual?

That might need to rebuild via full import.  I'll try it out on my own system and let you know what I find.

Hi, I guess this is not possible right?

We had this happen where an IE update superseded a prerequisite for a earlier IE update.  The earlier IE update broke because the prerequiste patch was disabled. But the patch that superseded it was just in testing.

We elected to disable the automatic runs of PMImports.  Once we are done staging and rolling out, then we'll manually trigger a PMimport for the next batch.  I think this would also deal with your reporting problem.  It would not be good workaround if you stage patches for testing before the production rollouts are complete.

Thanks for your reply. I think this is the only workaround. However, it is impossible not to stage new patches for testing, especially in large environment.