I was working with a customer recently and one of the asks was to configure OMS to monitor for stopped automatic services on servers throughout the environment. My first thought was that we could easily use the data collected by the Configuration Tracking solution and configure queries to alert when a service is stopped. Unfortunately, although Configuration Tracking is a great solution, for this purpose it did not meet the requirements due to the 1 hour data collection interval. We needed to be notified of the critical service stopping as close to real-time as possible. Plan B was to utilize Event ID 7024 and custom fields as we were already collecting the Application log. However, during my testing on Windows Server 2012 R2, the only event logged to the Application log when a service was stopped manually was Event ID 1. Further, what if a service just doesn’t start after reboot? Once again, there may be no events logged as technically there could be no error.
SO…although technically both of the other options could work in certain scenarios, in this particular case we needed something a bit more granular. Time for some fun with PowerShell, Azure Automation and the Data Collector API!