In a previous post I talked about Operations Management Suite aka Log Analytics and how it can help you achieve a better understanding of what’s happening on your on-premise and cloud resources. In this blog post I will show you how to enroll your Azure VMs in OMS.
These days I was doing some Azure work for a customer and I was asked if it was possible to create multiple custom RBAC roles for their Azure subscription because the existing ones don’t suit their needs. So I rubbed my hands together and said to client that’s a definite yes and to let me know the requirements so I can start working on the new roles 🙂
I’m writing this short post because of a small issue that can occur when you’re using hosted agents in your Visual Studio Team Services instance. The problem is that the Azure PS version on the agents is quite old; v.1.3.2 OLD. Which means that if you’re like me and update all your modules on a daily basis you will surely have Azure PS version 2.0.x which has a lot of breaking changes between versions.
One of those breaking changes is the way you can create a Storage Account.
The V2 command version looks like this:
New-AzureRmStorageAccount -ResourceGroupName $ResourceGroup -Name $StorageAccount -SkuName Premium_LRS -Location $Location
Looks pretty normal right? Here’s the V1 version of the cmdlet:
New-AzureRmStorageAccount -ResourceGroupName $ResourceGroup -Name $StorageAccount -Type Premium_LRS -Location $Location
See the difference? No? In version 1 if you wanted to provision a spindle based or SSD based storage account, you had to type in the parameter -Type, parameter that was later changed in V2 with -SkuName.
So why I’m writing this blog post? Because if you use develop scripts on your local workstation and you have the latest version of the Azure PS cmdlets and then use that script in an Azure PowerShell task in VSTS, you will get a very very nice error saying that the SkuName parameter was not filled. Now go look at the cmdlet and figure it out. In my ignorance I forgot that the Visual Studio Team Service team that manages the hosted agent images didn’t update the PowerShell version / Azure PS version on the machines and that wasted 30 minutes of my time.
Please be aware that if you’re writing PowerShell scripts that are to be later used in VSTS tasks, TEST your scripts in a PowerShell 4 constrained instance. The agents are not using the latest and greatest version of WMF5 nor the latest and greatest Azure PowerShell cmdlets.
Sometimes working with the latest and greatest isn’t always a good thing 🙂
Most of my DSC blog posts target on-premise or remotely accessed VMs which most of the times are in Azure. While everything is fine and dandy when you’re running PowerShell / PowerShell DSC on your local infrastructure, but when it comes to Azure, you might need to rethink your strategy a bit.
If you worked with Azure for a long time, you know that when you wanted to upload your own custom VM image to Azure, it was an easy thing. You prepared the VM, you sent it to Azure using PowerShell and after that you tagged it as an OS disk and that was it. Well that was the old way using the Azure Service Manager which I must say it was quite an easy procedure. With Azure Resource Manager, things changed quite a bit. You still have the possibility of uploading the VHDs to Azure but the deployment requires a little more work. You have to write code for that deployment to happen, be it in PowerShell or JSON. In this blog post I’m going to give you two ARM templates which you can use to deploy your freshly uploaded VHDs.