Terminology and Concepts
Microsoft has added some terms in Operations Manager 2012 with which you need to become familiar. Before beginning how to deploy and operate OpsMgr, familiarize yourself with the terminology and concepts that define System Center 2012 Operations Manager, discussed in the following sections. Microsoft provides a glossary of terms for System Center 2012 Operations Manager at http://technet.microsoft.com/en-us/library/hh710011.aspx.
AEM: Capturing Application Crash Information
Agentless exception monitoring provides data on application crashes, resulting in information your organization can analyze for patterns. A management server can optionally forward AEM data to Microsoft for analysis rather than having each individual client forward the data.
Operations Manager Agent
An OpsMgr agent is the feature installed on a computer that performs management. Based on the management packs associated with the computer, the agent collects data, compares sampled data to predefined values, creates alerts, and runs responses. Computers can be agent-managed, or agentless. An agentless-monitored computer does not run the OpsMgr agent. The agent feature on a management server (or another OpsMgr agent) gathers data from the agentless managed computer through remote calls to that system.
ACS is a secure and efficient way to gather Security event logs from systems and consolidate them for analysis and reporting. These events are stored in an audit database. Deploying ACS involves ACS forwarders, the ACS collector, and the ACS audit database. The ACS agent is included in the OpsMgr agent deployment.
Post OpsMgr 2007 R2, Microsoft extended ACS to include cross platform support. ACS capabilities are largely unchanged in System Center 2012 Operations Manager. ACS is discussed further in Chapter 10, “Security and Compliance.”
Classes: Templates for Objects
A class is an item that is targeted for all operations. Think of a class as a template defining a set of objects of a certain type and the properties of those objects. Classes can exist in a parent-child relationship where the child class inherits properties from the parent class.
Features Versus Components
Components in OpsMgr 2007 are now called product features, as the previous products in the System Center suite are now components of System Center 2012. As an example, the OpsMgr agent is now a feature, rather than a component.
The gateway server plays two roles in Operations Manager:
- Operations Manager requires mutual authentication between the management server and the agent. A gateway server enables monitoring of computers that lie outside the Kerberos trust boundaries (Kerberos realm) of the management group. When an agent belongs to an untrusted domain, is outside the corporate firewall, in a demilitarized zone (DMZ, also known as a perimeter network), or in a workgroup, it is not able to use mutual authentication as a secure channel to communicate with a management server. Gateway servers use certificates to communicate with those agents that cannot otherwise communicate with a management server. The gateway acts as a proxy server to take data from these agents and forward it to a management server inside the firewall.
- An additional use of gateway servers is their implementation in distributed environments where remote sites are located at the end of a long-distance wide area network (WAN) link. The gateway server aggregates communications from agents and minimizes traffic between the remote site and a management server. The data transmitted between the agent and a management server (or gateway server) is both encrypted and compressed. By compressing at the gateway before sending it across the WAN, you can take advantage of a compression ratio ranging from approximately 4:1 to 6:1. More information on using gateways is in Chapter 4.
Heartbeats: Checking the Health of the Agent
A heartbeat is a message sent by an agent to its management server that tells the management server the agent is functioning. The heartbeat also informs Operations Manager of the current rules evaluated by the agent and requests updates if necessary.
A management group is the basic functional unit of an Operations Manager implementation that can perform monitoring. It must contain a SQL Server database server, one or more management servers, one or more Operations consoles, and one or more agents. It can also contain a SQL Server reporting server, a gateway server, and an ACS server and database.
The heart of Operations Manager is its management packs, which are collections of objects including monitors, rules, alerts, performance events, and reports for a specific application or product feature set. Management packs use XML. Management packs are the brains of Operations Manager; they provide the logic and reports used for monitoring.
Management servers are those components of an Operations Manager management group that are responsible for communication with agents, databases, and the consoles. Each management group must have at least one management server, which is installed during OpsMgr setup.
Models are software representations of hardware, software, services, and other logical components that are in your environment. The model captures the nature of those components and the relationships between them.
A resource pool is a collection of management or gateway servers that automatically distribute Operations Manager workflows between the management servers in that collection. If one or more servers in the pool become unavailable, the workflows are automatically redistributed.
The RMS emulator is a management server designated to run management pack functions specifically targeted to the Root Management Server class. These tend to be older (legacy) management packs, as newer management packs do not target this class. The RMS emulator role was created to not break existing management packs that specifically target the RMS. Here are two articles with additional information:
Run As Account
This is a Windows account that can be associated with a Run As profile, and can use Windows Authentication, NTLM, Basic, Digest, Simple, or Binary methods of authentication.
Run As Profile
A Run As profile is a profile that associates a credential with a workflow so it can run using those credentials.
When a workflow requires credentials that cannot be provided by the default action account, it can be written to use a Run As profile. The Run As profile can have multiple Run As accounts associated with it, each specifying the necessary credentials for specific computers. Multiple workflows can use the same Run As profile, as shown in Figure 2.10.
Figure 2.10. Using a Run As profile.
A user role is a combination of a profile that combines actions users can take (such as an OpsMgr Administrator or OpsMgr Operator) and a scope, which are the objects the users can take those actions on, such as all SQL Servers. A user role is also a security boundary. The OpsMgr administrator can utilize user roles to control access to views and tasks to those OpsMgr users assigned to that role.