Introduction to System Center Operations Manager 2012 (Part 3) - Management Pack Fundamentals

by [Published on 13 Dec. 2011 / Last Updated on 13 Dec. 2011]

In this part of this series, you will learn how SCOM works and what role management packs play in System Center Operations Manager.

If you would like to read the other parts of this article series please go to:

Introduction

Welcome back! In part 1 of this series, you learned about many of the new features coming to System Center Operations Manager 2012 and you also discovered some key prerequisites that must be met before you can forge ahead with an installation of this technology monitoring framework and system.

In this part 2, you performed a complete installation of the product and, by the end of the article, had a working system that we’ll use in this part—part 3—to begin understanding the OpsMgr framework.

Specifically, in this part of this series, you will learn how SCOM works and what role management packs play in System Center Operations Manager. By the end of this article, you will know how management packs work and the role that agents play.

System Center Operations Manager fundamentals

Before jumping into SCOM/OpsMgr as a whole, let’s take a look at some fundamental elements that comprise a working monitoring environment.

First of all, we’ve already created an OpsMgr management group. Earlier in this series, you learned that OpsMgr 2012 eliminates a single point of failure that was a hallmark of older versions of the product. This single point of failure was called the root management server. In OpsMgr 2012, the root management server is simply referred to as a management server and, if you have multiple management servers, management workloads are split between them.

For this series, I’ve deployed a single OpsMgr 2012 server.

Once you have OpsMgr deployed and you’ve opened the console, what’s next? You probably want to start monitoring things. If that’s the case, your next job is to determine what you want to monitor. The cornerstone for this process is the management pack.

Before I jump into management packs, a little history. Infrastructure monitoring used to look sort of like this:

  • Each Monday. Log on to each server and verify that available disk space is sufficient.
  • Each morning. Use your log-viewing tool (aggregate logs) to see if there were any major issues since the previous day.
  • Continually. Monitor Exchange-related performance counters to ensure that the service is operating normally.
  • As needed.
    o   React to user-discovered issues, such as a database going offline for some reason, resulting in problems with Outlook.
    o   If issues, such as disk space issues, crop up between manual monitoring cycles, address the issue.

When you look at this simplistic list, the following needs come to mind:

  • You need to identify which servers you plan to monitor for disk space.
  • You then need to go to the disk object and look at the remaining space and determine if the remaining space is within tolerance.
  • Using the event viewer, you need to peruse operational logs and sift through thousands of entries to locate the ones that might be pertinent.
  • You need to continually monitor various Exchange-related metrics and determine whether or not the result of the information that you’re monitoring are within desirable operational parameters.

With OpsMgr 2012, everything on the above list can be handled for you with various pieces of management packs. Management packs take the place of your old manual rule sets and do a lot of your work for you. Here are some things you should know about management packs:

  • Management packs include a number of rules and other components designed to monitor events, hardware, services and other items.
  • Management packs are not one-stop shops. Generally, each management has a laser focus on a particular service, such as DNS, DHCP or printing.
  • You should deploy only the management packs you need. Resist the temptation to simply start installing dozens of management packs at a time.
  • There are a great many management packs available on the Internet. Some are free and some are not.
  • Most are sealed, meaning that the content cannot be modified, but you customize the monitoring environment through the use of what are called overrides.

So, you might want to install a management pack that monitors the specific performance of your DHCP server and you might install another management pack that focuses on monitoring your Active Directory environment. Each individual management pack has components that allow it to monitor its intended components.

Here are the individual items that comprise a management pack:

  • Object Discoveries. Each monitored item in SCOM must be discovered in some way. Management Packs contain items necessary to discover managed objects. Discovery can be accomplished with the registry, WMI, scripting, OLE DB, LDAP, or custom code. If too much is discovered and it becomes difficult to sift through the morass, you can use an override to limit object discovery. In the case of the examples above, the DHCP management pack would contain discovery methods that help OpsMgr discover DHCP servers.
  • Monitors. Monitors are used to determine health information and make sure items are working within specifications. If things are out of whack, raise an alert if. Only state change events are stored in the data warehouse for future reporting. There are different kinds of monitors available for your use:
    o   Unit monitors.
    §  SNMP, WMI performance, Log files, Windows events, Windows services, Windows performance counters, Scripting, WMI events
    o   Aggregate rollup monitor.
    §  An aggregate rollup monitor is a collection of several other monitors.  State can be monitored on either a best-case or worst-case basis.
    - Best-case. If any one of the child monitors is healthy, the overall aggregate monitor will show up as healthy.
    - Worst-case.If any one of the child monitors is not healthy, the overall aggregate monitor will not be healthy, either.
    o   Dependency rollup monitor.
    §  Very similar to aggregate rollup monitors, but more flexible and granular (i.e. Only raise alert if 5 of 8 DNS servers are down)
    - Monitor state can also change based on monitoring availability.
    - Ability to decide how alerts will be handled when the system is in maintenance mode.
  • Rules. Whereas a monitor actively checks on a components state, a rule serves a similar purpose through the collection of performance data or by running scripts. All collected data is stored in the data warehouse, making the use of rules superior when data collection and analysis is a top priority. Like a monitor, a rule is capable of raising an alert to an OpsMgr operator, but the objects included in a rule cannot be monitored for health.
  • Tasks. Like the name implies, a task is a method that performs some action based on rules that are defined. Among other actions, a task can run a program or script, or reset a failed service.
  • Views. A view is a customized look at items that might be unique to a particular management pack. For example, the Operations Manager management pack (yes, there is a management pack so that OpsMgr can monitor itself) includes a view for displaying the current state of agents that have been deployed to servers.
  • Knowledge. What caused a particular alert? How was it addressed? As operators learn how to correct problems, that knowledge can be captured right in a management pack, making it quickly available to other operators that might run across the same problem in the future.
  • Reports. A management pack can include reports customized to support the management pack.
  • Run As Profiles. Discovering objects, running scripts and gathering information requires credentials that can access the appropriate resources. This is the job of a Run As profile.
    o   Windows credentials
    o   SNMP community string
    o   Basic authentication
    o   Simple Authentication
    o   Digest Authentication
    o   Binary Authentication
    o   Action account
  • Overrides. Overrides are discussed in-depth later in this series. In short, an override is a way by which an operator can customize a management pack.

Managing management packs

In the sample installation I’ve done for this series, 74 management packs were loaded during deployment. You can see a list of all of the loaded management packs by going to the Administration area and choosing Management Packs. Figure 1 gives you a look.


Figure 1: 74 management packs were loaded at install time

In the Tasks pane at the right hand side of the window, you can see ways that you can add more management packs. Microsoft maintains a management pack catalog connected to OpsMgr from which you can download and install new management packs. To connect to this service, click “Import Management Packs” and start a wizard that walks you through the process of adding new management packs. I’m not going to walk through that process here but do want to make one important point. Some management packs have dependencies on other management packs. During the management pack deployment process, if you choose to add a management pack that depends on another management pack, you’ll have the opportunity to install both the management pack you want as well as its dependencies.

Agents

As you add management packs, their impact will be immediate. You will see new items added to the Monitoring area in the form of new monitored items, dashboard and the like. But, even though management packs have the ability to discover items, nothing can be discovered until OpsMgr agents have been deployed to systems you wish to monitor.

The agent is responsible for communications from monitored systems to the OpsMgr server. The agent operates by watching various event sources, such as the local Windows logs and WMI counters and other sources. Information is forwarded to the OpsMgr server for analysis.

Summary

We’ll cover how to install agents and perform basic monitoring using the built-in management packs in the next part of this article series.

If you would like to read the other parts of this article series please go to:

Featured Links