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.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
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 effective 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 performance data, which can include critical pattern analysis, trend analysis, capacity planning, and security auditing. Reports also provide availability statistics for distributed applications, servers, and specific components within a server.
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.
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 management packs.
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.
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 following 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 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
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 respective 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.
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 requirements must be taken into account, as well as factors involving specific OpsMgr components, 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, troubleshooting, 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)
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
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 server or set of dedicated member servers that do not run any other applications that could interfere in the monitoring and alerting process.
A few other requirements critical to the success of OpsMgr implementations are as follows:
- Microsoft .NET Framework 2.0 and 3.0 must be installed on the management server and the reporting server.
- Windows PowerShell.
- Microsoft Core XML Services (MSXML) 6.0.
- WS-MAN v1.1 (for UNIX/Linux clients).
- Client certificates must be installed in environments to facilitate mutual authentication between nondomain members and management servers.
- SQL Reporting Services must be installed for an organization to be able to view and produce custom reports using OpsMgr's reporting feature.
OpsMgr Backup Considerations
The most critical piece of OpsMgr, the SQL databases, should be regularly backed up using standard backup software that can effectively perform online backups of SQL databases. If integrating these specialized backup utilities into an OpsMgr deployment is not possible, it becomes necessary to leverage built-in backup functionality found in SQL Server.
Understanding Advanced OpsMgr Concepts
OpsMgr's simple installation and relative ease of use often belie the potential complexity of its underlying components. This complexity can be managed with the right amount of knowledge of some of the advanced concepts of OpsMgr design and implementation.
Understanding OpsMgr Deployment Scenarios
As previously mentioned, OpsMgr components can be divided across multiple servers to distribute load and ensure balanced functionality. This separation allows OpsMgr servers to come in four potential "flavors," depending on the OpsMgr components held by those servers. The four OpsMgr server types are as follows:
- Operations database server -- An operations database server is simply a member server with SQL Server installed for the OpsMgr operations database. No other OpsMgr components are installed on this server. The SQL Server component can be installed with default options and with the system account used for authentication. Data in this database is kept for 7 days by default.
- Reporting database server -- A reporting database server is simply a member server with SQL Server and SQL Server Reporting Services installed. This database stores data collected through the monitoring rules for a much longer period than the operations database and is used for reporting and trend analysis. This database requires significantly more drive space than the operations database server. Data in this data-base is kept for 13 months by default.
- Management server -- A management server is the communication point for both management consoles and agents. Effectively, a management server does not have a database and is often used in large OpsMgr implementations that have a dedicated database server. Often, in these configurations, multiple management servers are used in a single management group to provide for scalability and to address multiple managed nodes.
- All-in-one server -- An all-in-one server is effectively an OpsMgr server that holds all OpsMgr roles, including that of the databases. Subsequently, single-server OpsMgr configurations use one server for all OpsMgr operations.
Multiple Configuration Groups
As previously defined, an OpsMgr management group is a logical grouping of monitored servers that are managed by a single OpsMgr SQL database, one or more management servers, and a unique management group name. Each management group established operates completely separately from other management groups, although they can be configured in a hierarchical structure with a top-level management group able to see "connected" lower-level management groups.
The concept of connected management groups allows OpsMgr to scale beyond artificial boundaries and also gives a great deal of flexibility when combining OpsMgr environments. However, certain caveats must be taken into account. Because each management group is an island in itself, each must subsequently be manually configured with individual settings. In environments with a large number of customized rules, for example, such manual configuration would create a great deal of redundant work in the creation, administration, and troubleshooting of multiple management groups.
Deploying Geographic-Based Configuration Groups
Based on the factors outlined in the preceding section, it is preferable to deploy OpsMgr in a single management group. However, in some situations, an organization needs to divide its OpsMgr environment into multiple management groups. The most common reason for division of OpsMgr management groups is division along geographic lines. In situations in which wide area network (WAN) links are saturated or unreliable, it might be wise to separate large "islands" of WAN connectivity into separate management groups.
Simply being separated across slow WAN links is not enough reason to warrant a separate management group, however. For example, small sites with few servers would not warrant the creation of a separate OpsMgr management group, with the associated hardware, soft-ware, and administrative costs. However, if many servers exist in a distributed, generally well-connected geographical area, that might be a case for the creation of a management group. For example, an organization could be divided into several sites across the United States but decide to divide the OpsMgr environment into separate management groups for East Coast and West Coast, to roughly approximate their WAN infrastructure.
Smaller sites that are not well connected but are not large enough to warrant their own management group should have their event monitoring throttled to avoid being sent across the WAN during peak usage times. The downside to this approach, however, is that the reaction time to critical event response is increased.
Deploying Political or Security-Based Configuration Groups
The less-common method of dividing OpsMgr management groups is by political or security lines. For example, it might become necessary to separate financial servers into a separate management group to maintain the security of the finance environment and allow for a separate set of administrators.
Politically, if administration is not centralized within an organization, management groups can be established to separate OpsMgr management into separate spheres of control. This would keep each OpsMgr management zone under separate security models.
As previously mentioned, a single management group is the most efficient OpsMgr environment and provides for the least amount of redundant setup, administration, and troubleshooting work. Consequently, artificial OpsMgr division along political or security lines should be avoided, if possible.
Sizing the OpsMgr Database
Depending on several factors, such as the type of data collected, the length of time that collected data will be kept, or the amount of database grooming that is scheduled, the size of the OpsMgr database will grow or shrink accordingly. It is important to monitor the size of the database to ensure that it does not increase well beyond the bounds of accept-able size. OpsMgr can be configured to monitor itself, supplying advance notice of data-base problems and capacity thresholds. This type of strategy is highly recommended because OpsMgr could easily collect event information faster than it could get rid of it.
The size of the operations database can be estimated through the following formula:
Number of agents x 5MB x retention days + 1024 overhead = estimated database size
For example, an OpsMgr environment monitoring 1,000 servers with the default 7-day retention period will have an estimated 35GB operations database:
(1000 * 5 * 7) + 1024 = 36024 MB
The size of the reporting database can be estimated through the following formula:
Number of agents x 3MB x retention days + 1024 overhead = estimated database size
The same environment monitoring 1,000 servers with the default 400-day retention period will have an estimated 1.1TB reporting database:
(1000 * 3 * 400) + 1024 = 1201024 MB
It is important to understand that these estimates are rough guidelines only and can vary widely depending on the types of servers monitored, the monitoring configuration, the degree of customization, and other factors.
Defining Capacity Limits
As with any system, OpsMgr includes some hard limits that should be taken into account before deployment begins. Surpassing these limits could be cause for the creation of new management groups and should subsequently be included in a design plan. These limits are as follows:
- Operations database -- OpsMgr operates through a principle of centralized, rather than distributed, collection of data. All event logs, performance counters, and alerts are sent to a single, centralized database, and there can subsequently be only a single operations database per management group. Considering the use of a backup and high-availability strategy for the OpsMgr database is, therefore, highly recommended, to protect it from outage. It is recommended to keep this database with a 50GB limit to improve efficiency and reduce alert latency.
- Management servers -- OpsMgr does not have a hard-coded limit of management servers per management group. However, it is recommended to keep the environment between three to five management servers. Each management server can support approximately 2,000 managed agents.
- Gateway servers -- OpsMgr does not have a hard-coded limit of gateway servers per management group. However, it is recommended to deploy a gateway server for every 200 nontrusted domain members.
- Agents -- Each management server can theoretically support up to 2,000 monitored agents. In most configurations, however, it is wise to limit the number of agents per management server, although the levels can be scaled upward with more robust hardware, if necessary.
- Administrative consoles -- OpsMgr does not limit the number of instances of the Web and Operations Console; however, going beyond the suggested limit might introduce performance and scalability problems.
Defining System Redundancy
In addition to the scalability built in to OpsMgr, redundancy is built in to the components of the environment. Proper knowledge of how to deploy OpsMgr redundancy and place OpsMgr components correctly is important to the understanding of OpsMgr redundancy. The main components of OpsMgr can be made redundant through the following methods:
- Management servers -- Management servers are automatically redundant and agents will failover and failback automatically between them. Simply install addi-tional management servers for redundancy. In addition, the RMS system acts as a management server and participates in the fault tolerance.
- SQL databases -- The SQL database servers hosting the databases can be made redundant using SQL clustering, which is based on Windows clustering. This supports failover and failback.
- Root Management Server -- The RMS can be made redundant using Windows clus-tering. This supports failover and failback.
Having multiple management servers deployed across a management group allows an environment to achieve a certain level of redundancy. If a single management server expe-riences downtime, another management server within the management group will take over the responsibilities for the monitored servers in the environment. For this reason, it might be wise to include multiple management servers in an environment to achieve a certain level of redundancy if high uptime is a priority.
The first management server in the management group is called the Root Management Server. Only one Root Management Server can exist in a management group and it hosts the software development kit (SDK) and Configuration service. All OpsMgr consoles communicate with the management server so its availability is critical. In large-scale envi-ronments, the Root Management Server should leverage Microsoft Cluster technology to provide high availability for this component.
Because there can be only a single OpsMgr database per management group, the database is subsequently a single point of failure and should be protected from downtime. Utilizing Windows Server 2008 R2 clustering or third-party fault-tolerance solutions for SQL data-bases helps to mitigate the risk involved with the OpsMgr database.
Monitoring Nondomain Member Considerations
DMZ, Workgroup, and Nontrusted Domain Agents require special configuration; in partic-ular, they require certificates to establish mutual authentication. Operations Manager 2007 R2 requires mutual authentication, that is, the server authenticates to the client and the client authenticates to the server, to ensure that the monitoring communications are not hacked. Without mutual authentication, it is possible for a hacker to execute a man-in-the-middle attack and impersonate either the client or the server. Thus, mutual authenti-cation is a security measure designed to protect clients, servers, and sensitive Active Directory domain information, which is exposed to potential hacking attempts by the all-powerful management infrastructure. However, OpsMgr relies on Active Directory Kerberos for mutual authentication, which is not available to nondomain members.
Workgroup servers, public web servers, and Microsoft Exchange Edge Transport role servers are commonly placed in the DMZ and are for security reasons not domain members, so almost every Windows Server 2008 R2 environment will need to deploy certificate-based authentication.
In the absence of Active Directory, trusts, and Kerberos, OpsMgr 2007 R2 can use X.509 certificates to establish the mutual authentication. These can be issued by any PKI, such as Microsoft Windows Server 2008 Enterprise CA. See Chapter 14, "Transport-Level Security," for details on PKI and Windows Server 2008 R2.
Installing agents on DMZ servers is discussed later in this chapter in the section "Monitoring DMZ Servers with Certificates."
Security has evolved into a primary concern that can no longer be taken for granted. The inherent security in Windows Server 2008 R2 is only as good as the services that have access to it; therefore, it is wise to perform a security audit of all systems that access information from servers. This concept holds true for management systems as well because they collect sensitive information from every server in an enterprise. This includes potentially sensitive event logs that could be used to compromise a system. Consequently, securing the OpsMgr infrastructure should not be taken lightly.
Securing OpsMgr Agents
Each server that contains an OpsMgr agent and forwards events to management servers has specific security requirements. Server-level security should be established and should include provisions for OpsMgr data collection. All traffic between OpsMgr components, such as the agents, management servers, and database, is encrypted automatically for security, so the traffic is inherently secured.
In addition, environments with high-security requirements should investigate the use of encryption technologies such as IPSec to scramble the event IDs that are sent between agents and OpsMgr servers, to protect against eavesdropping of OpsMgr packets.
OpsMgr uses mutual authentication between agents and management servers. This means that the agent must reside in the same forest as the management server. If the agent is located in a different forest or workgroup, client certificates can be used to establish mutual authentication. If an entire nontrusted domain must be monitored, the gateway server can be installed in the nontrusted domain, agents can establish mutual authentication to the gateway server, and certificates on the gateway and management server are used to establish mutual authentication. In this scenario, you can avoid needing to place a certificate on each nontrusted domain member.
Understanding Firewall Requirements
OpsMgr servers that are deployed across a firewall have special considerations that must be taken into account. Port 5723, the default port for OpsMgr communications, must specifically be opened on a firewall to allow OpsMgr to communicate across it.
Table 23.1 describes communication for this and other OpsMgr components.
TABLE 23.1 OpsMgr Communication Ports
|Agent||Root Management Server||5723|
|Agent (ACS forwarder)||Management server ACS collector||51909|
|Gateway Server||Root Management Server||5723|
|Gateway Server||Root Management Server||5723|
|Management or Gateway server||Unix or Linux computer||1270|
|Management or Gateway server||Unix or Linux computer||22|
|Management server||Operations Manager database||1433|
|Management server||Root Management Server||5723, 5724|
|Management server||Reporting data warehouse||1433|
|Management server ACS collector||ACS database||1433|
|Operations console||Root Management Server||5724|
|Operations console (reports)||SQL Server reporting services||80|
|Reporting server||Root Management Server||5723, 5724|
|Reporting server||Reporting data warehouse||1433|
|Root Management Server||Operations Manager database||1433|
|Root Management Server||Reporting data warehouse||1433|
|Web console browser||Web console server||51908|
|Web console server||Root Management Server||5724|
The firewall port for the agents is the port that needs to be opened most often, which is only port 5723 from the agent to the management servers for monitoring. Other ports, such as 51909 for ACS, are more rarely needed. Figure 23.6 shows the major communications paths and ports between OpsMgr components.
FIGURE 23.6 Communications ports.
Outlining Service Account Security
In addition to the aforementioned security measures, security of an OpsMgr environment can be strengthened by the addition of multiple service accounts to handle the different OpsMgr components. For example, the Management Server Action account and the SDK/Configuration service account should be configured to use separate credentials, to provide for an extra layer of protection in the event that one account is compromised.
- Management Server Action account -- The account responsible for collecting data and running responses from management servers.
- SDK and Configuration service account -- The account that writes data to the operations database; this service is also used for all console communication.
- Local Administrator account -- The account used during the agent push installation process. To install the agent, local administrative rights are required.
- Agent Action account -- The credentials the agent will run as. This account can run under a built-in system account, such as Local System, or a limited domain user account for high-security environments.
- Data Warehouse Write Action account -- The account used by the management server to write data to the reporting data warehouse.
- Data Warehouse Reader account -- The account used to read data from the data warehouse when reports are executed.
- Run As accounts -- The specific accounts used by management packs to facilitate monitoring. These accounts must be manually created and delegated specific rights as defined in the management pack documentation. These accounts are then assigned as Run As accounts used by the management pack to achieve a high degree of security and flexibility when monitoring the environment. New to OpsMgr 2007 R2 is the ability to selectively distribute the Run As Account to just the agents that need them.
Integrating System Center Operations Manager 2007 R2 with Windows Server 2008 R2
Using OpsMgr 2007 R2 to monitor Windows Server 2008 R2
OpsMgr 2007 R2 hardware, software, security requirements
OpsMgr 2007 R2 installation steps
Operations Manager 2007 R2 configuration
Operations Manager 2007 R2: Using alerts, running reports
Printed with permission from Sams Publishing. Copyright 2010. Windows Server 2008 R2 Unleashed by Rand Morimoto, Michael Noel, Omar Droubi and Ross Mistry. For more information about this title and other similar books, please visit Sams Publishing.