Windows Server 2008 R2 Unleashed (158 page)

The reporting database stores data for long-term trend analysis and is designed to grow

much larger than the operations database. Data in the reporting database is stored in three

states: raw data, hourly summary, and daily summary. The raw data is only stored for 14

days, whereas both daily and hourly data are stored for 400 days. This automatic summa-

rization of data allows for reports that span days or months to be generated very quickly.

Determining the Role of Agents in System Monitoring

The agents are the monitoring components installed on each managed computer. They

monitor the system based on the rules and business logic defined in each of the manage-

ment packs. Management packs are dynamically applied to agents based on the different

discovery rules included with each management pack.

Defining Management Groups

OpsMgr utilizes the concept of management groups to logically separate geographical and

organizational boundaries. Management groups allow you to scale the size of OpsMgr

architecture or politically organize the administration of OpsMgr.

At a minimum, each management group consists of the following components:

. An operations database

. An optional reporting database

. A Root Management Server

802

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

. Management agents

. Management consoles

OpsMgr can be scaled to meet the needs of different sized organizations. For small organi-

zations, all the OpsMgr components can be installed on one server with a single manage-

ment group. In large organizations, on the other hand, the distribution of OpsMgr

components to separate servers allows the organizations to customize and scale their

OpsMgr architecture. Multiple management groups provide load balancing and fault toler-

ance within the OpsMgr infrastructure. Organizations can set up multiple management

servers at strategic locations, to distribute the workload among them.

NOTE

The general rule of thumb with management groups is to start with a single manage-

ment group and add on more management groups only if they are absolutely neces-

sary. Administrative overhead is reduced, and there is less need to re-create rules and

perform other redundant tasks with fewer management groups.

ptg

Understanding How to Use OpsMgr

Using OpsMgr is relatively straightforward. The OpsMgr monitoring environment can be

accessed through three sets of consoles: an Operations Console, a Web console, and a

command shell. The Operations Console provides full monitoring of agent systems and

administration of the OpsMgr environment, whereas the Web console provides access

only to the monitoring functionality. The command shell provides command-line access

to administer the OpsMgr environment.

Managing and Monitoring with OpsMgr

As mentioned in the preceding section, two methods are provided to configure and view

OpsMgr settings. The first approach is through the Operations Console and the second is

through the command shell.

Within the Administration section of the Operations Console, you can easily configure

the security roles, notifications, and configuration settings. Within the Monitoring section

of the Operations Console, you can easily monitor a quick “up/down” status, active and

closed alerts, and confirm overall environment health.

In addition, a web-based monitoring console can be run on any system that supports

Microsoft Internet Explorer 6.0 or higher. This console can be used to view the health of

systems, view and respond to alerts, view events, view performance graphs, run tasks, and

manage Maintenance mode of monitored objects. New to OpsMgr 2007 R2 is the ability to

display the Health Explorer in the Web console.

Understanding How to Use OpsMgr

803

Reporting from OpsMgr

OpsMgr management packs commonly include a variety of preconfigured reports to show

information about the operating system or the specific application they were designed to

work with. These reports are run in SQL Reporting Services. The reports provide an effec-

tive view of systems and services on the network over a custom period, such as weekly,

monthly, or quarterly. They can also help you monitor your networks based on perfor-

mance data, which can include critical pattern analysis, trend analysis, capacity planning,

and security auditing. Reports also provide availability statistics for distributed applica-

tions, servers, and specific components within a server.

23

Availability reports are particularly useful for executives, managers, and application

owners. These reports can show the availability of any object within OpsMgr, including a

server (shown in Figure 23.5), a database, or even a service such as Windows Server 2008

R2 that includes a multitude of servers and components. The Availability report shown in

Figure 23.5 indicates that the SP server was down on 9/29/2009 for about 4.17% of the

time or just slightly over 1 hour. The rest of the time it had been up.

ptg

FIGURE 23.5

Availability report.

The reports can be run on demand or at scheduled times and delivered via email. OpsMgr

can also generate HTML-based reports that can be published to a web server and viewed

from any web browser. Vendors can also create additional reports as part of their manage-

ment packs.

804

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

Using Performance Monitoring

Another key feature of OpsMgr is the capability to monitor and track server performance.

OpsMgr can be configured to monitor key performance thresholds through rules that are

set to collect predefined performance data, such as memory and CPU usage over time.

Rules can be configured to trigger alerts and actions when specified performance thresh-

olds have been met or exceeded, allowing network administrators to act on potential

performance issues. Performance data can be viewed from the OpsMgr Operations Console.

In addition, performance monitors can establish baselines for the environment and

then alert the administrator when the counter subsequently falls outside the defined

baseline envelope.

Using Active Directory Integration

Active Directory integration provides a way to install management agents on systems

without environmental-specific settings. When the agent starts, the correct environmental

settings, such as the primary and failover management servers, are stored in Active

Directory. The configuration of Active Directory integration provides advanced search and

filter capabilities to fine-tune the dynamic assignment of systems.

ptg

Integrating OpsMgr Non-Windows Devices

Network management is not a new concept. Simple management of various network nodes

has been handled for quite some time through the use of the SNMP. Quite often, simple or

even complex systems that utilize SNMP to provide for system monitoring are in place in

an organization to provide for varying degrees of system management on a network.

OpsMgr can be configured to integrate with non-Windows systems through monitoring

of syslog information, log file data, and SNMP traps. OpsMgr can also monitor TCP port

communication and website transaction sequencing for information-specific data

management.

New to OpsMgr 2007 R2 is the ability to monitor non-Microsoft operating systems such as

Linux and UNIX, as well as the applications that run on them such as Apache and

MySQL. OpsMgr monitors the file systems, network interfaces, daemons, configurations,

and performance metrics. Operations Manager 2007 R2 supports monitoring of the follow-

ing operating systems:

. HP-UX 11i v2 and v3 (PA-RISC and IA64)

. Sun Solaris 8 and 9 (SPARC) and Solaris 10 (SPARC and x86)

. Red Hat Enterprise Linux 4 (x86/x64) and 5 (x86/x64) Server

. Novell SUSE Linux Enterprise Server 9 (x86) and 10 SP1 (x86/x64)

. IBM AIX v5.3 and v6.1

These operating systems are “first-class citizens” in Microsoft’s parlance, meaning they are

treated as equals with the Windows operating systems. Agents can be pushed from the

Understanding OpsMgr Component Requirements

805

console, operations data is collected automatically, tasks can run against the agents, and

all major functions are supported.

Special connectors can be created to provide bidirectional information flows to other

management products. OpsMgr can monitor SNMP traps from SNMP-supported devices

as well as generate SNMP traps to be delivered to third-party network management

infrastructures.

Exploring Third-Party Management Packs

23

Software and hardware developers can subsequently create their own management packs

to extend OpsMgr’s management capabilities. These management packs extend OpsMgr’s

management capabilities beyond Microsoft-specific applications. Each management pack

is designed to contain a set of rules and product knowledge required to support its respec-

tive products. Currently, management packs have been developed for APC, Cisco, Citrix,

Dell, F5, HP, IBM, Linux, Oracle, Solaris, UNIX, and VMware to name a few. A complete

list of management packs can be found at the following Microsoft site: http://technet.

microsoft.com/en-us/opsmgr/cc539535.aspx.

ptg

Understanding OpsMgr Component Requirements

Each OpsMgr component has specific design requirements, and a good knowledge of these

factors is required before beginning the design of OpsMgr. Hardware and software require-

ments must be taken into account, as well as factors involving specific OpsMgr compo-

nents, such as the Root Management Server, gateway servers, service accounts, mutual

authentication, and backup requirements.

Exploring Hardware Requirements

Having the proper hardware for OpsMgr to operate on is a critical component of OpsMgr

functionality, reliability, and overall performance. Nothing is worse than overloading a

brand-new server only a few short months after its implementation. The industry standard

generally holds that any production servers deployed should remain relevant for three to

four years following deployment. Stretching beyond this time frame might be possible,

but the ugly truth is that hardware investments are typically short term and need to be

replaced often to ensure relevance. Buying a less-expensive server might save money in

the short term but could potentially increase costs associated with downtime, trou-

bleshooting, and administration. That said, the following are the Microsoft-recommended

minimums for any server running an OpsMgr 2007 server component:

. 2.8GHz processor or faster

. 20GB of free disk space

. 2GB of random access memory (RAM)

806

CHAPTER 23

Integrating System Center Operations Manager 2007 R2 with

Windows Server 2008 R2

These recommendations apply only to the smallest OpsMgr deployments and should be

seen as minimum levels for OpsMgr hardware. More realistic deployments would have the

following minimums:

. 2–4 2.8GHz cores

. 64-bit Windows operating system

. 64-bit SQL Server

. 60GB free disk space on RAID 1+0 for performance

. 4–8GB RAM

Operations Manager 2007 R2 is one of Microsoft’s most resource-intensive applications, so

generous processor, disk, and memory are important for optimal performance. Future

expansion and relevance of hardware should be taken into account when sizing servers for

OpsMgr deployment, to ensure that the system has room to grow as agents are added and

the databases grow.

Determining Software Requirements

ptg

OpsMgr components can be installed on either 32-bit or 64-bit versions of Windows

Server 2003, Windows Server 2008, or Windows Server 2008 R2. The database for OpsMgr

must be run on a Microsoft SQL Server 2005 or Microsoft SQL Server 2008 server. The

database can be installed on the same server as OpsMgr or on a separate server, a concept

that is discussed in more detail in following sections.

OpsMgr itself must be installed on a member server in a Windows Active Directory

domain. It is commonly recommended to keep the installation of OpsMgr on a separate