Essential Microsoft Operations Manager

Additional Components

The MOM 2005 components introduced so far are directly involved with the creation of an alert, the management of an alert, and the storage of an alert. But these are not all the components available. This section introduces other components and gives an overview of where they fit and their purpose. Figure 1-16 shows these additional components; however, note that none of these are involved with the generation of an alert.

Administrator Console

While the Operator console is used to consume and manage the alert, event, performance, and status data that MOM 2005 produces, the Administrator console (point 1 in Figure 1-16) is used to manage the configuration of MOM 2005. The Administrator console performs most of its work through the DAS on the MOM 2005 management server, but for some specific tasks, it works directly with MOMService.exe. Like the Operator console, the Administrator console is a Microsoft Management Console (MMC) snap-in.

There are four top-level objects used to break down the functions in the Administrator console. They are the Information Center object; the Operations object used for launching the Operators, Reporting, and the Web consoles; the Management Packs object; and the Administration object. Figure 1-17 shows the Administrator console.

If you have administrator permissions to MOM 2005, you will have full access to all objects in the Administrator console. A MOM 2005 administrator controls the configurations that govern the overall behavior of MOM 2005, including:

• Deciding which computers the management server will manage via a set of discovery rules, e.g., all computers in the homelab domain or only those computers whose names start with XYZ.

• Installing and uninstalling agents.

  

  Figure 1-16. Additional MOM 2005 components

• Deciding the type of management to be applied to a managed node: agent-managed, agentless-managed, or unmanaged.

• Creating and controlling console scopes that filter information in the Operator console based on the user’s Active Directory ID.

• Controlling the global settings for all of the management servers that operate together. This includes database grooming, managing security settings, determining which email server to send notifications through, defining alert resolution states, defining custom fields for alerts, and deciding the communications ports to be used.

• Creating and managing product connectors that are objects built using the MOM Connector Framework (MCF) to allow bidirectional communication between groups of MOM servers and other operations management products.

Figure 1-17. Top level of the Administrator console

Only individuals who have been granted administrative permissions to MOM 2005 can access these objects.

The MOM 2005 Administrator console is also used to manage the MOM 2005 management packs. People who are responsible for maintaining the role-based computer groups and the sets of rules that are pushed down to the agents will use this node. These individuals are called MOM authors. Administrators also have full access to this node.

MOM 2005 administrators must have in-depth knowledge of how MOM 2005 works. This does not mean that they must be experts on all the applications and server types that MOM can monitor. Usually, each application that MOM monitors has an associated group of experts at your company who are responsible for administering that application. These are the folks who receive the notifications from MOM when something goes wrong with that application and are responsible for fixing it. Give these application experts full authority to manage their applications rules by making them MOM authors. Otherwise, the MOM administrator will be an unnecessary middleman when it’s the application administrators who really need to tune the monitoring of their specific management packs.

In the management packs node, MOM authors will manage:

• Import/export and creation of management packs

• Role-based computer group membership

• Event, performance, and alert rules for their applications

• Performance and event rule thresholds and criteria to override default settings for selected computer groups

• Tasks available for a computer role type in the Operator console

• Who gets notified and how they are notified of an application-specific alert

• Scripts that are used to gather information and execute responses on a managed node

• Computer attributes that are used to classify the role of a discovered computer

• Data Provider definitions, for example, the definitions for performance counter objects and counters that are used by performance rules

MOM authors also have the necessary rights to open the Operations object to launch the Operator, Reporting, or Web consoles. MOM authors cannot access the Administration object.

There is no need to grant administrative or authoring permissions to individuals who will only resolve alerts. These are typically the help desk and datacenter employees who are the recipients of MOM 2005 notifications. For them, access to the Administrator console is restricted to the operations object. From there, they can only launch the Operator, Web, or Reporting consoles, according to the rights they have been granted.

When you select the Information Center object, the Details pane brings up links to MOM 2005-specific web sites. From here, you can access the MOM 2005 homepage, MOM 2005 updates, the product documentation, community web sites, technical support, licensing, and security information.

Warehouse Database

While the operations database supports the monitoring, alerting, and configuration functions of MOM 2005, the data warehouse database (point 2 in Figure 1-16) supports the reporting function. MOM 2005 reports are based on historical data and give you a longitudinal view of the performance of your monitored applications and the servers they run on. A scheduled task runs once a day by default, which transfers the “live” data from the operations database to the data warehouse database. The dataflow in the transfer is unidirectional, going from the operations database to the data warehouse database only. The transfer is accomplished by a SQL Server DTS package and is coordinated with the grooming jobs on the operations database to ensure that no data is groomed out of operations before it has been transferred.

SQL Server Reporting Services

MOM 2005 reporting makes use of SQL Server Reporting Services. SQL Server Reporting Services (point 3 in Figure 1-16) is a separate product from MOM 2005. SQL Server Reporting Services separates the presentation of the data from the retrieving of the data, thereby allowing you to present the same data in different formats, including HTML, XML (for Office 2003 applications), and PDF. SQL Server Reporting Services does not include a printing engine, so you must export a report to one of these other formats before printing.

The reporting services in MOM 2000 SP1 were based on a Microsoft Access frontend. They did not scale well and did not reliably deliver scheduled reports. Because the reporting engine for MOM 2005 is server-based, it has the flexibility and robustness that its predecessor lacked. This is one of the most improved features in MOM 2005.

Security can be applied on a per-report basis. By borrowing some functionality from Microsoft Windows Sharepoint Services, reports can be subscribed to.

Reporting Console

MOM 2005 takes the SQL Server Reporting Services Report Manager and presents it as the Reporting console (point 4 in Figure 1-16 and shown in Figure 1-18). All MOM 2005 reports are accessed and managed through the Reporting console.

Figure 1-18. MOM 2005 Reporting console

Inside individual reports, users can enter parameters for filtering the information that they want to see. For example, in Figure 1-19, the Agent Configuration report, the user can specify the management group, the agent, the sort order, and the primary management server for this report.

For each report, a user with the appropriate permissions can also access the Properties, History, and Subscriptions tabs that are located across the top of the report. Through these tabs, you can set the default parameters for a report, change the data source, and set credentials for accessing the data source. You can create cached reports that have a Time To Live (TTL) value and create snapshots of reports that capture a report at a fixed point in time.

Figure 1-19. The MOM 2005 Agent Configuration report

The Microsoft-defined reports are included in the application management packs. As of the MOM 2005 release, Microsoft is shipping in excess of 200 reports. Custom reports are now designed using the Report Designer in Microsoft Visual Studio .NET 2003 as a Report Project. Through this tool set, you can access the objects defined in the new Report Definition Language (RDL) that was created for SQL Server Reporting Services.

System Center Data Warehouse (SCDW)

The data warehouse database, SQL Server Reporting Services, and the Reporting console compose the System Center Data Warehouse. Microsoft came up with this name because it plans on combining the data from future versions of MOM and Systems Management Server (SMS) into a single database. Further down the road, the two products will become more tightly integrated in their user interfaces and eventually merge into one product, called System Center Suite.