The System Center Platform in Service Manager Part 5: The Management Configuration Service
This post is a continuation in the series which describes the System Center common platform components implemented in Service Manager. Previous posts:
The System Center Platform in Service Manager Part 1: Introduction
The System Center Platform in Service Manager Part 2: The Model-Based Database
The System Center Platform in Service Manager Part 2: The Model-Based Database - Try It!
The System Center Platform in Service Manager Part 3: The System Center Data Access Service
The System Center Platform in Service Manager Part 3: The System Center Data Access Service - T...
The System Center Platform in Service Manager Part 4: The System Center Management Service
The System Center Platform in Service Manager Part 4: The System Center Management Service – Tr...
Last time we talked about the System Center Management service. Next up is the System Center Management Configuration service. Obviously these two services are related so we’ll get into some details on that in this post. Since the names are so similar for the rest of this post I’ll refer to the System Center Management Configuration service as the “configuration service” and we’ll drop the System Center in front of the names for brevity.
The Configuration service has a relatively straightforward purpose – to provide configuration to the Management service. In other words, the Management Configuration service is the boss of Management service. It tells the Management service what to do, when to do it, where to do it, and how to do it.
What to Do
The instructions the Configuration service provide to the Management service are in the form of what we generically call “workflows”. These workflows can be Rules, Tasks, Monitors (not applicable to Service Manager), or Discoveries. Each of these workflows is comprised of series of reusable modules which can be combined together to form different workflows.
The most common kind of workflow in Service Manager is a Rule. Connectors, process workflows, and other automated portions of the common platform such as the MP Sync process between Service Manager and the Data Warehouse are all implemented as Rules. For those of you experienced with Operations Manager or System Center Essentials, this will all be familiar. It’s all the same infrastructure.
Where to Do It
Each workflow in the system has a “Target” class which indicates where the workflow should run. In Operations Manager, a Rule could be targeted at something like the ‘SQL Server Database’ class. This would mean that the Rule would run once for each discovered database. For example, if an Operations Manager agent discovered 3 databases on the computer on which it was installed, three instances of the Rule targeted at the ‘SQL Server Database’ class would be running.
In Service Manager, we don’t have a distributed topology of Management services like Operations Manager does. All of the workflows in Service Manager run only on a single Service Manager Management Server at a time which makes the targeting much more straightforward. Generally speaking, all workflows in Service Manager should target the Microsoft.SystemCenter.WorkflowTarget class or a class that derives from that one. There are a few other special classes which are used for internal system targeting, but all other workflows targeted at other classes are not allowed to run in Service Manager. This prevents workflows defined in monitoring MPs intended for Operations Manager from running inadvertently on the Service Manager server.
In Beta 2 of Service Manager we will be introducing the concept of multiple Management Servers which will each have a Configuration Service and a Management Service. When we release Beta 2, I’ll come back to this post and update it with more information about how targeting works when multiple management servers are involved.
How to Do It
Each workflow has a section in its definition called “Configuration” which is essentially input parameters to the workflow that tell the workflow how to do what it is supposed to do. For example, a Rule may be defined to connect to Configuration Manager to collect inventory and synchronize it with the Service Manager database. This Rule has input configuration which describes what the Configuration Manager database server name and database name are and what credentials can be used to connect to the database.
The Configuration service tells the Management service what the configuration of the Rule should be. In the case of Operations Manager, the Configuration service also takes configuration Overrides into consideration. Let’s take our example above with the Rule targeted at the ‘SQL Server Database’ class. Let’s say you don’t want this Rule to run for a couple of the databases out there or all the databases in a specific group. You can define a disable Override which disables this rule just for those databases. The Configuration service calculates the resulting set of configuration by applying the Overrides on top of the original configuration. In Service Manager, there isn’t really a use for Overrides so I won’t go into much more detail on those here.
When to Do It
The Configuration service also tells the Management service when to do something. In the case of Rules, the information about when to run a rule is usually provided as part of the Configuration. For example, the Rule configuration might say to run the Rule every Monday at 2:00 in the morning. In this case the Configuration service simply hands the Rule to the Management service and says run this continuously according to the schedule configuration provided in the rule.
Tasks are typically initiated by the user on demand from the console, so the Configuration service will hand the Task workflow to the Management service along with the configuration for running the task that particular time and say “Do it now!”
Summary
The Configuration service in Service Manager is extremely important to the functioning of Service Manager, but it is also something you should never need to worry about. You don’t need to configure it, back it up, or otherwise maintain it. It should always be running, but other than that you shouldn’t need to think twice about it. Just think of it as the boss of the Management service.
Here is a new version of the Architecture diagram with the Management Configuration Service in place (click to view full size).
