Presumably this tool is developed in house. If all it does is change BIOS settings, and does nothing else to the target computer, then it is not a suitable target for being packaged for WSUS. At a minimum you need to modify the utility to "leave a trace behind". An appropriate option might be a registry value in HKLM\Software\<ProductName> that indicates it has been executed; then you can use this as an Installed Rule test.
Of course, since all it does is change BIOS values, there's no way to determine that something or somebody hasn't changed those BIOS values back, so you're absolutely on the right track, because you'll need to use WMI Query rules to determine if any of those BIOS values are NOT set correctly -- which should then trigger the package being reported as NotInstalled. Note that for this type of utility that doesn't actually get "installed" it is possible to craft a set of Applicabiliity Rules that can distinguish between NotApplicable and NotInstalled, without actually requiring an Installed Ruleset to return the "Installed" state -- which in this case would not actually be a valid state.
However, the WMI Query you want to use is not against the WIndows Update History -- for the same reason that we already identified the registry value option as not suitable. What you need to query via WMI are the actual BIOS settings that the utility is designed to change. I'm not proficient enough with WMI to offer query code, but perhaps some other readers will be. In the meantime, I will also point out that WMI is extensively documented in the MSDN Library, and that might be a good resource to look at as well.
Actually it's the Dell Configuration Manager Toolkit. It allows you to configre BIOS settings and then export an EXE file to run on workstations to apply the setrtings. In this case I am enabling WOL for use with Patch Manager. I was hoping that the PackageBoot helper would allow me to create a file, folder, key or something when it was deployed, but I didn't see anything. The application does show up in Installed Updates after deployment, but I don't see any way to access that except using the WMI Query in Patch Manager. I haven't explored if a BIOS report would let me detect if WOL is enabled and S5 Deep Sleep is disabled like it needs to be. A non-optimal workaround is running a report for all computers of that model and deploying to all 300 blindly, then unapproving/declining the update so it won't install over and over. The bad part is when we add another 50 computers I need to deploy it to all of them again. Thank you for your very nice program. I do wish it could create a key upon deployment. Or maybe had a path to "Include Aditional File" that would remain after the deployment. Not leaving clutter is very important and Patch Manager does a fine job of it, but I wish I could leave a little when I need it..:)
Message was edited by: Joe Norton because he can't spell.
Regarding your request for creating a registry on a target machine. This could be accomplished via package boot with the following process.
Create a REG file with the desired settings.
Include the REG file as an Additional File.
Configure PackageBoot to use a <postexecution><programs><program> element to execute REG.EXE IMPORT filename.REG after successful installation of the related update.
We had a couple of shortcuts and programs that we needed to add to the users workstation and found that leaving a 0k file behind in a specific directory seemed to do the trick.