Stupid Little Problem with SNMP Version Tags

Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.

I don’t normally get to work with SNMP, but I’ve been at a customer this week where we needed to configure SCOM to do SNMP monitoring.  This is fairly straight forward, and Kevin has written a nice article how to do that here.  I ran into an issue though with regards to removing the version tags.

First, let’s start with a recap of the problem. If a network object is discovered with one version of SNMP, traps generated by a different version of SNMP by the same object will not generate alerts. This is a known issue.  I’m not sure of the logic behind it, but whatever.  The solution is documented. All we need to do is remove the version tag or simply clear the contents of said version tag.  Again, this is straight forward and documented.

My discovery though is that if by chance one were to choose to edit the SNMP monitor or rule, SCOM is so kind as to decide to add the contents of the version string back into the unsealed MP. It does this whether you remove the tag or simply clear its contents.  What this means is that if you ever need to go back and edit your custom SNMP Monitor or Rule, you need to do this task again.

SLIGHT UPDATE:  This appears to happen only to monitors. Rules do not re-write the version tag.