Overview of Operations Manager 2007

Applies To: Operations Manager 2007 R2, Operations Manager 2007 SP1

An Operations Manager 2007 infrastructure is composed of certain core components that must be implemented and a set of optional components and features that you can choose to implement as needed. This section presents these components and features according to their required and optional classification. In general, a component is something that you will install from your source media, and a feature is something that you will configure and make use of once all the required components for that feature have been installed.

Required Server Roles and Components

The basic unit of functionality of all Operations Manager 2007 implementations is the management group. It consists of an installation of Microsoft SQL Server 2005 or Microsoft SQL Server 2008, which hosts the OperationsManager database, the root management server, the Operations console, and one or more agents that are deployed to monitored computers or devices are the base components of a management group.

OperationsManager Database

The OperationsManager database is the first component to be installed in all management groups. This database holds all the configuration data for the management group and stores all the monitoring data that has been collected and processed by the agents.

To optimize performance of Operations Manager, you must keep the size of the OperationsManager database under control. Testing has shown that staying under 50 GB is a good practice. To keep from exceeding this limit, Operations Manager 2007 will automatically groom out older, unnecessary data according to parameters that you set.

Because only one OperationsManager database can be in a management group, it must be functional for the management group to function. To mitigate the single instance of the OperationsManager database from being a single point of failure, the OperationsManager database can be placed in a Cluster service (formerly known as MSCS) failover cluster. In addition, log shipping can be configured so that current operations data and configuration information can be sent to another Microsoft SQL server of the same version that is hosting a duplicate copy of the primary OperationsManager database. Should there be a failure in the primary database, the duplicate can be updated and switched to. The OperationsManager database is involved in these activities:

• management pack import – Management pack imports place a load on the CPU, the memory, and the disk of the database server.

• discovery – As the discovery process occurs, agents return data to the management servers. Ultimately, this data is inserted into the OperationsManager database. This process places a load on the disk and on the CPU of the database server.

• monitoring operations – All data that is collected from agents and all management group configuration information is stored in the OperationsManager database.

Root Management Server

The root management server (RMS) is a specialized type of management server in a management group, and it is the first management server installed in a management group. Only one RMS can be active per management group at a time. In brief, the RMS is the focal point for administering the management group configuration, administering and communicating with agents, and communicating with the OperationsManager database and other databases in the management group.

The RMS also serves as the target for the Operations console and the preferred target for the Web consoles.

The RMS hosts the System Center Data Access service and the System Center Management Configuration service. These services run only on the RMS. The System Center Data Access service provides secure access to the OperationsManager database for all clients, including the Operations console, Operations shell, and Web console. The System Center Management Configuration service is responsible for calculating and distributing the configuration of all management servers and agents, including which management packs they should receive.

Like the OperationsManager database, the RMS role can be installed into an MSCS failover cluster to make it highly available. In addition, other management servers in the management group (if you have them) can be manually promoted to the role of RMS.

The RMS participates in the functions:

• management pack import – When you import management packs, the RMS first verifies that the management pack is valid. Then, it converts the XML-formatted data of the management pack to relational database format. Finally, it sends the data to the OperationsManager database. Both operations place a load on the RMS CPU, disk, and memory.

• maintenance of the Instance space – The System Center Management Configuration service calculates the configurations for all monitored devices in the management group. To do this, the service maintains a copy of all the configuration information in memory and performs its calculations there. This places a load on memory. After the instance space calculations are run, agents send a synchronization request to their management server, which sends the request to the RMS. The RMS stores these requests until it can act upon them in an in-memory queue.

• discovery – After management packs are sent to the agents, the discovery process starts. Agents return the discovery data to their management servers and then to the RMS. This data is inserted into the OperationsManager database and incorporated in the Instance space. Both activities place a load on the disk, the CPU, and the memory on the RMS.

Agent

An Operations Manager 2007 agent is a service that is deployed to a computer that you want to monitor. On the monitored device, an agent is listed as the System Center Management service. Every agent reports to a management server in the management group. This management server is referred to as the agent's primary management server. Agents watch data sources on the monitored device and collect information according to the configuration that is sent to it from its management server. The agent also calculates the health state of the monitored object and reports back to the management server. When the health state of a monitored object changes or other criteria are met, an alert can be generated from the agent. This lets operators know that something has gone awry and requires attention.

Agents also have the ability to take many different types of action to help diagnose issues or correct them. By feeding health data to the management server about the monitored device, the agent provides an up-to-date picture of the health of the device and all the applications that it hosts.

It is possible to monitor devices in an agentless fashion. In this case, a management server performs the monitoring remotely.

Operations Console

The Operations console provides a single, unified user interface for interacting with Operations Manager 2007. The Operations console provides access to monitoring data, basic management pack authoring tools, Operations Manager 2007 reports, all the controls and tools necessary for administering Operations Manager 2007, and a customizable workspace.

For a user to access the Operations console, the user's Active Directory user account must be assigned to an Operations Manager 2007 user role. A user role is the combination of a scope of devices that access is granted to and a profile that defines what the role can do within its defined scope. Role-based security is enforced in the Operations console so that Operations Manager administrators can define what any given user can see in the console and what actions the user can take on those items. For more information, see the "Role-Based Security" section in this document.

Management Packs

Management packs contain an application's health definition as defined by the application developers. When imported into Operations Manager, they enable the agent to monitor the health of an application, generate alerts when something of significance goes wrong in the application, and take actions in the application and its supporting infrastructure to further diagnose the application or restore it to a healthy state. Without an application, operating-system, or device-specific management pack, Operations Manager 2007 is unaware of those entities and is unable to monitor them.

Optional Server Roles and Components

These additional server roles extend the functionality of a management group. Most of these components are installed separately from the required core components, but some can be installed at the same time as the core components. For complete details on installing Operations Manager 2007 components, see the Operations Manager 2007 Deployment Guide.

Management Server

A management server is used primarily for receiving configurations and management packs from the RMS and distributing them to the agents that report to the management server. It does not perform any of the special functions of the RMS. A management server can be promoted to the RMS role if the RMS fails, as long as it was present in the management group prior to the RMS failure. Multiple management servers are installed in a management group to provide extra capacity for agent management. In addition to providing scalability, introducing additional management servers in a management group allows for agents to fail over and start reporting their data to another management server if communication with their primary management server is lost.

The management server can also be used for remote monitoring purposes (such as URL monitoring and cross-platform monitoring). One additional role for a management server is to host the Audit Collection Service (ACS) Collector role. The ACS Collector can be installed only on a management server or gateway server. See the "Audit Collection Service (ACS)" section later in this document for additional information about Audit Collection Services. Other roles include the AEM file share role, which is also explained later in this document.

The management server makes heavy use of the CPU for data collection activities, and it also makes heavy use of disk for UNIX and Linux data queues.

Gateway Server

Operations Manager 2007 requires that agents and management servers authenticate each other and establish an encrypted communication channel before they exchange information. Kerberos is the default authentication protocol. When the agent and the management server are in the same Active Directory forest or in forests with forest trust, mutual authentication occurs automatically. This is because Kerberos is the default authentication protocol in Active Directory.

When agents and management servers are not within the same Kerberos trust boundary (that is, not in the same Active Directory forest or in forests with forest trust), certificate-based authentication mechanisms must be used. In this situation, a certificate must be issued and maintained for those agents and the management servers to which they report. In addition, if there is a firewall between the agents and the management server, either the firewall rules must permit each computer that hosts an agent to communicate directly through it over an encrypted channel or the Operations Manager communication port must be opened inbound.

An Operations Manager 2007 gateway server can be used to drastically reduce the administrative overhead required to maintain communication between agents and management servers that are separated by a trust boundary. The gateway server acts as a proxy for agent communications. The gateway server is placed within the trust boundary of the agents (which can be a domain), and all the agents communicate with it. Then the gateway server, through the use of its computer certificate, performs mutual authentication with the management server and forwards the agent-to-management server and management server-to-agent communications along. This then requires only one certificate for the management server and one for the gateway. In the firewall scenario, only the gateway server and the management server need to be authorized to communicate with each other.

Multiple gateway servers can be installed in a management group for the purposes of scalability and failover. Should an agent lose communication with its gateway server, it can then fail over to a different gateway server that is in the same management group and within the agent's trust boundary.

Likewise, gateway servers can be configured to fail over between management servers in a management group. This configuration then provides fully redundant communication channels for agents that lie outside a management server's trust boundary.

The gateway server participates in the following activities:

• All data communication between untrusted agents and management servers – gateway servers proxy communications between management servers and agents. They also serve as a concentration point for the same communications. This data consists of configuration data and management packs that are sent to the agent, and it consists of discovery and monitoring data that is sent to the management server. All this data is queued on the gateway servers local disk. Because this places a significant load on the gateway server disk, be sure to provide plenty of fast disk.

Web Console Server

The Web console server provides an interface to the management group that is accessible via a Web browser. It does not have the full functionality of the Operations console, however, and provides access to only the Monitoring, Favorite Reports, and My Workspace views. The Web console provides access to all the monitoring data and tasks that are actions that can be run against monitored computers from the Operations console. Access to data in the Web console has the same restrictions as access to content in the Operations console.

Management Pack Authoring Console

The Operations Manager 2007 authoring console is a stand-alone application that provides richer management pack authoring functionality than what is provided by the Operations console authoring space. Using the authoring console, you can create new management packs, view and modify existing management packs, verify the integrity of management packs, and import and export management packs to and from management groups. The Operations Manager 2007 authoring console can be downloaded here: https://go.microsoft.com/fwlink/?LinkId=136356.

Reporting Data Warehouse

The Reporting Data Warehouse stores monitoring and alerting data for historical purposes. The management servers write their data to the Data Warehouse at the same time it is written to the OperationsManager database, so the reports generated always contain the most up-to-date data. The Data Warehouse automatically aggregates performance data on an hourly and daily basis. This allows long-term trending reports to be run much faster than they would be otherwise, and far less data needs to be retained to support long-term trend reporting.

The Reporting Data Warehouse can receive data from multiple management groups, thereby allowing for an aggregated view of data in your reports.

Reporting Server

Operations Manager Reporting Server is installed into an instance of Microsoft SQL 2005 Reporting Services SP1 or later or Microsoft SQL Server 2008 SP1 Reporting Services. It is responsible for building and presenting the reports from data queried from the Reporting Data Warehouse. All reports are accessed in the Operations console, so access to reports is controlled via role-based security.

Audit Collection Services

Audit Collection Services (ACS) is a high-performance, secure solution that collects and stores events from the Security Event Log on monitored computers. Events are stored in a separate database, the ACS database (discussed later in this document), in Microsoft SQL Server 2005 SP1 or later and Microsoft SQL Server 2008 SP1. ACS collects all events written to the Security Event Log on computers that the ACS Forwarder is enabled on. Events are forwarded from monitored computers to the ACS Collector, which runs on a management server, which then processes them and writes them to the ACS database. The events are transmitted in an encrypted, near real-time fashion from the forwarders to the collector. A separate component, ACS Reporting, is then used to generate reports from the stored ACS data.

A key to using ACS effectively is the development of a sound Windows Audit Group Policy that is implemented as a domain Group Policy. For details on Windows Audit Group Policy and implementing ACS, see Managing Audit Collection Services in Operations Manager 2007 https://go.microsoft.com/fwlink/?LinkID=144374 .

ACS Forwarder

The ACS Forwarder is embedded in the Operations Manager 2007 agent, so no separate deployment or configuration is required. The ACS Forwarder appears as the Audit Forwarder service and is disabled by default. The ACS Forwarder on an individual computer or on groups of computers is enabled via a task in the Operations console.

ACS Collector Server

The main purpose of the ACS Collector server is to collect, filter, and pre-process all the Windows security log events for insertion into the database. Because the ACS collects all security events in near real-time, vast amounts of data enters the system from the forwarders. Not all of this information will be of interest to your company, as defined in your company's Windows Audit Group Policy. The filtering mechanism at the collector allows you to specify which events you want written to the ACS database for long-term storage.

The ACS Collector server has a separate installation program from the Operations Manager servers, agents, or reporting components. It can be installed only on an existing management server or RMS if you have not installed any additional management servers. One ACS Collector server can support hundreds to thousands of servers, depending on the server role and Windows Audit Group Policy, and tens of thousands of workstations. However, there is a one-to-one relationship between the ACS Collector server and the ACS Database (which is discussed in the next section). If for scalability or control reasons your company requires additional ACS Collectors, you will need one ACS Database per ACS Collector.

ACS Database

After the data has been pre-processed by the ACS Collector server, it is written to its ACS Database, which is just a database created on a Microsoft SQL Server 2005 SP1 or SP2 instance. Because it is a standard SQL database, it can be clustered for high-availability. To accommodate the one-to-one relationship between collectors and databases, you can create, via named instances, multiple ACS Databases on a single SQL Server 2005 server as long as it can support the additional load. For more information about sizing and capacity planning for ACS, see that section later in this guide.

ACS Reporting

The ACS Reporting server is also a separately installed component. A number of preconfigured reports are available. Installation of ACS Reporting requires an existing instance of SQL Server 2005 SP1 or later Reporting Services or Microsoft SQL Server 2008 Reporting Services. This can be a stand-alone instance, or you can install ACS Reporting along with Operations Manager 2007 Reporting with one tradeoff.

If you install ACS Reporting into the same Reporting Services instance as Operations Manager 2007 Reporting, ACS Reporting is fully integrated with Operations Manager Reporting. This results in reduced administrative overhead, because anyone who has been assigned to the Operations Manager Reporting role will have access to the ACS reports. Some companies might not find this to be a desirable configuration, and they might elect to install ACS Reporting into its own instance of SQL Server Reporting. In this case, you must define your own security groups and roles, resulting in higher administrative overhead but extremely tight control over access to ACS data.

Proxy Agent

Operations Manager 2007 has the ability to monitor network devices, via SNMP v2, computers that are not running a Windows operating system, and computers without agents. In these cases, another computer that has an agent installed is actually performing the monitoring remotely. The computer that is performing the remote monitoring is called a proxy agent. The agent that is acting as a proxy for monitoring other devices is a standard Operations Manager agent. It is merely configured differently by selecting the Allow this agent to act as a proxy and discover managed objects and other computers option in the agent properties. Then you configure the agentless managed device to designate the proxy agent it is to use. For more information about agent deployment and management of devices, please see the Operations Manager 2007 Operations Guide.

Operations Manager 2007 Command Shell

In 2006, Microsoft introduced the Windows PowerShell command-line interface for use on its Windows Server 2003, Windows Server 2008, Windows XP, and Vista operating systems. This interface was developed for use by system administrators for automating tasks. The interface includes an interactive prompt and a scripting environment that can be used independently or in combination. The objects that you interact with in PowerShell are called "command-lets" and are binary native commands in Windows PowerShell. Windows PowerShell commands are designed to deal with objects—structured information that is more than just a string of characters appearing on the screen. Command output always carries along extra information that you can use if you need it.

The Operations Manager 2007 Command Shell is a grouping of 203 individual command-lets that have been specifically developed for automating Operations Manager 2007 administrative tasks. The Command Shell can be installed on any computer that will have the Operations console installed.

Features

Features are present by default and only require configuration to make use of them. The ability to configure and use features as you please in Operations Manager 2007 is a hallmark of its flexibility.

Cross-Platform Monitoring (UNIX-based or Linux-based Computers)

Operations Manager 2007 R2 management servers and gateway servers can monitor UNIX and Linux computers. For a complete list of UNIX-based and Linux-based operating systems that can be monitored, please see the Supported Configuration guide at https://go.microsoft.com/fwlink/?LinkId=144400.

In cross-platform monitoring, the system center management service on the management server or gateway server runs all the monitoring intelligence. The monitoring system center management service communicates with the monitored computer through a WSMAN layer that is on both the management server and the computer being monitored. It is a prerequisite that the WSMAN layer be installed on the monitored computer. Communication between the WSMAN layers occurs over TCP port 1270 and always originates from the management server or gateway server. In some cases, such as when the WSMAN layer is not present on the monitored computer or it has failed, the communication can occur to SSH TCP 22. SSH can be used for installing the WSMAN layer or performing diagnostics.

Agentless Exception Monitoring

In Windows operating systems, when an application error occurs, the Watson service can capture the error and forward the information about the error to Microsoft to determine the root cause of the problem. Typically, each computer does this individually. Because error monitoring and reporting is occurring on an individual basis, IT administrators do not have any visibility into these exceptions across their organization.

When the Agentless Exception Monitoring feature is enabled, all the exceptions can be forwarded to a management server in your management group and aggregated. Because they are then concentrated in a single place, your company can use this data for analyzing and diagnosing desktop and server application issues as they are occurring throughout your company. If you choose, you can also configure the management server to forward the exception-monitoring information to Microsoft for crash analysis.

Connector Framework

The Connector Framework is an application programming interface (API) that exposes Operations Manager functionality for the purposes of integrating with other management products or other technologies, such as trouble-ticketing systems. It enables the development of connectors that can bidirectionally exchange information with Operations Manager. The Connector Framework interacts primarily with the System Center Data Access service on the RMS. For more information about developing applications that use the Operations Manager 2007 Connector Framework, see the Operations Manager 2007 SDK.

URL Monitoring

Operations Manager 2007 provides the ability to monitor URL availability from a watcher node (another health service running on a different computer. Management servers that perform this function will have a heavy load placed on their CPU resources and then disk resources. If you are going to monitor more than 1000 URLs, you should create a dedicated management group for this purpose.

Concepts

In planning your topology, you must understand the concept of role-based security as implemented in Operations Manager.

Role- Based Security

Role-based security is used to control the objects that you can see and what actions you can take on those objects. A role is made up of two parts. The first part is a scope that contains the objects that can be accessed or seen. For example, a scope can be defined as containing nothing but domain controllers or SQL servers. The second part is a profile. Each profile defines actions that can be taken on objects that can be seen. Out of the box, Operations Manager 2007 provides the following five profiles:

• Administrator profile—This profile has full privileges to Operations Manager.

• Advanced Operator profile—This profile has the limited ability to tweak the monitoring configuration by configuring overrides on rules and monitors.

• Author profile—This profile has the ability to author the monitoring configuration elements, such as rules, tasks, monitors, and views.

• Operator profile—This profile has the ability to access Alerts, Views, and Tasks.

• Read-Only Operator profile—This profile allows read-only access to Alerts and Views.

• Report Operator profile—This profile allows read access to Operations Manager reports.

Operations Manager also contains five predefined roles, each of which is globally scoped. For example, the Operations Manager Administrator role uses the Administrator profile and is globally scoped, meaning that it can see and manipulate all objects in Operations Manager. There are matching predefined roles for each of the profiles listed above.

In addition to the predefined roles, you can create new roles based on the Advanced Operator, Author, Operator, and Read-Only Operator profiles. When creating a new role, after you have selected the profile that you want to use, you then create the scope of objects that the role will have access to. In this fashion, you can create a role that uses the Operator profile and is scoped only to Microsoft Exchange Servers for your Exchange administrators. When you then assign the Exchange administrators to the role (either by membership in an Active Directory Group or by individual account), they are able to open the Operations console, but they only see the Exchange servers and are allowed to take action only on the Exchange-related Alerts, Views, and Tasks.

Role-based security is applied no matter how you access Operations Manager functionality, whether it is through the Web console or the Command Shell. For more information about roles and role-based security, see the Operations Manager 2007 Security Guide.