Illustration from Altova XML Spy

A discovery is a dedicated workflow that must submit discovery data.  No other data can be submitted from the workflow.  You should never use a rule to submit discovery data – always use a discovery.  Discoveries are shown in the Operations Console under the Object Discoveries folder in the Authoring space. 

A discovery consists of a declaration of types that the workflow will discover and a single data source module.  If you need to use more than one module in your workflow you must first create a composite data source module type.

A discovery has the following attributes:

Name	Type	Use	Description
ID	ManagementPackUniqueIdentifier	required	The identity of the element.  This must be unique within all elements of the management pack
Comment	ManagementPackString	optional	Use for author comments.
Enabled	ManagementPackMonitoringLevel	optional
Target	ManagementPackIdentifierReference	required	The target class.  The workflow will run against all instances of the targeted class
Confirm Delivery	xsi:boolean	optional	TBC
Remoteable	xsi:boolean	optional	Defines whether this workflow will run for agentless monitoring.  If it is not specified it is assumed to be true
Priority	ManagementPackWorkflowPriority	optional	TBC

Category

The category of a discovery should always be set to Discovery.

Discovery Types

This element declares the classes and relationships that the discovery will discovery.  This information is used to show the correct discoveries when the Operations Console user scopes to a target in the Object Discoveries view.  In future versions of Operations Manager it is planned to not allow discovery data that is outside of the declared types in this section so it is best practice to enter a full set of information in this section.  The schema for this section is as follows:

Illustration from Altova XML Spy

Consider the following class definition:

<ClassType ID="Demo.ApplicationX" Abstract="false" Accessibility="Internal" Hosted="true" Base="Windows!Microsoft.Windows.LocalApplication">

  <Property ID="Version" Type="string"/>

  <Property ID="Path" Type="string"/>

</ClassType>

If I have a discovery that discovers only instances of this class the basic discovery types section would be as follows:

<DiscoveryTypes>

  <DiscoveryClass TypeID="Demo.ApplicationX">

    <Property PropertyID="Version"/>

    <Property PropertyID="Path"/>

  </DiscoveryClass>

</DiscoveryTypes>

 

However since all classes inherit a DisplayName property from System.Entity I should specify this property as well if I discovery it.  Since this is an inherited property I have to qualify the property with the ID of the class it is defined on (in this case System.Entity in the System.Library MP).  So my revised declaration is as follows:

 

<DiscoveryTypes>

  <DiscoveryClass TypeID="Demo.ApplicationX">

    <Property PropertyID="Version"/>

    <Property PropertyID="Path"/>

    <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>

  </DiscoveryClass>

</DiscoveryTypes>

 

Finally my class derives from Windows Local Application.  This is hosted by a Windows computer.  Therefore when I insert instances of my class I am implicity creating a hosting relationship with Windows computer.  Therefore to be fully accurate in my declration I should include the relationship type in my declaration.  Therefore the full discovery types declaration is:

 

<DiscoveryTypes>

  <DiscoveryClass TypeID="Demo.ApplicationX">

    <Property PropertyID="Version"/>

    <Property PropertyID="Path"/>

    <Property TypeID="System!System.Entity" PropertyID="DisplayName"/>

  </DiscoveryClass>

  <DiscoveryRelationship TypeID="Windows!Microsoft.Windows.ComputerHostsLocalApplication"/>

</DiscoveryTypes>

 

Data Source

The data source element must reference a data source module type previously declared in this management pack or a referenced management pack.  This element is considered a Management Pack Sub-Element and can have a display string defined for it.  The data source element has the following attributes

Name	Type	Use	Description
ID	ManagementPackLocal IdentifierReference	required	The identity of the sub-element.  This must be unique within the containing element.  Since there is only one sub element within a discovery there can be no ID collisions so you can use anything you want here.  Often you just call it DS.
Comment	ManagementPackString	optional	Use for author comments.
RunAs	ManagementPack IdentifierReference	optional	References a secure reference.  You should use this attribute only if you want to associate this module with a Run As profile.
TypeID	ManagementPack IdentifierReference	optional	The ID of the data source module type that is to be used.

 

The data source that you use must output discovery data.  These modules are common examples of types used for discovery:

 

• Microsoft.Windows.Discovery.RegistryProvider
• Microsoft.Windows.FilteredRegistryDiscoveryProvider
• Microsoft.Windows.TimedScript.DiscoveryProvider
• Microsoft.Windows.WmiProviderWithClassSnapshotDataMapper

The data source element must contain the necessary configuration for the module type.  MPVerify will check this configuration.  It is not possible for XML tools to verify the inner XML of the data source element because this is a schema within a schema.  The MP Schema allows any XML:

Illustration from Altova XML Spy

 

This discovery uses the existence of a registry key to discovery a class instance.  For the full management pack sample which this discovery is taken from see the AuthorMPs.Demo.ClassDiscoveryUsingRegistryKey.xml sample MP.