Triggering Automation from Event Logs with Orchestrator and OMS AzureAutomation

I recently hooked my home lab into Microsoft Operations Management Suite (MSOMS or OMS) and have been dabbling in Azure Automation. I wanted to put together some quick examples of triggering automation through event logs in Orchestrator and compare it to OMS with Azure Automation.

This is not a super technical deep dive of automation, the automation is just a simple PowerShell script that finds all running virtual machines in my lab and puts them in a saved state. The point of the blog is to show how easy it is trigger the automation. What the automation is can be as simple or complicated as you want.

To get started in OMS you can follow this resource.
You’ll also need to setup your Hybrid Worker in Azure Automation.

First we need a log to capture to trigger the automation. Using PowerShell I created a new log called “SCORCHAzure.”

New-Eventlog -LogName SCORCHAzure -Source scripts

And then for generating the log:

Write-EventLog -LogName SCORCHAzure -Source scripts -Message “shutdown lab” -EventId 0 -EntryType information 

In Orchestrator we can use the “Monitor Event Log” activity to get start the automation based on this specific event. Note: I know you can do this and much more through Operations Manager (SCOM) with Orchestrator integration, but that is not the point of this post.

We’ll point to our machine, and when we select the ellipses for event log, our custom event log will be available. Note: the Orchestrator service account needs to have remote access to the machines event log for the activity to work.

Under description I put “lab.” I did this because maybe in the future we can add branch logic where if the event description says “shutdown” it will perform the shutdown, and conversely if the description contains “start” we can start the lab.

Next we have our “automation,” as previously noted this is just a simple example.
Next we’ll need to create our runbook in Azure Automation. In this case I just dropped the exact same PowerShell into the runbook, tested it with the test pane feature and it worked, connected to my HyperV lab and saved all running machines. Save it and publish it, if it is not published you will not see it in OMS.

We also need to capture our custom event log in OMS, under Settings -> Data we add “SCORCHAzure” OMS will now collect the custom event log.

And finally setting up the log search in OMS to trigger the Azure Automation Runbook. This is where OMS log analysis shines. Under log search with the following query:

Type=Event EventLog=”SCORCHAzure” “shutdown lab”

The only caveat here is I couldn’t figure out how to get OMS to read the RenderedDescription field which had “shutdown lab” in it. I was trying queries like:

Type=Event EventLog=”SCORCHAzure” renderedDescription=”shutdown lab”

Which would return no results. Putting just “shutdown lab” found it though.

The best part is there are tons of examples provided so you are not stuck trying to find what you need, you can most likely piece together what you are looking for just from the examples.

To link it to Azure Automation click on Alert and a new fly-out will appear to the right. Set your criteria for how many times this event is generated before taking action. In my case I selected greater than 0 over 15 minutes.

Enable remediation and select our runbook and also select Hybrid Worker since that is what we are testing on. Save it and generate a log and in about 15 minutes the runbook will run.

So, which was easier to setup? Orchestrator without a doubt was easier. However, this is because we had to go through OMS for Azure Automation. If we were using SCOM in conjunction with Orchestrator the setup would be more complicated.

Orchestrator is slightly less complicated if you want to do special logic with the description field. With Azure Automation you have to add a webhook in OMS to parse that data if you want to create logic from it. There’s a good blog here that shows how to do that. Or you have to add a PowerShell module in Azure Automation that will live query OMS for that data.

There are benefits and drawbacks to both automation tools. Running Orhcestrator means you are responsible for your own environment, including the database(s) to run it. Where as with OMS and Azure Automation you don’t have to support the environment, while the free tier provides some options in a bigger environment you will quickly jump out of the free tier.

I think OMS with Azure Automation are definitely something everyone should check out, especially if you are running SCOM.

Orchestrator and Azure Automation are both very powerful tools we should all be using to automate self service tasks, or automate server tasks

2 thoughts on “Triggering Automation from Event Logs with Orchestrator and OMS AzureAutomation”

  1. You've probably figured this out by now, but for the sake of future readers: If a field is grey (like renderedDescription), then it is only available via free text search. It's not indexed in the same way as the facet fields (blue), which can be queried by their exact value, or even within a range.

    You can get around this by extracting a custom field from any free-text field:

    For more on OMS search:

  2. Hey Thanks Camille. I have figured out a way to get greyed out fields and that is by using "| select fieldnamehere"

    I actually have a few blog posts about this coming up, and also presenting on it tomorrow at HASMUG.

Comments are closed.