MOM2005 ConceptsGuide

Microsoft
Operations Manager
2005 Conceptual
Guide
Authors: Dan Wesley, Chris Furlin
Program Manager: Ashvin Sanghvi
Published: October 2004
Applies To: Microsoft Operations Manager 2005
Document Version: Release 1.0
Introduction 4
Introduction
The information contained in this document represents the current view of
Microsoft Corporation on the issues discussed as of the date of publication.
Because Microsoft must respond to changing market conditions, it should
not be interpreted to be a commitment on the part of Microsoft, and
Microsoft cannot guarantee the accuracy of any information presented
after the date of publication.
This White Paper is for informational purposes only. MICROSOFT
MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO
THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the
user. Without limiting the rights under copyright, no part of this document
may be reproduced, stored in or introduced into a retrieval system, or
transmitted in any form or by any means (electronic, mechanical,
photocopying, recording, or otherwise), or for any purpose, without the
express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or
other intellectual property rights covering subject matter in this document.
Except as expressly provided in any written license agreement from
Microsoft, the furnishing of this document does not give you any license to
these patents, trademarks, copyrights, or other intellectual property.
Unless otherwise noted, the example companies, organizations, products,
domain names, e-mail addresses, logos, people, places, and events depicted
herein are fictitious, and no association with any real company,
organization, product, domain name, e-mail address, logo, person, place,
or event is intended or should be inferred.
 2004 Microsoft Corporation. All rights reserved.
Microsoft, MS-DOS, Windows, Windows NT, Windows Server, Active
Directory, ActiveSync, and Windows Mobile are either registered
trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
The names of actual companies and products mentioned herein may be the
trademarks of their respective owners.
Acknowledgments
Primary Reviewers: Ashvin Sanghvi, Travis Wright, Vlad Joanovic
Did you find
Managing this information
Editor: useful? Please send your suggestions and comments about
Sandra Faucett
the documentation to momdocs@microsoft.com.
Looking for more MOM information? Experience the power of customer communities!
MOM Community
The MOM Feature Set and Concepts 5
Welcome to the Microsoft® Operations Manager 2005 Conceptual Guide. This guide provides
information on service and operations management concepts, and identifies the basic
requirements for managing computers and the applications that they host. It also provides
information about the MOM 2005 operations units, user interfaces, and features that show how
MOM implements and supports service management.
Send feedback to the Microsoft Operations Manager Documentation Team:
momdocs@microsoft.com.
Purpose
This guide describes high-level, overview information about MOM 2005. This guide includes the
following topics:
• Operations Management
• MOM Overview
• MOM Operations Components
• MOM User Interfaces
• The MOM Feature Set and Concepts
Scope
The Microsoft MOM 2005 Conceptual Guide describes high-level overview information about
MOM architecture, components, and features. This guide does not include information about
deploying, operating, or maintaining MOM in an enterprise environment. This guide has been
created for the final release of Microsoft Operations Manager (MOM) 2005.
Intended Audience
This guide is primarily for anyone who is evaluating MOM 2005 for use with an existing IT
infrastructure, or for operators, administrators, management pack authors, and support staff who
must develop a basic understanding of MOM 2005.
Did you find this information useful? Please send your suggestions and comments about
MOM Community
6 Microsoft Operations Manager 2005 Conceptual Guide
Operations Management
Today’s complex and rapidly changing technology infrastructures need to be supported by
excellence in processes and people (skills, roles, and responsibilities). Any automated
management solution must support and enhance these processes.
The Microsoft Operations Framework (MOF) uses a process model that describes Microsoft's
approach to the Information Technology (IT) operations and service management life cycle. This
model organizes the life cycle into the following quadrants:
• Changing
• Operating
• Supporting
• Optimizing
Each quadrant has a specific focus and set of tasks that are carried out through its corresponding
set of service management functions (SMFs). SMFs provide consistent policies, procedures,
standards, and best practices that can be applied across the entire suite of service solutions found
in today's IT environments. For more information about the MOF, see the Microsoft Operations
Framework site on TechNet.
An organization also needs operations management because it ensures that Information
Technology (IT) meets an organization’s business goals and objectives. These goals include
things such as reducing costs, complexity, and providing information security. Reducing costs
and complexity is important because, in addition to making up a significant part of the IT budget,
the business impact of failed systems or performance degradation can be significant. This can
result in increased operational costs, decreased quality of service, and lost revenue. Information
security is also important as compromised systems and the associated costs of computer and data
recovery continue to rise every year.
MOM Overview
MOM 2005 provides comprehensive event and performance management, proactive monitoring
and alerting, reporting and trend analysis, and system and application specific knowledge and
tasks to improve the manageability of Windows-based servers and applications.
MOM 2005 Features Overview

The following are features of MOM 2005.
MOM Community
Security
MOM implements a security model that enables staff and components to work with accounts that
have lower privilege levels.
Speed and ease of deployment
By combining using automation and wizards it is possible, depending on the scale of the
deployment, to deploy MOM in a matter of hours, rather than weeks.
Low bandwidth or un-reliable networks
MOM’s use of agents ensures that data collection on managed entities continues even if there is a
temporary network outage.
Extended problem diagnostics
Because MOM retains operational data in its own database, analysts have a longer time to engage
in diagnostics.
Data volume
MOM’s multiple views, refined health model, and intelligent monitoring enable customers to
filter and reduce large volumes of alert data.
Flexible, robust, and secure reporting
MOM Reporting uses Microsoft SQL Server™ and SQL Server Reporting Services to support
long term storage, report customization, dynamic reports, data exports, auditing, planning, and
report security.
High availability
MOM’s management model enables you to add management servers so you can implement
failover to eliminate a single point of failure.
Scalability
MOM design is such that you can manage thousands of entities.
High level of integration
MOM provides the MOM Connector Framework (MCF) and extensible APIs that enable you to
integrate MOM with virtually any kind of management system or application.
MOM Community
MOM Operations
Components
Figure 1 illustrates how the primary MOM components map to the operations management
model.
Figure 1 MOM operations management components
The fundamental operations management unit is the Management Group. The following
components are in this group:
• MOM Management Server - At least one MOM Management Server and the MOM
Database, which is used to store operational data.
• Managed Computer - At least one managed computer. Managed computers are either Agent-
managed, the default, or Agentless Managed. These are covered in more detail later in this
guide.
• Management Pack - At least one Management Pack, which contains the rules that are applied
to managed computers in the Management Group. The Microsoft Operations Manager 2005
Management Pack, which enables you to monitor MOM health and performance, is installed
by default during setup.
• User interfaces - The Administrator Console and Operator Console are installed by default
when you install MOM.
MOM Community
The optional components shown in Figure 2 are:

• MOM Reporting - Which consists of the MOM Reporting Server, the MOM Reporting
Database, and the Reporting Console.
• The Web Console
Note
Another optional component, which is not shown in Figure 2, is
the MOM Connector Framework (MCF), which will be covered
later in this guide.
The user interfaces shown in Figure 2 are covered in more detail in the next section, “MOM User
Interfaces”.
MOM User Interfaces

MOM 2005 introduces re-designed and new interfaces that give you the flexibility required to
meet the needs of your operations center staff.
The complete set of design criteria is too large to cover in detail, but two usability themes are
worth noting — discoverability and automation.
First, make it easy for any user to find information, where to start a task, or where to change a
configuration. Second, make it easy to complete a task by automating and guiding the process by
using wizards and dialogs wherever possible. A good example that combines both usability
themes is installing or uninstalling agents. There are numerous locations where a MOM
administrator can start the Install/Uninstall Agents wizard, which they can use to install or
remove agents on computers.
These interfaces, derived from Microsoft’s usability engineering work with personas, are role-
and task-based, and map to the following primary user types that are pre-defined for the MOM
environment:
• Administrators
• Authors
• Users
In addition to being flexible, the MOM user interfaces are easily implemented in distributed
Note
The idea of role delineation is further enforced by the MOM
Local Groups that are created when you first run the MOM
setup program. Group membership determines what you can
Did you view andinformation
find this the actions useful?
that youPlease
can take in your
send a console.
suggestions and comments about
MOM Community
The following table lists the MOM user interfaces and identifies the accounts, the primary users,
and the typical tasks that a user would perform with one of these interfaces.
Table 1 MOM interface and user summary
User interface Accounts Primary users Typical tasks
Administrator MOM IT Administrators, MOM
console Administrators, those responsible Management and
MOM Authors for configuring configuration,
and maintaining Global Settings
MOM. configuration,
Management
Pack authoring,
and Management
Pack
import/export
Operator console MOM Users (MOM Tier 1 & 2 Alerts
Administrators, Operators who management,
MOM Authors) identify, changing Views,
diagnose and fix Monitoring, and
problems. Launching tasks
Web console MOM Users (MOM Operators, IT Alerts
Administrators, staff, and management,
MOM Authors) downstream changing Views
operations
customers on
thin clients, with
a need to access
basic alert,
event, and
computer
information.
Reporting SC DW Reader, IT staff, analysts, View information
console SC DW DTS and managers in the Reporting
who are database, edit
interested in information in the
seeing the Reporting
historical database
analysis of
operational data
MOM Community
The Administrator Console

The Administrator console is a Microsoft Management Console (MMC) snap-in, but as you can
see by looking at Figure 2, the details pane is enriched by using hyperlinks to information and
tasks.
Figure 2 The details pane for the Microsoft Operations Manager Home page
These changes extend the functionality of the MMC structure shown in Figure 3 by using it
selectively to provide detailed information for certain elements in the navigation pane.
Figure 3 The details pane for Global Settings
MOM Community
Figure 4 illustrates the full extent of the design implemented in of some of the details panes in
the MMC and shows the new functionality that is provided by using hyperlinks in this pane.
The hyperlinks shown in Figure 4, and used on other revised details panes, are used to:
• Provide quick links to points in the navigation pane. In the example shown, clicking on the
Computer Attributes link opens the Management Packs node in the navigation pane and
positions the cursor on the Computer Attributes folder.
• Launch the wizards or dialogs that you can use in the Administrator console. For example,
clicking on the Import/Export Management Packs link starts the Management Pack
Import/Export Wizard.
If you refer to Figure 4 again, you’ll see that the details pane also provides summary information
related to this specific point in the navigation pane. In the illustration this information is the
number of Rule Groups, Management Pack Rules, Custom Rules, Computer Groups, and Scripts.
This summary information changes dynamically as MOM configuration changes are
implemented, such as adding rules or scripts.
Figure 4 The details pane for Management Packs
MOM Community
The active location in the navigation pane determines which type of details pane is displayed, the
conventional one (Figure 3) or the new one shown in Figure 5. The following navigation pane
nodes and sub-nodes use the extended details pane:
• Microsoft Operations Manager
• Information Center
• Operations
• Management Packs, Rule Groups, Notification
• Administration, Computers
The Administrator console serves two purposes. First, it provides all the tools that a MOM
Administrator needs to manage and maintain a MOM environment. This includes tasks such
installing/removing agents, and changing configuration settings.
MOM Community
The Second purpose is to provide the tools that members of the MOM Authors group can use to
change the monitoring environment defined by the Management Packs that are installed. For
example, they can add rules, delete or disable rules, and change rules.
The Operator Console

The Operator console (Figure 5), is written in managed code and provides the look and feel that
you’d expect from both the MMC and the browser interface. Like the MMC, the toolbar is
customizable and you can view all the panes or a single pane. In addition, right-click
functionality is implemented where appropriate.
Figure 5 The default Operator console panes
The Operator console gives your operations staff the interface they need to:
• See the health, in real time, of the computers they are monitoring.
• Obtain different views of the information coming from managed computers.
• Obtain high level and detailed information about a specific event or alert.
MOM Community
• Work with alerts, for example, acknowledge an alert or assign the problem to another staff
member.
• Run pre-defined tasks that are provided in the console.
The Web Console

The Web console (Figure 6) is browser-based and designed to provide a light weight interface
that can be used to provide basic functionality for distributed monitoring situations that only
require limited views and alerts management capability.
• The views include Alerts, Events, and Computers. Depending on the view that you select,
you can examine view information (for example, computer Attributes, event Properties, and
alert Product Knowledge) or change alert state (for example, flag the alert as
Acknowledged).
Figure 6 The Alerts view in the Web console
MOM Community
The Reporting Console

Accessed from the Start menu or from within the MOM Administrator console, the Reporting
Console (Figure 7) is browser-based and is implemented by Microsoft SQL Server Reporting
Services. This interface provides a front-end to the MOM Reporting Server, which applies report
templates to the appropriate data that is stored in the MOM Reporting Database.
The Reporting Database contains a copy of the operational data that is collected in the MOM
Database.
Figure 7 The Reporting console
In addition to using the Reporting console to obtain and filter the historical data that is available,
you can perform other tasks, such as:
• Configure SQL Server Reporting Services.
• Apply security settings.
• Create custom folders for organizing reports.
• Specify alternate data sources.
MOM Community
• Export reports.
The MOM Feature Set and

Concepts
MOM implements the operations management requirements that are identified in this guide. This
section summarizes the MOM feature set and highlights some key concepts.
This section describes the primary interfaces for working with MOM, the Administrator console
(MOM Administrator and MOM Author) and the Operator console (MOM User). It includes the
following topics:
• MOM Data
• Administrator Console – MOM Administrator
• Administrator Console – MOM Author
• Operator Console – MOM User
MOM Data
During computer and application monitoring, the data that is generated is stored in the MOM
Database. Monitoring produces four types of data: event data, performance data, alert data, and
discovery data.
Event Data
Managed computers log events in local event logs (Application, Security, and System), and
MOM collects event information from these logs. The collected event data can be used to:
• View operational data in the Operator console.
• Generate reports using the Reporting Server and Reporting Database.
• Provide a context for problems (in the form of Alerts) that are detected.
• Provide information about MOM monitoring and management activities.
• Provide information about computer state, which is derived from correlating data from
consolidation events or missing events.
MOM Community
Performance Data
Numeric performance data is gathered from sources such as Windows performance counters and
Windows Management Instrumentation (WMI). The collected performance data can be used to:
• View performance data in the Operator console using different formats such as forms, lists,
and graphs.
• Generate reports using the Reporting Server and Reporting Database.
• Identify critical threshold crossings that may indicate performance issues.
Alert Data
Alert data represents a problem that is detected on managed computers. Alert data contains the
following information about a detected problem:
• The type of entity the problem is about. This is described as a service discovery type. It
could be about a Computer class or a child class that is referenced as Server Role.
• The entity the problem is about. This is described as a computer name and the instance name
of the entity, which is called the Server Role Instance. For example, the problem could be
about a SQL Server Instance on a specific computer.
• The problem area for the entity. This is referred to as the SubGroupComponent of the
entity. For example, SQLAgent could be the SubGroupComponent of a SQL Server
Instance.
• The Severity of the problem. Alert severity is indicated by a level, such as Error, Critical,
and Warning.
• The Alert Name, which is a descriptive name for the problem.
• The Alert Description provides a brief description of the problem.
• The Problem State shows the current state of the problem. It indicates if the reported
problem is still occurring.
• The Alert Count indicates how many times the problem was reported.
• The Alert Resolution State indicates if the problem has been acknowledged, if it has been
assigned, or if it has been resolved.
• The Alert History, contained in the knowledge base, provides a record for the alert. (The
knowledge base contains a problem description, as provided by the Management Pack
creator (Product Knowledge) or it can contain customer knowledge that describes the
problem and its resolution.)
MOM Community
Alerts are the indicators that inform users about the health of managed computers. Alerts also
provide the basis for the status monitoring, which the “Status Monitoring” section describes in
more detail.
Alert updates
Alert data that is stored in the MOM Database is continuously updated as MOM continues to
collect information about the computer that generated the alert. When a problem is detected, an
alert dataitem is generated in the MOM runtime. The alert dataitem is inserted in the database as
an alert that represents a new problem. If MOM detects that the problem has disappeared, MOM
generates another alert dataitem to update the problem state of the original alert. Eventually, the
problem state of the existing alert in the database is updated and flagged as fixed; however, you
still have to acknowledge the alert by resolving it.
Alert suppression
Alert suppression is the mechanism for specifying which alerts should be considered as unique
problems. As part of the rule definition that generates the alert, alert suppression fields are
defined. If alert suppression is not set, every new alert generated by the MOM runtime is treated
as a new problem. Alert suppression fields are used to specify the alert properties whose value
should be identical if two alerts represent the same problem.
Discovery Data
Discovery data contains a snapshot of the entities discovered for a particular scope. Unlike the
other operations data, discovery data is not directly exposed to the user. Discovery data is
exposed as topology diagrams, computer attributes, services list, or computer lists. This data is
presented in different views such as the State view. For more information about service
discovery, see the “Computer Attributes and Service Discovery” section.
Administrator Console - MOM

Administrator
As noted earlier, the Administrator console is used to administer MOM infrastructure — the
management group, the computers in the management group, and the custom console scopes for
operations support team members. The following table lists the main categories and sub-
categories in the Administration node of the navigation pane and summarizes the purpose of
each.
Table 2 Administrator console - Administration
Category/sub-category Purpose
All Computers View all the computers in a
MOM Community
management group, install or install

agents, change type of
management, and view/edit
properties for individual computers.
Management Servers View all the management servers,
install or install agents, change type
of management, run computer or
attribute discovery, and view/edit
properties for individual
management servers.
Unmanaged Computers View the unmanaged computers,
install an agent, begin agentless
management, and view/change the
properties of an agent-managed
computer of an unmanaged
computer.
Agentless Managed Computers View all the agentless managed
computers, stop agentless
management, run attribute
discovery, and view/change the
computer of an agentless managed
computer. .
Agent-managed Computers View all the agent-managed
computers, uninstall agents, run
attribute discovery, view/change the
computer, and update agent
settings.
Windows Server Cluster Computers View Windows Server Cluster
computers, change the management
mode, run attribute discovery,
view/change the properties of a
cluster computer, and update agent
settings.
Pending Actions View, approve, or delete pending
actions.
Computer Discovery Rules View the discovery rules for adding
computers to the management
group, create or modify a discovery
MOM Community
rule, and run computer discovery.

Console Scopes Define and modify scope for
Operator console users.
Global Settings Change the default global settings
that are applied to various
management group and
Management Pack elements.
Product Connectors Create a product connector to
implement multi-tiered MOM
environments.
The basic MOM operations management unit is a management group, which contains a
management server and managed computers.
MOM Management Server

The MOM Management Server fulfills several critical roles in the management environment. It:
• Deploys Management Pack configuration information to the Agent-managed computers; and
in the case of Agentless Managed computers, applies specific rules when contacting these
computers.
• Provides an environment for creating, modifying, and applying Management Packs
• Provides the tools for administering the MOM environment.
• Communicates with the Data Access Service (DAS) to interface with the MOM Database.
Managed Computers
MOM implements two approaches to managing computers, Agent-managed and Agentless
Managed. MOM also enables you identify and track unmanaged computers.
Agent-managed
In the agent-managed scenario you use MOM to install software on the computer that you want
to manage. This component, MOM Agent, runs a local service on the computer you where you
installed it and monitors this computer using the Management Pack rules that are installed as part
of the agent installation.
You can install agents automatically from the Administrator console or manually by logging on
to the computer where you want to install an agent.
Agentless Managed
MOM Community
In the agentless scenario MOM does not install any software on the computer that you want to
manage. Instead, the MOM Agent, which runs locally in the MOM Management Server runtime,
collects data from the managed computer.
Unmanaged
This management state is used in cases where you want to identify computers that you will
manage in the future, or that you have taken offline for maintenance purposes.
Note
As noted in Table 2, MOM supports Windows Server Cluster
computer management as a special case for implementing
Agent-managed, Agentless Managed, and Unmanaged
computers.
Pending Actions
Not all actions occur automatically in MOM, some are stored in the Pending Actions folder and
you have to explicitly approve the action.
Computer Discovery Rules

Computer discovery, not to be confused with Service discovery, is the processing of finding
computers that you want to include in a management group. When you run the Install/Uninstall
Agents wizard you are asked to specify a computer name(s) or search criteria where you can use
wild cards for the computer name.
After the wizard completes its task, the discovery rule is listed in the Computer Discovery Rules
folder. You can create custom discovery rules, change existing rules, and force computer
discovery.
Console Scopes
Console scopes provide a tool that you can use for setting the scope of operational data viewing
in the Operator console. MOM Administrators, for example, need to view different data than a
Tier 1 operator in the MOM Users group.
Three scopes are defined for the Operator console: MOM Author, MOM Administrator, and
MOM User. By default each scope has access to all the Computer Groups defined in the MOM
Management Pack.
You can edit the existing scopes to remove access to specific groups or give specific users access
to one of the existing scopes.
You can also create custom scopes that enable you to further compartmentalize your operations
environment.
MOM Community
Global Settings
There are several aspects of the MOM environment where global settings are used by default. In
some cases, it’s desirable to override or change a global setting. You can view and change the
following settings:
• Custom Alert Fields
• Alert Resolution States
• Operational Data Reports
• Email Server
• Communications
• Security
• Web Addresses
• Database Grooming
• Notification Command Format
• Management Servers
• Agents
Product Connectors
Product connectors, which are implemented by the MOM Connector Framework (MCF), give
you a tool for setting up multi-tier MOM environments. In a multi-tier environment, alerts and
configuration information from one management group (Source Management Group) are
forwarded to another management group (Destination Management Group). MOM provides a
wizard that steps you through the process of creating a MOM-to-MOM Connector.
Typically, this type of intra-management group communications is two tier, but you can set up
three tier configurations if you business requires it.
Administrator Console - MOM Author

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
MOM Community
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.
MOM Community
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
doesn’t 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.
MOM Community
• 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
MOM Community
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 SQL Server Reporting Server services
Reporting Database 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
MOM Community
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.
MOM Community
• 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
MOM Community
• 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
MOM Community
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.
MOM Community
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.
MOM Community
• 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
MOM Community
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.)
MOM scripts run within an instance of the MOMHost.exe process. The MOMHost.exe process
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 Community
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.
MOM Community
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 class’s
primary key value and parent class’s 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 to identify 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
MOM Community
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.
MOM Community
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
MOM Community
Operator Console - MOM User

As noted earlier, the Operator console enables members of the MOM User group to view the
specific information that their role requires and take appropriate action. A fundamental concept
that provides the foundation for all activities in this console is status monitoring.
Status Monitoring
Status monitoring is used to indicate whether or not a managed computer is healthy at a given
time. MOM updates the status of the managed computers exposed to the user and presents their
status in the status monitoring view.
The status of different entities are rolled up at different levels. These levels are:
• Computer group level - At this level the user can see if there is any problem in any of the
computers by checking the health of a computer group. The health of the computer group is
derived from the health of all the computers contained in the computer group by using one of
the rollup algorithms.
• Computer level - At this level the status of a computer shows whether or not the applications,
or server roles, running on the computer are healthy. The health of a computer is derived
from the health of the hosted applications, such as SQL Server or Exchange.
• Application level (Server role) - At the application level the status of the Server Role
represents the overall status of all the application instances of a server role. For example,
SQL Server health is dependent on all of the SQL instances running on a computer.
• Application instance level (Server role instance) - At the application instance level the health
of the application instance is derived from the health of different areas of the application
instance — the Sub group component.
• Sub group component - At this level the health of a Sub group component of an application
instance is derived by reviewing the unresolved alerts — after alert suppression —
associated with the sub group component. The status becomes the severity of the most severe
unresolved alert that has an active problem state.
In summary, the status of a managed computer is an alert severity value that specifies how severe
the problem is — if it exists — in the managed computer environment. In the Operator console,
status is color mapped (for example, red, yellow, and green) to icons that are associated with an
alert severity.
Data Filtering
Data volumes and operator roles require a mechanism for filtering the information that is
displayed in the Operator console. One filter is Group, which is determined by the console scope
that you are using.
MOM Community
Group
You can use the drop-down list by the Group label on the menu bar to select a particular group
that you want to work with. This applies one level of filtering. For example, when you view the
entire list for the MOM Administrator Scope for the MOM Management Pack, you can select one
of the following folders:
• Microsoft Operations Manager 2005 Agentless
• Microsoft Operations Manager 2005 Agents
• Microsoft Operations Manager 2005 Databases
• Microsoft Operations Manager 2005 Product Connector Servers
• Microsoft Operations Manager 2005 Report Servers
• Microsoft Operations Manager 2005 Reporting Database Servers
• Microsoft Operations Manager 2005 Servers
• Microsoft Operations Manager 2005 Virtual Servers
If you select “Microsoft Operations Manager 2005 Agents” as the group that you want to work
with, you will only see the data related to Agent-managed computers. You can then apply the
various views that are available to this data.
Note
By default the Group data is not filtered, all the data for all the
groups is displayed in a view.
Rule Group
A second type of filtering is by rule group, which is determined by the Management Packs that
are installed. At a minimum, the MOM Management Pack is installed so you can filter
information by the various MOM rule groups, such as Agent Deployment or Computer
Discovery. For example, you can select the Alerts view (All: Alert Views by default) and expand
the navigation tree down to Agent Deployment rule group.
Figure 10 illustrates the group and rule group filtering options. The rule group hierarchy is shown
in the Alert Views window and the drop down list for groups is displayed.
Figure 10 Group and Rule Group filtering in the Operator console
MOM Community
The role of views

Views provide an additional level of filtering and they provide a means for looking at monitoring
data from different perspectives.
The Views that MOM provides display dynamic information for each view in a results window.
You can select a specific item in the results display, and depending on the view, additional details
are displayed in a details window. Figure 11 shows the results and details windows for an Events
view. (The scope is MOM Administrator Scope for all Groups.)
Figure 11 Events view results and details window
MOM Community
Filtering Typically, a Tier 1 operator only needs to see a visual indicator that a managed
computer is unhealthy. After seeing this indicator they have to take an action, such as
acknowledge the alert and notifying another support staff member.
Perspective Each user in the MOM environment is interested in seeing different information. If
you are a MOM administrator for example, your information requirements are likely to be far
different than a Tier 1 operator. You might for example, be responsible for monitoring MOM
performance. If this is the case, the Performance view is more relevant to your role than the
Alerts view.
MOM Views
MOM Community
MOM provides the following views that you can use and customize when you’re working with
the Operator console.
Note
The following view descriptions are based on the MOM
Management Pack and the scope is MOM Administrator, all
groups.
Alerts
The Alerts view is divided into two categories, Alerts and Service Level Exceptions. These views
display all the alerts in both categories. This view displays summary information in a results
window and expanded information for a specific alert in a details window.
State
The State view shows aggregated information about alerts and their associated entities (for
example, computer groups, computers, and application instances.) The State view uses the
results, details window pair.
Events
The Events view is divided into two categories, Events and Task status for the tasks that you run
from the Operator console. This view shows all categories of events that are generated and uses
the results, details windows pair.
Performance
The Computer Performance view is generated in stages. First, you select the computer that you
want to work with from a list of computers in the initial view window. Then you select the
performance counters that you want to graph. The final view displays the graph in the results
windows for the view and the accompanying details windows displays information about each
counter in the graph.
Computers and Groups
The Computers and Groups view uses two categories, Computer Groups and Computers. This
view uses the results, details windows pair to display information.
Diagram
The Diagram view uses a single window to generate a topology diagram that is based on your
management group and the Management Pack(s) that is selected.
My Views
MOM Community
My Views displays any custom views that you create. You can nest your views and incorporate
any of the views that we just described.
Public Views
Public views provide another way of working with the views. All the views that we described,
excluding My Views, are displayed as navigation tree.
MOM Community

MOM2005 ConceptsGuide

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MOM2005 ConceptsGuide

Uploaded by

Copyright:

Available Formats

Microsoft

MOM 2005 Features Overview

The optional components shown in Figure 2 are:

MOM User Interfaces

The Administrator Console

The Operator Console

The Web Console

The Reporting Console

The MOM Feature Set and

Administrator Console - MOM

management group, install or install

rule, and run computer discovery.

MOM Management Server

Computer Discovery Rules

Administrator Console - MOM Author

Computer Groups Create computer groups, manage

Computer Attributes Create a computer attribute and

Management Pack Content

Managing MOM Components

Agent-managed Computer Script failures, Service Discovery

Rule Groups and Rules

Notification, Notification Groups, and Operators

Computer Attributes and Service Discovery

Operator Console - MOM User

The role of views

You might also like