During a migration project from Opalis 6.3 to Orchestrator 2012, I had to migrate a runbook that was using the Monitor SNMP Trap activity. The idea of this runbook is to receive a trap that is composed of two OIDs, first one contains the target name and the second one contains the description and to raise an alert in Operations Manager (SCOM) based on there values.
In Opalis, as I explained here : http://scug.be/christopher/2011/06/17/system-center-opalis-monitor-snmp-trap-activity/ this configuration is working. Now, it’s time to migrate it ! As this is a quite simple runbook, I just did a runbook export in Opalis, an import in Orchestrator and started the runbook.
To test the good working of my newly imported runbook, I sent several SNMP traps to my orchestrator server. I noticed that the Monitor SNMP Trap activity catch the trap, published the result correctly, but when I checked the content of the trap, the result was really not what I was expecting. Let’s me explain what I did in detail.
I used the command line application SNMPTrapGen ( http://www.snmpsoft.com/freetools/snmptrapgen.html ) , to send a SNMP trap to the Orchestrator server. Below the content of my SNMP Trap :
C:SnmpTrapGen.exe -r:OrchestratorServer -v:2c -p:162 -to:.126.96.36.199.4.1 -vid:.188.8.131.52.4.1.11307.10.1 -val:'azerty' -vtp:str SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company [ More useful network tools on http://www.snmpsoft.com ] OK
As my trap contained the string ‘azerty’, I was expecting to receive the same value from the Monitor SNMP Trap activity in Orchestrator, but I received the following value :
I did several tests and every time that I sent a SNMP Trap that was containing a string to Orchestrator, the Monitor SNMP Trap activity published a suite of numbers, which was really not the contain that I was expecting. I also did a network capture on the Orchestrator to check if the trap content was correct and yes, it was.
As it was not working when I sent a string value, I tried to sent an integer value to Orchestrator :
C:SnmpTrapGen.exe -r:gdcgmsoap702 -v:2c -p:162 -to:.184.108.40.206.4.1 -vid:.220.127.116.11.4.1.11307.10.1 -val:12345 -vtp:int SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company [ More useful network tools on http://www.snmpsoft.com ] OK
and there, Orchestrator returned the right value.
After all my tests, I observed that the Monitor SNMP Trap activity always returned a suite of number when the SNMP trap was containing a string value. In that project, It’s what I need to do, I have to pass a string value to this activity. As this was working perfectly with Opalis and not anymore with Orchestrator, I continued my investigation and I focused on the Monitor SNMP Trap activity itself.
By default, this activity use the Microsoft SNMP Trap Services :
I decided to choose the “No dependency’” connection. For that configuration, the first step is to stop and disable the SNMP Trap service on the Orchestrator server.
I changed the connection setting of the Monitor SNMP Trap activity and I started my runbook again.
I sent a new trap, which was containing a string value, to my Orchestrator with the SNMPTrapGen command line..
C:SnmpTrapGen.exe -r:gdcgmsoap702 -v:2c -p:162 -to:.18.104.22.168.4.1 -vid:.22.214.171.124.4.1.11307.10.1 -val:"azerty test" -vtp:str SnmpTrapGen v1.1 - Copyright (C) 2009 SnmpSoft Company [ More useful network tools on http://www.snmpsoft.com ] OK
And this time, when I checked the value returned by the Monitor SNMP Trap activity, it was correct
Yes, We have a solution to get this working ! I don’t know exactly why this was working correctly with the Microsoft SNMP Trap Service in Opalis 6.3 and not anymore with the same service in Orchestrator 2012. If you have me more information about it, please contact me.
As I changed the Monitor SNMP Trap activity connection to No Dependency, we are now limiting to run only one instance of the Monitor SNMP Trap activity on this Orchestrator server (on the same port), which was not the case by using the Microsoft SNMP Trap Service connection. By changing the connection type, this activity is taking the control on the defined port and it seems logical that it cannot be shared with another activity.
Now that I can only use one Monitor SNMP Trap activity, what can I do if I need to receive SNMP Traps from several locations ? Well, You will have to redesign your runbooks to get only one entry point for all the SNMP traps :
Configured the Monitor SNMP Trap activity to get and publish all the different OIDs that you will need .
On the link between the Monitor SNMP Trap and the Invoke Runbook activities, apply a filter based on the SNMP Trap sender IP address.
You have to define all the published OIDs value that you need to pass to your Invoke Runbook activity.
And finally pass these information to your original runbook by replacing the Monitor SNMP Trap activity with an Initialize Data activity .
I hope this post could help you to configure the SNMP Trap monitor with Orchestrator 2012.