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… This is an administrative nightmare and has to be a better way of dealing with this. 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. 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. 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. So now it is up to an admin to set individual actions to patch the workstations. Since it is not advised to put corrupt patches in a baseline, no actions are outstanding to automatically reinstall the patches.

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.įor example to resolve an incident a Tech restores someones PC to an earlier date and now the workstation shows up missing 10 corrupt patches.

Nups patch is corrupt