Troubleshooting SCOM discovery - a thorough how-to

Something not getting discovered? Objects not appearing in the console after importing a management pack?

Too often it turns out the wrong version of the product's management pack was imported, or a typo in the Run As Account credentials. So double-, triple-check:

Do you have the right management pack? Do you have the right account credentials?

Only then follow these steps:

• Determine the seed discovery class for the management pack. This is the first class that gets populated after the MP is imported.
  • To do this, look up all the discovery rules in the MP. You can find these discovery rules by finding your MP on SystemCenterCore.com or use the MPViewer tool. In this example, I'll use SystemCenterCore.com.
  • We're looking for the seed discovery rule. The seed discovery rule usually says “seed” somewhere in the name. But if this is missing, you can also find it because it’s typically the only discovery that targets a more common class:
    • Here's a screenshot from SystemCenterCore.com (note, this is a non-Microsoft website) showing all the discoveries in the Microsoft BizTalk Server 2013 MP
    • Look at the "Target" column for all these discoveries:
      • 
    • We see one discovery rule that targets Windows Computers, a 'common' class. This is our seed discovery; the one that all the other discovery rules depend on.
• Find the Class name that the seed discovery rule discovers/populates (this is NOT the same as the Target)
  • 
  • In this example, the class name is Microsoft.BizTalk.Server.2013.BizTalkInstallation

• • In the SCOM console, Monitoring Pane, Discovered Inventory view – Change Target Type (see right-side Task pane) of this view to the class name you just found. This will show us if the seed class has populated.
    • 
  • If there are no results, the seed discovery is not working. If there are results, the seed discovery IS working, but perhaps a subsequent discovery rule is not, or the other view you were using is not populating correctly.
    • Check that the discovery rules are enabled
    • Check if the MP uses a Run As account: check the Distribution of the account and all appropriate agents have this account distributed to them
    • Look in the OpsMgr event log on an agent and verify it has downloaded the MP (filter for event ID 1201 - the event description includes MP name and version)
    • Check the frequency/interval of the discovery rule – has enough time passed?
    • Finally, after confirming everything above – look at the actual configuration of the discovery rule. You can see this in the Authoring pane, MPViewer, or SystemCenterCore.com. The raw XML will show you what the rule looks for on the agent. Usually it’s a registry key. Verify the agent has this.
      • <Continuing the example with screenshots from SystemCenterCore.com:>
      • 
    • At this point, if everything is verified – Run As Account, healthy Agent, existence of registry key…you’re best off opening a support case because something is going wrong! Possibly the management group has stopped processing configuration. But in my experience, 98% of the time, some step above has been missed. Double check everything.