In my previous post titled Azure Automation: Sync Runbooks from Visual Studio Team Services, I used a webhook. The webhook is just a URL that will be triggered using an HTTP POST. In Azure Automation, they look like this:

https://s1events.azure-automation.net/webhooks?token=xxyyzzaabbcc

Anyone who got the URL, could simply do an HTTP POST and your webhook would be invoked. For example:

Invoke-WebRequest -Uri https://s1events.azure-automation.net/webhooks?token=xxyyzzaabbcc -Method POST

All is not lost, we can add *some* security to this using WebhookData.

[continue reading…]

This is sort of an update or branch off of a blog post by Gary Keong titled: Azure Automation: Integrating Runbook Source Control using Visual Studio Online (July 2014) and includes some of my learnings.

Use Case

We are going to sync some runbooks for the purposes of subscription management. This could include things like setting up alerts, applying permissions, and applying policies to the subscription. I’m going to assume you have a Visual Studio Team Services Account (create one if not).

In this example, I will use two Azure Automation Accounts.

• The first one will hold the “Sync Runbook.” It simply syncs my Visual Studio Team Services (VSTS) Git repository to my second Automation Account. We’ll call this the Sync Automation Account.
• The second one will hold the runbooks that manage the subscription. We’ll call this the Manager Automation Account.

[continue reading…]

I’m working on encrypting RedHat 7.2 VM using Managed Disks. Keep in mind, to work with Managed Disks in PowerShell, you should upgrade to the latest AzureRM module (version 3.7.0 as of this writing). The command to start the encryption process is the same for Windows as it is for Linux:

Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGroupName -VMName $vmNameForEncryption `
-AadClientID $aadClientID -AadClientSecret $aadClientSecret -DiskEncryptionKeyVaultUrl $diskEncryptionKeyVaultUrl `
-DiskEncryptionKeyVaultId $keyVaultResourceId -VolumeType OS

However, when executing this command for a Linux VM which uses Managed Disks, it fails:

Set-AzureRmVMDiskEncryptionExtension : Object reference not set to an instance of an object.
At line:1 char:1
+ Set-AzureRmVMDiskEncryptionExtension -ResourceGroupName $resourceGrou ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[continue reading…]

EDIT: Updated the hyperlink to GitHub, this is now published here: https://github.com/Azure/azure-quickstart-templates/tree/master/101-vm-automatic-static-ip

During a recent project, I had a need to use only static IP addresses for my virtual machines. However, having to look up the next available IP address seemed counter-intuitive.

What’s the problem anyway

For systems that require a static IP addresses (like Active Directory), or systems that rely on external (non-self-updating) DNS, the default behavior in Azure is problematic because by default a dynamic private IP address is assigned. You can absolutely assign a static IP address by specifying it in your Azure Resource Manager (ARM) template or PowerShell script:

However, there are a couple of issues with this:

1. I need to know the IP address ahead of time. Unlike the ASM model where we had Test-AzureStaticVNetIP cmdlet, we don’t have an ARM equivalent.

2. Azure’s DHCP system isn’t always aware that this IP address is taken.

What’s the solution

I’m going to detail one approach, the one I have used to solve this and would be happy to hear about other approaches to this. What we can do is let the Azure Virtual Network’s DHCP system allocate the IP address and then switch it over to a static IP. This is simple to do from the Azure portal as shown in several articles such as this one. However, we need a more automated approach. By using linked templates, we can create a Network Interface Card (NIC) with a dynamic IP address and then update that NIC with its own IP address, setting it to static.

The ARM template to create the NIC will look as follows:

I’m showing two resources. First the NIC and it’s being created as your normally would with a dynamic IP address. The other resource is a deployment (linked template) that is dependent on creation of the NIC. In this resource we are passing a private IP address as the parameter. The value of this parameter is coming from the existing NIC resource. The linked template is simply specifying the creation of the NIC again, but with a static IP. Here’s how that looks:

Note that we are using “Static” allocation and specifying the parameter for the privateIPAddress. When called, this template is overwriting the original NIC properties and we can include other items such as tags.

Try it out

The complete example is available on GitHub. Please note, you will need to customize the parameters and also update the location of the linked template (it currently points to a non-existent location). For example, you could update it to point directly to my GitHub repository or use your own storage account.