Questions seem to be coming up more and more about using SNMP with MOM 2005. I thought I’d take a few minutes here to go over how MOM and SNMP interact.
Sending SNMP Traps
SNMP traps are generated in MOM 2005 as a response action on various rules. When the rule fires, MOM 2005 will write the trap information to the local registry and the SNMP service (which must already be configured – if not configure it in add/remove programs) will then retrieve that data and pass it along to the trap receiver that is part of the configured SNMP community. MOM can be configured to generate SNMP traps either on the MOM management server or the agent itself.
When MOM generates an SNMP trap it writes the data for the trap to the local registry at HKLM/Software/Mission Critical Software/Onepoint/SNMP/Data and sets a value in this key called ‘dataavailable’ to 1 which prevents further SNMP trap information from being written until the SNMP service picks up the data already present and resets the ‘dataavailable’ flag back to 0.
The SNMP service should automatically be configured to scan the MOM regisry keys and retrieve the SNMP data. In some cases, however, the SNMP service may not be configured to scan for MOM data. If this happens, the SNMP data will remain in the MOM registry keys and subsequent SNMP responses will fail. To verify that SNMP is configured correctly check the SNMP registry key, located at HKLM/System/CurrentControlSet/Services/SNMP/Parameters/ExtensionAgents, to verify the value MCSExtnAgent exists and points to the MOM SNMP registry hive – HKLM/Software/Mission Critical Software/Onepoint/SNMP.
SNMP traps are typically configured on rules that also generate alerts. On the alert tab of the event rule there is an option to ‘suppress duplicate alerts’ – which helps keep the noise down while problem conditions are investigated. SNMP responses are not subject to alert suppression. For this reason, it is normal to receive multiple SNMP traps for a rule where alert suppression is disabled. Take a look at knowledge base article 883338 if it is desired to avoid these multiple SNMP traps. This article discusses a method of creating two event rules, one to detect the problem condition and execute a script and a second rule to detect the execution of the script and send an SNMP trap. The following diagram illustrates how these rules interact. Rule 1 detects the problem event and rule 2 generates an SNMP trap.
This example works to ‘workaround’ the fact that duplicate SNMP traps are not suppressed and is effective because duplicate script responses ARE suppressed. One drawback to this approach, however, is that the script described in the article to trigger action by rule 2 does not provide for passing the data for the initial event of interest to rule 2. A simple modification of the script using the methods available in the MOM SDK can facilitate passing event data to rule 2 which will then allow this data to be included in the SNMP trap. The following sample modification illustrates how this might be done – the example uses static data but with SDK methods the static data could easily be replaced with dynamic data based on the events being received by rule 1.
set objEvent = ScriptContext.CreateEvent()
objevent.eventnumber = 9999
objevent.eventtype = event_type_warning
Receiving SNMP traps
It is also possible to configure MOM 2005 to receive and respond to traps. The process is fairly simple and is well described in the attached powerpoint presentation that was developed by Bob Wilton on our WMI team. Essentially, SNMP trap information is received by WMI by using the WMI SNMP provider. MOM, then, is able to tap into WMI to read the trap information received and act on that information accordingly. The attached presentation explains this process is greater detail.