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. https://automys.com/blog/post/azure-automation-hybrid-runbook-workers-look
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.
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.