Today I was addressing this error in the Operations Manager event log at one of my customers:

Error in SNMP GET response from IP Address: Status: noSuchInstance(129)

According to What Gets Monitored with System Center Operations Manager 2012 Network Monitoring this can be caused by several things:

Possible Resolutions

• Stale Discovery Data – Device has been reconfigured since the last discovery and Operations Manager is attempting to monitor a component that no longer exists on the device.
• If the device doesn’t support the workflow, then a solution is to disable the workflows utilizing the value for the device. This will prevent these workflows loading and failing in the future.
• Possibly a device issue, try updating the Firmware and OS on the device
• Possible a discovery issue where the instance is being discovered incorrectly.  For example Operations Manager is expecting to monitor a performance counter but this is a virtual interface and the counters are not present for the interface.  Try running a re-discovery for the device.

In my clients case the network devices in question did not respond to the information request of certain workflows.

I resolved the issue by creating a group and adding the ports which were not returning data to that group. Then I evaluated each of the event log errors for the name of the workflow that was executing the snmp get, see example below:

Log Name:      Operations Manager
Source:       Health Service Modules
Event ID:      11009
Error in SNMP GET response from IP Address: 10.11.11.1, Status: noSuchInstance(129).
One or more workflows were affected by this.
OID: .1.3.6.1.2.1.10.7.2.1.2.268
Workflow name: System.NetworkManagement.MIB2.NetworkAdapter.InputPacketBroadcastPct
Instance name: Port-37

There is a great reference at http://mpdb.azurewebsites.net which you can use to match up the workflow name to the corresponding rule or monitor. If I use the above example and search the page for System.NetworkManagement.MIB2.NetworkAdapter.InputPacketBroadcastPct I can see it correlates to a rule called Input Broadcast Packets Percentage (netcor) which I can override to turn off against the group I created earlier.

It can be a lengthy process and there are other causes which are easier to address so you will need to do some testing in each individual case.