Introduction Few weeks ago, OMS Alerting has introduced a new feature that enables the alert to trigger a webhook: This feature can be enabled with or without the existing 2 actions (email and Azure Automation runbook remediation). As we all know, the existing Azure Automation runbook remediation also leverages webhooks to trigger Azure Automation runbooks. I have previously posted a blog on OMS Alerting Walkthrough, and also presented Introduction to OMS Alerting in Windows Management User Group Netherlands, you can watch the recording on YouTube: https://www.youtube.com/watch?v=JEZZzIj66uU So, why do we need this new webhook feature? Comparing with the Azure Automation
Introduction This blog has been a bit quiet over the last few weeks. This is because I have been really really busy. I have spent a lot of time working on an updated version of the SharePointSDK PS module. Just in case you have not played with this module, here’s some background info: Just over a year ago, I posted a PowerShell / SMA / Azure Automation module on this blog called SharePointSDK. Few months ago, I have also published this module on Github and PowerShell Gallery. This module was designed to help automate operations around SharePoint lists (i.e. CRUD
Couple of weeks ago, I published a post titled OMS Alerting Walkthrough. I mentioned in the post that I have written a test runbook called Test-OMSAlertRemediation that extracts information from the OMS alert JSON input sends to you via email. Once you have created this rnbook in your Azure Automation account, you can use it as the remediation runbook for any OMS alerts. Source code:
#Process inputs from webhook data
Write-Verbose "Processing inputs from webhook data."
$WebhookName = $WebhookData.WebhookName
Write-Verbose "Webhook name: '$WebhookName'"
$WebhookHeaders = $WebhookData.RequestHeader
$WebhookBody = $WebhookData.RequestBody
Write-Verbose "Webhook body:"
$SearchResults = (ConvertFrom-JSON $WebhookBody).SearchResults
$SearchResultsId = $SearchResults.id
$SearchResultsValue = $SearchResults.value
$SearchResultsMetaData = $SearchResults.__metadata
#$SearchResult = $Inputs.SearchResult
Write-Verbose "Search Results:"
$SMTPConnection = Get-AutomationConnection SMTPNotification
$Subject = "Alert Remediation Runbook Input'"
$Body = @"
$($SearchResultsValue | out-String)
-Body $Body `
-HTMLBody $false `
-SMTPSettings $SMTPConnection `
-Subject $Subject `
Requirements This runbooks uses the SendEmail module for sending emails. You can install it to your automation account directly from PowerShell gallery(https://www.powershellgallery.com/packages/SendEmail/), or download the source code from GitHub(https://github.com/tyconsulting/SendEmail_PowerShellModule). Once the module is deployed
Introduction Earlier today, the OMS product team has announced the OMS Alerting feature has entered Public Preview. This is indeed an exciting news and it is another good example that Microsoft is working very hard to close the gaps between OMS and the existing On-Prem monitoring solution – System Center Operations Manager. Alex Frankel from the OMS product team has already given a brief introduction on this feature from the announcement blog post. In this post, I will demonstrate how I used this feature to alert and auto-remediate an issue detected in my lab environment. Background Few months ago, I
Often when you are playing with security related products, you would need to create dummy/fake viruses on your computers. The most common way to do this is to create a EICAR test file (https://en.wikipedia.org/wiki/EICAR_test_file). I have used this method in the past when testing the Microsoft Forefront Endpoint Protection management pack in OpsMgr. Today I needed to use it again when I was preparing a demo for the OMS Malware Assessment. I thought, why not make an Azure Automation runbook that automatically create the EICAR test file for me on remote computers, so I can trigger it manually or schedule
Today I was writing a PowerShell runbook (let’s call it Runbook A) that’s designed to run on on-prem hybrid workers. At the end of Runbook A, I needed to kick off another runbook (let’s call it Runbook B) that must run on the same Hybrid Worker group. Because I don’t want to hardcode the Hybrid Worker group name in the script (or using an Automation variable), I wrote a very simple function that returns the Hybrid Worker configuration (including the Hybrid Worker group name) from registry if runs on a Hybrid Worker. To use it, simply place the function shown
Nowadays, OMS / Azure Automation is full of surprises. almost every time I visit the OMS and Azure Automation portals, I’d notice new features being made available. Today, I just noticed a new setting for graphical runbooks called Activity-level tracing: You can now configure additional verbose tracing for graphical runbooks. Please note in order to leverage this new capability, you must also turn on verbose logging for the particular graphical runbook. Verbose Logging without Activity-level tracing: Detailed Activity-level Tracing Enabled: As you can see, once turned on, you can see a lot more verbose logging activities (starts with ‘GraphTrace”) for
Last week, I had an opportunity teamed up with the legendary CDM MVP Pete Zerger (@pzerger) and delivered a session on Azure Automation at Microsoft Ignite Australia in Gold Coast, Queensland. Our session was the first session right after the opening keynote, so while some other sessions are still waiting to be uploaded to Channel 9 at the moment, our session has already been published. You can watch the recording here: https://channel9.msdn.com/Events/Ignite/Australia-2015/ARC311 I have also published all the sample runbooks and other information on Github: https://github.com/tyconsulting/AUIgnite2015
My friend and fellow CDM MVP Pete Zerger just pinged me and told me he just spotted that Azure Automation webhooks now support targeting Hybrid Workers. The webhook configuration used to look like this: (Source image from David O’Brien’s blog: http://www.david-obrien.net/2015/05/azure-automation-webhooks/) Currently, the webhook configuration looks like this: Few days ago when Pete and I delivered the Azure Automation session at Microsoft Ignite Australia, in one of our demos, we used Webhook to kick off a process to create AD user accounts on On-Prem Active Directory using Hybrid Workers. Because Webhook did not support Hybrid Workers back then, we had
Introduction This is the 19th instalment of the Automating OpsMgr series. Previously on this series: Automating OpsMgr Part 1: Introducing OpsMgrExtended PowerShell / SMA Module Automating OpsMgr Part 2: SMA Runbook for Creating ConfigMgr Log Collection Rules Automating OpsMgr Part 3: New Management Pack Runbook via SMA and Azure Automation Automating OpsMgr Part 4:Creating New Empty Groups Automating OpsMgr Part 5: Adding Computers to Computer Groups Automating OpsMgr Part 6: Adding Monitoring Objects to Instance Groups Automating OpsMgr Part 7: Updated OpsMgrExtended Module Automating OpsMgr Part 8: Adding Management Pack References Automating OpsMgr Part 9: Updating Group Discoveries Automating OpsMgr