Introduction to System Center Operations Manager 2012 (Part 1)

by Scott D. Lowe [Published on 18 Oct. 2011 / Last Updated on 18 Oct. 2011]

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.

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

SCOMs 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 wont open and everything pretty much
comes to a standstill.
Although its possible to cluster RMS servers and promote other management servers to assume the root role, SCOM 2007
hasnt 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, SCOMs 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, its 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 youve used any Microsoft product that has come out within the past five years, youve 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 isnt 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
well 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 2012s operational and data warehouse databases unless you use direct-access mechanisms. Microsoft also indicates
that the virtual platform used cant 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 Microsofts recommendations for each SCOM role.

Management Server
Operations Console
Web Console
Operational Database
Operations Manager Reporting
Operations Manager DW
Operations Manager Gateway

Processor

RAM

Disk

2.8 GHz
2.8 GHz
2.8 GHz
2.8 GHz
2.8 GHz
2.8 GHz
2.8 GHz

2 GB
2 GB
2 GB
4 GB
2 GB
4 GB
2 GB

1 GB
512 MB
1 GB
1 GB
1 GB
1 GB

.NET 3.5
SP1
X
X
X
X
X
X

.NET 4.0
X
X
X
X
X
X

Table 1
There are a number of other requirements that need to be met depending on which role youre working with. Bear in mind that
Im 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, Im 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.
Im going to install the Reporting feature later on. Well cover specific reporting requirements later in this series.
I wont be covering the requirements for SQL Server 2008 R2 in this article. However, if youre 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.
Im 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
by Scott D. Lowe [Published on 22 Nov. 2011 / Last Updated on 22 Nov. 2011]
In this part of a series on SCOM 2012, you will review a complete installation of the product and, by the end of the article, have
a working system that well use in part 3 to begin monitoring key systems.

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.
Im assuming that youve already downloaded the beta or, if its available when youre 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, youre 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 youre 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 youd like to install as a part of your SCOM 2012 installation. For my purposes, Im 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, its 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, youre asked to provide a
bunch of details related to this critical element, including:

Server name and instance name. For my purposes, Im installing SCOM using a locally installed copy of SQL Server, so Ive
simply used localhost as the server name. If youre 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 Im 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 youre 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, Im
interested in functionality, not security. In a production deployment, I would make different decisions than you see in the figure
below. Id create a separate Active Directory user account for each service so that Im 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 youd
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?

Youre getting close! The next screen of the installation process provides you with an opportunity to review the selections that
you have made. Once youre 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, youre 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
youre 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

Advertisement

Summary
Youve 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
by Scott D. Lowe [Published on 13 Dec. 2011 / Last Updated on 13 Dec. 2011]
In this part of this series, you will learn how SCOM works and what role management packs play in System Center Operations
Manager.

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 well
use in this partpart 3to 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.
Advertisement

System Center Operations Manager fundamentals

Before jumping into SCOM/OpsMgr as a whole, lets take a look at some fundamental elements that comprise a working
monitoring environment.
First of all, weve 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, Ive deployed a single OpsMgr 2012 server.
Once you have OpsMgr deployed and youve opened the console, whats next? You probably want to start monitoring things. If
thats 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 youre 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 worstcase 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 Ive 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. Im 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, youll have the opportunity to
install both the management pack you want as well as its dependencies.

Agents
As you add management packs, their impact will be immediate. You will see new items added to the Monitoring area in the form
of new monitored items, dashboard and the like. But, even though management packs have the ability to discover items, nothing
can be discovered until OpsMgr agents have been deployed to systems you wish to monitor.
The agent is responsible for communications from monitored systems to the OpsMgr server. The agent operates by watching
various event sources, such as the local Windows logs and WMI counters and other sources. Information is forwarded to the
OpsMgr server for analysis.

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

Introduction to System Center Operations Manager 2012 (Part 4)

- Agent installation and configuration
by Scott D. Lowe [Published on 12 Jan. 2012 / Last Updated on 12 Jan. 2012]
In this article, you'll learn how to install and manage OpsMgr agents.

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, Ive upgraded to the release candidate.
To do this, I:

Uninstalled OpsMgr 2012 beta.

Upgraded my server to Windows Server 2008 R2 SP1 (I didnt have SP1 installed before). SP1 is required for the release.

Installed OpsMgr 2012 release candidate.

Advertisement

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.

Well 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, Ive 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, youre asked to provide
credentials either explicitly which I have done or you can use one of the Management Server Action Accounts that youve
previously defined.

Figure 4: Choose an account with administrative rights

Once youve 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. Thats a really important thing to understand: OpsMgr is only as smart as
you allow it to be. If you havent 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 dont 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 youve 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 its 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 its
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, thats the choice Ive made, as you can see in Figure 7.
If youre 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 youve had a successful completion, youre 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 youve 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 servers agent properties, you need to select the checkbox next to Override global
agent settings. Once youve 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 dont 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, youre 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, youre 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 youve 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 youve 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.
If you would like to read the other parts of this article series please go to:

Introduction to System Center Operations Manager 2012 (Part 5)

- Agent installation and configuration
by Scott D. Lowe [Published on 31 Jan. 2012 / Last Updated on 31 Jan. 2012]
In this part of this series, you will learn how to further manager OpsMgr 2012.

Introduction
Welcome back! So far in this series, youve 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.
Advertisement

OpsMgr Operations
In previous parts of this series, weve 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, its 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 its 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 youd like to monitor differently than Microsoft recommends or, you
might choose to skip monitoring a particular component altogether.
Heres 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, thats 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, youre likely to run into situations in which youre 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 youve thoroughly read Part 3 of this series as it contains
critical information related to whats contained in management packs. Im 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 cant 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 theyre just everyday XML files that you can edit to your hearts 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, didnt 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 cant be edited.

What gives?
This is where the real power and flexibility of OpsMgr becomes apparent. Through the use of whats 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?
Heres an override explained: Suppose youre monitoring available disk space and the default management pack wants to warn
you when youre 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 youre 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, youre not modifying the original management pack at all. Rather, youre 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!

Lets see whats out there

Although overrides are really cool and its critical to understand that they exist, we wont be creating any in this part of this series
(thats next, though). For now, lets 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, well 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, lets 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. Thats what youre 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. Youre 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, its nice to have a place to start.

Figure 3: A rule

Figure 4: Product knowledge about the rule

Now, lets take a look at some potentially more interesting information that can be gleaned from your OpsMgr installation. Up to
this point, weve 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 isnt the root cause of a clients performance issues. Easy! Take a look at the
screen in Figure 5.

Figure 5: OpsMgr agent performance

Here, youre 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 Im working remotely.
But, suppose youre 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, youll 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, heres why that information is captured. Theres 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, lets 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. Youll 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

Introduction to System Center Operations Manager 2012 (Part 6)

- Monitors
by Scott D. Lowe [Published on 29 Feb. 2012 / Last Updated on 29 Feb. 2012]
In this, part 6, you will continue to investigate the OpsMgr interface and discover how monitors work.

Introduction
Welcome back! So far in this series, youve 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 thats running at 8% free space. Lets say that the management pack youre using expects to see at least 15% available
space, below which the management pack wants to raise an alert. Its 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

Event monitor
Windows Event logs
Text logs

Description
Looks for events in the Windows event log
matching specified criteria.
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
collection
rule in 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. Lets 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.
Heres how an aggregate rollup monitor can be used: Suppose youre 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 youre 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.