Microsoft Operations Manager 2000 SP1 Conceptual Guide

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

June 2003

Click here to download a copy of this paper

Abstract

The Microsoft Operations Manager 2000 SP1 Conceptual Guide provides high-level, overview information about Microsoft Operations Manager 2000 (MOM) SP1. This conceptual guide describes MOM architecture, MOM components and the three supported topologies for MOM deployment. In addition, a section is included that discusses the elements of a Management Pack module, how these modules work, and the tasks involved in using a Management Pack Module. And finally, this guide provides information about the predefined Management Pack Modules that Microsoft releases to work with MOM.

On This Page

Introduction
Microsoft and Management
MOM Overview
MOM SP1 Components
MOM Topologies
Management Pack Modules
Predefined MOM Management Pack Modules

Introduction

Welcome to the Microsoft Operations Manager 2000 Service Pack 1 Conceptual Guide. This section describes the material in the rest of the guide.

Send feedback to the Microsoft Operations Manager Documentation Team:momdocs@microsoft.com.

Purpose

This guide describes high-level, overview information about Microsoft Operations Manager 2000 (MOM) SP1. This guide includes the following topics:

Microsoft and management

This section describes the products and processes that Microsoft offers to plan and manage your enterprise environment.

MOM overview

This section introduces MOM components and features, and it provides references for obtaining updated documentation.

MOM SP1 components and topologies

This section describes MOM components, illustrates the three supported topologies for MOM deployment, and describes how you can use different MOM topologies to ensure security, distribute workload, and provide redundancy in your environment.

Management Pack modules

This section describes the elements of a Management Pack module, how Management Pack modules work, and the tasks that are involved in using a Management Pack module. MOM uses Management Pack modules to collect, process, and respond to monitored events in the management environment.

Predefined Management Pack modules

This section describes the predefined Management Pack modules that Microsoft releases to work with MOM. The listing includes a brief overview of the features of each Management Pack module.

Scope

The Microsoft Operations Manager 2000 Service Pack 1 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 is provided for use with MOM SP1.

Intended Audience

This guide is primarily for anyone who is evaluating MOM 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.

Additional resources

For product lifecycle information, see the Microsoft Product Support Web site at https://www.support.microsoft.com/default.aspx?scid=fh;[ln];LifeSrvr.

For the latest information about MOM, see the MOM Web site athttps://www.microsoft.com/mom/default.asp.

To access the MOM core product documentation on the Web, see to the Technical Resources section of the MOM Web site at https://www.microsoft.com/mom/techinfo/.

To access additional MOM technical papers, see the Microsoft TechNet Web site at https://www.microsoft.com/technet/prodtechnol/mom/default.asp

Microsoft and Management

Systems management is a complex, multifaceted challenge, which no single tool or technology can address. Microsoft has developed a management strategy that offers a variety of effective management solutions to be developed, deployed, and integrated. This strategy includes:

• Technical guidance that addresses the people, process, technology, and management issues that pertain to complex, distributed, heterogeneous IT environments.

• Core management services that are incorporated into the operating system.

• Software applications that provide enterprise-level IT management services and solutions.

Microsoft Operations Framework

The Microsoft Operations Framework (MOF) provides technical guidance that helps organizations achieve mission-critical system reliability, availability, supportability, and manageability of enterprise management products and technologies.

MOF provides operational guidance in the form of white papers, operations guides, assessment tools, best practices, case studies, templates, support tools, and services.

For more information about Microsoft Operations Framework, see https://www.microsoft.com/mof/.

Windows Management Technologies

Underlying all Microsoft management solutions are the management technologies that are built into Microsoft Windows operating systems. These technologies provide a solid foundation for Microsoft management solutions and for other software and hardware vendors. Where possible, these core management technologies are built following industry standards to make them widely accessible. For more information about the technologies described below, see https://www.microsoft.com/windows/default.mspx and enter the name of the technology you want in the Search for box.

Windows core management technologies include the following:

Windows Management Instrumentation

Windows Management Instrumentation (WMI) provides access to Windows management data and method information from a variety of programming and command-line tools.

Group Policy

Group Policy defines user-related policies in addition to security, networking, and other policies that are applied at the computer level. Also, Group Policy provides a way to manage domain controllers, member servers, and desktop user computers.

Windows Script Host

Windows Script Host (WSH) is a Windows administration tool that makes objects and services available for scripts and provides a set of guidelines within which the script is run. Also, Windows Script Host manages security and invokes the appropriate script engine.

Windows Installer

Windows Installer is a system service that installs and manages applications. It provides a standard method for developing, customizing, installing, and updating applications.

Microsoft Management Console

Microsoft Management Console (MMC) is a framework for hosting administrative tools, called consoles. A console may contain tools, folders or other containers, World Wide Web pages, and other administrative items. These items are displayed in the left pane of the console, called a console tree. A console has one or more windows that can provide views of the console tree.

Microsoft Management Applications

Microsoft offers management applications for all businesses, from small businesses to enterprise level businesses. These applications are described in this section.

Enterprise and Medium-Sized Business Applications

Microsoft Operations Manager

Microsoft Operations Manager (MOM) provides comprehensive event management, monitoring and alerting, reporting and trend analysis, in addition to event consolidation, intelligent agent functionality, and automated responses to events. MOM contains extensive product support knowledge in the form of Management Packs.

Systems Management Server

Systems Management Server (SMS) is a Windows-based product designed to manage, support, and maintain a distributed network of computer resources and to help automate change and configuration management.

MOM includes a Management Pack module with the knowledge for managing SMS-enabled servers.

Application Center

Application Center manages clusters of Web-based content servers. It provides an easy way to replicate content throughout server clusters and to distribute workload by using load balancing.

By adding Microsoft Operations Manager to the system, IT managers can use a single console to better manage their Application Center-enabled clusters together with other Windows services and Windows operating systems on their networks.

Figure 1: What applications manage

Additional Management Applications

Network Monitor

Network administrators use Network Monitor to view and detect problems on local area networks (LANs). Network application developers can use Network Monitor to monitor and debug network applications as they are developed.

Network Monitor monitors the network data stream, which consists of all information transferred over a network at any given time.

Terminal Services

Terminal Services delivers the Microsoft Windows 2000 Remote Desktop, and the latest Windows-based applications, to almost any computer, including those that cannot run Windows. You can also use it to remotely administer a server running Windows 2000.

Server Status Monitor

You can use the Server Status Monitor tool (SSM) to monitor the up or down status of a group of servers. The MOM SSM tool is available in the MOM SP1 Resource Kit.

Health Monitor

Health Monitor is available in Microsoft Application Center 2000. Health Monitor displays events and threshold breaches by running an agent on each monitored server and tracking values in the Windows Machine Interface.

Management Application Feature Comparisons

The following table illustrates the features of various Microsoft management applications.

Table 1 Management Features of Microsoft Management Applications

MOM Overview

MOM SP1 provides comprehensive event management, monitoring and alerting, reporting, and trend analysis. MOM includes the ability to consolidate events and to determine which events are of critical importance to an administrator. You can configure MOM to respond to events, either by contacting an administrator, or by resolving the event automatically, based on criteria that you specify.

The MOM architecture includes various components, including user interfaces that are referred to as consoles. These components are deployed in configuration groups. The basic components in a configuration group are:

• MOM Database — a Microsoft SQL Server database that stores configuration and monitoring data.

• MOM DCAM — the central MOM server

• Agents — run on each monitored computer

• MOM Administrator console — a MOM user interface

Figure 2: MOM components

MOM SP1 Features Overview

The following are features of MOM SP1.

Distributed event management

MOM captures a wide variety of system and application events from Windows-based computers that are distributed throughout an enterprise IT environment and collects them in a central database.

Performance monitoring

You can configure MOM to monitor key performance thresholds. You can monitor performance trends by using predefined set of rules or customized rules. Additionally, you can set thresholds that generate alerts and actions in response to performance changes.

Enterprise-class scalability

MOM manages events for networks of all sizes, from small-business networks, to enterprise networks. By using a three-tier architecture, you can design systems running MOM that can handle hundreds of millions of events per day, with full redundancy and workload distribution.

Mission critical availability

MOM provides mission-critical availability of the servers and of the MOM database itself. You can eliminate single points of failure by using MOM database clustering and redundant DCAMs.

Global systems support

MOM can monitor servers and applications that are localized

Interoperability

MOM with WMI can collect a wide range of events and performance data from any Windows 2000–based system.

You can configure MOM to monitor SNMP event data (traps) for any specified devices. Additionally, you can set MOM to generate SNMP trap messages. MOM can deliver such traps to a third-party SNMP management console. This lets MOM send data into third-party management systems, including network and enterprise management frameworks.

Further, you can use the Syslog protocol to have MOM monitor live event streams that are generated by UNIX-based systems, and by many network devices.

Active monitoring agents

Based on the rule-sets that are defined by the administrators at a central console, MOM agents provide a high degree of active monitoring. These local agents filter, collect, and consolidate event data. They can trigger actions locally. This architecture minimizes the traffic that MOM creates on the network, and it allows critical data to flow freely to administrators.

MOM SP1 Updates

MOM SP1 extends the functionality of MOM by:

• Allowing non-English environments to be managed through improved international language support.

• Improving performance and scalability to let you monitor twice as many servers as before.

• Providing support for installing the MOM database on a SQL Server Cluster.

• Adding updates to Microsoft Exchange 2000 and Active Directory Management Pack modules.

• Adding new Management Packs modules for Microsoft .NET Framework, Network Load Balancing, and Server Clusters.

• Providing resource kit that includes:

  • Server Status Monitor (SSM)

  • New testing and debugging tools that let you test scripts prior to production use

  • A data warehousing process and tool

• MOM SDK2 includes documentation and samples for two-way connectors, integrations of user-interface views, creation of management packs, and better support for managing third-party platforms.

MOM SP1 Documentation Resources

TechNet is the best resource for the most current MOM documentation.

Figure 3: TechNet location

To ensure that you have the most current information, MOM SP1 documentation is posted to TechNet when it is completed or updated, instead of only with a product release cycle.

Table 2 MOM Documentation Sites

	Best resources for MOM documentation
Evaluation	Reviewers Guide (www.microsoft.com/mom/evaluation/) Webcast - 11/2002: An Introduction to MOM Architecture, Features, Performance and Sizing (www.microsoft.com/mom/support/webcasts/) Webcast - 10/2001: MOM, An Overview and Technical Comparison with NetIQ AppManager (www.microsoft.com/mom/support/webcasts/) Microsoft Operations Manager Service Pack 1 Conceptual Guide (TechNet)
Planning and Deployment	Microsoft Operations Manager Service Pack 1 Deployment Checklists (TechNet: MOM\Deploy) Microsoft Operations Manager Service Pack 1 Deployment Guide (TechNet: MOM\Deploy) Whitepaper: MOM Performance and Sizing (www.microsoft.com/technet/prodtechnol/mom/mom2000/mompfsiz.mspx) Webcast - 02/2003: Understanding the MOM Sp1 Refresh (www.microsoft.com/mom/support/webcasts/) Webcast - 07/2001: Installing and Deploying MOM 2000 (www.microsoft.com/mom/support/webcasts/)
Maintaining and Operating	MOM SP1 Operations Guide (TechNet: MOM\Maintain) Webcast - 03/2002: How to manage the MOM Database (www.microsoft.com/mom/support/webcasts/) Webcast - 08/2001: MOM, Scalability and Complex Configurations (www.microsoft.com/mom/support/webcasts/) Webcast - 06/2001: Understanding MOM 2000 Management Packs (www.microsoft.com/mom/support/webcasts/)
Troubleshooting	MOM Support (www.microsoft.com/mom/support/default.asp) Microsoft Operations Manager Service Pack 1 Operations Guide (TechNet: MOM/Maintain)
Extending	MOM SDK (www.microsoft.com/mom/downloads/)

MOM SP1 ships with a basic Microsoft Windows NT 4.0 agent. If you have the NetIQ agent installed on a computer that is running Microsoft Windows NT 4.0, and you upgrade from any version of NetIQ Operations Manager to Microsoft Operations Manager 2000 SP1, computers lose some of the NetIQ agent functionality because the NetIQ agent is replaced by the MOM basic agent. To retain the functionality of the NetIQ agent, you must obtain a new license key from NetIQ. Install the NetIQ license key after you install or upgrade to MOM SP1.

MOM SP1 Components

The following MOM components make up a basic MOM configuration group and are described in this section:

Agent

You install an agent on each computer that you want MOM to monitor. Agents collect monitoring data on a remote computer, apply processing rules to the collected data, and then send the resulting data to the Consolidator. The agent software includes the OnePoint service that runs on each managed computer.

MOM SP1 ships with a basic Microsoft Windows NT 4.0 agent. If you have the NetIQ agent installed on a computer that is running Microsoft Windows NT 4.0, and you upgrade from any version of NetIQ Operations Manager to Microsoft Operations Manager 2000 SP1, computers lose some of the NetIQ agent functionality because the NetIQ agent is replaced by the MOM basic agent. To retain the functionality of the NetIQ agent, you must obtain a new license key from NetIQ. Install the NetIQ license key after you install or upgrade to MOM SP1.

DCAM

The DCAM is the central MOM server on which the MOM Administrator console is installed. The DCAM includes three components:

• Data Access Server (DAS)

• Consolidator

• Agent Manager

MOM OnePoint database

MOM uses a SQL Server database to store two types of information:

• Configuration data

• Monitoring data from agent-managed computers

MOM Administrator console

The MOM Administrator console is an MMC snap-in that you can use to monitor, configure, and deploy in the enterprise environment.

MOM Reporting

MOM Reporting is an optional component that you can use to generate reports based on the monitoring data that MOM collects. More than 100 predefined reports cover general system monitoring, operations, capacity planning, performance analysis, and application-specific reports that you can use to monitor resources, traffic, and availability.

Agent

The agent is installed on each computer that you want MOM to monitor and manage. An agent collects monitoring data on managed computers, applies processing rules to the collected information, and sends the resulting data to a DCAM.

An agent can collect the following information from the computer on which it is running:

• Events from Windows event logs

• Events from third-party application logs

• Performance data, such as thresholds and capacity planning data

• Missing events

• Timed events

• WMI information, including changes to the system services list and SNMP traps

• Events created by scripts

The agent applies processing rules to the collected information and performs the actions that are specified by the processing rules. By applying processing rules to collected information, the agent can perform any of the following actions and responses:

• Filter events

• Consolidate events into one event

• Send data to a Consolidator

• Send an alert when a performance threshold is crossed

• Send an alert to a Consolidator based on an event

• Generate an SNMP trap

• Run a batch or command file

• Run a script

• Update a state variable

The agent temporarily stores information in a buffer before it sends the data through an assured delivery mechanism to a Consolidator. MOM can work with enterprise management frameworks to send high-priority events as SNMP traps from each agent.

Agents continue to collect data even during lengthy network outages by sending batched data when network connectivity resumes.

At regular intervals, the agent initiates communication with a Consolidator. You can configure the amount of data that is sent at each interval. For quicker response to alerts, you can configure the agent to send alerts immediately when they occur. You can also configure whether the communications are encrypted, and you can set the encrypted communications port.

Agents send a periodic heartbeat to a Consolidator to ensure that the agent is operating properly. In response to the heartbeat, the Consolidator alerts the agent that the agent's rules must be updated.

You can install agents in two ways. You can use the Agent Manager to install agents automatically, or install agents manually if:

• A target server is in a domain that has no trust relationship with the MOM server domain.

• A target server is across a firewall.

• A target server is in a workgroup.

• You must control and limit network bandwidth usage (for example, to monitor target servers that are across slow network links).

• You must monitor a highly secure or sensitive server.

DCAM

The DCAM is the central MOM server on which the MOM Administrator console is installed. The DCAM includes three subcomponents:

• Data Access Server (DAS) — Controls the flow of data between the database, the Consolidator, the MOM Administrator console, and the Web console.

• Consolidator — Collects monitoring data from agents on managed computers and forwards this data to the DAS. The Consolidator also sends configuration changes to agent-managed computers. This component also acts as the agent for the MOM server itself. This gives MOM self-management capabilities and provides data forwarding for multitiered MOM server configurations.

• Agent Manager — Discovers, installs, and uninstalls agents on managed computers. The Agent Manager also passes configuration information to managed computers based on the processing rules for the configuration group.

Each DCAM contains its own agent component for monitoring itself and for forwarding alerts to the master configuration group when alert forwarding is configured.

DCAM refers to the DAS, Consolidator, and Agent Manager residing on the same server. CAM refers to the Consolidator and Agent Manager. MOM SP1 does not support installing the DCAM components on separate servers.

Database

The database consists of two files: the primary database, which contains tables, indices, views, and stored procedures, and the transaction log. The MOM Express Setup installs the Microsoft Data Engine (MSDE), which supports up to 2 GB of data. For additional data storage, you must use SQL Server as your MOM database.

MOM can collect large amounts of information, which you can use to assist in capacity planning. MOM stores all data and configuration information in the Microsoft SQL Server 2000 (OnePoint) database.

The MOM database can grow very large, particularly in environments where MOM collects significant amounts of data or monitors a large number of computers. You must maintain at least 40 percent of free space to let indexing and database jobs be completed successfully. For complete information about sizing your database, see the Performance and Sizing white paper at https://www.microsoft.com/MOM/techinfo/administration/perfsize.asp.

Database grooming

Database grooming is the process of deleting data from the MOM database and automatically resolving alerts. The grooming process is a SQLSERVERAgent batch job that resolves alerts or deletes the collected events, alerts, performance counters, and other events from the database.

MOM provides default grooming jobs in the MOM database. You can change grooming settings to meet your individual requirements.

When MOM grooms data, you can lose performance, alert, event, security, and capacity planning data. You might want to retain this historical data for a number of business reasons, such as long-term security auditing or capacity planning. To retain historical MOM data and keep the MOM database at optimum levels, you can create a separate database to serve as a MOM data warehouse.

MOM database on a SQL Server cluster

MOM SP1 supports the installation of the MOM database on a SQL Server cluster only for failover. In SQL Server failover clustering, the operating system and SQL Server work together to provide availability if an application fails, hardware fails, or if an operating system error occurs. Failover clustering provides hardware redundancy through a configuration in which vital, shared resources are automatically transferred from a failing computer to an equally configured server. Failover clustering is available only in the SQL Server 2000 Enterprise Edition.

MOM SP1 supports installing the MOM database on a cluster only for Active/Passive mode, which means only one instance of the MOM database can exist in the cluster. Having multiple instances of the MOM database in the cluster, referred to as Active/Active mode, is not supported in MOM SP1. This requirement does not affect other databases, which might use Active/Active mode.

For more information about using the MOM database in a SQL Server cluster, see Appendix C, Deploying the MOM SP1 Database on a SQL Server Cluster in the Microsoft Operations Manager 2000 Service Pack 1 Deployment Guide.

MOM Administrator Console

The MOM Administrator console is an MMC snap-in that is used to:

• Monitor servers across the enterprise

• Configure monitoring rules and responses

• Configure MOM settings and deploy MOM agents

You can customize the MOM Administrator console for specific user roles within your organization. You typically install the console on a DCAM server, but you can also install it on another server and in multiple Network Operations Centers.

Figure 4: MOM Administrator console

The left (console) pane contains the console tree. The console tree contains all the management components that are available in snap-ins.

The right pane in the MOM Administrator console is the details pane. When you select an item in the console tree, in the left pane, the right pane changes to display the details for that item.

The MOM Administrator console provides a framework for the following snap-ins:

Monitor Snap-in

The Monitor snap-in displays views for alerts, computers, computer attributes, computer groups, events, and performance data based on selected criteria. You can also use it to monitor product component status.

You can use the default views that are provided, or you can create custom views that are specific to your environment.

When you click the Monitor item in the console tree, the details pane displays descriptions of the types of views that you can create. The details pane also includes descriptions of the MOM Components and Advanced folders. Clicking an icon or link in the details pane displays the default view of that type of view.

Figure 5: MOM Administrator console, Monitor default view

Expanding the Monitor snap-in gives you access to the following items:

Components

Provides an overview of the product architecture and links to the Web console (if installed), published HTML reports, and component folders. You can use the Agents, Consolidators, and Agent Managers folders to monitor specific product components.

Advanced

Contains the Temporary Views folder. MOM SP1 uses the Temporary Views folder as a temporary container during the creation of new views.

Custom tasks

Use to define custom tasks that are available only to you or that are available to all users. You can create custom tasks for event, alert, attribute value, and computer items.

The Custom Task command becomes available on the Action menu when you select an alert in an Alert view.

Rules Snap-in

The Rules snap-in displays computer groups, processing rule groups, notification groups, and the advanced rule functionality that is used in one configuration group. You can create or modify computer groups and processing rules by using the Rules snap-in. You can create or modify computer attributes, which you can use when you create computer groups. You can also create or modify notification groups, scripts, and data providers, which you can use when you create processing rules.

If you want to create new computer groups and processing rules for several configuration groups, you can add other MOM snap-ins to the MOM Administrator console.

For more information about rules and computer groups, see the Management Pack Modules section later in this guide.

Figure 6: MOM Administrator console, Rules default view

Expanding the Rules snap-in gives you access to the following items:

Computer groups

Lists all computer groups that are defined for the configuration group and lets you to create new computer groups.

Processing rule groups

Related processing rules that are grouped together for categorization. The Processing Rule Groups folder provides links to detailed HTML reports on all processing rule groups. You can expand processing rule groups in the left pane to display information about child groups and processing rules. You can print reports about a processing rule group or about rules.

Event Processing Rules

Collect specified events and take appropriate actions. Event processing rules instruct MOM to perform the following actions:

• Collect specific events (Collection rules)

• Alert on or respond to event (Event rules)

• Filter event (Filtering rules)

• Detect missing event (Missing event rules)

• Consolidate similar events (Consolidation rules)

Alert Processing Rules

Lists all alert processing rules in this processing rule group. You can create new alert processing rules, modify properties of alert rules, and modify the company knowledge base associated with a rule.

Performance processing rules

Lists all performance processing rules in the processing rule group. You can create new performance processing rules, modify properties of performance rules, and modify the company knowledge base associated with a rule.

Notification groups

Lists all notification groups for the configuration group. You can create new notification groups in this folder. In each notification group folder, you can create operators for the group and modify notification group properties.

Advanced

When you select the Advanced folder in the console tree, the details pane displays descriptions of the advanced processing rule folder. Clicking an icon in the details pane displays the related contents of the folder.

Scripts

Lists all scripts that are available to be used within processing rules. Use to create new scripts and modify the properties of existing scripts.

Computer attributes

Lists available computer attributes and lets you to create new ones. This lets you to create computer groups that are based on common attributes. You can create a new computer attribute based on a Registry key or value.

Providers

Lists all providers available for this configuration group. Create new providers and modify existing ones.

Operators

Lists all operators available for this configuration group. Add new operators and modify existing ones.

Search results

Shows results of Processing Rule searches that you have performed. The Processing Rule Search Results item displays the processing rules that match the search criteria.

Configuration Snap-in

The Configuration snap-in displays the agents, Consolidator, and Agent Manager components within a single configuration group. You can view and modify configuration group settings for all components, and configure individual components. You can also use the Configuration snap-in to view and approve agents before they are automatically installed on, or uninstalled from, computers within the configuration group.

Figure 7: MOM Administrator console, Configuration default view

Expanding the Configuration snap-in gives you access to the following items:

Global Settings

Lets you to configure component settings that apply throughout the configuration group. Some of the items contained in the Global Settings folder are:

Agent Managers

You can specify how often Agent Managers scan the Managed Computers list and perform a manual managed computers scan. You can identify the agent service account and specify how agents are deployed. You can specify whether MOM immediately installs or uninstalls agents as required, or adds them to the Pending Installations list. You can also specify the amount of time MOM waits before removing unneeded agents.

Consolidators

Specify how often Consolidators poll for rule changes, the number of responses that can run simultaneously, and how the Consolidator buffers data.

Agents

Specify agent buffering properties, heartbeat parameters, and how often the agent checks for service status changes. You can also specify the number of responses that can run simultaneously, communication retry parameters, packet settings, and logging parameters.

Pending installation

Lists the computers on which an agent installation or removal is pending. You can approve or cancel pending actions globally, or approve or cancel them one at a time. You can specify in Global Settings whether you want agents installed immediately or added to Pending Installations.

Agent Managers

Lists all computers in the configuration group on which an Agent Manager is installed. You can view details about each Agent Manager, including its Managed Computer rules and its Managed Computers list, which is the list of all computers matching the rules. You can specify when an individual Agent Manager scans computers in its Managed Computers list. You can also specify the service account that is used by the agents that an Agent Manager installs.

MOM Web Console

MOM includes a Web console that is installed on a DCAM server and runs in Microsoft Internet Explorer. You can access the Web console from any Windows operating system that supports Internet Explorer.

The Web console functionality is similar to the Monitor snap-in that is in the MOM Administrator console. You can use the Web console to view MOM database information, such as events, alerts, performance data, and information about computers in the configuration group. You can also use the Web console to change the state of alerts and to view MOM knowledge base information and company knowledge base information. You can create custom views for specific situations, such as all Critical Error alerts. If you install the Web console component on a DCAM, you can access Web reports, which are reports that you have saved as HTML. The Web console lets administrators access MOM data and perform some administrative functions from a remote computer.

There are security issues you should be aware of before you decide to install the Web console and make reports available through it. For details about installing and using the Web console securely, see Appendix A, Deploying the Web Console in the Microsoft Operations Manager 2000 Service Pack 1 Deployment Guide.

MOM SP1 Reporting and Data Warehousing

The MOM Reporting component provides reports for data that MOM collects. More than 100 predefined reports cover general system monitoring, operations, capacity planning, performance analysis, charts, and application-specific reports to monitor resources, traffic, and availability. These reports offer easy access to the data you need to manage and monitor your enterprise.

Data warehousing lets you groom your database for optimum performance and retain historical data for reporting purposes.

MOM Reporting

MOM Reporting uses a run-time version of Microsoft Access 2000 and an Open Database Connectivity (ODBC) connection, authenticated by the operating system, to the database. You can generate reports on demand, or at scheduled times. You can save reports in HTML format and view them through an Internet browser, or you can link to them from the MOM Administrator console or the Web console.

Reports provide information about the operations of various subsystems. For example, the MOM report titled Windows Operations provides information about the health of computers that are running Windows operating systems. MOM Reporting also provides information about the health of MOM itself. Such reports help the administrator to detect problems.

Reports that are specific to applications or services, such as the Active Directory directory service and Remote Access, are also included in MOM Reporting. These reports cover data for application-specific resources, such as data for remote access connections and sessions, and data for Active Directory replication and discovery.

Note: The MOM Reporting application creates reports in a Microsoft Access database by using data from the MOM database. In this section, the term MOM database refers to the SQL Server database in the MOM application. The term reporting database refers to the Microsoft Access database in the MOM Reporting application.

You can generate reports for specific data by using parameters. For example, you can limit the report to select data for specific servers, services, or computer groups, or for a specific date range. Reports that are created by using parameters can reduce the load on the MOM database.

When you first use MOM Reporting, default parameters are set by using the MOM Reporting console. If you change the parameters for a report, those parameters become the default for future versions of that report.

The parameters that are used most often in reports are date range and server list. The default date range is the previous seven days, and the default selection for server list is all servers. The server list that you select displays only servers that are specific to the report you are creating. For example, IIS reports only display IIS servers in the server selection list, while the Windows 2000 reports display only Windows 2000–based servers in the server selection list.

You can access MOM Reporting from the Start menu or from a command-line interface.

MOM Reporting Topology

It is a best practice to install MOM Reporting on a computer that is separate from the MOM database server. This prevents reporting-related memory and CPU usage from adversely affecting MOM database performance. With MOM Reporting installed on a separate computer, report generation times increase due to network latency, but MOM performance is not adversely affected.

MOM Reporting generates reports by using Microsoft Access to retrieve information that is stored in the MOM database. Access retrieves data from this Microsoft SQL Server database by using an ODBC connection authenticated by the Windows operating system. MOM configures the ODBC connection automatically during installation.

Multiple instances of MOM Reporting can connect to a single MOM database and generate reports by using its data. This is useful when different administrators monitor different aspects of MOM. One administrator can generate reports for performance and capacity, and another administrator can generate reports for operations. A single instance of MOM Reporting can also connect to multiple MOM databases and generate reports from those databases. This is useful for reporting on multiple configuration groups from one computer. MOM Reporting can generate reports from only one database at a time. The following figure illustrates a simple MOM topology with MOM Reporting installed.

Figure 8: MOM Reporting topology

MOM Reporting Console

By using the MOM Reporting console, you can view or print reports, and you can save reports as HTML.

Reports that you save as HTML are not automatically published to the Web. You must install the MOM Web console on one of the DCAM computers in the configuration group to make the reports that you save as HTML available for viewing in a browser.

Figure 9: MOM Reporting console

Important: Installation of the MOM Web console on a computer other than a DCAM computer is not supported.

Reports Published to the Web

Authorized users can use MOM Reporting to view and print reports, and to save reports as HTML files.

Merely saving reports as HTML files does not make the reports available as Web-based reports. To publish HTML reports to the Web, you must install the MOM Web console on one of the DCAM computers in the configuration group.

Important: If you install the Web console, anyone with access to the Reporting Web site can view reports that are published to the Web. Consider this when you are deciding which reports to publish to the Web, because it can create a potential security risk, depending on the data contained in the reports. For more information, see Chapter 5, MOM Security in the Microsoft Operations Manager 2000 Service Pack 1 Operations Guide.

Reporting Security

Because MOM Reporting accesses the MOM database, reports should be generated only by authorized users. This helps to reduce the chances of unauthorized access to MOM data. Limiting the number of users who can run reports also helps prevent MOM Reporting from adversely affecting the MOM database performance. Multiple reports that are generated simultaneously and long-running reports can have an adverse effect on MOM database performance.

Data Warehousing

MOM can collect large amounts of information, which you can use to assist in capacity planning. MOM stores all data and configuration information in the MOM (OnePoint) SQL Server 2000 database. The MOM database can become very large, particularly in environments where MOM is collecting large amounts of data or monitoring many computers. For performance reasons, MOM supports a maximum database size of 30 GB and requires that you maintain at least 40 percent of free disk space to allow indexing and database jobs to be completed successfully.

To maintain the optimum database size, MOM periodically removes (grooms) data from the MOM database. As MOM removes data, you can lose performance, alert, event, security, and capacity planning data, which is no longer available for MOM Reporting. You might want to maintain this historical data for a number of business reasons, such as long-term security auditing, long-term capacity planning, or other types of custom reporting.

MOM SP1 does not provide a supported data warehousing solution, but you can create a data warehouse by using instructions that are available in the MOM SP1 Resource Kit, which you can then use to store historical MOM data.

To maintain historical MOM data and keep the MOM database at optimum levels, you can create a separate database to serve as a MOM data warehouse. You can periodically back up MOM data from the MOM database, restore it to a holding database, and then import that data to the MOM data warehouse. Typically, you would perform this process on a regular basis and prior to your scheduled grooming cycles to preserve data. Because the MOM data warehouse contains all of the historical MOM data, you can use it to run reports containing long-term data.

How MOM Components Communicate

This section describes the communication mechanisms that MOM components use. Understanding how MOM components interconnect is critical to designing and implementing MOM solutions that meet your requirements.

The following figure illustrates the communication mechanisms among MOM components.

Figure 10: MOM communication

The Consolidator and Agent Manager (CAM) components make up the OnePoint service. This service performs Consolidator and Agent Manager functions and also local agent functions.

Consolidator functions

The Consolidator functions include passing processing rules and configuration data to agents, receiving monitoring data from agents, and inserting the agent data into the database by using the DAS. The Consolidator also uses the DAS to obtain new configuration data that is stored in the database. The Consolidator communicates to the DAS by using the Distributed Component Object Model (DCOM), and the DAS communicates to the database by using OLEDB. Security authentication is performed on this function.

Communication between agents and the Consolidator is not authenticated. For security reasons, it is more detrimental for the agent to trust the Consolidator than for the Consolidator to trust the agent. For this reason, the agent is designed to always initiate communication with the Consolidator.

At a set interval (five minutes, by default), agents send heartbeat information to the Consolidator. This heartbeat information includes the version of the agents latest configuration. At this time, the agent uploads its queues.

After the agent has uploaded all its queues, the Consolidator verifies whether the agents configuration is current. If the configuration is not current, the Consolidator sends the newest configuration information to the agent. The agent stores the new configuration information on the local computer. The Consolidator also keeps track of the last time it communicated with the agent, and this information is displayed in the Last Contact column of the MOM Administrator console.

Agent Manager functions

The Agent Manager functions include discovering managed computers, installing and removing agents, and scanning configuration group computers based on specified attributes. The Agent Manager usually uses remote procedure calls to perform its functions and requires local administrator privileges on each managed computer.

The Agent Manager discovery process involves several steps:

1. You specify the computers that you want to manage in a Managed Computer Rule (MCR).

2. During the discovery process, MOM scans Active Directory based on the entries in the MCRs. The scan is optimized for multiple queries within the same domain.

3. After MOM has the list of computers returned by the scan, it queries the MOM database for the list of currently managed computers, and then merges the two lists.

4. MOM performs a deeper level discovery on those computers that are contained within the merged list by making domain calls to determine which operating system is running on these computers. The merged list is then filtered based on this information.

5. MOM makes remote registry calls to perform attribute scans and collection on the computers in the merged list. These scans determine which applications the computers have installed, so that MOM can assign them to the appropriate computer groups.

6. MOM determines which computers on the list do not have an agent installed. If MOM is configured to install agents automatically, the agents are installed immediately. Otherwise, the computers that need agents are queued in the Pending Installation list until an authorized MOM user approves each computer.

7. After the agent is installed, it starts the local OnePoint service and calls the Consolidator to get information about the rules it must have so it can run.

Local agent functions

The local agent functions not only as an agent on the DCAM server, but also as a forwarding agent to send alerts to another Consolidator in a different configuration group.

MOM Administrator console

The MOM Administrator console communicates to the MOM database through the DAS by using DCOM. The Web console communicates to the Web console server components by using HTTP. This requires the Internet Information Services component. The Web console server communicates to the database through DAS by using DCOM.

MOM Reporting

MOM Reporting is based on Microsoft Access and communicates directly to the MOM database by using ODBC, bypassing the DAS component.

MOM Topologies

MOM SP1 components are deployed in configuration groups.

A configuration group consists of the following components:

• One database

• One or more DCAMs

• Up to 2000 agents

A configuration group represents a simple MOM topology. More complex topologies, or groupings of configuration groups, might be necessary to adequately monitor your environment. There are three supported design topologies that you can use to deploy MOM. This section includes a brief description of three supported topologies.

Single Configuration Group

The single configuration group topology works well for environments of up to 2000 managed computers, if you have the appropriate number of DCAMs installed and planned for failover. This topology provides a central administrative model and is the simplest of the three architectures to manage. You can use this architecture in environments with one or more domains.

Summary of topology

• One configuration group with one or more DCAMs

• One or more domains

• MOM database on a separate server running SQL Server

• Up to 2000 agents

Note: In a smaller enterprise environment with fewer than 50 monitored computers, you can install all MOM components on a single server. If the number of servers that you are monitoring grows to more than 50, consider moving to a distributed MOM deployment based on the single configuration group architecture. If the number of servers that you are monitoring is more than 100, deploy a distributed MOM deployment that is based on the single configuration group architecture.

The following figure illustrates a single configuration group by using multiple DCAMs with provision for DCAM failover.

Figure 11: MOM single configuration group

Multiple Configuration Groups with Multihomed Agents

Multihoming lets you configure agents to be a member of more than one configuration group. By installing multiple configuration groups, you can distribute monitoring requirements across groups. For example, many enterprises consist of organizations, with multiple departments, that are responsible for managing different aspects of a server. One group might monitor security issues, and another group might monitor only servers that are running specific Windows applications, such as Exchange.

In a multihomed agent environment, the agent reports to multiple configuration groups for events, alerts, and performance counters it collects. The multihomed agent processes work from the different configuration groups independently of one another so there is no conflict of rules. Agent computers can belong to up to four configuration groups.

You can deploy this topology across one or more domains.

Summary of topology

• Multiple configuration groups

• Up to 2000 agents per configuration group

• Single or multihomed agents

• One or more domains

• Dedicated database server in each configuration group

• Up to ten DCAMs per configuration group

The following figure illustrates to topology of multiple configuration groups with multihomed agents.

Figure 12: MOM multiple configuration groups with multihomed agents

Multitiered Configuration Groups with Alert Forwarding

Many enterprises with servers in multiple geographical locations require central monitoring of those servers. Alert forwarding is a set of workflow processes designed to create a hierarchical monitoring infrastructure.

Alert forwarding is used to achieve centralized monitoring. It is designed to forward only alerts and the events that are associated with those alerts, so it is very efficient and can reduce the network bandwidth requirements. Alert forwarding lets consolidators in one configuration group send alerts to another configuration group, which creates an efficient hierarchical alert-management structure for large enterprise networks.

Alert forwarding is recommended for:

• Managing more than 2000 agents.

• Monitoring sites in regions that do not have high-bandwidth capacity.

• Monitoring large numbers of servers that are behind a security boundary.

• Implementing a centralized administrative model.

Alert forwarding is accomplished by establishing a master configuration group to receive alerts, and then establishing one or more zone configuration groups to send alerts. The alerts and associated events are kept separately in the zone configuration group database and in the master configuration group database, so the data in the zone configuration group can be used for trend analysis.

Alerts that are forwarded maintain the source computer name from where the actual event was generated. Alert responses are processed independently between the zone and master configuration groups. Changes that are made in the alert properties within a zone configuration group do not affect alerts in the master configuration group and vice versa.

MOM supports a two-tiered architecture: zone configuration group to master configuration group. Implementing more than two tiers is not supported. A master configuration group can support up to 10 zone configuration groups with up to 120,000 alerts per day forwarded to the master configuration group.

Designing and operating a multitiered topology requires considerable team effort and coordination to implement processing-rule changes and configuration changes.

Summary of topology

• Master configuration group

• Up to 10 zone configuration groups with alert forwarding to the master configuration group

• Multiple domain environment

• Multiple configuration groups

• Up to ten DCAMs in each zone configuration group

• Single or multihomed agents

The following figure illustrates the topology for multitiered configuration groups with alert forwarding.

Figure 13: Multitiered configuration groups with alert forwarding

More About MOM Topologies

Security and workload issues are important considerations in any MOM deployment, and they can be built into your MOM topology.

Partitioned Configuration Groups

A partition is one or more DCAMs that manage a different set of computers than those managed by other DCAMs in the same configuration group. All of the partitions, whether they are in the same domain or not, share the same MOM database server. Each partition uses a different CAM service account than the other partitions.

Because different server applications can often have different administration teams that are responsible for them, you can use partitions to create distinct functional groups. For example, you can create a single configuration group with a partition of servers that are running SQL Server, another partition of servers that are running Exchange, and a third partition of Web servers. Each partition can have a separate administration team, or two or more partitions can share administration teams.

A configuration group can have a total of six partitions and a total of 10 DCAMs per configuration group. A partition can have redundant DCAMs to provide failover support, balance the agent load, or both. A configuration group can have partitions in different domains or in the same domain.

Note: MOM administrators in one partition can view data and change settings in another partition. MOM cannot be configured to prevent this from happening.

For more information about partition configuration groups, see Appendix D, Deploying a Partitioned Configuration Group in the Microsoft Operations Manager 2000 Service Pack 1 Operations Guide.

Implementing Multiple Configuration Groups

You can deploy MOM to monitor agents within a single configuration group. Additional configuration groups can be added to accommodate a growing organization or to scale across geographic locations. Eventually, your organization might require additional configuration groups for MOM to run optimally. This section includes factors that indicate that additional configuration groups might be required. Typically, all MOM components run within a configuration group. However, there are several reasons why multiple configuration groups within a single MOM enterprise might benefit your organization:

• Monitoring more than 2000 agents

  A single DCAM can monitor up to 1000 agents, and a single configuration group can monitor up to 2000 agents. To monitor more than 2000 agents, you must add additional configuration groups.

• Monitoring across a firewall

  If you have many agents that are across a firewall, it might be more efficient for you to add an additional configuration group across the firewall to manage these agents. Alerts can be forwarded to a configuration group outside the firewall.

• Slow links

  If you have many agents that are across a slow link, you might be able to optimize MOM performance and network performance by installing an additional configuration group on the other side of the slow link to manage these agents. Alerts can be forwarded to a configuration group on the other side of the slow link.

• Geographic location

  If your enterprise has multiple physical locations, it might be more effective for administrators in each location to keep their data local.

• Network bandwidth

  If your enterprise consists of wide-area links, the most effective use of your network bandwidth is to keep the majority of the traffic local, configuring your DCAMs to forward alerts and their associated events to the master configuration group.

• Organization departments

  If one department wants to keep their data separated from another department, you can establish separate configuration groups. The MOM Administrator console only reports data for each configuration group.

• Monitoring specific applications

  To optimize the process of monitoring specific applications, you can create configuration groups based on each application.

• Monitoring for security

  You can create configuration groups to monitor for specific security issues. This allows centralized monitoring of critical security issues.

Workload Distribution and Redundancy

In MOM, you can distribute the workload by adding multiple DCAMs to a configuration group. You can install up to ten DCAMs in one configuration group. Each DCAM can manage up to 1000 agents efficiently. However, one configuration group can only support up to 2000 agents. If you must distribute the agent load beyond the limits of a configuration group, then consider adding multiple configuration groups to your MOM design.

By installing multiple DCAMs in a configuration group, you also build redundancy into your design. Agents automatically recognize additional DCAMs that are installed in a configuration group. However, the DCAMs must use the same service account. DCAMs that use separate, security-partitioned security accounts are not redundant. If a DCAM is installed in a configuration group after the agent is installed, then the agent recognizes the redundant DCAM after the OnePoint service is restarted. If you install an agent manually, then you can specify a redundant DCAM (secondary Consolidator) during setup.

Redundancy is primarily achieved through the Consolidator. When you design a configuration group for redundancy, keep the number of agents assigned to each DCAM low enough so that failover from one DCAM to another does not result in more than 1000 agents reporting to a single DCAM.

Consolidator

Consolidator redundancy ensures that data is placed in the database even if a Consolidator is unavailable for some reason. If a Consolidator is unavailable, agents that typically send data through that Consolidator to the DAS send data to a redundant Consolidator instead.

You can create redundancy for the Consolidator component of the DCAM by installing at least one additional DCAM in a configuration group. To be redundant, DCAMs do not have to be configured for load balancing. Consolidators must use the same service account to achieve redundancy. Consolidators that are using different service accounts (accounts that are located within different security partitions) are not redundant.

Consolidators can manage their own agent load in addition to serving as a redundant Consolidator for other agents.

DAS

Redundancy for the DAS component ensures that the MOM database provides updated information to the MOM Administrator console. With multiple Data Access Servers, the database computer determines the most available DAS and then uses that DAS to update the MOM Administrator console. A DAS does not have to have the same service account to be redundant. If the DAS that the MOM Administrator console uses, fails, you must restart the MOM Administrator console to connect to a different available DAS.

Management Pack Modules

The Management Pack module is the container for a collection of rules, knowledge, and public views that you use to manage a system or application. The module contains all the Management Pack elements, such as processing rule groups, processing rules, and computer groups. It also contains the relationships between those elements.

MOM can collect an array of information from many different sources. By using Management Pack modules, you can specify how MOM collects, handles, and responds to information.

Figure 14: MOM Management Packs

Elements of an Management Pack Module

The following elements are included in a typical Management Pack module.

Computer Attributes

Computer attributes are characteristics that you can determined by looking at a Registry key or value.

Computer Groups

Computer groups are computers that are grouped together based on their domain, computer name, or attributes.

By using MOM, you can group similar computers, and then monitor and manage the group rather than each individual computer. Monitoring and managing computer groups saves you time and effort.

Computer grouping rules define groups of computers. You can group computers together based on their domain, computer name, or attributes such as the operating system version or installed applications. You can also identify specific computers to always be included or excluded from a computer group, regardless of their other characteristics.

Computers can be grouped in the following ways:

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

• By computer attributes, choosing from existing attributes, or by creating your own.

• By grouping computers based on their inclusion to or exclusion from a group, regardless of their other characteristics.

Naming a computer group lets you easily include one computer group in other computer groups.

Computer groups are dynamic. For example, a computer group defined as all computers that are running Windows 2000 includes all computers running Windows 2000 when the rule was created, in addition to any new computers on which Windows 2000 is installed. If you remove Windows 2000 from a computer, the computer no longer fits the computer grouping rule. The Agent Manager periodically scans managed computers to regroup computers according to the computer grouping rules.

Management Pack modules define specific computer groups based on the application or technology that the Management Pack module monitors. Changes that you make to computer groups are stored as configuration changes in the Management Pack module.

Notification Groups

A notification group contains a list of operators who can receive pages or e-mail as responses. The notification group specifies operators and operator schedules. Operators can belong to more than one notification group.

Data Providers

Data providers are Management Pack module components that create the connection to the relevant management technology, such as Windows event logs or Windows performance counters. Providers tell processing rules what information to acquire from the operating system. Processing rules can be applied on top of providers to indicate more specifically what to do with the information that is acquired from the provider. For example, a provider can indicate that processing rules can look for events in the Microsoft Windows NT application log. A processing rule can then be created to look for events with an event ID equal to 100 and an event source equal to Disk.

Processing Rule Groups

A processing rule group is a container for a logical grouping of similar processing rules, making processing rules easier to find. You can deploy processing rules by creating an association between Processing Rule Groups and Computer Groups. For example, a Processing Rule Group named IIS Server Rules contains 10 rules associated with the IIS Server 5.0 computer group. Any computer that becomes a member of the IIS Server 5.0 computer group receives the rules that are within the IIS Server Rules Processing Rule group.

Grouping processing rules together lets you associate more than one processing rule with a computer group. Processing rule groups can also contain other processing rule groups.

Processing rule groups that are provided as part of Management Pack modules contain specific Microsoft Knowledge Base information that defines the purpose, features, and configuration of the processing rule group.

Processing Rules

A processing rule defines how MOM collects, processes, and responds to information. Processing rule types include event, filtering, missing event, consolidation, alert, performance measuring, and performance threshold.

Processing rules define the information MOM collects and retains in the database. For example, processing rules can specify which events trigger alerts, how the alerts are processed, and how performance data is collected.

Processing rules have three parts. The first part defines the information that MOM collects. The second part of a processing rule defines what MOM does with the information it collects, and the third part defines MOM responses.

When MOM receives information that matches a processing rule, a processing rule match occurs. When a processing rule match occurs, MOM performs the actions of the processing rule, and the response that is defined in that rule. For example, a processing rule that matches events with a specific event ID might specify to save the event in the database, to generate an alert, and to send e-mail to a network administrator.

When you create a processing rule, you can also define the significance of the specified condition and provide detailed information to help administrators resolve the problem. This information, called the company knowledge base, is stored with the processing rule.

Note: Management Pack modules that are distributed by Microsoft contain information from Microsoft that is called the Microsoft Knowledge Base. You cannot edit the Microsoft Knowledge Base.

The following are typical processing rule types:

Event processing rules

Event processing rules monitor events. MOM evaluates event processing rules in the following order:

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

• Missing event rules specify that MOM generates an alert or response when a defined event does not occur during a specified time. MOM stores missing event alerts in the database.

• Event consolidation rules group similar events on an agent computer into a single summary event, which is stored in the database.

• Event filtering rules specify that MOM ignore the defined events. Filtering rules typically identify events that you do not consider significant.

• Event rules specify that MOM generate an alert or run responses when specific events occur. You can create event rules when certain events are not covered in other processing rules. MOM stores the events and alerts in the database.

Alert processing rules

Alert processing rules let you specify a response for an alert or for a number of previously defined alerts. For example, you might specify that the High-Priority Notification Group be paged for all Critical Error alerts resulting from the processing rules in the SQL Server processing rule group.

Performance processing rules

Performance processing rules define how MOM processes performance counter data and WMI numeric data. There are two types of performance processing rules:

• Measuring rules cause MOM to collect numeric values from WMI or from performance counters. MOM stores sampled numeric measures in the database. You can view this graphical data by using the Monitor snap-in and the Web console. Measuring rules can include a response.

• Threshold rules specify that MOM generate an alert when a WMI value or performance counter crosses a defined threshold. MOM does not store threshold data in the database. Threshold rules can include a response.

Knowledge Base

The knowledge base is a collection of information that is part of a Processing Rule or Processing Rule Group. The knowledge base describes the meaning, importance, and possibly the resolution for the relevant condition or problem that is discovered by the rule.

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

The Microsoft Knowledge Base contains information from Microsoft and cannot be edited. This is not the same as the online Microsoft Product Support Services knowledge base, although the purpose is similar.

A second knowledge base, called the company knowledge base, contains information that is entered by the end user. You can add information to the company knowledge base when you create or edit a processing rule or when you modify an alert. Over time, the company knowledge base can become invaluable to an organization. It reflects specific knowledge gained through experience, and it is available to benefit others in your organization.

Public Views

A public view is a database query against the data that is collected by processing rules. These views can be created to show administrators a particular set of information. For instance, the Application Center Management Pack module ships a public view that shows all open alerts on Application Center servers.

Responses

A response is an action that a processing rule initiates when a criteria match occurs. A response could be the sending a notification (email, net send, and page), or running a command, an executable file, or batch files, scripts, SNMP traps, and updating a state variable.

Associating Processing Rule Groups with Computer Groups

You associate, enable, disable, or inherit a processing rule group with a computer group so that MOM evaluates specific processing rules on specific computers. For example, you could associate a processing rule group named High Security with a computer group named Accounting. All processing rules in the High Security processing rule group are evaluated on computers in the Accounting computer group.

Evaluating the processing rules on all the computers in the computer group ensures similar data collection and management. By using the Monitor snap-in, you can create a Monitoring view of only the computers in that computer group.

If you associate a computer group with a parent processing rule group, rules in both the parent and child rule groups are evaluated on the computer groups computers.

If you have parent and child processing rule groups, you might want to associate the individual child groups with computer groups instead of associating the parent group with computer groups. A child group can have more than one parent group.

Also as a general rule, if you associate computer group A with parent rule group 1, and computer group B with the child rule group 1.1, rule group 1.1 is evaluated on computers in both computer groups A and B.

How Management Pack Modules Work

Management Pack modules provide specific processing rule groups, computer groups, and processing rules, such as filters, alerts, and performance sampling and threshold rules. These rules send configuration data to agents that define events to be monitored, and then collect the monitored data from providers that are defined in the agents. This data is stored in the database, and can be configured to create alerts and responses that are meaningful to your management environment.

Sending Configuration Data to Agents

Management Pack module rules contain configuration information for agent computers. This configuration data is sent by the Consolidator to the agent on the managed computer during the regularly scheduled Agent Manager scan, or by manually initiating an Agent Manager scan.

Agent Manager functionalities include discovery, installation and removal of the agent, and scanning to group computers based on specified attributes.

Consolidator functionalities include pushing rules and configuration to agents, receiving data from agents, and then forwarding the data to the DAS. The DAS inserts the data into the database. The Consolidator also obtains new configurations stored in the database through the DAS. At a configurable interval (five minutes, by default), agents send heartbeat information to the Consolidator. This heartbeat information includes the version of the agents latest configuration. When the heartbeat is received, the Consolidator verifies whether the agents configuration is current. If the configuration is not current, the Consolidator sends the newest configuration information, including updates to agent properties and processing rules. The agent stores the new configuration information on the local computer. The Consolidator also keeps track of the last time it communicated with the agent and displays this.

Monitoring data from agents is also sent to the Consolidator at a configurable interval (30 seconds, by default). However, alerts and responses that require a central response (a response that is generated on the DCAM rather than the agent) are forwarded to the Consolidator immediately.

Collecting Monitoring Data from Agents

MOM can collect information from many different sources. By using processing rules, you can specify how MOM collects, handles and responds to information. Processing rules define the information MOM collects and retains in the database.

Understanding Providers

MOM collects information from a variety of sources called providers. Processing rules define the provider of the information you want to collect. MOM can collect information from the following provider types:

Windows event logs

Provide events that are generated by Windows.

Application log providers

Provide events from Microsoft Internet Information Services (IIS) log files, SQL Server trace log files (SQL Server 6.5 only), generic ASCII log files, Unicode log files, and UNIX syslog files.

Timed event providers

Provide the functionality to run responses at scheduled times.

WMI event providers

Provide events from Windows Management Instrumentation (WMI), such as SNMP traps that are sent to the computer.

WMI numeric data providers

Provide sampled WMI numeric values.

Internal providers

Provide events that MOM generates internally, such as when an agent heartbeat does not occur on time. The internal provider is available only in Management Pack module processing rules.

Figure 15: How MOM collects information

Understanding Events

Events make up the majority of the information MOM collects from providers. An event is a defined occurrence in the system or in an application. MOM monitors events logged in Windows 2000 and other event logs, and responds to timed events, missing events, and script-generated events.

Event logs

Monitored computers log events in specific event logs, and MOM collects events from these logs. MOM can collect events from all Windows NT event logs and from the following Windows 2000 logs:

• Application — records events from applications on the monitored computer.

• System — records events from system components.

• Security — records events based on specified security options.

• DNS Server service — Records events from the Domain Name Service (DNS) server on computers that run Windows 2000.

• File Replication — Records events from the File Replication service on computers that are running Windows 2000.

• Directory service — Records events from the Active Directory service on computers running Windows 2000.

Application log events

Some software applications create their own text log files. By using MOM, you can monitor the following application log files or messages:

• Microsoft Internet Information Services

• World Wide Web Service

• Internet Locator Service

• Microsoft SQL Server trace log (SQL Server 6.5 only)

• Any generic, single-line log

Missing events

A missing event is an event that is supposed to occur within a specified time interval, but does not. You can create processing rules for events that you expect to occur within a specific time interval. If the event does not occur, it is considered to be missing. For example, if you have an automated backup procedure that is supposed to run on all your monitored computers every 24 hours, you can create a processing rule to notify you if one of those backups fails to occur.

Timed events

MOM SP1 can create timed events, which are events that are automatically created on a timed basis. For example, you might want to test your notification software once a day. You can create a processing rule that creates a daily event at 3:00 P.M. You can then assign a notification response to page a network administrator, sending a test message. Timed events are not stored in the database.

WMI events

WMI displays management information, such as computer configuration information and events, as a database structure. MOM can monitor WMI extrinsic or intrinsic events:

Extrinsic	Events that are provided to WMI by other applications. For example, MOM can monitor SNMP traps through WMI extrinsic events.
Intrinsic	Events that are generated by changes to WMI data, such as configuration changes on a computer. MOM can monitor configuration changes such as service status.

SNMP traps

MOM SP1 can monitor SNMP traps through extrinsic WMI events. An SNMP trap is a packet of information sent by a network device that is running SNMP. An SNMP trap is usually sent in response to an occurrence, such as a service stopping. Some SNMP traps indicate standard system operation.

Service status changes

MOM can monitor changes to the service status list through intrinsic WMI events. A WMI event is generated when a service changes states. Service states include:

• Stopped

• Starting

• Stopping

• Running

• Continuing

• Pausing

• Paused

For example, you might want to monitor the print spooler on a remote computer. You want to know if the spooler service stops for any reason. You can create a processing rule that monitors WMI for an event indicating that the spooler service on the computer has stopped, and when the event occurs, generates an alert.

Collecting specific events

MOM SP1 collects information based on processing rules. By default, information is not collected.

Collection rules let you identify events with specific criteria to be collected from specific sources. These events are added to the data processed by MOM. Events that match a collection rule are further evaluated for other processing rule matches.

Collection rules do not generate alerts or provide responses. Collection rules provide an easy way to centralize events in a common database.

Saving Monitored Information to the Database

MOM SP1 saves information that matches a processing rule to the database. For example, if you create a processing rule that generates an alert when a specific event occurs, MOM stores the event and the alert in the database. You can create filtering rules that specify events that you do not want MOM to process or store

You can monitor the collected events, alerts, and performance data by using the Monitor snap-in in the MOM Administrative console and in the Web console. You can create reports from the collected data by using MOM Reporting.

Understanding Performance Data

MOM SP1 can monitor and graph numeric data from WMI. Scripts can also generate performance data. You can create performance data from managed computers by using processing rules to define performance thresholds that create an alert when the threshold is crossed.

Performance measurement

MOM SP1measures performance by sampling numeric data from performance counters and from WMI. You can identify trends by collecting values as often as you specify, and creating graphs of the information.

You can identify WMI numeric properties to track. For example, MOM can monitor a computers free disk space, collecting a value at a specified interval. You can use this data in capacity planning. Monitoring the free disk space provides useful information for you to use in planning for upgrades or additional drives.

Performance thresholds

MOM SP1 can also monitor computers for performance thresholds by using Windows 2000 performance counters or by using WMI numeric values. For example, you could set a threshold value for free disk space being less than 20 percent. If the sampled free disk space value falls below the 20 percent threshold, MOM can create an alert.

Sampling performance values

Creating performance measurement rules lets you monitor performance counter data and WMI numeric data. You can identify trends by sampling average values as often as you specify.

In a performance measurement rule, you can identify a performance counter or WMI numeric data provider, and then specify a schedule for the data to be sampled. You can view graphs of sampled performance data in the MOM Administrator console, in the Web console, and in certain reports.

Sampled performance data is stored in the database. You can define responses for sampling rules.

Comparing performance values

MOM can compare sampled performance values to defined thresholds for generating alerts. You can define responses for threshold rules.

Understanding Criteria

You identify the information you want MOM SP1 to process by specifying its criteria. After you specify the provider, you must define the criteria that identify the specific event, alert, or performance data. For example, specific criteria help distinguish one event from another.

You can define some criteria by using wildcards, regular expressions, or Boolean regular expressions.

Event criteria

To identify specific Windows events, you can specify the following criteria, and combinations of these and other criteria:

• Event source

• Event number

• Event type

• Description text

• User generating the event

• Source computer

• Source domain

• Computer on which the event is logged

• Domain in which the event is logged

Alert criteria

An alert processing rule requires that you identify a number of alerts to which to assign a response. To identify specific alerts, you can specify the following criteria, and combinations of these and other criteria:

• Alert source

• Alert severity

• Alert owner

• Resolution state

• Computer

Performance criteria

To identify performance data, you can specify the following criteria, and combinations of these:

• Counter

• Object

• Instance

• Domain

• Computer

Understanding Alerts

Alerts help you detect conditions and performance thresholds to ensure that MOM brings the condition to your attention. Typically, alerts mean that the condition indicates potential problems. You can also create alerts that indicate informational events. Several processing rules can generate alerts and other actions:

• Event rules

• Missing event rules

• Performance threshold rules

You can assign more than one alert to an event. For example, a hard disk failure event can generate a Critical Error alert that initiates a paging response. An administrator is paged with the pertinent information about the hard disk failure. The same hard disk failure event can also generate an Error alert that sends an SNMP trap to an administrator monitoring SNMP.

Also, an alert processing rule lets you create the same responses for many alerts. For example, you could specify that a specific administrator is paged whenever a Security Breach alert occurs.

Alert severity

When an event or threshold occurs that matches a processing rule, MOM associates the specified alert, and the alert severity, to that event. The alert severity lets you quickly determine the importance of the indicated condition. You choose the alert severity when you create the processing rule. The different possible alert severities are listed in the MOM Help.

Alert resolution

When an event or threshold occurs that matches an alert-generating processing rule, MOM generates an alert. You can monitor alerts by using the Monitor snap-in or the Web console.

When you monitor alerts, you can read important information about each alert that helps you determine the action you might take to resolve the alert. An alert includes the following properties, among others:

• Alert icon and severity

• Computer generating the event associated with the alert

• Resolution state

• Resolution history

• Knowledge base

• Custom alert fields

Custom alert fields

You can create your own custom alert property fields. You can view these fields when you view the properties of any alerts. Custom alert fields might include the following examples:

• Trouble-ticket number from a related help desk application.

• Customer name whose service level agreement is affected by this indicated condition

• Building containing the affected computer

Suppressing duplicate alerts

Event storms occur when an application or system rapidly produces a large number of identical events.

If you have an alert associated with an event in an event storm, receiving multiple alerts for the same event within a short time might not be useful. The Consolidator can provide duplicate alert suppression. If duplicate alerts are received while the original alert remains unresolved, MOM SP1combines the duplicate alerts into a single alert. The MOM Administrator console then displays only a single alert. The alert properties indicate the number of alerts that were combined.

You can enable duplicate alert suppression when you create a processing rule. You can specify the fields in the alerts, the events, or the thresholds that generated the alerts that must be the same for the alert to be considered a duplicate.

Detecting missing events

A missing event is an event that is supposed to occur within a specified time interval, but does not. If you perform or automate routine tasks such as system backups, MOM SP1 can generate alerts and responses if these tasks do not occur as planned.

For example, each night, you might run a backup application that backs up your critical data. The backup should finish successfully between midnight and 6:00 A.M. When this application finishes successfully, it logs an event in the application log. You can create a missing event rule that stipulates this particular event must show up in the application log between midnight and 6:00 A.M. If the event is not logged during that time, MOM can send an alert and respond with a paging notification to a network administrator.

Consolidating similar events

Consolidation rules group multiple duplicate events from an agent computer into one summary event. Event consolidation provides a combined event to replace many similar events generated in a short time period.

Event consolidation can reduce system stress during an event storm. For example, if a hard disk begins to fail, it might send 100 events each second as failure notification. A consolidation rule can compress all events occurring within 60 seconds into a single event. Duplicate alert suppression combines duplicate alerts that are received while the condition is unresolved into a single alert. You see only one alert. The single alert indicates the number of alerts that were combined, the time of the first alert, and the time of the last alert.

The consolidated event shows the number of duplicate events that were combined during a specified time, and the time of the first and last event that the consolidated event represents.

MOM SP1 can consolidate events from a single computer. If multiple similar events occur on two computers during the specified time, the individual agents consolidate the events on each computer, resulting in two separate summary events.

Consolidation rules do not generate alerts or define responses. You can create other event rules to generate alerts or provide responses for the consolidated event.

Filtering events

Filtering helps you effectively manage the large number of events that occur throughout your network. You might not want MOM to process every event that occurs on every computer. Filtering rules can specify which events MOM does not process or store in the database.

MOM evaluates filtering rules after consolidation rules and before event rules. MOM provides you with the following choices for filtering actions:

Prefilter

For events that match a prefilter, MOM stops evaluating further processing rules, and it does not save matching events to the database.

Database filter

For events that match a database filter, MOM continues to evaluate processing rules, but it does not save matching events to the database. You can define responses for database filters.

Conditional filter

For events that match a conditional filter, MOM continues evaluating processing rules, but it saves events to the database only if another processing rule match occurs. You can define responses for conditional filters.

Automated Responses

A response is an action initiated by MOM SP1 when a processing rule match occurs. By using processing rules, you can define an automated response to a detected condition, such as an alert, a performance sample or a performance threshold. Responses help resolve the issue indicated by the event. The following processing rule types let you define responses for a processing rule match:

You can define the following automated responses within processing rules:

• Send a notification to a notification group

  • E-mail

  • Page

  • External command notification

• Run a command or batch file

• Send an SNMP trap

• Change state variables

• Launch a script

You can define more than one response for each processing rule match. For example, if an event indicates that a critical application has stopped, MOM can respond by restarting the application and by paging a network administrator.

In contrast, when you create an alert processing rule, you can assign one response to a number of alerts. For more information about alert processing rules, see the Alert Processing Rules Section earlier in this guide.

Responses can occur on the Consolidator computer or the agent computer. Responses that occur on the Consolidator computer are central responses. Responses that occur on the agent computer are local responses.

Sending Notification

Sending a notification to a network administrator is one way that MOM SP1 can respond to a processing rule match. The Consolidator performs notifications. Notification responses include the following actions:

• Sending e-mail

• Sending a page

• Sending a notification by external command

For notification responses, you must create notification groups.

Notification groups

A notification group specifies operators and operator schedules. An operator is someone who can receive and respond to a notification. Operator schedules indicate the days of the week and hours of the day when the person can be reached by e-mail, page, or external command notification. Using notification groups provides support for shift-based responsibility for handling responses.

By using the Rules snap-in in the MOM Administrator console, you can create the notification group and then create operators within the notification group. Operators can belong to more than one notification group.

For complete coverage in your enterprise, at least one operator in each notification group must be scheduled to receive e-mail or a page for every hour in every day. If certain times are not included in at least one operators schedule, then no one is notified if the processing rule match occurs during that time.

E-mail

MOM SP1 can send e-mail to a notification group when a processing rule match occurs. MOM supports Exchange and SMTP for e-mail notifications.

You can specify information to include in the e-mail, including, but not limited to, the following information:

• Computer name generating the alert or event

• Alert description

• Time of the alert or event

• Alert severity

• Alert resolution state

If an application or computer produces an event storm, and the event is one that calls for an e-mail response, you could potentially receive hundreds of identical e-mails. MOM can suppress duplicate alerts, so that you see only one alert, and receive only one e-mail. The alert properties indicate the number of alerts that were combined.

Paging

MOM SP1 can send a page to designated operators when a processing rule match occurs. A third-party paging service is required. Your paging service must provide an SMTP e-mail service for MOM paging to work. MOM paging works by sending e-mail to the paging service, which forwards the e-mail to the appropriate paging recipient.

External command

MOM SP1provides paging through the SMTP e-mail service. You might also want to use another paging software application to avoid paging through the SMTP e-mail service.

You can use third-party paging applications to notify operators of a detected condition. You can configure MOM to use an external command line to run paging software. For information about running a third-party paging application from the command line, see the paging software documentation.

Command or batch files

You can configure MOM SP1 to run a command or batch file when a processing rule match occurs. You can run the command or batch file on the agent or DCAM computer.

State variables

MOM SP1 provides state variables to let you keep track of the ongoing state of your enterprise. You can configure MOM to set or change state variables when a processing rule match occurs without having to launch a script. You can then access the state variables from a script the same way you would access any named ScriptState object by using the GetSet method. This response provides efficient correlation of high volume events.

You can configure MOM to update state variables in any of the following ways when a processing rule match occurs:

• Increment variable value

• Decrement variable value

• Set variable value to property

• Set variable value to text

• Set variable value to number

• Store the last n occurrences

You can configure MOM to update the state variable at the agent or at the consolidator.

Scripts

You can create automated scripts for MOM SP1 to run in response to a processing rule match. Scripting capabilities provide advanced monitoring and responses.

SNMP traps

MOM SP1 provides SNMP capabilities that let MOM and SNMP to integrate with other network monitoring applications. You can configure MOM to generate an SNMP trap when an alert-generating processing rule match occurs. An SNMP-ready monitoring application can then capture these traps. You can ensure that the event information is captured and stored in the database and passed on to other network monitoring applications.

The operating system SNMP service must be installed on the computer where you want to monitor SNMP traps.

You can specify that SNMP traps be sent from the agent or Consolidator computer. The advantage of sending a trap from the agent computer is that the trap originates on the computer experiencing a problem. This is a requirement if you are integrating MOM with other monitoring tools. This requires SNMP installation and configuration of SNMP on each agent computer. Sending a trap from the Consolidator computer reduces SNMP installation and configuration.

Using Management Pack Modules

This section describes how Management Pack modules are added to your environment, and how you can customize Management Pack modules to fit your management needs.

Importing and Exporting

MOM uses Management Pack modules to monitor specific applications. After the processing rule groups, rules, and other items that belong in the Management Pack are complete, they can be exported to a Management Pack module .akm file. The exported file can then be imported by another MOM installation. The exported file consists of the computer groups, processing rule groups, computer attributes, processing rules, data providers, notifications, notification groups, responses, scripts, knowledge base, and public views for a monitored application or set of applications.

The MOM Administrator console contains menu choices for exporting and importing Management Pack modules. Additionally, a command-line tool, ManagementModuleUtil, is available for exporting and importing Management Pack modules. ManagementModuleUtil is also useful, for example, when you are setting an application up. The application's Management Pack module could be imported to the MOM installation as part of the setup and then an administrator would not have to be at the MOM Administrator console.

You can import Management Pack modules to install a Management Pack module in a configuration group. You can also import a Management Pack module to update an existing Management Pack module.

When you import a Management Pack module, it is placed at the top level of the processing rules tree. The upward hierarchy is not retained during the export and import process into another computer group. Only the downward hierarchy is retained.

Testing and Deploying

The recommended process for introducing Management Packs into your environment includes testing the Management Pack in a test environment, piloting the Management Pack with a limited number of servers, and then deploying the Management Pack into your production environment. At each stage of deployment, configure and customize the Management Pack, test the changes, and then export the Management Pack to archive the results. Introduce only one Management Pack into your production environment at a time.

If you follow this process for introducing Management Packs into your environment, you can reduce the effect on your network environment and ensure that Management Packs are appropriately configured for your environment.

Customizing

You can customize a Management Pack module in two different ways.

• You can customize rules within an existing Management Pack module, changing the way you collect and process information for that Management Pack module. This kind of customization is useful for restricting what is monitored to only those items that you want.

• You can also create custom Management Pack modules, by using existing rules or writing new ones that are specific to the application and events that you want to monitor. For more information about customizing Management Packs, see the Microsoft Operations Manager 2000 (MOM) Service Pack 1 Management Pack Authoring Guide.

Monitoring Management Pack Data

This section describes different ways to use the monitoring features of MOM and the resolution of monitored events.

Viewing Monitoring Data

Two key mechanisms let you access the monitored data: views and reports. Both offer default and custom means of viewing the data. With these mechanisms, you have an many ways to view this vital information.

You can use the default views in the MOM Administrator console and in the Web console to view database information, or you can create your own views. You can create private views, which are accessible only by the user who created them. You can also create public views, which are accessible by anyone.

MOM Reporting offers predefined views of the monitored application or environment. These views display reports or graphs of the collected data. These reports offer you access to the data you must have to manage and monitor your enterprise.

Management Pack modules provide default public views that are related to the specific monitored application or environment. These predefined views save you time and effort, and offer you an immediate glimpse of the monitored application or environment. Reports associated with Management Pack modules also offer quick access to specific information you need.

Monitoring with Multiple MOM Administrator Consoles

The MOM Administrator console is an Microsoft Management Console (MMC) snap-in and is the central user interface for monitoring and managing configuration groups.

For an implementation that uses SQL Server for the MOM database, you can install and access the database with multiple MOM Administrator consoles. The additional user interfaces do not have much effect on performance and can greatly increase MOM usability.

Note: For an express implementation that uses MSDE for the MOM database, using multiple MOM Administrator consoles can adversely affect performance.

The following figure illustrates the basic topology for deploying the MOM Administrator console to the network operations center. You can install multiple MOM Administration consoles to monitor the same MOM configuration group.

Figure 16: Operations desk topology

Changing the State of an Alert

By using the Monitor snap-in or the Web console, you can track alerts throughout the process of resolving the indicated condition. The alert resolution state indicates the alert's current point in the resolution process. The default resolution state for alerts is New. You can change the resolution state to match the current state of the process.

You can assign an Owner to an alert. The Owner is typically the person responsible for resolving the alert.

MOM automatically tracks alert resolution history. The history indicates whether any responses were carried out for this alert, and records all changes that are made to alert fields. You cannot edit the alert resolution history, but you can add your own resolution comments that are appended to the history.

When the condition that caused the alert has been resolved, you can change the alert resolution state to Resolved.

Resolution state

Resolution state indicates whether you have begun to resolve the alert. You can change the resolution state of an alert to track resolution progress. The default resolution states are defined below.

Table 3Default resolution states defined

Resolution state	Definition
New	Indicates this alert has not yet been addressed. Alerts are New by default.
Acknowledged	Indicates that this alert has been read and acknowledged, but not assigned.
Level 1: Assigned to helpdesk or local support	Indicates that the help desk or local support is now responsible for this alert.
Level 2: Assigned to subject matter expert	Indicates that a subject matter expert is now responsible for this alert.
Level 3: Requires scheduled maintenance	Indicates that the alert identifies a condition requiring maintenance, which has been scheduled.
Level 4: Assigned to external group or vendor	Indicates that an external group or vendor is now responsible for this alert.
Resolved	Indicates that the condition that generated this alert has been resolved.

You can modify or delete the default resolution states (except New and Resolved), and also create your own to meet the requirements of your network enterprise. Example custom resolution states might include In Progress or Deferred.

You can set a service level agreement time for each resolution state. Service level agreement time is the maximum time that an alert can remain in a particular resolution state. For example, company policy might require that no alert can remain in the New resolution state for longer than 10 minutes. If an alert remains in the New state for longer than 10 minutes, it is considered a service level exception. The Monitor snap-in provides a view of all service level exceptions.

A report on Alert Resolution Times presents the average time spent by alerts in a given time period.

Note: Scripts can also change alert resolution states. For example, if you run a script to resolve an alert condition, the script can also change the resolution state to Resolved.

Resolution history

MOM SP1 automatically tracks and records all changes to alert properties, including changes made by a processing rule, changes made by scripts, and any automatic responses that have occurred. You cannot edit the automatic alert resolution history. It provides a record of alert resolution.

You can, however, add your own information to the resolution history. When you change the resolution state of a specific alert or when you have gathered more information about the issue, you can provide your own comments to keep a current record of the alert resolution process. Providing specific comments lets you accumulate knowledge about this particular instance of the alert. By adding resolution comments to individual alerts, you can track how a particular condition was addressed. The resolution history is important in tracking the alert, particularly if the process of resolving the alert spans several operator shifts.

Predefined MOM Management Pack Modules

This section provides a complete listing of predefined Management Pack modules that Microsoft offers for use with MOM SP1.

Predefined Management Pack modules for MOM SP1 are grouped into two Management Packs.

Base Management Pack

The following Management Pack modules are included in the Base Management Pack, which is shipped and installed as part of the MOM SP1 product.

Microsoft Routing and Remote Access Service (RRAS) Management Pack Module

The Microsoft RRAS Management Pack module collects the events RRAS places in the Windows 2000 system logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• No active ISDN lines or dial tone, indicating a connectivity or configuration issue

• RRAS security failures

• Maximum number of LAN interfaces, dial-in interfaces, or RAS clients has been reached, indicating a capacity issue

• Invalid user account names, expired passwords, and other authentication problems

Microsoft Operations Manager Management Pack Module

The Microsoft Operations Manager Management Pack module monitors events placed in the application log by MOM, and performance of MOM components. This Management Pack module collects events that might indicate service outages or configuration problems, so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• MOM cannot monitor the specified application log files due to file format issues

• MOM cannot monitor performance counters due to configuration issues

• MOM cannot monitor SNMP traps due to SNMP errors

• Consolidator cannot find the DAS

• DAS cannot find the database

This Management Pack module also collects and displays CPU information. By providing attribute views sorted by BIOS date, BIOS version, CPU Identifier, CPU Speed, and CPU vendor, this Management Pack module provides a valuable inventory.

With this Management Pack module, you can increase the availability and performance of MOM. This Management Pack module provides the knowledge and expertise you need to leverage the product and get an immediate return on your investment.

Microsoft Distributed Transaction Coordinator Management Pack Module

The Microsoft Distributed Transaction Coordinator Management Pack module monitors the events that Microsoft Distributed Transaction Coordinator (MSDTC) places in the system and application logs. MSDTC is an important infrastructure application for SQL Server, Microsoft Message Queue, SNA Server, and Microsoft COM Transaction Integrator for CISC and Oracle databases.

This Management Pack module detects errors conditions that could affect the availability and reliability of MSDTC. Detecting and correcting problems with this critical infrastructure application ensures availability for the applications that rely on it. This Management Pack module lets you effectively manage MSDTC.

Microsoft Domain Name Service Management Pack Module

The Microsoft DNS Management Pack module collects DNS NT events from the system event log for Windows NT and events from DNS server event log for Windows 2000 and Microsoft Windows Server 2003. In addition, this Management Pack module also includes rules that apply thresholds to important DNS performance counters on Windows 2000 and Windows Server 2003. This Management Pack module collects events that might indicate service outages or configuration problems, so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• DNS is unavailable

• Shortage of available memory is affecting DNS

• DNS has detected corrupted registry data

Microsoft Dynamic Host Configuration Protocol Service Management Pack Module

The Microsoft DHCP Management Pack module collects the events that the Dynamic Host Configuration Protocol (DHCP) places in the Windows 2000 and Windows Server 2003 system logs. This Management Pack module collects events that might indicate service outages or configuration problems, so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• DHCP service has stopped or paused

• DHCP failed to initialize the global data, registry data, or database

• DHCP failed to start the RPC server

• DHCP was unable to restore the database

Microsoft Internet Information Server Management Pack Module

The Microsoft IIS Management Pack module monitors events that IIS and its services place in the Windows 2000, Windows Server 2003, and IIS event logs. This Management Pack module includes a script that polls and tracks the responsiveness of your IIS server. This script provides the performance data you need to understand usage trends and perform accurate capacity planning. This Management Pack module also includes scripts to test and track availability of selected web pages.

This Management Pack module lets you effectively manage IIS and avoid costly service outages. For example, this Management Pack module alerts you in the following critical conditions:

• Bad or missing links on your site or from a referring site

• Heavy web traffic preventing users from connecting to your site

• Configuration errors or resource shortages affecting service levels

• Security issues such as attempts at a buffer overrun attack

• Active Server Page errors indicating a possible service outage of an application on your site

This Management Pack module features saved public views that are specific to IIS, such as Access Denied Alerts, Possible Buffer Attack Alerts, Active Server Page Transaction Rate, Web Server Response Rime Measurement, and Web Server Throughput. These views provide a quick look at the health of your IIS implementation. This Management Pack module also includes many reports that are specific to IIS, to help you quickly identify and correct IIS issues. This Management Pack module quickly brings any service outages or configuration problems to your attention, increasing the security, availability, and performance of your Web site.

Microsoft Message Queue Management Pack Module

The Microsoft Message Queue Management Pack module collects the events MSMQ places in the Windows 2000 application logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Security authentication errors, indicating configuration, availability, security issues

• Memory allocation and disk space errors, indicating a possible service level issue

• Attempts to tamper with routed messages, indicating a possible security issue

• Database consistency and availability errors

Microsoft Systems Management Server Management Pack Module

The Microsoft SMS Management Pack module collects the events that SMS 2.0 places in the Windows 2000 application logs.

This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Starting and stopping SMS

• Memory allocation and disk space errors affecting service levels

• Failure to install or remove files

Note: SMS 2.0 is supported only on Windows 2000 with SMS 2.0 SP 2 installed.

Microsoft Transaction Server Management Pack Module

The Microsoft Transaction Server Management Pack module monitors events that Microsoft Transaction Server (MTS) placed in the application and system logs. This Management Pack module collects events that might indicate service outages or configuration problems, so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• MTS becomes unavailable

• MTS has detected replication errors

• Resource issues affecting MTS performance

• Configuration issues impacting MTS availability and performance

Microsoft Windows Active Directory Management Pack Module

The Microsoft Windows Active Directory Management Pack module provides the features you must have to effectively manage your Active Directory environment, such as automated discovery, change monitoring, health monitoring and recovery, and replication monitoring. This Management Pack module lets you effectively manage your Windows 2000 Active Directory environment, increasing availability, security, and performance. For example, this Management Pack module alerts you of the following critical conditions:

• Active Directory replication failure

• The Global Catalog is not available

• Active Directory is not responding

• The DNS server for a given domain is not available

This Management Pack module includes public views, which let you centrally monitor the health, performance, and availability of your Active Directory environment. Public views, such as the following, let you instantly begin managing your Active Directory environment and provide an immediate return on your investment:

• Available Disk Space on Windows 2000 Domain Controllers

• Active Directory Database

• Replication Traffic — Objects per Second

This Management Pack module provides many automated scripts to monitor the performance and health of essential Active Directory functions:

• Relative Identifier Role Master availability

• Replication latency

• Available disk space for drive hosting Active Directory database

These scripts gather data on speed, capacity, and availability. You can easily analyze this performance information by using the more than 30 Active Directory specific reports included in this Management Pack module. These reports let you perform accurate load balancing and capacity planning, and alert you to possible future problems. Additionally, there are reports that perform the following tasks:

• Track availability of domain controllers and key Active Directory services

• Provide details about domain topology, including information about trusts, replication topology, and location of operation masters

• Indicate if best practices for domain configuration are being followed

• Give information about possible replication problems

Microsoft Windows Operating System Management Pack Module

The Microsoft Windows Operating System Management Pack module monitors the events Windows places in the system and application logs. Originating from many different components of the operating system, these events indicate exceptional conditions associated with various aspects of Windows operations.

This Management Pack module includes threshold rules for many performance metrics. These threshold rules monitor the overall performance of the Windows operating system and alert you to critical performance issues. You can analyze and graph this performance information to understand usage trends, to perform accurate load balancing, and to manage system capacity.

This Management Pack module lets you effectively manage the Windows operating system, increasing availability, security, and performance. For example, this Management Pack module alerts you of the following critical conditions:

• Windows is unable to allocate the necessary system resources

• Conflict for an IP address on a system indicating network configuration errors

• An illegal server message block was received indicating a possible break-in attempt

• Windows audit log is full, indicating that audit data may be lost

Microsoft Windows Internet Naming Service Management Pack Module

The Microsoft Windows Internet Naming Service Management Pack module collects the events that Windows Internet Name Service (WINS) places in the Windows 2000 and Windows Server 2003 system logs. This Management Pack module collects events that might indicate service outages or configuration problems, so you can quickly take corrective or preventive actions. For example, this Management Pack module alerts you of the following critical conditions:

• WINS is not available

• Corrupt or missing WINS database

• Errors in the WINS database backup

• WINS database has reached its limit, indicating availability concerns

Microsoft Windows Terminal Server Management Pack Module

The Microsoft Windows Terminal Server Management Pack module monitors events placed in the application and system logs by Windows Terminal Server. This Management Pack module collects events that might indicate service outages or configuration problems, so that you can quickly take corrective or preventative actions.

For example, this Management Pack module alerts you in the following critical conditions:

• Terminal Server becomes unavailable

• Terminal Server Errors which could indicate transmission problems or faulty packets

• Resource issues affecting Terminal Server performance

• Configuration issues impacting Terminal Server availability and performance

This Management Pack module provides many automated scripts to monitor the performance and health of essential Terminal Server functions:

• The number of active and inactive sessions

• Total input/output in bytes per session

• CPU usage for all Terminal Server processes or for specific users or specific processes

• Memory usage for all users or per user

These scripts gather data on speed, capacity, and availability. You can analyze this performance information by using the Terminal Server specific reports that are included in this Management Pack module. These reports let you to perform accurate load balancing and capacity planning, and alert you to possible future problems.

Server Cluster Management Pack

The Microsoft Server Cluster Management Pack monitors the events that cluster components place in the system log. This Management Pack detects error conditions that could affect the availability and reliability of the cluster service and any cluster resources that are hosted by the cluster. Detecting and correcting problems with this Management Pack ensures availability of the applications that rely on it. With this Management Pack, you can effectively manage Microsoft server clusters and cluster applications.

Network Load Balancing Management Pack

The Microsoft Network Load Balancing Management Pack monitors the events that the Microsoft Network Load Balancing components place in the system log. This Management Pack detects errors and conditions that could affect the availability and reliability of the Microsoft Network Load Balancing clusters and the applications they host. Detecting and correcting problems with this Management Pack ensures availability for the applications that rely on it. With the this Management Pack, you can effectively manage Microsoft Network Load Balancing clusters.

.NET Framework Management Pack

The .NET Framework Management Pack module can collect some of the event and performance data generated by the applications leveraging the .NET Framework. This Management Pack module collects event and performance behaviors that might indicate service, performance, or availability issues.

Specifically, the .NET Framework Management Pack module lets you monitor performance data that is generated by the Common Runtime Library, ASP.NET, System Data, and the Network Class Library. The Management Pack module also monitors critical events that are generated by the ASP.NET component.

The Management Pack module consists of the Monitoring Rules rule set, and the Rule Templates and Samples rule set. These two different types of rule sets are in the respective processing rule groups. Rules in the Monitoring Rules processing rule groups provide basic monitoring and do not necessarily require user customization. The rules in the Rule Templates and Samples processing rule groups require user customization before use. These rules can be recreated or copied into custom, application-specific Management Pack modules, and then modified to suit the monitoring requirements of the application. A best practice is not to modify the rules under Monitoring Rules processing rule groups. Instead, use them as samples and templates for your own custom application-specific Management Pack modules.

Additional information about the specific features this management pack exposes is in the Knowledge Base on the following Processing Rule Groups:

• Common Runtime Library

• ASP.NET

• System Data

• Network Class Library

Application Management Pack

The following Management Pack modules are included in the Application Management Pack, which is shipped and installed as a product separate from MOM SP1.

Microsoft Exchange 2000 Management Pack Module

The Microsoft Exchange 2000 Management Pack module monitors events that are placed in the application log by various components of Exchange, such as directory service access, information store, extensible storage engine, message transfer agent, Exchange clustering, Microsoft Outlook Web access, and Internet protocols.

This Management Pack module includes important performance metrics to monitor the overall performance of Microsoft Exchange and to alert you to critical performance issues. By using MOM Reporting, you can analyze and graph this performance data to help you understand usage trends, to perform accurate load balancing, and to manage system capacity.

This Management Pack module lets you effectively manage your Exchange installation and to avoid costly service outages. For example, to alert you of possible critical conditions, this Management Pack module :

• Monitors vital performance monitor data, which can indicate that the server is running low on resources.

• Collects important warning and error events from Exchange 2000 servers, and alerts operators to problems.

• Monitors disk capacity and alerts operators when disk capacity is running low, and it provides knowledge about which Exchange files are on the affected drives.

• Monitors the Exchange services that are expected to be running on a specific server.

• Monitors whether an Exchange database can actually be reached by a MAPI client logon, which verifies both the Exchange database and the Active Directory functionality.

• Monitors high queue lengths that are caused by an inability to send e-mail to a destination server.

• Monitors and alerts operation to a high number of simultaneous connections, which indicate a denial of service attack

• Monitors configuration errors or resource shortages affecting service levels.

This Management Pack module uses saved public views that are specific to Exchange. These views provide a quick look at the health of your Exchange implementation. This Management Pack module also includes many reports that are specific to Exchange to help you quickly identify and correct Exchange issues.

This Management Pack module quickly brings any service outages or configuration problems to your attention, which increases the security, availability, and performance of your Microsoft Exchange installation.

Microsoft Exchange 5.5 Management Pack Module

The Microsoft Exchange 5.5 Management Pack module monitors events placed in the application log by various components of Exchange, such as the directory service, database, Internet mail connection, information store, message transfer agent, NNTP interface, and POP3 interface.

This Management Pack module includes important performance metrics to monitor the overall performance of Microsoft Exchange and to alert you to critical performance issues. By using MOM Reporting, you can analyze and graph this performance data to understand usage trends, to perform accurate load balancing and to manage system capacity.

With this Management Pack module ,you can effectively manage your Exchange installation and avoid costly service outages. For example, this Management Pack module alerts you to the following critical conditions:

• Slow delivery times indicating a reduction in the current service level

• High queue lengths resulting in an inability to send mail to or receive mail from the Internet

• High number of simultaneous connections indicating a denial of service attack

• Configuration errors or resource shortages affecting service levels

• Replication errors affecting distributed Exchange directories

This Management Pack module uses saved public views that are specific to Exchange. These views provide a quick look at the health of your Exchange implementation. This Management Pack module also includes many reports that are specific to Exchange, to help you quickly identify and correct Exchange issues.

This Management Pack module quickly brings any service outages or configuration problems to your attention. This increases the security, availability, and performance of your Microsoft Exchange installation.

Microsoft Proxy Server Management Pack Module

The Microsoft Proxy Server Management Pack module collects the events the Microsoft Proxy Server places in the Windows 2000 and Windows Server 2003 system logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following conditions:

• Microsoft Proxy service has stopped, paused, or started

• Microsoft Proxy service failed to reach the network or the Internet host

• Microsoft Proxy service is out of available memory

• The Microsoft Proxy service connection to the server has been reset

Microsoft ISA Server Management Pack Module

The Microsoft ISA Server Management Pack module collects the events Microsoft ISA Server places in the Windows 2000 and Windows Server 2003 event logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues, so that you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Microsoft Proxy service has stopped, paused, or started.

• Microsoft Proxy service failed to reach the network.

• Internet host Microsoft Proxy service is out of available memory.

• The Microsoft Proxy service connection to the server has been reset.

Many Microsoft ISA Server 2000 Performance objects are being sampled. The default interval used for these measurements is 15 minutes. The data collected can be viewed from the following Microsoft ISA Server 2000 Views in MOM:

• Open Alerts for Firewall service

• Cache Performance

• Firewall Service Performance

• Total Dropped Packets

• Web Proxy Service Performance

Microsoft Site Server 3.0 Management Pack Module

The Microsoft Site Server 3.0 Management Pack module monitors events placed by Microsoft Site Server 3.0 and its services in the application and system logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so that you can quickly take corrective or preventative actions. It lets you effectively manage your Microsoft Site Server configuration and avoid costly service outages. For example, this Management Pack module alerts you of the following critical conditions:

• Remote networks are unavailable

• Failure of Site Server authentication, indicating a security issue

• Resource issues affecting service levels

• Project or content index files are corrupt

Note: Microsoft Site Server 3.0 is supported only on Windows 2000 with Site Server 3.0 SP4 installed.

Microsoft SNA Server 4.0 Management Pack Module

The Microsoft SNA Server 4.0 Management Pack module collects the events generated by Microsoft SNA Server 4.0 running on Windows 2000 and Windows Server 2003 application logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Failures in starting and stopping the SNA server

• Resynchronization service failures

• Too many network resources active, indicating service availability issues

• LAN connection failures

• Host connection failures

Note: SNA 4.0 is supported on Windows NT 4 with SP6, and Windows 2000 with SNA 4.0 SP4 installed. It is not supported on other operating systems.

Microsoft Host Integration Server Management Pack Module

The Microsoft Host Integration Server Management Pack module collects events Microsoft Host Integration Server places in the Windows application logs. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Failures starting and stopping the Host Integration Server components

• Resynchronization service failures

• Too many network resources active, indicating service availability issues

• LAN connection failures

• Host connection failures due to service outages or other host-related issues

• Configuration replication failures between Host Integration servers

The Host Integration Management Pack supports monitoring of events, services, and performance counters for multiple instances of Host Integration Server.

Microsoft SQL Server Management Pack Module

This Management Pack module collects events that might indicate service outages or configuration problems, so you can quickly take corrective or preventative actions. For example, this Management Pack module alerts you of the following critical conditions:

• Deadlock type problems

• Blocking Issues

• Replication Failure Errors

• Log Shipping Related errors

• SQL Server becomes unavailable

• SQL Server can no longer accept connections

• The SQL Server process crashes

• SQL Server cannot allocate memory for normal operations

The SQL Server Management Pack supports monitoring of events, services, and performance counters for multiple instances of SQL Server 2000. In addition, this Management Pack also includes scripts to measure SQL Server availability.

Microsoft Application Center Management Pack Module

The Microsoft Application Center Management Pack module collects the WMI events created by Microsoft Application Center. This Management Pack module collects events that might indicate service outages, configuration problems, or security issues, so that you can quickly take corrective or preventative actions. Some of the critical conditions this Management Pack module alerts you of include:

• Clustering

• Cluster control unavailable

• Cluster controller errors and failures

• Cluster name resolution errors and failures

• Cluster tome synchronization errors and failures

• Monitoring

• Event Logging errors and failures

• Event Logging Agent errors and failures

• Performance Logging and Counter errors and failures

• Replication

• Replication Authentication errors and failures

• Replication HTTP connection errors and failures

• Object Replication errors and failures

• Application Replication errors and failures

• Request Forwarding

• Request Forwarding services unavailable

• Request Forwarding thread pool errors and failures

Many Microsoft Application Center Request Forwarding performance objects are also being sampled. The default interval used for these measurements is 15 minutes. The following are several examples of the data you can collect and view from the Application Center views in MOM:

• Total Failed Requests

• Publishing Requests

• Total Requests

• Application Center Administration Requests

• Coherent Session Requests