I'm trying to monitor a temperature sensor via the Network Device monitoring capability of Operations Manager. The device supports MIB-II, except that is does not support OID: 1.3.6.1.2.1.1.5 (sysContact). Which according to this link: http://www.systemcentercentral.com/snmp-discovery-fails-scom-2012/, will cause Operations Manager to fail to discover the device as an SNMP device. I've confirmed the failure via Microsoft Network Monitor, where I can see the response from the device back to the Management Server with the ErrorStatus: noSuchName (2), ErrorIndex: 3.

Is there a way to make Operations Manager ignore just the OID: 1.3.6.1.2.1.1.5 (sysContact) ? I'll be authoring a custom MP but I need the device to be added as a network device into Operations Manager first...

Thanks,

Hi,

According to the link:

http://www.systemcentercentral.com/snmp-discovery-fails-scom-2012/

" After clarification with Microsoft we now know that the following OIDs MUST exist and appropriate values must be visible:

• .1.3.6.1.2.1.1.1 (sysDescr)
• .1.3.6.1.2.1.1.2 (sysObjectID)
• .1.3.6.1.2.1.1.4 (sysContact)
• .1.3.6.1.2.1.1.5 (sysName)
• .1.3.6.1.2.1.1.6 (sysLocation)

If only one of them is missing your discovery will fail"

And OID: 1.3.6.1.2.1.1.5 should be for sysName.

Regards,

Yan Li

Just to clarify, the device in question does not support OID: 1.3.6.1.2.1.1.4 (sysContact).

I know what that link says, I referenced it in the question. But that link is NOT a KB article and it would be nice to have a formal KB article to reference if it is in fact a requirement (or limitation?).

Also, sysObjectID and perhaps sysName should really be the only necessary OIDs. The others shouldnt really matter. Ive come accross various environmental monitoring devices that partially implement MIB-II, that skip sysContact and/or sysLocation and thus fail to be discovered by SCOM. Which is disappointing, because I could write up an MP to monitor these devices otherwise, but the initial discovery needs to succeed!

If anyone has any idea how to make SCOM ignore these less important OID's to get the initial discovery to work, please post - thanks!

Hi,

Please refer to the following link:

http://technet.microsoft.com/en-us/library/hh212935.aspx

Best Regards,

Vincent Wu

Vincent that technet link does not detail the above considerations around the actual OID's required.

I ended up logging a case with Microsoft and essentially they ended up confirming the information in the link: http://www.systemcentercentral.com/snmp-discovery-fails-scom-2012/. They did not supply any extra technical details as to why this is the case and said that there is no way to adjust this behaviour.

Therefore, the only way to monitor devices that do no implement all 5 MIB-II OID's is to monitor them as ICMPONLY devices. You will then have to ensure that the Community String RunAs Account is associated with the SNMP RunAs Profile. You will also need to ensure that SNMP Version property in the Node object is adjusted to version 1 if the device happens to use version 1 - otherwise it will default to version 2 and any SNMP queiries making use of the SNMP Version property will fail.

Apparently, Microsoft will at some point publish an article but I have no timeframe about when that will be.

• Marked as answer by David B 101 Monday, September 15, 2014 10:03 PM

Vincent that technet link does not detail the above considerations around the actual OID's required.

I ended up logging a case with Microsoft and essentially they ended up confirming the information in the link: http://www.systemcentercentral.com/snmp-discovery-fails-scom-2012/. They did not supply any extra technical details as to why this is the case and said that there is no way to adjust this behaviour.

Therefore, the only way to monitor devices that do no implement all 5 MIB-II OID's is to monitor them as ICMPONLY devices. You will then have to ensure that the Community String RunAs Account is associated with the SNMP RunAs Profile. You will also need to ensure that SNMP Version property in the Node object is adjusted to version 1 if the device happens to use version 1 - otherwise it will default to version 2 and any SNMP queiries making use of the SNMP Version property will fail.

Apparently, Microsoft will at some point publish an article but I have no timeframe about when that will be.

• Marked as answer by David B 101 Monday, September 15, 2014 10:03 PM

Vincent that technet link does not detail the above considerations around the actual OID's required.

I ended up logging a case with Microsoft and essentially they ended up confirming the information in the link: http://www.systemcentercentral.com/snmp-discovery-fails-scom-2012/. They did not supply any extra technical details as to why this is the case and said that there is no way to adjust this behaviour.

Therefore, the only way to monitor devices that do no implement all 5 MIB-II OID's is to monitor them as ICMPONLY devices. You will then have to ensure that the Community String RunAs Account is associated with the SNMP RunAs Profile. You will also need to ensure that SNMP Version property in the Node object is adjusted to version 1 if the device happens to use version 1 - otherwise it will default to version 2 and any SNMP queiries making use of the SNMP Version property will fail.

Apparently, Microsoft will at some point publish an article but I have no timeframe about when that will be.

• Marked as answer by David B 101 Monday, September 15, 2014 10:03 PM

I'm running into this issue where the SNMP device hasn't implemented;- 

• .1.3.6.1.2.1.1.1 (sysDescr)
• .1.3.6.1.2.1.1.2 (sysObjectID)
• .1.3.6.1.2.1.1.4 (sysContact)
• .1.3.6.1.2.1.1.5 (sysName)
• .1.3.6.1.2.1.1.6 (sysLocation)

It sounds from your response that you were successfully able to workaround this issue.  I'm trying to follow your workaround, but am not having success.

The device gets discovered ok using an ICMP only discovery, but when I look at a packet capture of the SNMP traffic, a blank community string is being used for the custom SNMP performance rule I created.

When I created the discovery rule, I did select a Run As account that had the correct (non-blank) community string specified.

Ideas?

Hi y2b4sure,

I had to manually associate the RunAs Account (with the Community String) to the SNMP RunAs Profile (for an unknown reason, when using ICMP-only discovery, the association you make in the Network Discovery Rule has no effect).

I hope that helps.