Monitoring Windows Services States is one of the most common requests that I’ve seen on forums, groups and blog posts. My fellow MVP and OMS expert Stefan Roth wrote a similar blog post titled OMS – Monitor Windows Services / Processes. I would suggest to check it out as well. The approach I will show is somehow already cover in official article that demonstrates custom fields in Log Analytics. The difference is that we now have the new rich Log Analytics search syntax so we do not need custom fields anymore. This approach also is different from Stefan’s as his one covers wider topic with monitoring processes by using performance counters. In this approach we will use windows events which Stefan mentions that is not reliable but he was referring to specific Event Id which I also agree it is not reliable. In the next steps I will use another Event Id that is reliable 100%. The advantage of using windows events for monitoring windows services states are:
- Only windows events are gathered which results in less data uploaded compared to performance data
-
You do not have to add performance counter for each process, you just need to add only one event log to monitor all services
-
The services are shown with their actual name that is used in services.msc or Get-Service cmdlet.
-
We have the actual state of the service when it happened
Some of the disadvantages of this method are:
- Until the service is started or stopped it will take at least 5 minutes until the data appears in Log Analytics
Continue reading “Monitoring Windows Services States with Log Analytics”
. Back to the topic. While there are scenarios in which you can think of OMS like it is SCOM in many ways you should not and there is reason for that. I will try with this blog post to explain why and answer the above question. We can summarize the differences between Operations Management Suite and SCOM in the following statements: 
Cloud Administrator in Azure World 