SCOM 2012 – SNMP Traps, How The Heck Do I Get It Working?

In this post I would like to share some know-how and my personal experience, because I have seen it so many times in the forums and other blogs which had trouble getting SNMP Traps working in SCOM 2012.

The difference between SCOM 2007 R2 and SCOM 2012 (R2) in terms of network monitoring is, that Microsoft rebuilt their SNMP stack for monitoring SNMP devices. Some advantages are, that we got sexy dashboards available with a lot of performance and availability data, a broad range of network device vendor support, a new RunAs account type for the community string to support SNMP V1, V2 and V3 credentials and so on. In addition to the features mentioned, Microsoft integrated a SNMP trap receiver right into SCOM and right there the confusion starts. I would like to show what it takes to get SNMP traps up and running.

What are the requirements?

As I mentioned before, there are many sources on the internet, but most of them are missing some information. So I would like to give a short summary what is really needed.

Here just 5 steps to get your SCOM trap receiver working:

1. You must install and configure, the SNMP Service itself. If the SNMP service is not installed, add these features to your management server…

2. In other monitoring scenarios, if you would like to receive traps you usually need to install the SNMP Trap Service from the Windows operating system. This is NOT the case for a SCOM 2012 management server, don’t do that! If you have the SNMP Trap Service installed in your Windows Service console, stop it and disable the service…

3. Configure the SNMP Service like here, it is pretty much self-explaining…

4. You must have your network device discovered in order to receive traps and generate alerts.

5. This last step is probably where the most problems occur. SNMP traps are available in different versions. It is like when you try to discover a network device, you must choose if it is a SNMP V1, V2 or V3 configured device. The same applies to traps. The trap version can be configured separately on the network device. But why is this important? If your device is discovered in SCOM as version 2 and you will create a trap rule using the SCOM rule wizard, this rule will be listening for the same SNMP version as the device had been discovered. If your device is known as SNMP version 2 in SCOM, SCOM expects also a trap SNMP version 2. If your device sends traps in version 1 for that device, you will not receive an alert.

That’s it!

What is the problem?

I configured a SNMP Trap (Alert) Rule…

…just run the wizard, choose as target Node and when you have to choose an OID don’t enter any value, click Next, Next, Finish.

Then export the management pack where you saved the rule and look at the entry. It looks like this…

…this basically takes the SNMPVersion property of the target object and gets the value during runtime. In this example version 2…

So in our case, if we discovered a device with SNMP version 2, it will also listen for traps version 2. If the discovered network device is configured to send traps in version 1, the rule will not trigger and alert.

How can I troubleshoot?

As a SCOM administrator there are few ways you can find out. The easiest way is to create a trap rule, which listens to all versions of traps, check this post from Wei H Lim .

We basically remove the <Version> section from the management pack, so it will look like this…

Then save your management pack and reimport it. Soon you will receive alerts and if check the Alert Context and you will find out, that there is the SNMP version visible, here version 1…

Another way is to check with your network administrator on the device itself, for Cisco devices use show snmp host command…

As you can see SNMP version 1 is configured.

What is the solution?

In fact, you cannot select the trap version in the GUI wizard. It will always use the same version as your discovered device.

There are only few things you can do:

1. Re-configure your network devices to use a consistent SNMP version.
2. Build trap rules which listen to all version of traps. There is some work involved, because you need to export the management pack, modify each rule and import the management pack.
3. Build trap rules which listens to the specific trap version. Just replace the part within the <Version></Version> tags and write the version you would like to receive. E.g. for SNMP version 2 modify it like this…

There is also some work involved, because you need to export the management pack, modify each rule and import the management pack. In addition you need to figure out first, which SNMP trap version each network device is using.

I hope this helps and saves you some headache 🙂 .