Windows Automatic Services Monitoring using SCOM

Monitoring services in windows computers is available out of box in SCOM through Service Monitoring Template. But in a large enterprise with over 1000s of windows computers and 100s of applications, it is difficult to list out all services that needs to be monitored in each computer and create monitoring using template. Consider monitoring on average 30 services in 1000 computers would result on 30,000 instances added to SCOM DB. This will create numerous classes, discoveries and cause bloating of instance space which will make SCOM less responsive.

Also, we cannot create a monitor for each service and target it across all computers as each service may be present on bunch of computers and not on others. Thus targeting unanimously will result in false alarms and again, we may need 30+ windows service monitors targeted to all windows computers which will create overhead on agents and thus on the computers running the agent.

So, What is the solution?

Optimal solution would be creating a single rule to monitor all automatic services in each computer and alert on those which are not running. This can be accomplished using Powershell script with property bag output.

The rule runs on each computer at specific time interval, creates property bags for each service which is set to automatic but not running and an alert is generated for each property bag.

A catch to note in this monitoring scenario is not to alert on services that are stopped only for a moment. To overcome the issue, we will use consolidator condition. So only if the service is failed for ‘n’ consecutive samples, we will alert.

This solution, though optimal pose another challenge – What if we do not want to monitor a service which is set to automatic in one or few of computers.

This can be handled using a centrally located file with details of service and the computers to be excluded from monitoring.

We will see how to construct the Management Pack XML to accomplish this. You can also create MP using Visual Studio, MP Studio or Authoring Console.

Step 1:

Add references to the Management pack.

Step 2:

Now create a Powershell property bag probe script. The Powershell script fetches list for all services that are set to start automatic and checks for the current status. For each service that are set to Automatic but not running, a property bag is created.

To exclude some services from being monitored, a centrally located CSV file is used and the path of file is passed as parameter to the script. The script reads list of services to be excluded from monitoring from CSV file and compares it with the list of services in the target computer. The property bag for excludes services are not created.

Step 3:

Create a data source module incorporating the above written Powershell script. We will use consolidator condition as discussed in solution part to alert only on valid service failures.

Step 4:

Next we will create a rule using the data source. Below configuration needs to be customized according to the need.

ExcludeServiceList – the UNC path for the excluded services list file (in CSV format). Sample CSV provided below.

CSV has two headers- “ServiceToExclude” which is display name of service.

ComputersToExclude – NetBIOS Name of computer. If two or more computers, it can be specified as individual entry or using regular expression syntax. If need to exclude in all computers, the value should be “ALL_Computers”

IntervalSeconds – Polling Interval in Seconds

Count – Number of polls, the service should fail to alert. (Minimum 2)

ConsolidationInterval – The interval time within which the service status fails ‘n’ number of times to generate alert.  (Minimum value = (n-1) * IntervalSeconds where n = count)

Step 5:

Final step is to construct XML for presentation and language packs. Ensure the close the <ManagementPack> tag.

Step 7:

Deploy the MP in lab and check for alerts.



I have attached copy of XML which you can import in to any authoring tool. Customize as per your needs and have fun.

Happy SCOMing…

4 thoughts on “Windows Automatic Services Monitoring using SCOM

  1. curtmcgirt

    Good stuff. Just curious why you chose a rule instead of a monitor. With a monitor you can track health state/availability over time. Also, what if you discovered all instances of automatic services with PowerShell, then you could use scom overrides to disable the monitoring. Having the instances in scom would allow you to target other rules and monitors at the services later if you wanted to. (full disclosure: I do happen to be looking for guidance on authoring a powershell discovery)

  2. Gowdhaman Post author

    I have mentioned the reason for not discovering the services as instances in start of my post. Doing so will impact performance badly. Since we are targeting windows computer instance, a monitor would display either if all automatic services are running or not. But it cannot generate alert for each automatic service which is not  running. We need a rule to do that. Hence we can have a monitor if we need to track availability but not for alerting.

  3. steven123

    i have edit the path as below.


    inside the .csv i have add “Application Experience,ALL_COMPUTERS”

    and monitoring doesn’t seem working when i try manually stop one of the automatic state service.


  4. Pingback: SCOM – Windows Service Monitor Management Pack | Leibundgutski

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.