Crucial OpsMgr Services explained. Part III: The Config Service

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

This service plays a very important role in the OpsMgr environment. First of all, it manages the relationships and topology of the OpsMgr environment (Management Group).

It also takes care of the distribution of the Management Packs to the monitored systems. It delivers the monitoring configuration to every OpsMgr Agent Health Service. When the Config Service sends monitoring configuration it may also include sensitive data, which is stored and maintained by the OpsMgr database. Here SDK comes in to play. The SDK API performs two critical jobs here:

1. It prevents the Config Service from viewing this data
2. It makes sure the data is delivered to the Config Service in an encrypted format (the public key of the target Health Service is being used here)

Now the Config Service  will deliver this information to the Health Service of the OpsMgr Agent.

To put it into plain English, the Config Service becomes a parcel delivery service between the OpsMgr database and the targeted Health Service on a monitored system. Here the Config Service only knows the sender and the receiver. It has no clue what so ever about the contents of this parcel. And when it tries to take a sneak peek, the SDK API is there to give it a smack to its head… :)

The six steps of an monitoring configuration update process:
An update of the monitoring configuration exists essentially out of six steps: (The related events are to be found in the OpsMgr event log of each monitored system (as long as an OpsMgr Agent is in place of course)).

1. The HealthService is being notified by the Config Service that it needs an update:
   EventID 29102, source OpsMgr Config Service:
   
   Basically, the HealthService is told by the Config Service that its configuration is out of date and has to contact the OpsMgr Config Service in order to update/synchronize its configuration data.
   
   
2. The OpsMgr Agent contacts the Config Service in order to request an update package:
   EventID 21024, source OpsMgr Connector:
    
   The update/synchronization process is being prepared.
   
   
3. The Health Service has contacted the Config Service and is receiving the update package:
   EventID 29103, source OpsMgr Config Service:
   
   The OpsMgr Agent kicks in. 
   
   
4. The updated monitoring configuration has been received:
   EventID 21025, source OpsMgr Connector:
    
   
   
5. The secure configuration information has been received:
   EventID 7023, source HealthService:
   
   The sensitive information has been received as well.
   (Between steps 4 & 5 there are multiple EventIDs 7026 to be found. These are about the validation of the RunAs accounts.)
   
   
6. The new monitoring configuration has become active:
   EventID 1210, source HealthService:
   
   The new information has been processed by the Health Service.
   (Between steps 5 & 6 there are multiple EventIDs 7025, EventID 7024  and EventID 7028 to be found. These events are related to the validation/logon of the OpsMgr (RunAs) accounts)

Credits & used sources:
For this posting I have used – besides my personal experience from the field – information from the book SCOM Unleashed and input from Maarten Goet.