Watch Those Variant Types
August 13, 2009 2 Comments
When creating some types of Unit Monitors (such as SNMP polls) in the OpsMgr GUI, SCOM will set the default type of the values in the expressions to be strings. If your health monitoring logic performs numerical comparisons, this will create unexpected and unreliable results, because the monitor will be performing comparisons on the numbers as strings, instead of as numerical data (if the system believes the values are strings, greater than and less than operators are concerned with alphabetical order, and not numerical comparisions).
The good news is that the fix is rather easy, just export the management pack, edit the type definitions in the XML file, and import it back.
For more details:
As an example, we can create a simple SNMP Event Monitor to alert on a low CPU idle value on non-Windows servers running net-snmp. Start with creating the two-state SNMP probe monitor.
We define the SNMP OID (1.3.6.1.4.1.2021.11.11.0 in this case), and set up the error condition (less than or equal to 15).
We complete the second expression and set the Health State configuration to finish the monitor creation.
The problem with stopping here is that SCOM will retrieve the SNMP value, and perform a “less than or equal to” comparison on the numbers as if they were text.
If we export the MP and look at the XML for the monitor (under the Configuration section), we will see that the value retrieved from SNMP is a varianttype 8 (string), but more problematically, the comparison is using “String” types for the values. It’s ok to leave the SNMP value as a string varianttype, because we can force an implicit conversion to a numerical value in the expression.
To fix this, change the “Type” attributes for the ValueExpressions from “String” to “Integer” (or “Double” if dealing with non-integer numerical values). Because there are two expressions in a two-state monitor, this has to be done for both expressions. If you’re used to the MP Authoring Console, it’s easy to edit these values there instead of in the raw XML.
Then, just import the MP back into SCOM. If the expressions are modified on the monitor in the GUI again, this proces will have to be repeated.
About Kristopher Bash
Operating-Quadrant 
Thanks for writing this article, we ran into this particular issue with SCOM 2007 R2 and with the information quickly resolved it.
We found we also needed to set the VariantType to 3 (integer) rather than the 8 (string) and we also needed to use a XPathQuery of “/DataItem/SnmpVarBinds/SnmpVarBinds[2]/Value” to actually get the condition to be met.
We were left pondering why they didn’t create a drop down box for variable type in the application GUI and ability to run a live check…would save a load of time when setting up a lot of monitors!
I agree with you about the obvious omission from the GUI. However, much of OpsMgr’s SNMP capability is not exposed through the GUI, but only in the Authoring Console, and even then, much of it is not terribly well documented. I suspect this is an area that will be improving in every future version.
If you’re working in the Authoring Console and creating composite datasources, there’s a bit of handy trick you can play with the SNMP data types. A null value can be converted to a string without error, but not to a numeric data type. So if you’re polling an OID that may or may not have a value, you can use an expression filter to compare the value in string form, and only if it looks ok there pass it to a condition detection that compares it in numeric form.