That is a very good question, hmmm, the only way I know is to look at the vulnerability itself in the "Repair Failed Column"
But I found that this is not always accurate, (correct me if I'm wrong) the task will still show as fail in the case when a reboot is needed to COMPLETE the repair, meaning that if the Patch was applied but the machine has a reboot pending it will still show as vulnerable.
Now, it would be nice to have a report by Device with Failed Patches, Attempts, applied but Pending Reboot etc....
If some one could add more that would be great!
We show the device as vulnerable (until the reboot) because the device still *IS* vulnerable.
Windows only actually "really" installs the patches "at reboot", so just running the installer is NOT enough. We could go the "you're fine" route (as various other products have at this point), but we prefer a more accurate depiction of the estate (as installs can fail + roll-back) ...
So there's potentially more to this, depending on what you're going about.
If you're looking "patches that have actually failed with an error"-type of failures, those are caught in the relevant log(s) and you will see something of a "red bar" in the associated console side of things (if you're using a scheduled task).
if you're using Autofix, be aware that we only try (by default) 5x to install a patch, before "giving up" since there seems to be something pooched on the machine.
You may also want to have a look at the PATCH HISTORY of a device.
For DB-related stuff, this may help you get started a bit - Getting started with Patch Reporting (SQL, Tables & such) .
In short "there's a lot more" here, so your question would need some clarification as to what exactly you're talking about / are after.
If using Autofix (5x tries):
1. When does Autofix runs? Every vulscan? PolicySync? And will it attempt to install "all" patches set to autofix at once?
2. When a reboot is needed to finalize the Patch but deemed in a sense still "vulnerable", will it try to re-install 5x? (We have computers that do not restart often, not under our control)
1. Looks like there is not a report that shows you what you are looking for, in addition to the section I showed you you can also check the affected computers report for a particular patch, then you can right click the machines in question and select Security and Patch information, within tha window you can see more info about that Patch, including reason, install attempts etc.
I have the exact needs as you, so I may have to go to a database/report journey to get what we need.
phoffmann yes i'm using autofix , the problem is that i want to see all of the failure and the succeful patchs , i'm using a query to that but its really helpful to see information like that
i need to repair and fix the failed patchs
carlos exactly i'm using the same thing , but to see or repair failed patchs for more than 100 pc it will be difficult
I'm reasonably sure that the patching history will show you failed repairs of autofix related stuff ... (it helps if you have a DB on-hand where such things happened, which I don't). So that's why I pointed you at the "Getting started with patch reporting..." article. My expectation is that you should be able to see those events in the PatchHistory side of things.
Since I don't have any failed patches in my little lab DB, I'm having to go on a mix of memory & suspicions.
carlos - Autofix doesn't "run" as such. It's vulscan itself ... so "when vulscan runs, it'll try to autofix anything relevant" in effect (if you're only scanning for 2 vulns, and 1 of those is marked as needing to be autofixed, it'll ONLY try to autofix that one).
Interesting question, but not sure whether Autofix would re-try to patch something that has been patched (but is in need of reboot). Would need to try it out & see ... I *SUSPECT* that results might vary based on the specific patch (some patches might be better at marking themselves as 'technically applied').
So I'd expect (in sensible situations) for the relevant MSU to go / give a return code of "Oh, I'm already installed - just need to be rebooted to be applied" type of thing.
Yep - PatchHistory should be the place for you to look.
See here (click on the picture for the full-size version):
... so the relevant "report" would be most likely a SQL-based thing (which you could then put into the "regular" reporting if you so wanted) and/or XTraction -- filtering only failed items, if you so want.
yes that for just one device , it will be difficult for thound device
and to repair the failed patches , what is the best way to do it ? by using a custom groupe ? or a repair task ( the max of a repair task is 80 patchs )