Numerous Corrupt Patches

(imported topic written by chipjnr)

Hi,

There are now quite a high number of corrupt patches listed within the console. From what I’ve read BigFix checks the registry & the file versions to ensure the patch is installed correctly. A corrupt patch becomes relevant when a file version is older than the version than it should be when the patch is installed.

Does BigFix have any method of discovering what changed the file version or listing what files(s) have been changed so we could investigate what was installed/changed at the time it was modified?

All patches go through a change control mechanism in work & if I suddenly list all the corrupt patches I will have to detail why they became corrupt.

I’ve created a baseline of all the corrupt patches which should speed up the deployment but before I can deploy them I need to try to discover why they are corrupt.

Any help would be much appreciated.

Regards,

Neil

(imported comment written by BenKus)

Hey Neil,

As you mentioned the corrupt patches mean that at least one file that was supposed to be updated by the patch on the computer has been moved to a previous version (and thus the patch is corrupted). Unfortunately, there isn’t a built-in report that shows you the version of every file on the system to compare to see which file is back-leveled.

You can build custom relevance to look at file versions and retrieve them in a property for analysis, but you would need to do this on a ‘per-corrupt-patch’ basis… for instance, your relevance might look something like this:

q: (name of it, version of it) of files “kernel32.dll” of system folder; (name of it, version of it) of files “mpr.dll” of system folder
A: kernel32.dll, 6.0.6000.16386
A: mpr.dll, 6.0.6000.16386

and you would add all the files you wanted to view in the property just like this… it is slightly time consuming to get all this together, but it will get you the results you are looking for…

Ben

(imported comment written by chipjnr)

Hey Ben,

Thanks for that. I admit it would be too time consuming to go through that for each patch.

Does BigFix log when a fixlet becomes relevant to a client?

If so, when a corrupt fixlet becomes relevant for a client I can check the logs to confirm the date. I can then check the event logs to see what has changed & caused the corruption?

Using web reports can an e-mail be sent when a corrupt fixlet becomes relevant within the console?

Most of the corrupt patches are relevant to the production servers even though we have a D&T & QA environment where all software/changes are tested but we aren’t seeing any issues with those servers.

Thanks,

Neil

(imported comment written by BenKus)

Hi Neil,

Try this:

In Web Reports, create a “Blank Report” and paste this into the report:

<?Relevance trs of (td of name of fixlet of it & td of name of computer of it & td of ( last became relevant of it as string) & td of ( relevant flag of it as string)) of results of bes fixlets whose (name of it contains "CORRUPT")?>
Name of Corrupt patch Name of computer Last became relevant Currently relevant?

This should give you a list of all the computers with a Corrupt Patch relevant and the time it last became relevant.

Ben

(imported comment written by ErnieF91)

We see a lot of corrupt patches relevant when we install an older Service Pack on a recently patched system. Unfortunatly, the Service Pack will over write newer files and create the dreaded “Corrupt Patch” condition. The patch isn’t really currupt, it’s just one of the files in the patch is no longer the version the patch expects it to be.

This is one feature we like about Bigfix. Certain other patch management systems we evaluated at only look to the Add/Remove program lists to verify that a patch was installed. It will never report back that one of the files from the patch was overwrote with an older verion.

One thing that we would like to see would be the ablilty to re-patch a system without having to install the corrupt patches one by one. Most do not have a defaut action defined and have “reboot not needed” in the relevance, so we have to install them indivually with a reboot between them. Which means a machine with 20 Corrupt Patches listed = 20 reboots. Yuk.

Ernie

(imported comment written by chipjnr)

Hi Ben,

I created a blank report & added the information as requested.

When I submit the report I get the error below;

‘Singular expression refers to nonexistant object.’

I’ve attached a bitmap as well.

What other information do i need to add?

ErnieF: Thanks for bringing that to my attention. One of the Exchange servers has 19 corrupt patches so I don’t want to have to reboot it 19 times!

Thanks,

Neil

(imported comment written by BenKus)

Hmm… I think maybe I need to add more error checks, try this:

<?Relevance trs of (td of name of fixlet of it & td of name of computer of it & td of ( last became relevant of it as string) & td of ( relevant flag of it as string)) of results whose (exists name of computer of it AND exists last became relevant of it ) of bes fixlets whose (name of it contains "CORRUPT")?>
Name of Corrupt patch Name of computer Last became relevant Currently relevant?

Ben

(imported comment written by chipjnr)

Hi Ben,

That works now. Thanks.

Neil