SNMP monitoring of non-Windows "Windows" devices

16 hours ago, marting said:

The main thing I don't like about tweaking AppliesTo logic on LM-provided Modules is that I could see a scenario where we update our Modules at some point in the future and LM has changed the AppliesTo logic on one or more of those Modules which overwrites our custom AppliesTo logic and now we've lost monitoring on some of our devices without knowing it.

Totally right. But not just AppliesTo, but poll rate, thresholds, additional graphs (why doesn't the WinVolumeUsage- DS have a percent utilized graph?), DS group, discovery filters, etc. This is why Safe LogicModule Merge was available for a time. They pulled it back, not sure why. I've submitted a feedback request that they bring it back (and fix whatever caused them to roll it back) and I recommend you do to.

That said, if you do modify the OOTB LogicModules, when you go to pull down updates, there will be an option to see what has changed. It's not a great workflow. 

Ok, the isWindows() function "Returns TRUE if the value of “windows” or “hyper-v” is contained in the system.sysinfo or system.categories property." It actually doesn't look like it relies on the system.category of "Windows". So you may have two problems to fix: get "Windows" out of the system.category and also adjust any LogicModules that use isWindows() in the AppliesTo.

I've wanted for a while to have an implied  `&& (![ds_name].disable == "true" || [ds_name].enable == "false")` on all logicmodules. It would make it dead simple to disable datasources on the group level without ever having to touch the logicmodules by letting you put a couple properties on a group containing those CE devices and disable the Windows datasources.

One possibility is that the Windows category comes from a sysoid map. In which case, you might be able to edit that one to exclude the WindowsCE sysoid. Unfortunately, there's not a good way to determine where the system.categories come from (another feature request of mine). So, you may have to go digging through property sources to find which one is assigning that. 

Luckily, you can pretty easily modify the AppliesTo of the logicmodules to include/exclude them. I'd target whatever it is that is setting the windows system.category as that would give the biggest impact. 

The SNMP_Network_Interfaces DS is built with this problem in mind. You can set a category on your CE devices called "OverrideNoSnmpIf", which will apply that datsource regargless of the isWindows() or system.categories.

Thanks for the detailed response @Stuart Weenig

I kinda forgot about SysOID maps.  I was able to remove Windows from system.categories by putting in a SysOID Map for the specific OID (1.3.6.1.4.1.311.1.1.3.3) which is apparently the OID for Windows CE.  Since we don't have any other CE devices in our environment, I'm just telling LM it's not Windows.

Unfortunately, the device still shows up with the isWindows() AppliesTo function and I think that's because of the "Windows" that shows up in system.sysinfo.  I've reached out to the manufacturer to see if there is a way to tweak what gets presented there but my expectations are low.

I feel like have some overrides that could be applied at a group level would be great.  Something like a notWindows property...

But it sounds like I'll have to do this the hard way.  I really hate tweaking logic on core LM-provided LogicModules so I'm tempted to disable all the WMI LogicModules at the group level and then clone SNMP LogicModules with custom AppliesTo logic.

18 hours ago, marting said:

Unfortunately, the device still shows up with the isWindows() AppliesTo function and I think that's because of the "Windows" that shows up in system.sysinfo

I think this is the reason you'll have to do it the hard way. You can't modify the isWindows() function (boo!). You could create your own, but then you'd have to replace it everywhere isWindows() is used, which isn't ideal.

18 hours ago, marting said:

clone SNMP LogicModules with custom AppliesTo logic

This has the same disadvantage as modifying the core datasources.

On 7/20/2022 at 8:12 AM, Stuart Weenig said:

This has the same disadvantage as modifying the core datasources.

The main thing I don't like about tweaking AppliesTo logic on LM-provided Modules is that I could see a scenario where we update our Modules at some point in the future and LM has changed the AppliesTo logic on one or more of those Modules which overwrites our custom AppliesTo logic and now we've lost monitoring on some of our devices without knowing it.

In the other scenario (cloned DataSources with our custom AppliesTo logic), the worst that would happen is we wouldn't get updates on those Modules but would continue to have the level of monitoring we did before.

This make sense?  Are my concerns on the first scenario warranted?

Makes sense.

Brainstorming some more, I did find that I can override the isWindows classification despite them telling me I can't.  Turns out if you make your own isWindows AppliesTo function, that overrides the built-in one.  I did a quick test with this logic and it seemed to do what I needed.  See any issues with this (other than it not being officially supported)?

(join(system.categories,",") =~ "Windows" || join(system.categories,",") =~ "Hyper-V" || system.sysinfo =~ "Windows" || system.sysinfo =~ "Hyper-V")
&& !hasCategory("Crestron")

(we are applying the Crestron category as needed)

Undocumented feature! Cool! I don't see any reason not to do it that way. Just have to be aware of any other place that isWindows() is used that might be impacted.