Crucial OpsMgr Services explained. Part I: The Basics

--------------------------------------------------------------------------------- 
Postings in the same series:
Part  II: The SDK Service
Part III: The Config Service
Part IV: The Health Service
---------------------------------------------------------------------------------

On many occasions I do get questions about the OpsMgr specific services, like:

• What are they and what are their purposes?
• Why are certain services only available on OpsMgr Management Servers and not on Agent Managed servers?
• Why are certain OpsMgr services disabled on Management Servers but enabled on the Root Management Server?

Since there is much to tell and I strive for readable blog postings I have decided to launch a new series in order to cover this topic. At the moment I do not know exactly how many postings this series will contain, but lets start with Part I: The Basics and see how it goes from there.

As one has noticed, every OpsMgr Management Server has three OpsMgr Services: (Blue: RTM/SP1 name of service, Red: R2 name of service. Check out this posting)

1. OpsMgr SDK Service / System Center Data Access
2. OpsMgr Health Service / System Center Management
3. OpsMgr Config Service / System Center Management Configuration

An OpsMgr managed server (a server which runs the OpsMgr Agent) runs only the second service, OpsMgr Health Service / System Center Management.

As expected, every service has is own purpose. Also when checking a Management Server (not the Root Management Server!) one will notice that only the second service is running and the other two (SDK & Config) are disabled. This is by design and shouldn’t be altered.

1. Question: Why does a Root Management Server runs all three services?
   One can look upon the OpsMgr hierarchy as Windows NT4. Here one had a Primary Domain Controller (PDC) with a writable SAM and some or many Backup Domain Controllers (BDCs) with a read-only copy of the SAM. And no matter from what location the User Manager or Server Manager was being run, it always connected to the PDC since that server contained the only writable SAM. Any adjustment was done there and then replicated to the BDCs. 
   
   The RMS is just the PDC of OpsMgr and the Management Servers are the BDCs. So the RMS maintains the OpsMgr Management Group in every kind of way. Importing MPs? Done there. Adjusting MPs? Done there. (Web) Console connections? Authorizations? Notifications? Setting permissions? Scoping Views? Deleting objects? Setting Overrides? Yep! The RMS does it all. All changes are being put into the OpsMgr related DBs and replicated to the Management Servers (Better: The Management Servers are notified by the RMS things have changed so they have to update their configuration.)
   
   This makes the RMS a rather busy fellow. It has a lot of work to process.
   
   In order to do that, it needs all three OpsMgr Services to be in a running state. This also explains why enabling these three services on a Management Server is the recipe for disaster: the OpsMgr Management Group doesn’t know any more who the ‘leader’ is and ends up in a situation to be compared with one which is known in the Cluster world as a ‘Split-Brain’ scenario. Isn’t nice either….
   
   Only when a Management Server must be promoted to Root Management Server, these services need to be started and set to automatically. But that is another story.
   
   
2. Question: Doesn’t that make the RMS vulnerable?
   Hmmm. Yes. It does. Therefore in environments where Enterprise Monitoring is crucial, a Clustered RMS is advised. Personally I have some doubts about the mechanism behind Clustering but that is another discussion. But indeed, the RMS introduces a SPOF (Single Point Of Failure).
   
   On System Center Central there was a very interesting discussion going on about the new version of OpsMgr to be released in 201x. One (or more) person(s) raised the idea to distribute the RMS roles and thus leverage it to the Windows Domain Controllers as we do know them now. That is really a good idea. Lets hope it is being picked up.
   
   
3. Question: What about the specifics of these OpsMgr Services?
   Good question. I will describe every service in a separate blog posting. The blog postings in this series will look like this: 
   - Crucial OpsMgr Services explained. Part II: The SDK Service.
   - Crucial OpsMgr Services explained. Part III: The Config Service.
   - Crucial OpsMgr Services explained. Part IV: The Health Service.

And perhaps some other postings on this topic as well, based on the feedback I do get.