Wednesday, September 30, 2009

Crucial OpsMgr Services explained. Part IV: The Health Service

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: The Basics.
Part  II: The SDK Service
Part III: The Config Service
---------------------------------------------------------------------------------

Meet the workhorse of OpsMgr!
image

Where the other two services (Config & SDK) are only to be found on the OpsMgr Management Servers, this service is not only to be found there, but also on any monitored server/workstation where an OpsMgr Agent is installed. And, last but not least, this service also runs on an OpsMgr Gateway Server. This last one can be looked upon as a ‘super’ OpsMgr Agent.

Ok, let’s continue. What does the Health Service do? It is commonly known as the Workflow Engine. It provides the means for running/executing the monitoring modules. These can be chained together in different ways (AKA workflows), thus enabling end-to end monitoring scenario’s.

The Health Service comes into two shapes, even though it is still the same service:

  1. Agent Health Service
    Runs on monitored servers/workstations where an OpsMgr Agent is installed. It collects performance data, executes tasks and so on. Even when it is disconnected from the Management Server where it reports to, it continues to run. It queues the collected data and events on the disk of the monitored server/workstation. When the connection is restored it sends it collected data and events to the Management Server.

  2. Management Server Health Service
    Runs on a (Root) Management Server. Its functionality varies, based on the setup of the Management Group and the imported MPs.

But that is not all. The Health Service has also two other features which are good to be known as well:

  1. Extensibility
    When additional MPs are loaded with new functionality, the Health Service can be extended in order to support this new functionality.

  2. Credential Management
    For other OpsMgr processes it provides this functionality, so modules can be run/executed with a different set of credentials. How this is done? Well, hold on to your seats and fasten your seatbelts. :)

    The HealthService initiates the process MonitoringHost.exe. The HealthService can spawn multiple MonitoringHost.exe processes… as needed.  Typically – you will see a couple MonitoringHost processes executing under the Default Agent Action Account.  In addition, HealthService will launch MonitoringHost processes under any preconfigured Run-As accounts that are executing workflows on the agents, using those credentials. Thus ‘giving’ the HealthService the credential management capability to support the execution of modules running as different users. 

So when you look at the running processes on an OpsMgr Agent managed server/workstation you’ll see the process HealthService.exe and multiple processes MonitoringHost.exe, running under different credentials.

To be even more precise, the process MonitoringHost.exe is the real workhorse here, since it performs all these tasks:

  • Monitoring and collecting Windows event log data
  • Monitoring and collecting Windows performance counter data
  • Monitoring and collecting Windows Management Instrumentation (WMI) data
  • Running actions such as scripts or batches

As you can see, there is more then meets the eye. I hope this series cleared things up a bit about the OpsMgr services. Of course there is ACS (Audit Collection Services) as well which consist out the ACS Forwarder service and the ACS Collector service, but ACS is something different. Even though it needs OpsMgr as a basis, it performs a total different job (Audit collection).

Credits & used sources:
For this posting I have used – besides my personal experience from the field – SCOM Unleashed, the OpsMgr Security Guide and input from Kevin Holman.

No comments: