Introduction to System Center Operations Manager 2012

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.

Elimination of a single point of failure

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.

Changes to override default behavior

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.

Enhanced network monitoring capabilities

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.

Included in SCOM 2012:

 Network device discovery, monitoring and reporting

 SNMP v3 support. Previous versions of SCOM supported SNMP v1 and v2.

 IPv4 and IPv6 support

 Port/interface monitoring which includes, along other monitors:
o Up/down monitoring
o Traffic volume
o Utilization
 o Dropped packet rate
o Broadcast traffic stats
 VLAN health monitoring (SCOM will discover all of the VLANs for you)

 Overall connection health

 Hot Standby Router Protocol (HSRP) group health

 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.

New PowerShell cmdlets

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

SCOM 2012 requirements

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.”

Primary role requirements

Here are Microsoft’s recommendations for each SCOM role.

Processor RAM Disk .NET 3.5 SP1 .NET 4.0

 Management Server 2.8 GHz 2 GB 1 GB X X
Operations Console 2.8 GHz 2 GB 512 MB X X
Web Console 2.8 GHz 2 GB X X
Operational Database 2.8 GHz 4 GB 1 GB X X
Operations Manager Reporting 2.8 GHz 2 GB 1 GB X X
Operations Manager DW 2.8 GHz 4 GB 1 GB X X
Operations Manager Gateway 2.8 GHz 2 GB 1 GB
Table 1

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.

For SCOM 2012, you also need:

 .NET 3.5 SP1

 .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 to System Center Operations Manager 2012

(Part 2) – Installation

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

With the web console come a couple of different authentication options:

 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 to System Center Operations Manager 2012 (Part 3) - Management Pack

Fundamentals

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.

Introduction to System Center Operations Manager 2012

(Part 4) - Agent installation and configuration

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 part 3, you gained anunderstanding of the OpsMgr framework.

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:

o Uninstalled OpsMgr 2012 beta.

o Upgraded my server to Windows Server 2008 R2 SP1 (I didn’t have SP1 installed before). SP1 is required for the
release.
o Installed OpsMgr 2012 release candidate.

Deploying agents to systems

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.

Figure 1: Start the Discovery Wizard

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.

Figure 2: What kind of device do you want to discover?

You have a couple of different discovery options at your disposal. You can also OpsMgr to simply use its automated
mechanisms to discover unmonitored servers or you can advanced discovery options to better control the discovery
process. In very large environments, this advanced option might make things go a bit more quickly.

For my small lab, I’ve chosen the automated option as you can see in Figure 3.

Figure 3: We'll go for automatic discovery

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:

 Monitoring and collecting Windows event log data

 Monitoring and collecting Windows performance counter data

 Monitoring and collecting Windows Management Instrumentation (WMI) data

 Running actions such as scripts or batches

 Anything else needed by the OpsMgr server

Figure 7: Specify the agent action account

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.

Figure 9: The installations completed with success

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

Managing agent properties – per server

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.

Figure 12: The agent properties security tab

However, you’re not limited to managing agent settings on a server-by-server basis. You can manage agent settings
on a global basis by going to Administration > Settings and then choosing Heartbeat (Agent) from the work pane
(Figure 13).

Figure 13: Manage global agent settings

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.

Figure 14: Change the global agent heartbeat interval

You can modify the number of times that an agent can miss a heartbeat check in before an alert is raised. Go to
Administration > Settings and then choose Heartbeat (Server) from the work pane. Next, change the value in the
Number of missed heartbeats allowed field.

Figure 15: How many missed heartbeats are allowed?

Enabling manual agent installation

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 to System Center Operations Manager 2012

(Part 5) - Agent installation and configuration

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.

Introduction to System Center Operations Manager 2012

(Part 6) – Monitors
Welcome back! So far in this series, you’ve learned how to get System Center 2012 Operations Manager installed
and begin some basic monitoring activities.

Part 2. You performed a complete installation of the product and, by the end of the article, had a working system.

Part 3. You gained an understanding of the OpsMgr framework.

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.

What are monitors

 In the previous part of this series, you saw how the beginnings to how rules work. As a short recap, suppose that you
have a disk that’s running at 8% free space. Let’s say that the management pack you’re using expects to see at least
15% available space, below which the management pack wants to raise an alert. It’s the job of a monitor to keep an
eye on this very granular metric and report back to OpsMgr the current status.

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.

Monitors can be in any one of three states:

 Green. All is well with the world. Go home and relax!

 Yellow. A monitored element has fallen into a warning level for the particular monitor. For example, you might
configure a free space alerts to go to yellow when a disk goes below 15% free space so that an administrator can be
alerted that something might be amiss.

 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.

Unit monitor type Data source Description

Event monitor Windows Event logs Looks for events in the Windows event log matching
specified criteria.
 Text logs Tracks specific text-based logs.
WMI events Monitors events created by Windows Management
Instrumentation (WMI).
Syslog events Looks for events from Unix systems and other
devices that use Syslog.
SNMP events Looks for matching criteria in traps sent from SNMP
devices.
Performance monitor Windows performance Use a performance monitor counter as a rule in
collection OpsMgr.
WMI performance Collect a performance value from a WMI query.
Script monitors Script collection Monitor a value from a scheduled script.
Script monitors Collect events or performance data from a
scheduled script.

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.

Aggregate rollup monitors

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.

Health rollup policy

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.

Worst state health policy

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.

Worst state health policy

Figure 1: Aggregate monitor health rollup examples

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.