Embed Size (px)
Citation preview
Introduction to System Center Operations
Manager 2012 (Part 1)
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.
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.
If you would like to read the other parts of this article series please go to:
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.
Summary
We’ll cover how to install agents and perform basic monitoring using the built-in management
packs in the next part of this article series.
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
Introduction
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
collection
Use a performance monitor counter as a
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. 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.
