Re: Scom 2012 Sp1 Agent Download
Hercules Montero
In System Center Operations Manager, an agent is a service that is installed on a computer that looks for configuration data and proactively collects information for analysis and reporting, measures the health state of monitored objects like a SQL database or logical disk, and executes tasks on demand by an operator or in response to a condition. It allows Operations Manager to monitor Windows, Linux, and UNIX operating systems and the components of an IT service installed on them like a website or an Active Directory domain controller.
On a monitored Windows computer, the Operations Manager agent is listed as the Microsoft Monitoring Agent (MMA) service. The Microsoft Monitoring Agent service collects event and performance data, executes tasks, and other workflows defined in a management pack. Even when the service is unable to communicate with the management server it reports to, the service continues to run and queues the collected data and events on the disk of the monitored computer. When the connection is restored, the Microsoft Monitoring Agent service sends collected data and events to the management server.
The Operations Manager agent sends alert and discovery data to its assigned primary management server, which writes the data to the operational database. The agent also sends events, performance, and state data to the primary management server for that agent, which writes the data to the operational and data warehouse databases simultaneously.
The agent sends data according to the schedule parameters for each rule and monitor. For optimized collection rules, data is only transmitted if a sample of a counter differs from the previous sample by a specified tolerance, such as 10%. This helps reduce network traffic and the volume of data stored in the operational database.
Additionally, all agents send a packet of data, called a heartbeat, to the management server on a regular schedule, by default every 60 seconds. The purpose of the heartbeat is to validate the availability of the agent and communication between the agent and the management server. For more information on heartbeats, see How Heartbeats Work in Operations Manager.
For each agent, Operations Manager runs a health service watcher, which monitors the state of the remote Health Service from the perspective of the management server. The agent communicates with a management server over TCP port 5723.
The architecture of the UNIX and Linux agent differs from a Windows agent significantly. The Windows agent has a Health Service responsible for evaluating the health of the monitored computer. The UNIX and Linux Agent doesn't run a health service; instead it passes information to the Health Service on a management server to be evaluated. The management server runs all of the workflows to monitor operating system health defined in our implementation of the UNIX and Linux management packs:
The UNIX and Linux agents for Operations Manager consist of a CIM Object Manager (that is, CIM Server), and a set of CIM Providers. The CIM Object Manager is the server component that implements the WS-Management communication, authentication, authorization, and dispatch of requests to the providers. The providers are the key to the CIM implementation in the agent, defining the CIM classes and properties, interfacing with the kernel APIs to retrieve raw data, formatting the data (for example, calculating deltas and averages), and servicing the requests dispatched from the CIM Object Manager. From System Center Operations Manager 2007 R2 through System Center 2012 SP1, the CIM Object Manager used in the Operations Manager UNIX and Linux agents is the OpenPegasus server. The providers used to collect and report monitoring data are developed by Microsoft, and open-sourced at CodePlex.com.
Communication between the management server and the UNIX and Linux agent is split into two categories: agent maintenance and health monitoring. The management server uses two protocols to communicate with the UNIX or Linux computer:
Communication between the Operations Manager management server and UNIX and Linux agent uses WS-Man over HTTPS and the WinRM interface. All agent maintenance tasks are performed over SSH on port 22. All health monitoring is performed over WS-MAN on port 1270. The management server requests performance and configuration data via WS-MAN before evaluating the data to provide health status. All actions, such as agent maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined profiles according to their requirement for an unprivileged or privileged account.
In Operations Manager, the system administrator is no longer required to provide the root password of the UNIX or Linux computer to the management server. Now by elevation, an unprivileged account can assume the identity of a privileged account on the UNIX or Linux computer. The elevation process is performed by the UNIX su (superuser) and sudo programs that use the credentials that the management server supplies. For privileged agent maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstallation, and agent recovery), support for su, sudo elevation, and support for SSH key authentication (with or without passphrase) is provided. For privileged WS-Management operations (such as viewing secure log files), support for sudo elevation (without password) is added.
Gateway servers are used to enable agent-management of computers that are outside the Kerberos trust boundary of a management group. Because the gateway server resides in a domain that isn't trusted by the domain that the management group is in, certificates must be used to establish each computer's identity, agent, gateway server, and management server. This arrangement satisfies the requirement of Operations Manager for mutual authentication.
This requires you to request certificates for each agent that will report to a gateway server and import those certificates into the target computer using the MOMCertImport.exe tool, which is located on the installation media SupportTools\ (amd64 or x86) directory. You need to have access to a certification authority (CA), which can be a public CA such as VeriSign, or you can use Microsoft Certificate Services.
Agents that are installed using the Discovery Wizard can be managed from the Operations console, such as updating agent versions, applying patches, and configuring the management server that the agent reports to.
When you install the agent using a manual method, updates to the agent must also be performed manually. You'll be able to use Active Directory integration to assign agents to management groups. For more information, see Integrating Active Directory and Operations Manager.
The protocol that is used depends on the action or information that is requested on the management server. All actions, such as agent maintenance, monitors, rules, tasks, and recoveries, are configured to use predefined profiles according to their requirement for an unprivileged or privileged account.
By elevation, an unprivileged account can assume the identity of a privileged account on the UNIX or Linux computer. The elevation process is performed by the UNIX su (superuser) and sudo programs that use the credentials that the management server supplies. For privileged agent maintenance operations that use SSH (such as discovery, deployment, upgrades, uninstallation, and agent recovery), support for su, sudo elevation, and SSH key authentication (with or without passphrase) is provided. For privileged WS-Management operations (such as viewing secure log files), support for sudo elevation (without password) is supported.
System Center Operations Manager allows you to take advantage of your investment in Active Directory Domain Services (AD DS) by enabling you to use it to assign agent-managed computers to management groups. This feature is commonly used with the agent deployed as part of a server deployment build process. When the computer comes online for the first time, the Operations Manager agent queries Active Directory for its primary and failover management server assignment and automatically starts monitoring the computer.
This feature works well for controlling agent assignment in a distributed management group deployment, to prevent agents from reporting to management servers that are dedicated to resource pools or management servers in a secondary data center in a warm-standby configuration to prevent agent failover during normal operation.
Configuration of agent assignment is managed by an Operations Manager administrator using the Agent Assignment and Failover Wizard to assign computers to a primary management server and secondary management server.
Active Directory Integration is disabled for agents that were installed from the Operations console. By default, Active Directory Integration is enabled for agents installed manually using MOMAgent.msi.
To understand how to install the Windows agent from the Operations console, see Install Agent on Windows Using the Discovery Wizard or to install the agent from the command line, see Install Windows Agent Manually Using MOMAgent.msi.
To learn how to create the container in Active Directory, configure agent failover assignment, and manage the configuration, review How to configure and use Active Directory Integration for agent assignment.
If you need to check that SCOM agent is installed on this machine (which literally means that this machine is monitored by SCOM) - it's enough to check that the following Windows service is installed: - HealthService (it's display name different for different versions of SCOM and might be a "Microsoft Monitoring Agent" or "System Center Management ")
So my enterprise as a mixture of manually installed and operations manger installed agent. I don't understand why there are any manually installed agents (outside of our DCs) and see no benefit to the practice. I have three questions here really.
aa06259810