I’m curious here as the corrupt patches are a major pain in the behind to deal with because the way Big Fix writes them to not allow you to chain them as well as requiring a reboot between every patch reinstall.
For example to resolve an incident a Tech restores someones PC to an earlier date and now the workstation shows up missing 10 corrupt patches. Since it is not advised to put corrupt patches in a baseline, no actions are outstanding to automatically reinstall the patches. So now it is up to an admin to set individual actions to patch the workstations. To add to the grief, one has to put out an action and wait to have it install and the end user reboot (my company policy allows user to hold off rebooting for 24hrs) then send down another action to reinstall the next patch. If one were to put out all 10 actions at once, the first one in would run fine then the remaining would then report back in as Not Relevant and the remaining actions would need to be reissued. In this example it might take 20 days to patch this workstation and generate a really pissed off end user after you present them countless reboot messages for days on end.
This is an administrative nightmare and has to be a better way of dealing with this.
So after looking at this a bit by comparing relevance between the install patch and the corrupt patch why does it matter that you check for the existance of the update being installed and having 2 different methods of dealing with it when the rest of the relevance actually checks if the patch is installed.
956391: Cumulative Security Update for ActiveX - Windows XP SP2/SP3
Regular Patch:
NOT exists key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB956391” of registry
Corrupt Patch:
NOT(NOT exists key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP4\KB956391” of registry)
Why not just skip the relevance checking for the past install? How many people really care to know that it is corrupt VS just want to know a patch is required?
In a perfect world, there would be no corrupt patches because all patches would apply successfully and nothing would overwrite the files… But, there are many different things that could cause a patch to be corrupted and it generally represents an issue…
We believe (and many customers appear to feel similarly) that knowing that a patch had been previously installed and is now “corrupted” is a very useful distinction and so we make the independent Fixlets to detect both situations (actually our lives would be much easier if we did it the way you mention, but then our customers wouldn’t know when their patches were corrupted).
The point you make about making it easier to apply them due to the “pending restart” relevance issue is well-taken… I believe someone in our company is working on an easy-to-use wizard that will allow you to package corrupt patches into a baseline easily… I will check and see the progress and let you know if there is something we can do to help…
It seems the easiest way to deal with these is to create a .reg poke like the one below and push it out, then patch with the normal patch. A real PITA but it is better than the alternatives.
