SCOM Tasks – Part II – How It Works

----------------------------------------------------------------------------------
Postings in the same series:
Part  I  – The Introduction
Part III – To Serve And To Protect
Part IV – Lets Create a Simple Task
----------------------------------------------------------------------------------

With this posting the way Tasks work will be explained.

As described before, there are two different kind of Tasks: Console Tasks and Agent Tasks. The way they operate is also different and important to know.

Console Tasks
These run locally on the system where the Console is being run from and use functionality and/or UI’s which aren’t typically SCOM based like the SQL Management Studio UI for instance. Of course, in order for this to work the required applications/features need to be present on the system. Otherwise these Task will not run. Also the output created by these very same Tasks aren’t piped back into SCOM.

So Console Tasks extend the SCOM interface in such a manner that the SCOM Console becomes a jumping board to other UI’s or functionality which aren’t typically SCOM based.

Another thing to reckon with are the way authorizations are being handled. As stated before the SCOM Console launches another UI and passes on the credentials which were used to start the SCOM Console. Depending on what UI is started, the authorizations set for the account used for launching the SCOM Console and the way security within the other application has been set and configured, additional logon might be required.

Huh? What am I talking about? Let show an example in order to clarify it. Lets say I started the SCOM Console with an account which has no permissions in the SQL environment (systemcenter\test). I am in the Database Engine View of the SQL MP in the Monitoring Pane of the SCOM R2 Console:

and select a server where the SQL Engine has been detected on by the SQL MP. In the Action Pane under SQL DB Engine Tasks part the Console Task SQL Management Studio is being displayed:

When I click this link SQL Management Studio is started but this message is displayed:

So in order to have this UI connect to a certain SQL DB Engine, I need other authorizations since the test account will not do.

Agent Tasks
Where as Console Tasks launch UI’s or functionality which reside outside the SCOM Console and as such the output created afterwards isn’t piped back into SCOM, Agent Tasks launch processes/scripts defined in SCOM (the MPs as such), which output is piped back into SCOM. The strength here is that everything is kept within a single UI, the SCOM Console.  In order for these Tasks to run, credentials are required. By default the credentials used by the SCOM Agent are passed on to that Task. However, one can run Agent Tasks with other credentials as well.

But how does it work exactly? What kind of processes are spawned and where? Let’s take a deeper look into how it works.

For starters, the Health Service process plays a crucial role here (for more detailed information about that process, read this posting of mine). In order to illustrate it, lets run an Agent Task and go through the nuts and bolts as it happens. In this example I run an Agent Task against a test server of mine, the SV02.

I am in the SCOM Console, the Monitoring Pane in the Windows Computer part:

I select the server (SV02) and check the Action Pane. Under the header Windows Computer Tasks there are multiple Tasks available. Among them the Agent Task, Display Local Users.

When I click this link the Run Task screen is displayed:
 

I have highlighted the Task Credentials area since this part plays a very important role in the Agents Tasks. The first option ‘Use the predefined Run As Account’ is always selected by default. Even though it seems self explanatory enough, some extra explanation is needed here because I have noticed that there is some confusion about it.

Why? Many times people tend to think that the Local System account is being used here. But that isn’t the case however. Lets take a few steps back and look at how the SCOM Agent operates.

Normally the SCOM Agent runs under the Local System account. When I say SCOM Agent, I actually mean the related Health Service, which process name is HealthService.exe. Taken from my earlier mentioned blog posting:

Typically – you will see a couple MonitoringHost processes executing under the Default Agent Action Account.  In addition, the 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 by default, the credentials defined in the Run As Profile ‘Default Action Account’ will be used to run the Agent Task when the default option ‘Use the predefined Run As Account’ is chosen and not the Local System account.

However, certain MPs require additional authorizations in order to function (also depending on how tight the security is set in your environment of course). For instance the SQL MP. When this MP is imported, three additional Run As Profiles are added to the list of available Run As Profiles: ‘SQL Server Default Action Account’, ‘SQL Server Discovery Account’ and ‘SQL Server Monitoring Account’.

In this case, when these Profiles do have Run As Accounts configured, an Agent Task based on the SQL MP will use the Run As Account defined in the first Run As Profile, ‘SQL Server Default Action Account’. When this Run As Profile doesn’t have a Run As Account configured, the account defined in the Run As Profile ‘Default Action Account’ will be used instead.

So depending on which MP the Agent Task comes from, the Default Action Account will be used or the Run As Account as defined in the related Run As Profile.

But as you know, you might even choose another set of credentials as well. For this select the option Other in the Run Task screen and type in the required User name, Password and select the Domain where the account resides.

When you hit the Run button, a flow of processes starts. The SCOM Agent is being notified to run a certain Task as defined within the related MP. In order to do this it will spawn an additional MonitoringHost.exe process, using the credentials as selected in the Run Task screen. In this example I have entered the credentials for the Test account in order to make it more visible:

When I check the running MonitoringHost.exe processes on the targeted server BEFORE hitting the RUN button, this is what I see:

Now I hit the RUN button and check the running processes again. Now an additional MonitoringHost.exe process is spawn and as you can see, it runs under the credentials of the test account:

This process runs only a couple of seconds. When the Task is finished the process will be automatically ended. The Task Output is collected and piped back to SCOM:

When an Agent Task is running the Run Task screen can be closed any time. It will not interrupt the Running Task however. Its results are to be found back in the Task Status part of the SCOM Console:

The Details Pane will display the details of the selected Task:

The next posting in this series will be about how to scope the Tasks to the correct group of SCOM Operators.