This document is part of the
Operations Manager Management Pack Authoring Center.
The discovery process lets you locate instances of classes and relationships that are defined in a management pack and create them in the Operations Manager database. A
discovery is an element that runs on agents creating new objects as they appear in the environment, changing the properties on existing objects, and removing objects as applications and components are uninstalled. Each class that is defined in the
service model must have at least one discovery associated with it or no instances of the class will ever be created.
Discoveries collect information from the local computer to determine whether one or more instances of a particular class are installed and collect values for its properties. The discovery itself is only responsible for collecting this information. It sends
the collected discovery data to the agent’s management server that is responsible for processing the collected data to insert into the Operations Manager database.
Discoveries are typically run on a scheduled basis. They continue to run on the agent even after instances are first discovered to determine whether changes were made. This interval will vary for different discoveries, balancing the considerations of the
time until a new instance is discovered with the overhead generated from the discovery process.
The first time that a discovery runs on an agent, it sends its information to the agent’s management server. It also stores a copy of the collected data in the local cache. Each successive time that discovery runs, the data is only sent to the management
server if a change is detected. Such changes could include a new instance, at least one property change to a previously discovered instance, or a previously discovered instance being removed. If any of these conditions are met, the discovery data is sent to
the management server where it is processed.
When the management server receives the discovery data, it will inspect it to determine whether the data is valid. This includes checks such as verifying that all specified classes and properties are valid and that all required key properties were provided.
If the discovery data is invalid, an error is generated on the management server and no discovery data is submitted. If the discovery data includes multiple instances and there is a problem with even a single instance, no data for any of the instances is submitted.
If the discovery data is valid, one of the following scenarios occur:
The primary responsibility of a discovery is to create discovery data. This includes the details of each class and relationship instance being discovered. A single discovery may only output a single set of discovery data. However, a single set of discovery
data can include a single instance of a single class or relationship, multiple instances of the same class or relationship, or multiple instances of multiple classes and relationships.
Discovery data must include the following information.
A discovery can access any information on the local agent to collect required information. The source of information will vary for different applications and for different classes and relationships. Because a management pack can include custom modules able
to access almost any available data, there is almost no limit to the sources that a particular discovery may use. There are a common set of data sources that apply to most scenarios however, and these are supported by modules included in management pack libraries
and wizards in the Authoring console.
Accessing the registry on the local computer is a preferred method of discovery because of the small overhead required. The registry frequently contains lots of easy to access configuration information for many applications. A discovery can check whether
a particular key or value exists, or it can collect the data from any value. Collected values may be either only collected for a property or compared to some known value to determine whether discovery data should be created.
For example, a discovery may have to check for a particular registry key to indicate that its application is installed on the local computer. If only a particular version of that application is supported by the management pack, a registry value holding the
application version may be inspected to determine whether an instance should be created. Other values in the registry may then be collected to populate properties of the discovered instance.
WMI can provide lots of information about a computer or Windows operating system components. It can also be the source of information for any application that includes a WMI provider exposing parts of the application through a WMI interface. A discovery
can run a WMI query to determine whether instances of a particular WMI class exist and to collect the properties from any returned instances.
For example, a particular management pack might collect information from the computer BIOS, that can be obtained by using the WMI32_BIOS WMI class.
If a discovery requires data inaccessible from the registry or WMI, or if the discovery needs more complex logic than those discoveries provide, a discovery script must be used. A discovery script can be written in any language that can access the MOM.ScriptAPI
COM object that is installed with the Operations Manager agent. The most typical scripts are written either in a language supported by Windows Script Host (VBScript or Jscript by default) or Windows PowerShell.
Discovery scripts that use VBScript or Jscript can be created by using modules in management pack libraries and wizards in the Authoring console. Modules are available for discovery scripts that are written in Windows PowerShell in Operations Manager R2
but are not supported by wizards in the Authoring console. A custom discovery would have to be created by using the appropriate module.
Any management pack requiring support by Operations Manager 2007 SP1 cannot use the Windows PowerShell modules because they are only installed with the Operations Manager R2 agent. In this case, custom discoveries that use Windows PowerShell can be created
by using a module that runs a command, configuring it to build the powershell.exe command line and starting the discovery script.
The target of a discovery determines where the discovery will run. Any agent managing an instance of the target class will run the discovery. In order to minimize overhead, the target for a discovery should represent the most specific class where the class
being discovered may potentially be found.
For example, a discovery determining whether an application is installed on a computer may have to target a broad class, such as the
Windows Operating System class, because the application could be potentially installed on any computer in the environment. Another discovery responsible for a particular component of that application could target the newly discovered application
class, because the component would presumably never be discovered on a computer where the application wasn’t installed.
In addition to instances of classes, instances of relationships must also be discovered. Hosting relationships are discovered automatically as part of the discovery of hosted objects, but containment relationships must be explicitly discovered.
Because a hosted object cannot exist without its hosting parent, the parent object must either already have been created before the child can be discovered or must be discovered at the same time as the child. Discovering the objects at the same time means
that both classes are discovered by the same discovery with instances included in the same set of discovery data.
Instances of hosting relationships are not explicitly discovered but are created automatically when a hosted object is discovered. If the object is hosted, the discovery data must provide the key property of any of its hosting parents in addition to the
key property for any instances that it includes. This is sufficient information to identify the source and target objects of the hosting relationship so that it can be automatically created.
For example, a class may be based on the Windows Computer Role class representing a particular application installed on a computer. Because the
Windows Computer Role class is hosted by the Windows Computer class, the application’s class is also hosted by the
Windows Computer class. The discovery for the class must provide the computer name because this is the key property of the
Windows Computer class, that is, the hosting parent of the object being discovered. If the class also had its own key property, this would have to be included. If it did not have a key property, the computer name would be the only key property
that would have to be provided.
Unlike hosting relationships, containment relationships must be explicitly discovered. The source and target objects for the relationship instance must either already have been discovered or be included in the same discovery. Containment relationships between
specific objects are usually discovered with a discovery script. The resulting discovery data specifies the GUID of the relationship in addition to the source object and target object for the relationship instance that should be created.
Groups are populated by creating instances of the containment relationship between the group objects and its members. You can do this by using a discovery script like other containment relationships, or a special group population module can be used. Group
population is different from other kinds of discoveries because it is performed on the Root Management Server by using information from the Operations Manager database instead of running on the agent that uses data that is collected from the local computer.
This process is typically easier and more efficient than manually creating the containment relationship instances.
The Authoring console does not provide a wizard for implementing group population. This kind of discovery must be created manually by using a special
Group Populator module.
Most discoveries discover objects managed by the local agent computer. There are scenarios where an agent may have to perform discovery of a particular object or set of objects that are either unhosted or hosted by another computer. An example of this scenario
may include collecting information from a Configuration Management Database. In this case, one agent might be responsible for running a discovery that uses a script to perform queries against information that is stored in the database. This information is
then used to create instances and set property values for objects that are located on other computers. The agent running the discovery is acting as a
proxy for the other agents.
The proxy scenario is typically performed with a script because other kinds of discovery are typically unable to access the required data or perform the required logic. As previously discussed, discovery data requires the key property of each discovered
object and any of their hosting parents. In the proxy scenario, the hosting computer will differ from the agent running the discovery, and the discovery merely needs to provide this computer name in the discovery data. The object will be discovered and managed
by the specified agent.
In order to perform discovery on behalf of another agent or discovery of an unhosted object, the agent running the discovery must have its proxy setting enabled. If this proxy setting is not enabled, the discovery will generate an error, and the discovered
instances will not be created. The proxy setting is configured in the Agent Properties, which are accessed from the Administration pane in the Operations console.
Most discoveries are performed on a scheduled basis. New objects or changes to existing objects are not discovered until the next time that the discovery for the particular class is scheduled to run. Discoveries with intervals that are too frequent put too
great a load on the agent performing discovery, whereas discoveries that are too infrequent can take too much time to recognize such changes.
Discoveries can be designed to be executed in response to a particular event, assuming that an application generates such an event in response to a configuration change. In this case, the discovery could be run immediately after the configuration change
and may not have to be scheduled. A discovery could also be designed to be run on demand by a user through an
The Authoring console provides wizards for scheduled discoveries only. Discoveries that run on demand or in response to an event may be created by using the Authoring console, but they must be created with custom discoveries that use custom modules.
After a set of classes and relationships is defined for an application, a method of discovering each must be defined. No instances of a class will be available for monitoring in Operations Manager until they are discovered.
There are three basic questions that must be answered for each class requiring discovery.
The discovery process for an application model composed of multiple classes will typically be performed in multiple steps, with each step including one or multiple discoveries. A basic set of classes is first discovered to identify the agents where the application
is installed. These classes act as targets for successive discovery of other classes.
For the basic model described in
Defining Classes and Relationships, discovery can typically be performed in three basic steps.
The first step in the discovery process for an application model with multiple classes is typically to identify which agents the application is installed on. Because application installations are identified by the application role classes based on the
Windows Computer Role class or the Windows Local Application
class, these are typically the first classes discovered.
These discoveries will typically target a broad class, such as Windows Operating System, because the application could be installed on any computer in the environment. There is no way to know which computers the application is installed
on until the discovery runs. If the application can only be installed on a particular version of Windows or if it can only be installed on a server or a client operating system, a slightly more refined target could be used. Examples include the
Windows Server Operating System class for an application that could only be installed on a server or the
Windows Server 2008 class for an application that could only be installed on a computer that is running Windows Server 2008.
Because discoveries of application roles are targeted at such a broad class, only registry discoveries should be used because they consume minimal resources. A heavier kind of discovery, such as a script, would put an unnecessary load on multiple computers
that do not have an instance of the class being discovered. For most applications, a registry key is sufficient to at least confirm that the application exists. If certain properties must use another data source, such as a script, an additional discovery for
the same class could be added that targeted to the class itself. This would guarantee that the more resource-intensive process runs only on those agents where it is required.
After the application’s roles are discovered, the newly discovered objects can be used as targets for discoveries identifying application components. These classes are typically hosted by one of the application’s roles so that the hosting parent class can
be used for the target. In addition to making sure that the discovery only runs on those agents where instances of the class being discovered are likely to be located, using the hosting parent as a target provides access to the hosting parent class’s properties
by using $Target variables.
For example, suppose that a class named MyLocalApplication hosts a class called MyApplicationComponent. When an instance of MyApplicationComponent is discovered, it must provide a value for any key properties of MyLocalApplication because that is the class’s
hosting parent. If the discovery for MyApplicationComponent targets MyLocalApplication, the discovery has access to all the properties of MyLocalApplication by using $Target variables.
Discoveries for application components typically use either WMI or script discovery. Registry discovery can be used if information about the application is stored there, but frequently another data source is required for this information. If a WMI provider
for the application is available and the discovery does not require complex logic, a WMI discovery can be used. If more complex logic is required, a script can be used to access information from the registry, WMI, or any other data source that can be accessed
from a script.
After all other classes are discovered, group population may be performed because this discovery uses instances and properties that have already been discovered. Group population discoveries target the group class itself. Because groups are unhosted, they
are managed by the Root Management Server. Any discoveries targeted at a group class will run on the RMS. This is appropriate because this is where group population discoveries are required to run so that the discovery can access information in the Operations
Most discoveries are run at set intervals, and this interval must be specified when the discovery is created. If the interval is too long, the user may have to wait an extended time until new instances or changes to existing instances are discovered. For
example, a particular discovery for an application may be configured to run one time every 24 hours. When a new copy of the application is installed on a computer, it may take that long until the new instance appears in Operations Manager 2007 and monitoring
Too short a time interval puts too much overhead on agents while providing minimal value. Also, if instances of the discovered class are expected to change frequently enough to warrant an aggressive discovery schedule, the design of the class may violate
the best practices for classes as described here.
The following table provides recommended intervals for different kinds of discoveries.
The following are common practices that should be avoided when defining discoveries.
New objects installed on a managed computer or changes to existing objects will not be recognized by Operations Manager until the next time that the discovery for the class runs. Frequencies of only a few minutes are sometimes used to reduce the time that
is required for such additions and changes to be detected. However, a short frequency interval increases the load on the agent running the discovery and usually provides minimal value.
Even though a particular management pack may have only a few discoveries, an agent must run discoveries from multiple management packs installed in the environment in addition to the other kinds of workflows, such as rules and monitors. Because of this,
care should be taken to balance the need for quick detection of changes with a minimization of overhead.
If a particular class requires a short discovery interval because of frequent changes to the application’s components, this may indicate a health model that violates the above recommendations for volatile objects and properties that update frequently.
Discoveries for some classes in a management pack will need to search across all computers in an environment (or at least a large set of computers) to identify where the application is installed. These discoveries will continue to run on a regular basis
even though the application may never be installed on most of these computers.
Because of their fairly small overhead, we strongly recommended that only registry discoveries target broad classes, such as the
Windows Operating System class. Script discoveries that have significantly larger resource requirements should target only those classes specific to the application that were previously discovered through the registry. This strategy means that
only those computers that have the application installed are required to run the scripts. Computers without the application installed must run only registry discoveries. These have minimal resource requirements.
There is a 4 MB limit to the discovery data that can be sent from the agent to the server at one time. If there is a need to discover a lot of data that might cross this
limit, break the discovery down to discover different object types as a part of different discoveries. It is also possible to have the discovery run at the management server to bypass the 4 MB limit.