Skip to content
adatum
  •  SCOM Web API
  • About adatum
Automation

Using webhook in scom subscription (POC)

  • 09/09/201611/09/2016
  • by Martin Ehrnst

Recently, I was at System Center Universe (Now, Experts Live) in Berlin. During one side session i got talk to Cameron Fuller (Microsoft MVP) and I asked if he knew if anybody had used azure automation and it’s webhook capabilites in a SCOM subscription.

At Intility (my employer) we have developed an alert central which handles alerts from Solarwinds and other systems we use daily. OpsMgr is one of few systems that still tap directly in to our ticketing system, but were working on a change here. Webhooks and azure automation is one thing were looking at.

My attempt (if possible), using webhooks and Azure automation is to be able to send alerts from SCOM, and not have something query for new alerts when there nothing to handle. Cameron quickly reached out to his fellow MVPs and a few ours later i got a reply. Turns out that Jakob Gottlieb Svendsen (MVP) from Coretech had used webhooks in a recovery task. He basicly done all the work now :).

http://blog.coretech.dk/jgs/azure-automation-scom-triggering-a-runbook-as-a-recovery-task-using-webhooks/ (read this :))

The rest of this post will quickly show how to.

 

  • Create azure automation account
  • Create a new runbook
  • Add webhook
  • Runbook parameter
  • SCOM Command Channel and subscription

 

Azure Automation Account

 

Search for automation accounts in services and add a new Automation account. Use an existing resource group or create a new. After wizard is finished we should have an account assigned to a subscription.

automationaccount

 

By now you have probably read Jakobs blog and you have a new runbook in place, but i will guide you through anyway 🙂

Create a new runbook and use “Powershell workflow”. Once finished you will be sent to the online editor which is fine for now, but i suggest you download azure automation addon for ISE if you plan to do a lot of scripting here 🙂

Azure Automation PS worflow will start like this. If you add script parameter and publish where able to create a webhook. Place your normal PS script between the two curly brackets.

workflow 'your runbook name'

{

Param [object]($WebhookData)

}

I have adde the parameter already, that way we are able to create webhook an parameter at the next step.

Next task is to create a webhook for your runbook. With a webhook you are able to call the runbook with a URL and also pass parameters with JSON data inside the url. (Heres where the parameter for your webhook and script comes in)

Remember, copy your webhook URL – it’s not available after it is created

webhook1

 

After youre ‘hooked’ add paramters and define where to run. For this test i just fire it off in azure, but you can run your script on prem with the hybrid worker. Use your script parameter in the webhook data input.

webhook

You have probably added your own script inside the Azure workflow already, but here is my OpsMgrAlertHandlerTEST script which is based on Jakobs example and will output some key alert datato the console. Instead of just output it to the console i can now pass this information to our alert central by triggering a new runbook or adding it directly within this script.

 

workflow OpsMgrAlertHandlerTEST

{

param (

[object]$WebhookData

)



    $WebhookName    =   $WebhookData.WebhookName

    $WebhookHeaders =   $WebhookData.RequestHeader

    $WebhookBody    =   $WebhookData.RequestBody



    $Inputs = ConvertFrom-JSON $webhookdata.RequestBody

    $ComputerName = $Inputs.ComputerName

$AlertName = $Inputs.Alert

$ResolutionState = $Inputs.State

$AlertID = $Inputs.AlertID



    Write-Output "Computername: $ComputerName"

Write-Output "Alert: $AlertName"

Write-Output "State: $ResolutionState"

Write-Output "ID: $AlertID"

Write-Output "$Inputs"

}

 

From scom we will use powershell to POST alert data with invoke-restmethod and the URL you copied from the webhook configuration, right?

Again Jakob is apparently our JSON webhook guy http://blog.coretech.dk/jgs/azure-automation-using-webhooks-part-1-input-data/

SCOM Command Channel and subscription

 

Our final step is to create a command channel, subscriber and a subscription to trigger the runbook. From the admin panel in scom create a new command notification channel

channel1

In settings we will add path to Powershell and a command to run. Remember. Webhook url and the parameters to POST

channel2

Here is my full commandline (i have removed my webhook uri here)

-executionpolicy Unrestricted -Command " &{Invoke-RestMethod -Method Post -Uri 'YOUR WEBHOOK URL' -Body (ConvertTo-Json -InputObject @{'ComputerName'='$Data[Default='Not Present']/Context/DataItem/ManagedEntityPath$\$Data[Default='Not Present']/Context/DataItem/ManagedEntityDisplayName$';'Alert'='$Data[Default='Not Present']/Context/DataItem/AlertName$';'State'='$Data[Default='Not Present']/Context/DataItem/ResolutionStateName$';'AlertID'='$Data/Context/DataItem/AlertId$'}) -ErrorAction Stop}"

Inside the JSON string we will pass Computer Name, Alert name and the resolution state. Modify this by using the picker on the right side. After you have created the channel, create a new subscriber to use with this channel and finally create the actual subscription

For this test/POC i have chosen to send all information alerts to this subscription. These are mostly rules i can close (and generate) during testing.

Subscriber and channel are the two we just created.

subscription

 

At this point you should have:

  • Azure automation account
  • Automation runbook, my example or your own
  • Web hook enabled
  • Command channel
  • Subscriber and subscription

 

Finally, lets test our solution. I have added all informational messages to this subscription. I will close one of those and cross my fingers. We can follow the process in azure portal

closealert


As you see the job is queued and in the output console we see the output from our webhook data
automationoutputwait

 

It worked!

automationoutput

 

 

As this is totally in  a proof of concept state for us i would greatly apriciate inputs on how we can accomplish the task using other methods.

As we see, using webhooks in a subscription works quite well. But i havent implemented it in our production environment or sent it to our alert central yet. I see some issues, one being limited by how many powershell scripts we can run at once. Jakob suggested maybe we will look in to creating a connector and let us query a subscription for new alerts but i haven’t gotten around to try it out.

 

Share this:

  • LinkedIn
  • Twitter

Top Posts & Pages

  • Azure AD authentication in Azure Functions
  • Access to Blob storage using Managed Identity in Logic Apps - by Nadeem Ahamed
  • Creating Azure AD Application using Powershell
  • Multi subscription deployment with DevOps and Azure Lighthouse
  • Using Azure pipelines to deploy ARM templates
  • Working with Azure Monitor Rest API
  • SCOMpercentageCPUTimeCounter cause CPU Spike
  • Resource health through Azure Rest API
  • SCOM Alerts to Microsoft Teams and Mattermost
  • Web API for System Center Operations Manager

Tags

agent announcements api ARM authoring Automation Azure AzureAD AzureCloudShell AzureFunctions AzureLighthouse AzureMonitor AzureSpringClean Bicep Community CSP database EventGrid ExpertsLive ExpertsLiveEU IaC Infrastructure as code Integrations LogAnalytics management pack monitoring MSIgnite MSIgnite2017 MSOMS MSP nicconf OperationsManager OpsMgr Powershell QUickPublish rest SCDPM SCOM SCOM2016 SCVMM Serverless SquaredUP SysCtr system center Webasto

Follow Martin Ehrnst

  • Twitter
  • LinkedIn

RSS Feed RSS - Posts

RSS Feed RSS - Comments

Microsoft Azure MVP

Martin Ehrnst Microsoft Azure MVP

NiCE Active 365 Monitor for Azure

NiCE active 365 monitor for Azure
Adatum.no use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it. Cookie Policy
Theme by Colorlib Powered by WordPress