If you havent heard about it, the future of automation is here!

In the form of  “Azure Automation”. also known as “OMS Automation” when it is part of the Operational Management Suite (OMS).

This cloud service can control our automation, just as System center Orchestrator has done for years.

It works in a very similar way, but has been extended to support more features, for instance it supports what is known as Webhooks.

A webhook enables us to trigger a runbook using a standard HTTP call, making it easier to integrate from other tools (could for instance be used from SharePoint (See my other blog post)

but we can also use it together with SCOM as a recovery action!

This means we can easily, without any special PowerShell modules, start a runbook and send information about the event to the input of the runbook.

Inside the runbook we can utilize these inputs as mentioned in this blog post


Here is how to add it to a Monitor in SCOM:

In my little example, I am triggering a runbook to extend the drive capacity whenever a disk runs out of space. I have demoed this before using SMA and Azure Automation PowerShell Module (See this video)

Create Runbook and Webhook

1. Identify the runbook that you want to trigger as part of the Recovery Action.

NB!  In this example I want to use the Expand-VMDrive runbook to fix the problem. That runbook does not support the input from a webhook. Therefore I create another runbook called Expand-VMDriveRequest (I always just add the Request in the end of the name). to handle the inputs and call the other runbook. See the runbook content in the end of this article)


2. On the runbook blade click Webhooks


3. Click Add Webhook


4. Click Create New Webhook


5. Give it a name and set a expiration date (maximum is 10 years in the future)


6. Copy the URL! Important. Since you cannot see it once the webhook is saved

7. Configure parameters and runbook setting. In this case we can to keep the webhook data parameter empty, but I want this to run in my data center in denmark, since this is where my SCOM environment lives.


8. Click OK, then Create to save the webhook.

Now we are ready to implement this into a recovery action

Implement a webhook as a recovery action in SCOM


1. In the SCOM Console, open the properties of the monitor or rule and switch to the Diagnostic and Recovery pane


2. Click Add and select Recovery for critical health state

3. Name the action and make sure the Run recovery automatically is ticked(we want to enable it later with override)


4. Insert full path to powershell


5. Insert this parameter string (sorry about the line breaks, use the view source button to see the code)

-executionpolicy Unrestricted -Command " &{Invoke-RestMethod -Method Post -Uri 'https://s2events.azure-automation.net/webhooks?token=xxxxMk5PD5SKJuB47U%2b5gzFgXBxaK6%2fXM702cN4%3d' -Body (ConvertTo-Json -InputObject @{'ComputerName'='TEST01';'DriveLetter'='C:'}) -ErrorAction Stop}"

6. Use the GUI to replace ComputerName (TEST01) and DriveLetter (C:) Values


7. The finished command parameter value looks like this (sorry about the line breaks, use the view source button to see the code):

-executionpolicy Unrestricted -Command " &{Invoke-RestMethod -Method Post -Uri 'https://s2events.azure-automation.net/webhooks?token=xxxxomMk5PD5SKJuB47U%2b5gzFgXBxaK6%2fXM702cN4%3d' -Body (ConvertTo-Json -InputObject @{'ComputerName'='$Target/Host/Property[Type="MicrosoftWindowsLibrary7585010!Microsoft.Windows.Computer"]/DNSName$';'DriveLetter'='$Target/Property[Type="System!System.Entity"]/DisplayName$'}) -ErrorAction Stop}"

8. Click OK to save the recovery action


9. Make sure that the recovery is disabled on all objects of the class if you do not want all machine to trigger the runbook.



10. Now set one or more overrides to enable the webhook on the specific objects that you want (in my example I only want to enable the recovery action for a specific drive on a test server).




Now trigger the alert to test the recovery action.

you can check the state changes in the health explorer to see any errors.

Your output should look like this, which includes a job ID.


Go to azure automation to check the job:


Here you can see the inputs and outputs and make sure that everything was triggered correctly:



Here is the content of the runbook that receives the information from SCOM

workflow Expand-VMDriveRequest
    param ([object]$WebHookData)
	$WebhookName    =   $WebhookData.WebhookName
    $WebhookHeaders =   $WebhookData.RequestHeader
    $WebhookBody    =   $WebhookData.RequestBody
	$Inputs = ConvertFrom-JSON $webhookdata.RequestBody
	$ComputerName = $Inputs.ComputerName
	$DriveLetter = $Inputs.DriveLetter

	#Expand-VMDrive -ComputerName $ComputerName -DriveLetter $DriveLetter
	Write-output "ComputerName: $ComputerName - Drive: $DriveLetter"