Discovery

Applies To: System Center Operations Manager 2007

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.

Note

Discovery does not apply to abstract or singleton classes.

The Mechanics of Discovery

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.

Discovery process

Overview of discovery process

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 occurs.

  • If any of the instances have not previously been discovered, they are then created.

  • If any of the instances have previously been discovered, any properties that may have changed are replaced with the value in the discovery data.

  • Any instances that were previously discovered but that are not in the current discovery data are removed.

Discovery data always includes the ID of the discovery itself and the ID of the target object. These values are then stored with all discovered objects. This is how data from a discovery can be compared to previously discovered data.

Discovery Data

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.

  • GUID of the discovery element itself

  • GUID of the target object that the discovery is running against

  • GUID of each class or relationship being discovered

  • Value for each key property of any class instances

  • Value for each key property of any hosting parents of any class instances

  • Source and target object for any relationship instances

In addition to this information, the discovery data can also include values for any non-key properties.

Conceptual view of discovery data

Conceptual view of discovery data

Each kind of discovery accesses this information through different means by using a combination of information that is provided by the management pack author and variables that are resolved when the management pack is run. Script discoveries in particular must be aware of each of these elements and explicitly provide a value for each.

Discovery Data Sources

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.

Registry

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

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.

Scripts

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.

Discovery Targets

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.

Discovering Relationships

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.

Hosting Relationships

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.

Conceptual view of class instance

Conceptual view of class instance

Containment Relationships

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.

Conceptual view of relationship instance

Conceptual view of relationship instance

Populating Groups

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.

Proxy Discoveries

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.

Discovery on Demand

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 Agent Task.

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.

See Also

Concepts

Defining Discoveries

Other Resources

Creating Discoveries