Alerting on SNMP traps in SCOM – Without discovering the SNMP Device

Well, sort of, anyway. 

I have written on SNMP monitoring in SCOM a few times:

https://blogs.technet.microsoft.com/kevinholman/2011/07/20/opsmgr-2012-discovering-a-network-device/

https://blogs.technet.microsoft.com/kevinholman/2015/02/03/snmp-trap-monitoring-with-scom-2012-r2/

https://blogs.technet.microsoft.com/kevinholman/2015/12/16/how-to-discover-a-windows-computer-as-a-network-device-in-scom-2012/

https://blogs.technet.microsoft.com/kevinholman/2016/04/20/writing-a-custom-class-for-your-network-devices/

This one will be a little different.

One of the challenges I have heard many times with SCOM – is that we must discover a network device, in order to monitor or receive SNMP traps from a device.

This can be a big problem for customers, as they often have network devices that only sent traps, but are not query-able via SNMP GET requests.  But if we cannot get a device to discover, we can’t generate an alert or collect the trap.

Let’s make that a little simpler.  This article will demonstrate how we can create a new class for our network devices, discover them from a simple CSV text file, and then monitor them for SNMP traps.

This post will be based on the work of Tatiana Golovina here:  https://blogs.technet.microsoft.com/scpferublog/2013/12/09/snmp-scom-2012-109/

The idea is to create a management pack with the following:

1.  A new Resource Pool, that will host our network devices and load balance them.

2.  A Class that will define our SNMP network device and any properties.

3.  A discovery, which is a PowerShell script to discover our network devices.

4.  Rules, to alert on all traps, specific traps from a specific OID, and specific traps where a varbind contains specific data

Our class definitions look like the following:

      <ClassTypes>
        <ClassType ID="Demo.SNMPDevice.Class" Accessibility="Public" Abstract="false" Base="System!System.ApplicationComponent" Hosted="false" Singleton="false" Extension="false">
          <Property ID="DeviceName" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />
          <Property ID="IP" Type="string" AutoIncrement="false" Key="true" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />
          <Property ID="SNMPCommunity" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />
          <Property ID="Description" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />
          <Property ID="Owner" Type="string" AutoIncrement="false" Key="false" CaseSensitive="false" MaxLength="256" MinLength="0" Required="false" Scale="0" />
        </ClassType>
        <ClassType ID="Demo.SNMPDevice.ResourcePool" Accessibility="Public" Abstract="false" Base="SC!Microsoft.SystemCenter.ManagementServicePool" Hosted="false" Singleton="true" Extension="false" />
      </ClassTypes>

There is a datasource for the Resource Pool, and a Discovery for that as well, but those aren't important here.  They just create the pool and load the relationship so the pool hosts our devices.

Then – there is a discovery that discovers against the CSV file and creates our instances:

You can override this for Interval, SyncTime, Timeout, and the CSV path you want to discover from:

My example CSV is very basic – you can add or remove fields you want to discover.  For my example I include the device name, IP, Base64 SNMP Community String, a description, and the Owner.  You may change these as you wish, but you have to change the discovery script as well if you do.

We require a DeviceName, IP Address, and Community String (base64) at a minimum:

The Base64 Community string is described here:  https://blogs.technet.microsoft.com/brianwren/2009/01/21/snmp-queries/  I have included the one for “public” in my example.

This will discover your objects:

And let you generate alerts when traps are sent to the SCOM Management server that hosts these objects:

I have included three different rule examples:

1.  A rule to alert on ANY trap sent from the device.

2.  A rule to alert on ANY trap sent to the device that comes from a specific OID.

3.  A rule that will filter a specific payload in the trap, such as data in a specific Varbind.

You can look at the rule configurations to better understand this method, to start creating your own rules.

This MP contain a Resource Pool dedicated for these devices.  You must configure this, as by default it will use Automatic membership, and distribute your network devices across all management servers.  This means each device must send a trap to EACH management server in the pool, because we do not control which management server hosts the device.  For this reason, especially for testing, you may want to set the Pool membership to manual, and limit the management servers.  Many devices are only able to send traps to two IP destinations, so it would be wise to choose two management servers for pool membership – to give high availability and load balancing, or just one management server for simplicity and testing:

So with a simple CSV, we can quickly “discover” our network devices, and start getting traps from them really quickly.

You can download the example management pack and sample CSV file here:

https://gallery.technet.microsoft.com/SCOM-Management-Pack-to-ac659c99