Академический Документы
Профессиональный Документы
Культура Документы
Introduction
SCOM 2012 is a big deal. Microsoft is overhauling the product to make it what it should be: A robust, comprehensive
monitoring tool that has no single points of failure and that can provide comprehensive monitoring for Windows
Systems, some UNIX/Linux systems and network devices. In this article, you will learn about the new and changed
elements of SCOM 2012 and discover some important prerequisites that you must understand before embarking on
an installation. In later parts of this series, we will delve deeper into new features and discover how they can improve
your business.
SCOM’s Achilles heel has always been the overall reliance on a single root management server. Without a functional
RMS server, SCOM is non-functional. Administrative tasks cannot be performed, consoles won’t open and everything
pretty much comes to a standstill.
Although it’s possible to cluster RMS servers and promote other management servers to assume the root role, SCOM
2007 hasn’t made it simple to establish high availability in the monitoring system. SCOM 2012 corrects this deficiency
by eliminating the RMS role and establishing an overall management server role that can be easily assigned to
multiple servers, which operate as a pool and automatically distribute workload between them. Each management
server will have the SDK service running which will allow any member to assume this functionality. I was to reiterate
that this is an automatic mechanism. As you add management servers, high availability is a given.
However, there is a client-side challenge associated with this availability mechanism. An agent has traditionally
reported to a single management server but with an automatic high availability mechanism, there needs to be a way
for agents to report to multiple management servers. As such, a new Control Panel applet entitled “Operations
Manager Agent Properties” has been added to client systems to enable easier management.
It has always been considered a best practice in Operations Manager to save overrides to a separate management
pack in order to facilitate ease of managing management packs. However, SCOM’s default behavior has always been
to save overrides to the default management pack. As such, many, many new SCOM administrators save their
overrides to the default management pack and unwittingly create future headaches for themselves in the process.
SCOM 2012 addresses this issue by not using the default management pack as the default override location.
SCOM 2012 includes significant new network monitoring capabilities that make it a much more comprehensive
monitoring solution for network admins. Some very basic features have been present in older versions, but SCOM
2012 expands on these capabilities and Microsoft considers many new network monitoring features to be “version 1”
in SCOM 2012. This is very good news. Personally, this is one area in SCOM that has always frustrated me due to its
lack of capability out of the box.
New visualization/dashboards
o Overall network summary. The health of the network.
o Network node. The health of a device on the network.
o Network interface. Provides the interface-level statistics listed above.
o Vicinity. Shows a device, it’s neighbors and connected Window servers monitored by SCOM. Aids in
troubleshooting network issues.
In a later article in this series, I will be going in depth into the network monitoring capabilities included in SCOM 2012.
This is an area for which I have a very high level of interest.
If you’ve used any Microsoft product that has come out within the past five years, you’ve come across PowerShell.
SCOM 2012 overhauls PowerShell support in the product through the introduction of a number of new cmdlets and
the apparent deprecation of some existing cmdlets in favor of the new ones, although the old cmdlets still work for
now. I will be covering the new PowerShell cmdlets in a future part of this article series.
Console modifications
The overall look of the primary console in SCOM 2012 isn’t all that different from preceding versions although
Microsoft has made a few changes, such as renaming the Actions pane Tasks. You will find other content
modifications as you explore, which we’ll be doing later in this series, but the overall structure of the console remains
consistent with previous versions.
Figure 1: SCOM 2012 console
The more significant change comes when you look at the SCOM 2012 web console, which has been completely
redesigned. Now based on Silverlight, the new SCOM web console provides access to more SCOM features than the
old version used to allow. However, the web console remains very limited when compared to the main console. For
example, the main console provides you with monitoring and full management capabilities and task areas that include
Monitoring, Authoring, Administration, Reporting and a My Workspace area. The web console provides access only
to Monitoring and My Workspace.
Figure 2: SCOM 2012 web console
Bearing in mind that SCOM 2012 is still in beta, there are some important requirements you should keep in mind
before embarking on your own installation.
Virtualization notes
SCOM 2012 can run completely in a virtual environment. However, Microsoft recommends the use of a physical
server for SCOM 2012’s operational and data warehouse databases unless you use direct-access mechanisms.
Microsoft also indicates that the virtual platform used can’t use “any functionality where activity on the virtual
computer is not immediately committed to the virtual hard drive. This includes making use of point-in-time snapshots
and writing changes to a temporary virtual hard drive.”
There are a number of other requirements that need to be met depending on which role you’re working with. Bear in
mind that I’m currently working with a beta version of SCOM 2012, so these requirements can and probably will
change as RTM approaches.
Other requirements
For the purposes of this article, I’m using Windows Server 2008 R2 and SQL Server 2008 R2. With the exception of
the Reporting feature, all components will be installed to a single server. So, for my purposes, SCOM 2012 will be
installed to the same server that holds the SQL Server instance for SCOM 2012.
I’m going to install the Reporting feature later on. We’ll cover specific reporting requirements later in this series.
I won’t be covering the requirements for SQL Server 2008 R2 in this article. However, if you’re following along at
home perform a installation of SQL Server 2008 R2 that includes Full Text Search and uses the
SQL_Latin1_General_CP1_CI_AS collation. I’m using the default SQL Server instance here.
.NET 4.0
For your own lab, if you run the SCOM installer, you will be able to use the prerequisites checker to see if anything
else is missing. You may need to take additional steps to prepare your environment, but the SCOM installer will lead
the way.
Introduction
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.
I’m assuming that you’ve already downloaded the beta – or, if it’s available when you’re reading this, the RTM version
– and have deployed a server to which SCOM can be installed.
To get started, double-click the installer program that is included in the download. Once you do so, you’re greeted
with a screen like the one shown in Figure 1 below. Click the Install option to proceed.
Figure 1: Click the Install option to begin
If you have a few hours, read the entire text of the licensing agreement (Figure 2). When you’re done, select the
checkbox beneath the agreement and click the Next button to continue.
Figure 2: You must agree to the license terms to proceed
First off, choose the features you’d like to install as a part of your SCOM 2012 installation. For my purposes, I’m
installing everything except the Reporting server function, which I will do another time.
Figure 3: What features would you like to install?
Next in succession: Choose an installation location for SCOM 2012. The default location is C:\Program Files\System
Center Operations Manager 2012. To choose a different location, click the Browse button and choose a new
directory.
Figure 4: Choose an installation location
The installer next checks to see if your system is deficient in any way – either in hardware or software (Figure 5). If
any issues are found, they are identified and displayed so that you can take necessary action, as shown in Figure 6.
If issues are found, click the down arrow to the right of the issue for more information. For this lab installation, you will
note that I had two issues. I intentionally left the installation hotfix uninstalled as part of this demonstration so you
could see what SCOM does in these cases. I did go back and install it before finalizing my installation. Once you
make corrections, click the Verify Prerequisites Again button to perform the check over.
Figure 5: The installer checks system hardware and software
Figure 6: Here are the issues that need addressing
Once the system has verified your system, it’s time to move on to the next step which entails making a decision about
what primary role this server will play with regard to management functionality. Will this be the first server in a new
management group or do you attend to add this server to an already existing management group? Since this is my
first SCOM 2012 server, this server will be the first in a new management group named HomeLab.
Figure 7: Choose your management group options
The database is the heart of your SCOM 2012 implementation. On the next screen of the installer, you’re asked to
provide a bunch of details related to this critical element, including:
Server name and instance name. For my purposes, I’m installing SCOM using a locally installed copy of SQL
Server, so I’ve simply used localhost as the server name. If you’re installing to a SQL Server instance other than
the default, then use SQL Server name\Instance name.
SQL Server port. The default SQL Server port is 1433 and is the one I’m using in this lab.
Database name. The SCOM installer uses the database name of OperationsManager as its default suggestion, but
you can change that to any name allowed by SQL Server.
Database size. The initial database size is set to 1,000 MB but you can provide any value you like.
Data file folder. Choose the folder to which the database files should be saved.
Log file folder. Likewise, decide where the database log files should be written.
Figure 8: Configure operational database parameters
As outlined in Part 1 of this article series, SCOM 2012 includes a brand new web console. On the next installation
screen, choose the IIS web site under which this console should be installed. This is useful if you’re intending to
install the SCOM 2012 web console to a server other than the SCOM server and there already exist web sites on that
server.
In a production environment, you should also select the Enable SSL checkbox to protect network traffic associated
with the SCOM console.
Figure 9: SCOM web console
Mixed authentication. Depending on the location from which the user if logging in, a user name and password may
not have to be provided.
Network authentication. Users always have to provide a user name and password.
Figure 10: Choose an authentication method
In the next step of the installation, provide a set of credentials for each of the accounts that are requested. For a lab
setting, I’m interested in functionality, not security. In a production deployment, I would make different decisions than
you see in the figure below. I’d create a separate Active Directory user account for each service so that I’m not
providing rights that exceed the needs of the service.
Figure 11: Configure an account to use for each service
Microsoft has two reporting programs that are available for your participation and that serve to improve the use of
Operations Manager for all customers. The first one, the Customer Experience Improvement Program, collects
general usage regarding how you use SCOM and reports that to Microsoft in an effort to build knowledge about
customer/product interactions. If you’d like to participate in the program, choose the Yes option.
The second choice you have to make is whether or not to participate in the Error Reporting program. In this program,
you have more than just a Yes or No decision to make… at least if you choose to participate. If you do decide to
share your error information with Microsoft, you can choose to have the error details sent automatically or you can
request that they be queued so that you can review them before sending.
Figure 12: Decide whether or not you want to participate in Microsoft's improvement programs
Way back in the day, Microsoft launched Windows Update so that the process of updating Windows could be
streamlined. Today, the process is called simply Microsoft Update and the updater can handle a number of different
Microsoft products through the same process, including Operations Manager 2012. On the next screen of the
installer, decide if you want to check for new Operations Manager updates automatically.
Figure 13: Do you want updates to be handled automatically or manually?
You’re getting close! The next screen of the installation process provides you with an opportunity to review the
selections that you have made. Once you’re satisfied with your decisions, click the Install button to proceed with the
installation of Operations Manager 2012.
Figure 14: Review your selections before installation continues
Throughout the installation process, you’re kept apprised of progress, as shown in the next two figures. The first one
shows you the SCOM 2012 installation as its underway while the second shows you what the final summary screen
should look like when you’re done. Your goal here is to have all green checkmarks!
Once the installation is complete, you can choose to simply start the management console by enabling the
appropriate checkbox. Regardless of whether or not you do that, click the Close button to complete the installation
process.
Figure 15: Installation is underway
Figure 16: SCOM 2012 is now installed
Summary
You’ve now successfully installed SCOM 2012. In the next and final part of this series, you will discover how to begin
monitoring critical infrastructure elements including your domain controllers, Exchange Server, file server and network
hardware.
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.
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.
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.
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.
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 part 2, you performed a complete installation of the product and, by the end of the article, had a working system.
In this part of this series, you will learn how to install and manage agents.
Note:
In previous parts of this series, I was using the public beta for OpsMgr 2012. In this part, I’ve upgraded to the release
candidate. To do this, I:
Before you can really monitor anything at all with OpsMgr, you need to get an OpsMgr agent deployed to the systems
you intend to monitor. There are multiple ways that you can get the agent installed, but somehow, OpsMgr needs to
have an understanding of what is available for it to manage. Here are your options:
Perform a discovery process that allows OpsMgr to determine what is available for it to monitor and then
automatically deploy the OpsMgr agent to selected devices.
Manually install the OpsMgr agent on selected devices.
We’ll cover the discovery process in this article. To get started with this process, go to the Administration area and
then choose the Discovery Wizard option that you see in Figure 1 below.
Clicking Discovery Wizard starts the Computer and Device Management Wizard, which is shown below in Figure 2.
For the purposes of this article, we want to learn how to deploy agents to Windows servers, so choose the Windows
computers option and then click the Next button to proceed with the wizard.
For my small lab, I’ve chosen the automated option as you can see in Figure 3.
In OpsMgr, as you attempt to work with managed systems, you will need to maintain a series of credentials that you
use for different purposes. In the discovery process, OpsMgr needs credentials that allow administrative access to
the discovered machines so that the OpsMgr agent can be installed. In the next step of the discovery process, you’re
asked to provide credentials either explicitly – which I have done –or you can use one of the Management Server
Action Accounts that you’ve previously defined.
Figure 4: Choose an account with administrative rights
Once you’ve chosen a discovery method and provided credentials for agent installation, the discovery process kicks
off as you can see in Figure 5.
Figure 5: The discovery process is running
In my lab, the discovery process discovered two machines – a domain controller and an Exchange server, although
OpsMgr at present sees them only as Windows servers. Once I add the appropriate management packs, OpsMgr will
then realize that they are, indeed, a domain controller and Exchange server. That’s a really important thing to
understand: OpsMgr is only as smart as you allow it to be. If you haven’t deployed any Exchange management
packs, for example, OpsMgr will never actually see Exchange on any of your servers since none of the discovery
protocols are in place by default. In Figure 6, you can see the two servers that were discovered in my lab.
Note also in this figure that the bottom of the window asks that you provide something called a management mode. In
OpsMgr, the default management mode is agent managed, which means that an OpsMgr agent will be deployed to
the target system. However, you can also choose agentless managed or unmanaged. These states provide lesser
and different management capabilities than the default option.
You don’t have to install the OpsMgr agent on every discovered machine. Just check the checkbox next to each
server on which you want to install the agent and then click the Next button to proceed.
Figure 6: Two systems were discovered
Now that you’ve decided the servers to which to install the agent, the next step is to provide details about how that
agent should be installed. Specifically, you need to tell OpsMgr the location to which the agent should be installed –
it’s generally fine to just use the default – and, more importantly, define the account that will be used as the Agent
Action Account.
This is a critical decision. The agent action account is the account that the agent will use to execute all of its tasks.
You can choose to use the Local System account or you can create and specify a domain user account for this
purpose. While it’s possible to use a very low privileged domain user account, by the time you get done managing all
of the access requirements that are necessary, you might be better off just having used the Local System account.
Using the Local System account is also easier maintenance in the long term since there is no password to track and
most management packs work very well with this configuration. As such, that’s the choice I’ve made, as you can see
in Figure 7.
If you’re wondering what kind of responsibilities are satisfied with the Agent Action account, here are just a few:
Once you click the Finish button, OpsMgr carries out your wishes and begins installing the agent as you can see in
Figure 8.
Figure 8: Keep and eye on agent installation progress
Once you’ve had a successful completion, you’re notified of this fact and will get a Success message like the one
shown in Figure 9.
From this point on, you need a way to manage the agents in an ongoing way. By going to the Administration area,
expanding Device Management and choosing the Agent Managed option (Figure 10), you can see a list of the
machines that are being managed by an installed agent.
Figure 10: A list of servers on which an OpsMgr agent is installed
After you’ve installed an agent on a server, you can make some minor adjustments to the way that that the agent
operates. To do so, right-click one of your servers and from the resulting shortcut menu, choose Properties. This
opens a Properties page like the one shown in Figure 11.
In order to make changes to an individual server’s agent properties, you need to select the checkbox next to Override
global agent settings. Once you’ve done that, you can then change the agent heartbeat interval. This might be a
necessary step in some cases; perhaps the managed server is at the other end of a particularly slow connection. You
don’t want to see a bunch of false alerts raised due to a perfectly normal condition, so you might increase the
heartbeat interval.
Figure 11: Agent Properties page
On the Security tab, you’re offered the opportunity to Allow this agent to act as a proxy and discover managed objects
on other computers. This setting is required by some management packs and in some monitoring scenarios.
With the properties page open, provide a new value for the heartbeat interval. Note that this value will not be
propagated to servers on which you’ve previously overridden the heartbeat interval.
Earlier, you learned how to automatically install an OpsMgr agent on your server. However, it is possible to install an
agent manually, but only after you’ve allowed it to happen. Go to Administration > Settings and then choose Security
(Server) from the work pane. As you can see in Figure 16.
By default, OpsMgr rejects any attempt to manually install agents. This is a security measure designed to thwart
attempts to add unauthorized systems to OpsMgr. To enable manual installations, select the checkbox next to the
appropriate option shown in Figure 16. Once you do so, a system on which an agent has been manually installed is
placed into a Pending Management area. An administrator must proactively go there (you can see it in Figure 10) and
approve the installation.
Optionally, you can choose to have manually installed agents automatically approved. This, however, is not
recommended as it would allow anyone to simply add managed systems to OpsMgr without administrative control.
Figure 16: Do you want to allow manual installations?
Summary
In this article, you learned how to install and manage OpsMgr agents, a foundational element in any OpsMgr
environment. In the next article, we will continue learning how to monitor these servers in OpsMgr 2012.
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 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!
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.
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).
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.
Part 2. You performed a complete installation of the product and, by the end of the article, had a working system.
Part 4. You discovered how to manage agents, which are key to making OpsMgr operate.
Part 5. You will learn how to further manager OpsMgr 2012 by investigating rules and monitoring.
In this, part 6, you will continue to investigate the OpsMgr interface and discover how monitors work.
You may recall that monitors are used to determine health information and make sure items are working within
predefined specifications. If things are out of whack, monitors can raise an alert.
Red. Now, suppose that disk falls below 5% available space. In this state, the alert may show as red, indicating that
immediate action on the part of the administrator is necessary.
There are a few different kinds of monitors available for your use. Each is described in the sections below.
Unit monitors
Unit monitors are often described as the “workhorses” of SCOM monitoring and are the most common kind of monitor
out there. A unit monitor is used to measure a specific item, such as the amount of free disk space on drive C:.
In short, unit monitors measures some aspect of a service. This might consist of checking a Windows performance
counter to determine the current performance of a specific service, running a script to perform a synthetic transaction
that is then measured against predefined management pack rules, or watching for an event in an event that indicates
an error that needs to be raised to the administrator.
The table below describes the various kinds of unit monitors you might encounter as you work with OpsMgr.
Table 1
These unit monitors can be used at an extremely granular level and provide you with a multitude of ways to monitor
even the most minor elements of system stability, performance and health. They also form the basis for all of the
monitoring that takes place in Operations Manager.
How does this monitoring work? Actually, monitors and rules – which we will discuss in a later part in this series –
work hand in hand. Let’s go back to the disk space example. A monitor is created that uses Windows Management
Instrumentation (WMI) to retrieve the currently available free disk space on C:. An associated rule is created that
compares the returned value to expected values. When the returned result is below that predefined threshold –
according to the rule – an alert is raised in the OpsMgr console telling the administrator that attention is necessary.
An aggregate rollup monitor is a collection of several other related monitors. State can be monitored on either a best-
case or worst-case basis, depending on the nature of the service. The word related here is in italics for a reason.
Aggregate monitors generally watch similar items – such as a group of DNS servers or a group of DHCP servers –
and report back to OpsMgr on the overall health of the service group as a whole.
Here’s how an aggregate rollup monitor can be used: Suppose you’re using a dependency rollup monitor to watch
eight separate DNS servers. You could create a high level monitor that undergoes a state change only once five of
the eight DNS servers become unavailable. In this way (i.e. Only raise alert if 5 of 8 DNS servers are down) you can
be alerted on your terms. However, in order to truly understand how aggregate rollup monitors work, you need to
understand a bit about health rollup policies.
When you have a group of items being monitored with an aggregate monitor, you have two choices for how you want
the state for the monitored group to be reflected.
The most common policy used by aggregate rollup monitors is called the Worst state health policy. In this instance,
the aggregate monitor matches the state of the child monitor that has the worst health state in the group. So, if you’re
monitoring 150 items with an aggregate monitor and one of those 150 items goes into a failure state, the entire parent
monitor is shown as being in a failed state. The worst state aggregate monitor is demonstrated in the left picture in
Figure XX below.
Best state health policy
On the opposite side of the health spectrum lies the best state health policy, which is the opposite of the worst state.
In this scenario, the parent rollup monitor is assigned the status of the healthiest member of the monitored group. In
Figure 1, this is demonstrated on the right-hand size of the diagram.
Dependency monitors
Also known as a dependency rollup monitor, a dependency monitor in SCOM 2012 allows the health of one object to
directly affect the health of another completely unrelated object. Although dependency monitors are similar to
aggregate rollup monitors, they are more flexible and much more granular. In Figure 2 below, you can see how this
might work. Suppose that the “different monitored item” is the aforementioned free space on drive C:. The “monitored
item” might be a Windows server object whose health is dependent on a number of underlying dependent monitors.
Figure 2
This type of monitor also adheres to the previously discussed best and worst health state policies. However, there is
some additional flexibility with this kind of monitor. You also have the capability to define a percentage health policy.
Suppose you have five monitored items and a percentage health policy of 60%. This would mean that 60% of the
monitored items would need to stay operational before the monitor goes red. In this example, the monitor would stay
green even if two monitored elements failed. But, once a third one failed, the 60% availability threshold would be
violated and the monitor would go red.
Summary
This has been a primer for how monitors work in OpsMgr 2012. We will continue our introduction to OpsMgr 2012 in
Part 7 of this series.