One would think this would be a default report as it is the same format that would appear in the Control Panel > Add/Remove Programs list. Would anyone happen to have that report readily available to share?
One would be mistaken, as one often can be when applying logic to Kaseya... ;-)
Interesting question and no easy answer, but maybe querying the database yourself.
I have someone diving into database stuff tomorrow and he might be able to cobble together a query....
I am looking forward to hearing back on this as when I looked into it Kaseya appears to be grabbing only the displayName and uninstallStr to populate the dbo.windowsAddRemProg Table. (Which explains the limitation on the Report Part) In researching this it appears that it has been noted as far back as 2007 and nothing was done to remedy it.
I am curious what you in the community are doing to pull Add/Remove Programs lists...? Anyone?
Looking on this forum to see if anyone else has come up with a solution! :-)
I have the same problem and looking through the Kaseya database tables and views, I cannot see a way to link the data that VSA pulls from Add/Remove Programs with the versions that are listed in the "Installed" application audit. Given that the Audit simply logs every single .exe file it finds on the PCs, I'd need the Add/Remove Programs list to include the install path to be able to link the results for the two tables (or rather, the table and the view) to be able to get the version number.
Of course, if Kaseya simply collected all the bavailable info from Add/Remove programs in the first place...
Although I have not done it, a procedure with PowerShell to populate custom fields?
Pulling this data is a standard part of our RMM Suite solution. We extract specific parts of Add/Remove each day and put it into a "cache" file with all other audit data. Selected elements are written to Custom Fields via API, and then the cache file is uploaded via GetFile. We have an admin tool that can collect ALL of the getfile results and extract the specific info you're looking for to report on. We don't and would not recommend writing this program data to custom fields - Custom Fields are for status or trigger data and should be generic in nature. We'd trigger this via a Special Tasks field that had a code if something was detected - trigger on the code, then remove the code from the custom field when the task completes.
The Applications list can also be configured to identify a specific app/version. This can be used to drive tasks in our Daily Maintenance tool, including version download and update. We use this for zero-day resolution of application issues by simply updating the audit config and maintenance config files and manually running the audit before the maintenance task. This can resolve a version issue across the environment within 7 hours (special audit run plus normal 6-hour maintenance task distribution window).
We currently grab only the app data we need, but its a trivial task to include any available information.
The audit tool also has the ability to collect WMI data if something specific is needed and add it to the cache file.