aLTeReGo ✭✭✭✭✭

1.3.6.1.4.1.9.1.2494 = Cisco Catalyst 93k (stack) Tracking internally under CORE-11014.

Thanks, dgven. We are tracking this internally under CUST-39910.

Fair point xpowels. GXT2-2000RT120 is likely what someone submitted to us as the device model for this SysObjectID. Probably because that's the type of device they were monitoring. Obviously, this is not correct for any other type of VERTIV/LIEBERT/EMERSON devices, and they have decided not to provide a unique SysObjectID…

jesse.schafer wrote: 1.3.6.1.4.1.11.2.3.7.8.5.4 = Aruba JL074A 3810M-48G-PoE+-1-slot Switch Logged internally under CORE-10971

tripley wrote: It looks like in a new code version 16.04, Aruba changed the SysObjectID for at least one of their devices. OLD 16.03 Code: 1.3.6.1.4.1.11.2.3.7.11.97 = HP J9780A 2530-8-PoEP Switch NEW 16.04 Code: 1.3.6.1.4.1.11.2.3.7.11.144 = "HP Switch" but it really is the J9780A above Both of these should already be…

That SysOID is already in our database and Orion should properly recognize the vendor model in the latest NPM 12.3 release. As for adding additional out-of-the-box support for this device (such as VPN tunnels, hardware health, etc.) you should post this to the NPM Feature Requests area.

thanks, ferrashoo. We are tracking this internally under CORE-10776.

What issue would that be exactly? If you have 'Unknown' devices, you'll want to grab their SysObjectID and post it here, along with the make & model of the device, exactly as Seashore​ has above.

The Cisco 8540 WLC and Cisco ASR1002-HX were added in Orion Platform 2018.2, which is part of NPM 12.3. The other two we are tracking internally under DC-214.

All of these have already been added to Orion Platform 2018.2 included with NPM 12.3 and SAM 6.6.1, currently in Release Candidate.

We are tracking these four Aruba devices internally under CORE-10706.

wrote: The below devices just show up as "Cisco" under machine type. 1.3.6.1.4.1.9.1.2135 = Cisco Catalyst 3560CX-8TC-S https://oidref.com/1.3.6.1.4.1.9.1.2135 1.3.6.1.4.1.9.1.2136 = Cisco Catalyst 3560CX-8PC-S https://oidref.com/1.3.6.1.4.1.9.1.2136 1.3.6.1.4.1.9.1.2191 = Cisco Catalyst 2960CX-8PC-L 1.3.6.1.4.1.9.1.1340…

dustin.ampania wrote: 1.3.6.1.4.1.11.2.3.7.11.174.3 - HP Aruba JL073A 3810M-24G-PoE+-1-slot Switch 1.3.6.1.4.1.11.2.3.7.11.174.4 - HP Aruba JL074A 3810M-48G-PoE+-1-slot Switch 1.3.6.1.4.1.11.2.3.7.11.152 - HP J9726A 2920-24G Switch 1.3.6.1.4.1.11.2.3.7.8.5.6 - HP Switch 5412Rzl2 VSF VC 1.3.6.1.4.1.11.2.3.7.8.5.2 - HP 3800…

Thanks, bobby.alvarez. I have captured these under case CORE-9799.

Thanks dustin.ampania​. I've logged these internally under CORE-10191.

Got it! We're tracking this internally under case CORE-10143.

Have you tried using any of the following application templates? * WebSense Network Agent * Websense Web Security * Websense Logging Server‌ * Websense Monitor

Based on preliminary glimpses it may not be exactly what you are asking for. At present there doesn't not appear to be any method of collecting PerfMon counters, which is what most people are talking about when they ask for WMI support. Now this is based on a demonstration or a very early development version of the product…

The issue is likely the format of the PowerShell script output, a reliance upon 64bit cmdlets, or another configuration related issue such as impersonation. If SAM is installed on a 64bit operating system then i suggest changing the "Platform to run polling job on" to x64. SAM's default is "x86" but when you open a…

Perhaps this is an issue with the version of NET-SNMP being used. What version are you currently running? Have you tried updating your version of NET-SNMP?

This is actually something we are currently working on in our Log & Event Manager product, dubbed "File Integrity Monitoring". Sign Up Info for LEM 5.8 Beta (with File Integrity Monitoring!)

beastroy wrote: aLTeReGo Has the table for the alert definitions changed? It appears the alert definitions are now in the "AlertConfigurations" table. There have been no significant changes since this was posted. The AlertDefinitionsView is still very much used.

Node CPU/Memory, Latency, Packet Loss, Response Time information will be preserved. All other historical information related to the node (Interface, volumes, Hardware Health, etc.) will be lost as it is impossible to reliably map these SNMP entities to WMI equivalents.

A more telling test would be running WBEMTEST from the Orion server and connecting to the remote host. In many cases the issue is with the Windows Firewall, or some other packet filtering device in between.

This is now officially my quote of the day. "all cert tools and procedures are required to be convoluted and/or simply fail at as many points as possible, by design, to maintain a secure environment " Thanks for the good laugh and please keep us posted on your progress. I'm really interested to know what ultimately…

I would concur with Manilyn Ramos‌. The following KB article outlines the same issue related to AppInsight for IIS, but it's equally applicable to AppInsight for Exchange. * SolarWinds Knowledge Base :: AppInsight for IIS: Polling fails due to a missing certificate.

As suggested above, the Top XX Interfaces resource can be used for this purpose, using the filter Vendor Like 'VMware*' as shown below.

Just the Chassis

This is not a change from 8.1. True, I just wanted to point out that this was tested under 8.5, not that it's new to 8.5. Sorry for the confusion.

Is the node managed by an additional polling engine?