Introduction to System Center Operations Manager 2012 (Part 4)

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

Introduction to System Center Operations Manager 2012 (Part 1)
Introduction to System Center Operations Manager 2012 (Part 2) – Installation
Introduction to System Center Operations Manager 2012 (Part 3) – Management Pack Fundamentals
Introduction to System Center Operations Manager 2012 (Part 5) – Agent installation and configuration

Introduction to System Center Operations Manager 2012 (Part 6) – Monitors

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:

Uninstalled OpsMgr 2012 beta.
Upgraded my server to Windows Server 2008 R2 SP1 (I didn’t have SP1 installed before). SP1 is required for the release.
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.

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