Administrator Console - MOM Author Features and Concepts

The Administrator console is used by a MOM Author to implement and adjust monitoring and management criteria.

The following table lists the main categories and sub-categories of the Management Packs node of the navigation pane and summarizes the purpose of each.

Table 3 Administrator console - Management Packs

Category/sub-category	Purpose
Computer Groups	Create computer groups, manage subgroups, delete a computer group, calculate group membership, and view/modify the properties of a computer group.
Discovered Groups	Create a replica of any discovered groups.
Rule Groups	Create a rule group, find rules, associate with a computer group, and view/modify the properties of a rule group.
Event Rules	Create a rule, find rules, configure alert handling (respond, filter, detect missing event), consolidate rule type, and view/modify rule properties.
Alert Rules	Create a rule, find rules, configure alert response, and view/modify rule properties.
Performance Rules	Create a rule, find rules, configure data sampling, configure performance data comparison, and view/modify rule properties.
Search Results	Search, and store the results of searches against rules and rule groups.
Override Criteria	Create an override that is not associated with a rule.
Tasks	Create pre-defined actions that are available to a MOM user.
Notification	Specify the recipients of notifications. Manage notifications by group.
Operators	Identify specific operations staff and give them the level of privilege that they require for their job.
Scripts	Create and view/modify scripts.
Computer Attributes	Create a computer attribute and view/modify attribute properties.
Providers	Create a provider and view/modify provider properties.

Management Packs

Management packs serve as a container and distribution vehicle that MOM uses to deploy the configuration information required for managing computers and applications.

A Management Pack consists of a collection of rules, knowledge, and public views. The Management Pack makes it possible to collect a wide range of information from different sources. Management Packs are used to determine how a MOM management server collects, handles, and responds to data. You can, and should, tailor Management Packs for your own environment.

Important

There is no generic, one size fits all Management Pack. The complexity and specific requirements of the computers and applications that organizations have to manage requires varying degrees of specificity. For example, a valid performance indicator for the operating system probably doesnt transpose well to an application such as Exchange Server.

Management Pack Content

The following information can be contained in a Management Pack:

• A list of Rule Groups that contain rules.

• A list of Rules for each Rule Group.

• A list of Provider Instances that the Rules reference.

• A list of Scripts that Rules need to call in response to an event.

• A list of registry-based Computer Attributes that are needed for discovery.

• A list of Computer Groups whose formula depends on the specified Computer Attributes.

• A list of Computer Group and Rule Group associations that specify rule targets.

• A list of Notification Groups that notification responses use in rules.

• A list of view instances definitions that define how the operations data produced by managed computers should be viewed.

• A list of Tasks that a user might need for managing the application.

• The Service Discovery Class Schema that defines the entities that will be managed, their properties, and their relationship to other properties.

• The Diagram Definitions that describes how service discovery data should be viewed as a diagram from an application perspective.

• Knowledge associated with the rules which specify how problems should be corrected and how the Management Pack should be used.

Management Pack formats

Management packs have three formats:

• A binary file called an AKM file. Management packs are usually distributed in this format.

• An XML file that describes the contents in human readable form. This format is used to edit and compare Management Packs.

• The database format used to store information in the database by importing a Management Pack (in binary or XML format) into the database.

Management Pack authoring

The supported method for Management Pack authoring in the Administrator console is:

• Create the configuration object definitions in the Administrator console.

• Export the new object definitions to an AKM file.

Managing MOM Components

The MOM Management Pack is the key to ensuring high availability and performance. This Management Pack leverages other Management Packs such as those for the operating system and SQL Server. Some of the key availability indicators are:

• Agent deployment and discovery

• Heartbeating and server availability

• Security

The following table lists the key MOM components that are monitored and provides examples of what is monitored.

Table 4 Typical component monitoring specified in the MOM Management Pack.

Component	Monitored
Agent-managed Computer	Script failures, Service Discovery problems, Managed Code Responses, Task Failures, Provider Problems, Overrides, Queues
Agentless Managed Computer	Monitoring failures, Permission issues
MOM Management Server	Agent Deployment, Agent Upgrade, Response Failures, Computer Discovery, Service Discovery, DAS, Queues, UDP and TCP Ports, Security
MOM Database	Space, Configuration, Authentication, Grooming
MOM Reporting Server and MOM Reporting Database	SQL Server Reporting Server services and Grooming
MOM Product Connectors	Forwarding, inserting, configuring data

In addition to the components described in Table 4, the MOM Management Pack handles general performance monitoring and provides state monitoring for the runtime. Figure 8 illustrates the robustness of the MOM Management Pack.

Figure 8 Structure and contents of the MOM Management Pack

Computer Groups

Computer groups contain a list of computers that are viewed and handled as a single entity. MOM uses technology-based computer groups to target rules (for example, all Exchange 2000 Servers) and supports nested computer groups as well as multi-group membership.

The benefit of using computer groups is that monitoring views and operations responsibility can reflect the way your business is organized, as well as the roles that your computers support. For example:

• by region (East Coast, West Coast)

• by business unit (marketing, manufacturing)

• by function (mail servers, database servers)

Computer group rules are used to define how similar computers are grouped together. The following criteria are available for creating a computer group.

• By domain membership or computer name, using wildcards, regular expressions, or Boolean regular expressions.

• By computer attributes, choosing from existing attributes (for example, operating system version), or by using a formula to create your own attributes.

• By inclusion or exclusion for a group, regardless of shared attributes or individual characteristics.

Computer groups are dynamic. For example, computer group Windows 2000 is defined as all the computers that are running Windows 2000 Server. This group includes all the discovered computers that are running Windows 2000 Server when the rule was created and any computers that had Windows 2000 Server installed after the rule was created. If you remove Windows 2000 Server from a managed computer, this computer no longer satisfies the group criteria and it is no longer a part of the Windows 2000 computer group.

You run periodic scans of managed computers to refresh group memberships according to the existing rules.

Management packs define specific computer groups according to the application or technology that the pack was written to monitor. For example, the Exchange 2000 computer group is pre-defined and part of the Exchange Management Pack.

Discovered Groups

Discovered groups are introduced in MOM 2005. The key difference between discovered groups and computer groups is that discovered groups are created and populated by discovery rules that are contained in Management Packs.

Rule Groups and Rules

Rule Groups contain collections of Rules for monitoring different aspects of a managed computer.

MOM uses Rules to determine how to collect, process, and respond to data generated by managed computers. Depending on the type of information a rule processes, rules are categorized as Event rules, Alert rules, and Performance rules. These rule types use different data sources and serve different purposes. In addition to defining the data that MOM collects and stores in the operational database, rules are used to refine operational data.

Some typical examples of rule subtypes are rules that respond to a specific event, filter an event, handle alert processing, and measure performance.

Rule elements

Rules contain the following elements:

• Data providers

• Criteria

• Responses

• Knowledge

Data providers

Data providers identify the source of the data and are used to determine how the data is collected.

Criteria

Criteria isolate the specific data to collect from the source and establish the conditions for a rule match.

Responses

Responses specify what should be done when collected data matches the criteria that are defined for a rule. When a rule match occurs, MOM performs the actions specified as a rule response. For example, a rule that matches a specific event ID might specify that the event is stored in the database, generates an alert, and sends an e-mail message to a network administrator.

Knowledge

Knowledge consists of Product Knowledge and Company Knowledge. Product Knowledge is information that is included with the MOM 2005 Management Packs.

Company Knowledge is detailed custom information that you can associate with a specific rule and condition*.* For more information, see the "Knowledge base" section.

Event rules

MOM uses Event rules to monitor events and in some cases, specify that alerts are generated and responses are initiated. Most events and their associated alerts are stored in the operational database.

The following order of precedence and event handling is applied to event rules:

• Event collection rules identify events with specific criteria to be collected from specific sources. Collection rules do not generate alerts or initiate responses.

• Missing event rules specify that an alert is generated or response is initiated when an event does not occur during a specified period. Missing event alerts are stored in the operations database.

• Event consolidation rules group similar events on a managed computer into summary events that are stored in the operations database.

• Event filtering rules specify that certain events should be ignored. Filtering rules typically identify events that you do not consider significant for monitoring purposes.

Alert rules

Alert rules specify a response for an alert or for a collection of pre-defined alerts. For example, you can specify that the High Priority Notification Group is paged for all Critical Error alerts generated by the rules in the SQL Server Rule Group.

Performance rules

Performance rules define how performance counter data and Windows Management Instrumentation (WMI) numeric data is processed. There are two types of performance rules, Measuring rules and Threshold rules.

Measuring rules

Measuring rules collect numeric values from sources such as WMI or Windows performance counters. The sampled numeric measures are stored in the operations database. Measuring rules can also include responses.

Threshold rules

Threshold rules specify that an alert is generated or a response initiated when a numeric measure meets or exceeds a defined threshold.

Knowledge base

The knowledge base is a collection of information that associated with a rule or a rule group. This knowledge describes the meaning, importance, and possibly the resolution for a relevant condition or problem that is linked to a rule.

When you view the properties of an alert in the Alert view, you can examine the knowledge base content that is associated with the rule that generated the alert.

Another aspect of the knowledge base, called the Company Knowledge, contains information that is created and stored by the user. You can add information to the company knowledge when you create or edit a rule, or when you modify an alert. This custom, organization-specific knowledge is a valuable resource that reflects policies and procedures used by your IT group.

Search Results

Search Results contain the results of a rule search. You can create search criteria, search against Rule Groups/Rules and store the results in named folders.

You can search against Management Pack rules and rule groups using the following criteria:

• Name - Specifies the name of the rule.

• Enabled - Specifies whether or not the rule is enabled.

• Type - Specifies the type of rule, such as Event Collection or Compare Performance Data.

• Rule Group - Specifies the Rule Group folder in which the rule resides.

Override Criteria

Overrides provide the capability of changing the settings of the rules used on a specific target computer without having to create custom rules for the target computer. This feature is designed for the user who wants to use a Management Pack that requires tuning for some of the computers in a management group.

You can implement the following actions on individual computers by using overrides:

• Disable a rule.

• Override the threshold value of a performance threshold rule.

• Override a script parameter value that is specified in the script response of a rule.

• Override an override parameter in the advanced alert severity formula.

Overrides are represented as names. You can overwrite different parts of a rule by specifying the name of the override in the appropriate location of the rule configuration.

For each override name, the values to override are specified in a list of computer group or computer, value pairs. The order of this list is important for resolving conflicts in cases where a computer is a member of multiple computer groups and multiple overrides may be targeted.

For a specific computer, the override value to use is calculated by checking the ordered list of computer group, value pair. If a computer is a member of a computer group then the corresponding value is used as an override value. If that computer is not a member of any computer group, then it means that the computer does not have an override for the specified override name.

Tasks

Tasks are actions that are provided for, and started by a MOM user. The following tasks are provided by default when you install MOM and you can create custom tasks.

General Tasks

• IP Configuration - This task displays the IP configuration data of the selected computer, including adapters, IP address, subnet mask, and DNS and WINS data.

• Remote Desktop - This task opens a remote desktop session to the selected computer.

• Computer Management - This task opens the Computer Management snap-in.

• Ping - This task pings the computer name of the selected computer.

• Event Viewer - This task opens the Windows Event Viewer.

MOM Tasks

• Start MOM 2005 Service - This task starts the MOM service from the console.

• Stop MOM 2005 Service - This task stops the MOM service from the console.

• Test end to end monitoring - This task logs an event in the event log on the agent which creates an alert for the management server.

Typically, tasks are run once from either the Operator console (console tasks) or the MOM runtime (runtime tasks).

Console task

A console task is an action that is started in the Operator console and run against an item displayed in the console window, for example, an alert, event, or computer. This type of task is used to automate activities that need to be handled at the console.

The action that is run as part of the task is specified in terms of a command line to execute. When a task is run against the selected item, the properties of that item are passed as context to the command line for execution.

For example, if you want to use a terminal server client to connect to a computer that generated an alert, you can create a console task that runs against the alert item. The command line to execute can be set to mstsc.exe $computername$. In this example, the variable $computername$ is replaced by the computer name associated with the selected alert.

Runtime task

A runtime task is an action that is started and run on either on a MOM management server or a managed computer. The available targets for a task are the managed computers that are found through service discovery. A runtime task should specify the following:

• A response instance that describes the action to take. This response instance is exactly the same kind of object that a rule contains as a response. Only script responses, command line responses, managed code responses, and the file transfer response are exposed as the response types that can be selected for a task.

• A target class name that specifies what type of entity this task runs against. This information is used by the user interface to present instances of that class, which is discovered as possible task targets.

• Where to run the task. This can be one of the following:

  • Run it on the management server no matter where the target instance is located.

  • Run it on the managed computer where the target instance is located. (The task can not be run against a remote entity.)

  • Run it as close as possible to the location of the discovered entity - run it on the managed computer if the target has an agent, or run it on the management server.

To start a task from the Operator console, select the item and then the task that you want to run against the item. The targets are the list of instances discovered for the specified class after service discovery. The user interface submits the task as well as the task target list. The MOM runtime handles task distribution according to the specified targets.

Notification, Notification Groups, and Operators

Notifications are the messages configured for rules and these notifications are organized as notification groups.

A notification group contains a list of operators that you create. When you create an operator you provide an operator name and specify how they should be notified, as well as when they are available to receive notifications.

After you create an operator you can add them to an existing notification group.

Depending on the Management Pack that is installed, Notification Groups might contain default groups configured to receive notifications from rules defined in the Management Pack. For example, the MOM Management Pack contains a group named Operators and two Notification Groups: Operations Manager Administrators and Operations Management Notification Testing.

Scripts

You can use either the MOM scripting interface or standard Microsoft scripting languages to create scripts that MOM can implement. Scripts can have parameters and parameters can have overrides. With scripts you can:

• Customize monitoring and respond to events, alerts, and performance data.

• Extend event management functions and data collection capability.

• Extend rule capability and configure rules to run on a scheduled basis. A rule response can launch one or more scripts.

MOM uses Microsoft Active Scripting through scripts and Automation COM objects. MOM invokes Active Scripting, identifies the language of the user-provided script, and then calls the appropriate scripting engine. (You can use other languages but you must install the custom scripting engine on the computers where the script will run and configure the script appropriately.)

Note

Objects that are automatically provided to scripts running in the Microsoft Windows Script Host environment are not present in the MOM scripting runtime. Similarly, MOM scripting objects are not meant to be used outside of the MOM scripting environment and runtime.

MOM scripts run within an instance of the MOMHost.exe process. The MOMHost.exe process and scripts run under the MOM Action account, which is used to control their security privileges.

Scripts are stored in the MOM Database and distributed with rules by the MOM Management Server. Management Packs can contain scripts created for a specific application or environment.

Computer Attributes and Service Discovery

Service discovery is the process of discovering roles, components, and relationships for managed computers. Service discovery also obtains information about managed computers and their relationships.

The information obtained by service discovery is used for multiple purposes, and includes:

• Identifying roles, instances, components, relationships, and attributes.

• Providing information such as the inventory of managed computers.

• Providing the information that can be used to group computers that share common properties. These groups are called Computer Groups and the formula used to define a computer group requires the information that is obtained from service discovery.

• Providing information that can be used for status monitoring.

• Providing information can be used to create and present a diagram of the managed computers and their interrelationships.

• Providing information that can be used to define targets for specific tasks. When a user starts a task that is authored for a specific class of component, the instances found through service discovery provide the list of possible task targets.

Service Discovery Schema

The service discovery schema is a specification of the types of entities and their relationships with other entities. Typically, the Management Pack author defines the service discovery schema for the application that needs to be managed.

The service discovery schema consists of two key elements, a Class and a Relationship Type.

Class A class represents the type of an entity. Some examples are Computer class, a SQL Server class, and an Exchange Routing Group class. The class schema contains the following types of information.

Primary Key Property

This is a property name that uniquely identifies an instance of this class. For example, ComputerName is the primary key property of the Computer class.

Non-Key Properties

Non-Key Properties is a list of properties that provides information about that the class. For example, OSVersion, IsExchangeServer are properties of the Computer class. These properties are also called Attributes.

Status Attributes

A status attribute is a property of the entity whose value represents the health of a specific part of the entity. IsAgentHeartBeating, agent heartbeat status, is an example of a status attribute for the MOMAgent class.

Parent Container Class (optional)

Instances of some classes always exist if another instance of a class exists. For example, an instance of an Exchange Server class could not exist if the instance of the Computer that contained the class did not exist.

The Parent Container Class specifies which class contains the child class. An instance of a child class is uniquely identified in the context of an instance of its parent class. The child classs primary key value and parent classs primary key value has to be specified in order to uniquely identify an instance of this class. For example, a SQL Server class contained by the Computer class has the primary keys, ComputerName (inherited from Computer class) and SQLInstanceName.

Relationship Type Instances of different classes may be related to each other for various reasons. For every instance where a class is related to another class, a relationship type must be defined. For example, a MOMServer class and a MOMAgent class can be connected with the relationship type MOMServerManagesAgent. An instance of a relationship type loosely binds two related instances together. If an instance of a class in a relationship is deleted, it does not mean the related instance is also deleted. Relationship type needs to define the following:

• Source Class Property - Used toidentify the class that this relationship connects from.

• Target Class Property - Used to identify the class that this relationship connects to.

• Non-Key Properties - A list of property names included in the relationship. For example, ConnectionSpeed could be a property of a relationship Connection that connects one Router class to another Router class.

The relationship type schema is stored in the operations database and is inserted during a Management Pack import.

Service Discovery Population

The service discovery schema itself does not contain any information about how to populate the classes and specified relationships. The Management Pack that defines the service discovery schema also provides rules that are targeted to set of computers - these rules define how to populate the schema. The service discovery rules have script responses that contain the business logic for discovering the appropriate entities.

Each data item delivered by a service discovery rule discovers a portion of the schema for a given scope. For example, you can write a service discovery rule that finds all instances of SQL Server on a specific computer. These rules send out their discovery results by generating a discovery dataitem on the MOM runtime. The discovery dataitem is processed by the Database Connector (a component that processes runtime generated data for populating the database) and the discovery result is inserted into the MOM Database. This is done by deleting, updating, or adding instances of the classes and relationships that are specified in the service discovery schema.

Discovery dataitem A discovery dataitem always contains a snapshot of the instances and their properties that are discovered for certain classes and relationship types for a given scope and time. As a result, service discovery rules only contain discovery information for an entity at a certain point in time. Because entities that need to be discovered are dynamic in nature, service discovery rules are often linked to a timed event provider to ensure that discovery occurs on a regular basis.

A discovery dataitem contains:

• A timestamp of the discovered snapshot.

• A list of class instance collections. Each collection includes the following information:

  • The class name of the instances in the collection.

  • The scope of the collection. For example, if a collection contains instances of SQL Server on a specific computer, then the scope is the specific computer.

  • A list of instances and their properties that were discovered in the scope. If this list is empty, it means that an instance of the class in given scope was not discovered.

• A list of relationship instance collections. Each collection includes the following information:

  • The relationship type name of instances in the collection.

  • The scope of the relationship collection. This scope is defined in terms of source class scope and target class scope.

  • The list of relationship instances and their properties.

Registry-based Computer Attributes

Registry-based computer attributes are a special case of service discovery schema that extends the Computer class by adding new properties. The Registry Based Computer Attribute definition also defines how that attribute is discovered and populated. Unlike the other parts of the schema, registry-based computer attributes do not require a service discovery rule specified in a Management Pack. During runtime, dynamically created rules are used to generate discovery data that populates any Computer class properties that were added because of a Registry Based Computer Attribute.

The definition of a registry-based computer attribute specifies a registry path or a value for a specific computer. The property value of an instance of a Computer class becomes the value for that registry value on that computer.

Registry-based computer attributes are used to find information about a computer, such as detecting what applications are installed. Computer groups use these attributes to group computers that have certain applications installed. As a result, rules that monitor specific applications can be targeted to a computer group whose members only have a specific application installed.

You can not specify the target computers for collecting computer attributes; computer attributes are always collected from all managed computers - both agent-managed and agentless managed.

Providers

A provider is the data source that a rule monitors. For example, an event provider sends data from an event log. Providers are imported with Management Packs and you can create custom providers for your rules. As an example, Figure 9 shows the properties of a performance counter provider that MOM uses for a MOM Agent.

Figure 9 Windows NT Performance Counter Provider for MOM Agent