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


Well, sort of, anyway.  Smile


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


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 that 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.  If we have challenges getting a network device to discover in SCOM, 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: along with feedback from Michael Bullwinkle.


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 SNMP varbind contains specific data


Therefore – even if you don’t need this functionality – this will be a very good MP example, of discovering objects from a CSV, and having those objects hosted by a resource pool and load balanced by resource pool members!


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 will host 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:  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 contains 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:

Comments (5)

Cancel reply

  1. Cyraz says:

    I don’t have a SCOM environment with SNMP devices at hand right now, but I have an obvious question : is there anything preventing us to create regular snmp poll rules and monitors against the devices discovered using this method, thus bypassing the need for the native network discovery rules?
    Moreover, would it be possible to discover “certified” network devices with this method?

    Reason why I’m asking is that it could be really useful in a scenario where you want to automatically add/remove devices you want to monitor from a cmdb…

    1. Kevin Holman says:

      I wish. I tried to create instances of the class “Node” (System.NetworkManagement.Node) which would allow such things, but I could not figure out how to make them initialize. So I used System.ApplicationComponent as a generic base class with my own custom properties. I’d prefer to discover node instances. I imagine there is some discovery data submitted in code, but I will keep playing with it. If I can get it to work I will update the MP.

      1. Cyraz says:

        Damn, I knew it sounded too good to be true 😀
        Anyway, thanks for everything, your blog has saved me more times than I’d care to admit !

  2. Nikhil says:

    I did followed this article and tried in our test SCOM env. But we are still not receiving traps. The scenario is as follows:

    We have a Dell OME server ( monitoring physical dell servers )which is forwarding the SNMP V1 alerts to SCOM 2012 R2, but the alerts are dropping off in the SCOM as the SNMP V1 has an “agent address” contains the source IP of physical dell servers.

    Is there a way in SCOM 2012 R2 where we can do some configuration to receive the traps/alerts.

  3. Han Seen says:

    hi Kevin,

    Can this custom MP cater for SNMP v3?

Skip to main content