The Antivirus module will report what AV the Windows Security Center recognizes and if you chose WSC from the column set it will even give information about version, active, and up to date.
Why can't we report on all of the info the AV/AM module gathers?
Report Parts - Under Audit > Installed Security Products - created a new table and in the Select Columns add "Computer Name" "Product Name" and "Version" then in the Group By add "Product Type Description"
Is there any way to include that on the "executive summary" report?
Tim Varvais That dataset only shows workstations, it doesn't pull for Servers. Which dataset contains active/up to date data for Servers?
Unless there are filters configured for the report part, data should be returned for all devices. I set up a report using Tim Varvais's configuration and added the field for Operating System. Both workstations and servers are returned.
If you're not seeing servers listed in the report part at all, check that the report part configuration does not filter and/or that when you run the report, you are not using a view which might prevent the servers from being included in the results.
If you're seeing the servers listed BUT there's no AV info for the servers (for me, a few test servers have a Product Name of *NONE*), check the Audit module to determine if there is in fact an AV product installed. If no AV product is reported within Audit, then the report part leveraging that info won't show an AV product name/version.
If it turns out Audit does show an AV product installed for a server but the report part is not providing that same detail, please open a ticket with Support. Provide detailed information about what you're trying to do, what you've configured, and what you're seeing so they can investigate and attempt to reproduce the issue. The more detail you can provide, the better Support will be able to assist.
There is no such thing as "Windows security Centre" on servers. It's a workstation only function.
Therefore, it is normal and expected for servers to return a blank here.
This is how Microsoft designed windows - not a Kaseya issue.
Craig is spot-on!
We actually have a tool to extract all of the Security Center data and report back to Kaseya when there are ongoing issues (not running, suspended, outdated defs, not installed, etc). Alerts are thrown after n-consecutive error conditions to minimize false alerts. It also logs the correct detected security platforms to a custom field each day, and it reports "Unsupported" for servers (because it is). Silly Microsoft - they actually thought nobody cared about AV and other security status on servers!?!?
gbarnas: Can you please provide some more information about that tool
The AV tool that we use is one of the Smart Monitors from our RMM Suite (See the Automation Exchange or www.mspbuilder.com).
This smart monitor is an executable that we wrote that extracts the information from the MS Security Center. It enumerates the products reported, then checks the status for each product. Some situations are reported directly, such as multiple AV products installed AND running, which is an unwanted condition. Most other conditions are more intelligent -
If the definitions are reported as "outdated", the monitor determines if a command-line tool is available to initiate an update and invokes it. It currently does this for 9 different AV products. If the definitions don't update after 3 distinct check/update cycles, it generates an alert to Kaseya.
The same logic applies to AV disabled or not-running status - after 3 checks in the same status, the alert is generated. This suppresses transient conditions where AV is disabled during app installs or other admin tasks and we happen to check the status at that moment. This way, we only get an alert if someone forgets to re-enable AV or intentionally disables it. If a C/L tool is available to re-enable AV, the monitor can try that on the third attempt and report only if unsuccessful.
That's the whole idea of our Smart Monitors - suppress transient (temporary) conditions; self-remediate where possible, and auto-adapt to local conditions. We currently have 4 Smart Monitors in production - the AV Security monitor described above, a Running in Safe Mode monitor, a Time Sync & Windows Time Config monitor, and a Disk Capacity monitor that auto-adjusts thresholds based on drive sizes. We have a couple others in development as well.
We put our intelligence into local monitors that Kaseya delivers and initiates. The smart monitors operate locally to adjust and remediate, and then alert Kaseya when the condition persists and can't be remediated. In addition to local remediation, some Smart Monitors use our Service Desk automation to invoke a Kaseya Procedure to perform alternate/additional remediation tasks. (this is why we love Service Desk!).