Please go through below KB:
There is already a answered thread for the same case of yours, to rollback patch deployment.
Maybe you misunderstand my question. I dont want to rollback the patching so I want to identify which patch had updated the printer driver and If I can discard the patching of drivers in Windows OOSS.
not exactly a question where BSA can help you.
However, maybe you con go through the patches that have been deployed and from their Description try to narrow down, which patch has affected your Printer-Drivers ? Also maybe worth checking the according Microsoft KB Articles.
The same applies for future patches.
Do you patch based on the Groups like "Security Updates" in the Patch Analysis job ?
If that is the case, you'll always have to deal with, what Shavlik considers as missing on your target.
If you want to manage and control, which patches go out to your servers, you would have to create Smart-Groups, which for example could be based on a Custom_Property like "Approval_Status" for Windows-Bulletins and then base your Patch-Analysis on these SmartGroups.
This Custom_Property could be a list of three values "New", "Approved", "Rejected", where the default value would obviously be "New".
So whenever you update your catalog and new Bulletins appear, they get the Approval_Status value of "New".
This way you can look at those patches and try to understand if they will potentially break your systems or not. When you are happy to roll them out, set the property to "Approved", or if not set in to "Rejected".
Then run your Patch-Analysis with an Include-List of your "Approved" Bulletins and you have full control over what goes out to your targets.
This mechanism can also be extended with QA phases, etc.
Let me know if that answers your question, or you need futher details on the matter.
I'd just clarify one point here:
you'll always have to deal with, what Shavlik considers as missing on your target
For the patches that originate from Microsoft, Shavlik implements the rules that Microsoft lay down for patch applicability.
Of course, both Microsoft and Shavlik sometimes can get them a bit wrong - we see corrections as well as new patches being added to the metadata, and of course, the rules cannot legislate for all possible implementation environments, so as Steffen has suggested, doing a test deploy on a target set aside just for that purpose can help prevent unwanted surprises :-)
Thanks & Regards,