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 🙂