OMS/Azure Automation Example – Part 1 – Custom Fields

The Scenario:

We are monitoring multiple servers using Operations Management Suite (OMS). We are very concerned about the Print Spooler service on our servers (because who isn’t worried about the Print Spooler service Winking smile ). We want to configure OMS to throw an alert whenever the Print Spooler service stops on a server, and then create an Azure Automation runbook to attempt to restart the service automatically for us.

We will break the solution into multiple steps:

  • Create custom fields in Log Analytics to hold Service Name and Service State
  • Create an alert that triggers whenever the Print Spooler enters a “stopped” state
  • Create an Azure Automation runbook that triggers a PowerShell script running on a Hybrid Worker role on premises, to try and restart the service

In this blog post we will look at how to create the custom fields we need.

Whenever a service is stopped in Windows, it generates an event ID of 7036. The following query will return all the events matching this event ID from Log Analytics:

Type=Event EventLog=System EventID=7036


We can see that the ParameterXML and the EventData fields have the service name in them, as well as the service status.  In this case, the service name is “Update Orchestrator Service for Windows Update” and the status is “stopped”. But these fields, the Service Name and the Service Status, are not located in their own fields in the returned event data. This can make it very difficult to query and alert on.  However, OMS provides us the ability to extract information from log analytics data into its own custom field.

Click the ellipse next to the  EventData field and select Extract fields from Event (Preview):



Highlight the Service Name the EventData field, and enter a name for the custom field. Notice that OMS automatically puts a _CF on the end of the field name (for “Custom Field”).



In the Filter column, select SourceSystem, Source, and EventLevelName, to help with making sure we filter to the correct events. We will see some examples of the search results, and if everything looks good, we can click the Save Extraction button to save this custom field.  Then repeat these same steps to create a custom field called WindowsServiceState_CF for the state of the service.

Now, if we return to Log Analytics, and run the original query, we can see that we have two new fields:



And we can use those fields in our queries.  For example, here is a similar query that shows me just the events for stopped Print Spooler services:

Type=Event WindowsServiceState_CF=stopped WindowsServiceName_CF=”Print Spooler”





In the next post, you’ll see how to take this query and generate Alerts.

  • Add Your Comment