Azure automation is, in my opinion, one of the heavily underrated offerings in the Microsoft Azure platform. During my time at Microsoft I had the opportunity to work with some great partners on Azure automation projects and also talk about it at the Microsoft Partner Days in Munich. So I thought it might be worth writing a few words about it on my blog and move away from the .NET Core topic. A huge challenge is to keep this as short as possible.

Microsoft Azure Automation provides a way for users to automate the manual, long-running, error-prone, and frequently repeated tasks that are commonly performed in a cloud and enterprise environment. It saves time and increases the reliability of regular administrative tasks and even schedules them to be automatically performed at regular intervals. You can automate processes using runbooks or automate configuration management using Desired State Configuration. I will not give the entire “Intro” talk here :). If you are not familiar at all with this topic, you may check the official Microsoft getting started guide.

There are two main components in Azure  automation: runbooks and desired state configuration (DSC). In this article, I will focus on runbooks.

Azure automation runbooks are basically PowerShell scripts (although you can also have graphic runbooks, PowerShell still runs under the hood) promptly executing when triggered. Just to give a simple example, you could create a runbook that shuts down designated VMs at certain hours. Additionally, Azure automation runbooks can be triggered manually or via webhooks. This means, that you can trigger it with a simple HTTP request. This allows external services such as Visual Studio Team Services, GitHub, Microsoft Operations Management Suite Log Analytics, or custom applications to start runbooks without implementing a full solution using the Azure Automation API.

This opens a huge set of possibilities. Imagine, for instance, an IT Helpdesk department or company that offers such services. Many years ago I made my entrance into the IT world as a helpdesk employee. As such, I had the following repeated situations: Something was not working and one of the steps needed to be done was a server restart. I didn’t had the necessary privileges to restart a server by myself, so I had to forward a ticket to the2nd level team. Response times are not always great and sometimes evem 2nd level colleagues didn’t have the necessary privileges so the ticket needed to be escalated further. After sever hours or one day, somebody restarted the server. In this scenario, a company could simply build a helpdesk portal, from which employees could restart server by triggering runbooks via a button lick. Since this is a simple HTTP request, the don’t need to know any admin credentials to perform this task.

As an example, the following javascript fuction triggers an Azure automation runbook that starts a specified VM:

[code language=”javascript”]
function sendRequest (vmName)

{
var check = validate();
if (check == “failed”) {
var exit = “Cannot proceed. Validation failed.”
console.log(exit);}
else if (check == “passed”)

{
var vmName = document.getElementById(“VMname”).value;
var httpRequest = new XMLHttpRequest();
var webhookdata = {
“Name”:vmName,
“ResourceGroupName”:”Contoso”
}

}
var JsonWebhookData = JSON.stringify(webhookdata);
httpRequest.open(‘POST’, “https://s2events.azure-automation.net/webhooks?token=sjYYSkefmE76%2fLcGoPZ0GFJCaGnjbtJoS7znd1L9wUQ%3d”, true);
httpRequest.setRequestHeader(“Accept”, “application/json”);
httpRequest.send(JsonWebhookData);

}
[/code]

Notice that you can also provide a webhook data object that will be sent as the request body and in which you can add necessary information that you could use in your runbook PowerShell script to implement different types of logic. The webhook data is sent in JSON format.

Here is also the corresponding PowerShell script running as an Azure automation runbook:

[code language=”powershell”]

param (
[object]$WebhookData
)

if ($WebhookData -ne $null) {

$WebhookName = $WebhookData.WebhookName
$WebhookHeaders = $WebhookData.RequestHeader
$WebhookBody = $WebhookData.RequestBody

.\ConnectAzureSubscription.ps1

$VM = ConvertFrom-Json -InputObject $WebhookBody
$azureVM = Get-AzureRmVM | Where-Object {$_.Name -eq $VM.Name}
Start-AzureRmVM -Name $azureVM.Name -ResourceGroupName $azureVM.ResourceGroupName -force
Write-Output The VM $azureVMName is now started

} else {

Write-Error Runbook mean to be started only from webhook.

}
[/code]

Notice that I include VM name and resource group name in the HTTP reuqest. In the PowerShell script I use this information in order to define exactly which runbook virtual machine should be stopped. That’s a little bit like magic, isn’t it? These are the type of scenarios in which I say that developers need to be also good system administrators and system administrators should also be familiar with development. Otherwise, they will never know what great features Microsoft Azure automation has to bring to the table.

I guess, that’s it for now. I am always open to your feedback so if you found the time to read till the end, maybe you’ll find one more minute to drop a comment. Till the next time!

Cheers.