Introduction to System Center Operations Manager 2012 (Part 5) - Agent installation and configuration

by [Published on 31 Jan. 2012 / Last Updated on 31 Jan. 2012]

In this part of this series, you will learn how to further manager OpsMgr 2012.

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

Introduction

Welcome back! So far in this series, you’ve 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.

In part 3, you gained an understanding of the OpsMgr framework.

In part 4, you discovered how to manage agents, which are key to making OpsMgr operate.

In this part of this series, you will learn how to further manager OpsMgr 2012.

OpsMgr Operations

In previous parts of this series, we’ve discussed some of the elements that comprise an OpsMgr installation. Specifically, we discussed the role that management packs and agents pay in the monitoring process.

There are, however, a lot of other pieces of the puzzle that are important to understand before you can jump into the deep end with OpsMgr. Admittedly, it’s really tempting to just start clicking around the console and installing dozens of management packs so that you can just get things up and running. Speaking from personal experience, I can guarantee you that it’s better to take a more methodical approach when it comes to using OpsMgr. Each management pack and each element in a management pack is tunable and comes set to defaults that Microsoft believes are appropriate. While this may be true for a vast majority of the settings, there are almost certainly going to be elements you’d like to monitor differently than Microsoft recommends or, you might choose to skip monitoring a particular component altogether.

Here’s a simple rule of thumb when it comes to deciding what to monitor: If a particular monitored item goes askew of norms, are you going to actually act on it? OpsMgr management packs can monitor dozens, hundreds or thousand of different elements. Do you, for example, really care if the network interface card that you use on a dedicated backup network is running at maximum utilization for 2 hours each night? Probably not. After all, that’s a good thing! The higher the utilization, the less time that it will take to back up your server.

If you fail to take things slowly and methodically in OpsMgr, you’re likely to run into situations in which you’re simply overwhelmed by the number of alerts that are being generated, even if most of them mean nothing to you.

With “slow and methodical” as the marching orders, make sure that you’ve thoroughly read Part 3 of this series as it contains critical information related to what’s contained in management packs. I’m not going to repeat here the elements that comprise management packs, but do want to reiterate two important points. First, most management packs that you download and install are sealed. A sealed management pack is actually a binary file with a .mp file extension and you can’t directly edit the file. In some cases, you may run across – or might create yourself – an unsealed management pack. Unsealed management packs are easy to identify because they’re just everyday XML files that you can edit to your heart’s content. In Figure 1, you can see some of the .mp files that are available in the directory structure.


Figure 1: .mp files in the file system

At this point, you might be confused. After all, didn’t I just get done telling you that you need to carefully consider what and how you want to monitor and adjust things accordingly? Immediately after that, I told you that most management packs come sealed and can’t be edited.

What gives?

This is where the real power and flexibility of OpsMgr becomes apparent. Through the use of what’s called an override, you are able to change the default behavior of a sealed management pack and make OpsMgr do your bidding. Pretty neat, huh?

Here’s an override explained: Suppose you’re monitoring available disk space and the default management pack wants to warn you when you’re down to less than 20% of available space. By creating an override for the individual monitor, you can change the behavior of the monitor to, for example, alert you when you’re at 5% or less disk space instead of the default 20%. You create this override rule in the OpsMgr console and then save it to a separate but linked unsealed management pack. In this way, you’re not modifying the original management pack at all. Rather, you’re creating a rule that tells OpsMgr to override the behavior of the original management pack based on a rule you create in the linked management pack.

Cool!

Let’s see what’s out there

Although overrides are really cool and it’s critical to understand that they exist, we won’t be creating any in this part of this series (that’s next, though). For now, let’s focus on the defaults and on what is being exposed to you as the OpsMgr administrator. As I mentioned OpsMgr can present to you an avalanche of information.

To get started, we’ll look at the Monitoring node and go to Active Alerts, shown below in Figure 2.


Figure 2: OpsMgr has raised an alert

First of all, let’s get some terminology pinned down. When OpsMgr, through a rule in a management pack, determines that something has gone awry on a monitored element, an alert is raised. That’s what you’re seeing in Figure 2. In this environment, there is a single alert that has been identified. Here, you can see the details of the alert. In this case, a PowerShell script failed to run on the OpsMgr server itself. You can also see which rule caused the alert to be raised. Here, the rule is “Alert on Failed Power Shell Scripts”.

If you click on the blue texted labeled “Alert on Failed Power Shell Scripts”, you will have the opportunity to view the actual rule configuration, which may also include some mitigation instructions. In Figure 3, take a look at the general information about this rule. You’re able to see in which management pack the rule resides (System Center Core Monitoring). If you click on the Product Knowledge tab (shown in Figure 4), you will see that there are some possible reasons listed along with mitigation advice. Although this is not true of every rule, it’s nice to have a place to start.


Figure 3: A rule


Figure 4:
Product knowledge about the rule

Now, let’s take a look at some potentially more interesting information that can be gleaned from your OpsMgr installation. Up to this point, we’ve looked at mundane stuff like alerts. But, OpsMgr is much more than just a system to raise alerts. It also keeps detailed performance statistics that you can use to track performance at extremely granular levels. For example, suppose you want to make sure that the OpsMgr agent itself isn’t the root cause of a client’s performance issues. Easy! Take a look at the screen in Figure 5.


Figure 5: OpsMgr agent performance

Here, you’re seeing the Opsmgr agent performance for two monitored servers over a twelve hour period. As you can see, a no time was performance off the charts. I apologize for the size of the graph. I have to keep a low monitor resolution on my OpsMgr server when I’m working remotely.

But, suppose you’re more interested in a macro level look at the OpsMgr agent. You can get as simplistic as looking at the master status for the OpsMgr agent and, from there, quickly drill down and look at any associated metric that you like.

In Figure 6 below, you’ll note that the OpsMgr agent is healthy on both of my monitored servers. But, I want to drill down a bit more. So, I right-clicked EX1 and followed the shortcut menu tree down to Health Explorer for EX1.globomantics.com.


Figure 6: Master agent status

The Health Explorer (shown in Figure 7) displays information in four key areas:

  • Availability
  • Configuration
  • Performance
  • Security

Inside each of these components, you can have rules related to that area. We looked earlier at a graph that showed you the process utilization for a selected OpsMgr agent. Well, in Figure 7, here’s why that information is captured. There’s a rule that explicitly instructs the OpsMgr agent to track this information and report it back to OpsMgr. As you can see in Figure 7, the metric currently has a green check mark meaning that everything is operating within expected parameters.


Figure 7: Health Explorer in action

With that said, what are these parameters, anyway? Well, let’s find out. Simply right-click the Agent processor utilization and, from the shortcut menu, choose Monitor Properties (Figure 8). (Tip: In many cases, you can also see the thresholds on the screen shown in Figure 7 – take a look at the Knowledge tab information).


Figure 8: Open monitor properties

When you get to the Properties page, navigate to the Configuration tab. You’ll get some XML code like what you see in Figure 9. With a little deciphering, you can see that the processor utilization threshold for the OpsMgr agent is 25%. After 6 consecutive reports back from a system that the OpsMgr agent is running beyond 25% of processor, the monitor will be changed to a Critical state. Once the problem has been corrected, it will take 3 “good” returns before the monitor health is reset to green.


Figure 9: Monitor configuration

Summary

In the next article in this series, we will continue to investigate the OpsMgr interface and discover how to use the aforementioned overrides.

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

Featured Links