Side question related to wmi polling...
Certain windows boxen that don't have an add-on SNMP software component installed (Dell Command Monitor, HPE CPQ agent) will return a hardware identifier of "Intel x64" and that is what populates the "Hardware" field for the Server/Workstation.
When the WMI module is enabled, one of the queries we make of the polled node is "SELECT Name FROM Win32_ComputerSystem".
My question is, could we also use that same (or similar) query to include "SELECT Model FROM Win32_ComputerSystem" and use that to populate the hardware field for the polled node? In the case of a baremetal device, it will return the actual hardware type, or in the case of a VM on an ESXI host, it will return "VMware Virtual Platform".
Examples: root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.50.52.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name Precision Tower 5810##RJM-T5810
root@observium:/opt/observium# /bin/wmic --user=<redacted> --password=<redacted> --workgroup=<redacted> --delimiter='##' --namespace='root\CIMV2' //'10.1.9.XX' "SELECT Name,Model FROM Win32_ComputerSystem" CLASS: Win32_ComputerSystem Model##Name VMware Virtual Platform##DBSRV2K8
On the first one, I have the Dell SNMP agent installed, so hardware is being populated by the SNMP query made under the Dell-specific MIB queries. The second one is a VM, and since there's no specific SNMP agent, hardware is currently shown as "Intel x64"... which doesn't tell me if that is a VM or not.
Thus my question... if the WMI query could be updated to include the Model information, and then populate the hardware field appropriately.
Thanks, Ron
On 2022-04-13 10:21, adama--- via observium wrote:
Yeah, in general our policy is that our changes/defauts shouldn’t break things that already work.
Since you have to manually add WMI, I don’t think it’s a hardship to set this explicitly. It should just be a checkbox in the WMI tab.
The default should maintain current behaviour on existing devices, but can be the new behaviour on any future added devices. This is easier with a devices table field than it is with a device attribute, but possible either way.
I’m not sure how much device table sprawl matters, it’s not functionally possible to have enough rows in that table for it to matter, so this can probably be a devices table field.
Adam.
FROM: observium observium-bounces@observium.org ON BEHALF OF Tom Laermans via observium SENT: 13 April 2022 17:00 TO: Tony Guadagno tonyg@guadagno.org; Observium observium@observium.org CC: Tom Laermans tom.laermans@powersource.cx SUBJECT: Re: [Observium] wmi issues, need a syntax change
Tony,
I don't disagree that it needs to work correctly on new systems, however the adage of Observium (for better or for worse...) usually is "don't break either", hence my question.
I guess we'll have to think a bit...
Microsoft also said they'd stop doing SNMP, and claimed they'd stop doing unsigned LDAP - for now neither has materialised ;-)
Tom
On 2022-04-13 16:22, Tony Guadagno wrote:
Tom, there is a couple of moving parts here. First, if you have a system that is still patchable, then this applies because this is pushed in patches. Now, if you are still using WinXP or Server 2003, then probably not. Whether the fix will break WMI monitoring on these old systems, I cannot say.
This is my feeling, should we let newer systems break with WMI monitoring or older (unsupported) systems break? I think it does not make sense to break new systems in favor of old.
I guess another option would be to make a config pram (WMI-signing?) if true, the new call is used?
But to be clear, right now, the WMI hardening results in error messages in the event log but the command succeeds….however…as of 2023, the command will fail and no info will be returned so doing nothing will break WMI.
Thanks for your time on this