Menu Close

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:


  1. Dane Rafn

    If you were doing this type of SNMP discovery for devices/appliances that are Windows based, would you also need to edit the ic-post-processor.asl file (mentioned in you blog “How to discover a Windows Computer as a Network Device in SCOM 2012”)?

  2. Mohamed Sybulla

    Hi Kevin,

    We have discovered vCenter 6.5 version in SCOM 2016. We added them using both the methods (i meant SCOM discovery and Without discovering the SNMP Device). and udp ports 161 and 162 are also open between source vcenter to SNMP SCOM Receiver server. We could capture the test trap by wireshire running on SCOM SNMP Reciever Management Server from vCenter. But this trap is not captured by SCOM. We already created test trap capturing rule and test trap events capturing rule. All the traps are captured from various devices but from this vCenter it is not capturing. We removed the version line also in the discovery as you suggested.

    • Kevin Holman

      Thats by design, and a fundamental understanding of SCOM. Unmonitored means simply there is no health state from MONITORS targeting that class. If you discover a class, and only target rules at it, it will always have no health state… by design. Rules and monitors are different.

      • Kshitij

        Thanks Kevin for replying. I am able to receive traps from Lenovo server. but how could i set it for limited set of OIDs.. How to get the OIDs details? Please let me know if you have any published anything for it.. Thanks for your help Kevin.

  3. Piotr

    Hello Kevin,

    I need to configure Hitachi monitoring and the problem is G600 devices have no name defined in AD (nslookup doesn’t show any name).I just have an IP of Hitachi controller from which SNMP are sent and in wireshark I can see SNMP packets coming through to MS. How should I proceed if the device name doesn’t exist?

  4. Alaguraj Palaniappan

    Hello Kevin,
    Using Community String for SNMP device is vulnerable as per organizational policies, hence we are advised to use SNMP V3 which is using credentials based authentication or device identification. So how do we proceed with this scenario ?

  5. GV

    This is a great article, surprised that more like this don’t seem to exist. Please can you advise on how to do this for SNMPv3. thanks

  6. GV

    Does this work with Windows 2016 and SCOM 2016. We cant for the life of us get it to work. Discovery works fine and devices are listed, Community string is base64 as per article, resource pool is statically set to one server. Wireshark on SCOM server shows traps being received on port 161 as Version 1 and type TRAP. However, nothing is displayed in the Alerts?

    We have confirmed on SCOM server port 161 is bound to snmp.exe (Windows SNMP Service) and 162 is bound to MonitoringHost.exe (SCOM Agent) . We even set the community string in the Windows service settings to see if this made a difference. Any ideas?


  7. GV

    Ok, we have it working now.

    For other that struggle
    – Ensure you use same community string as shown in this article – nothing else works
    – Ensure your SNMP Trap sending device is configure to send traps to port 162
    – Ensure your SNMP Trap sending device is configured to use SNMPv2
    – Ensure port 162 is bound to MonitoringHost.exe (netstat -abn)

    thanks again to Kevin for taking the time to share this

Leave a Reply

Your email address will not be published. Required fields are marked *