This week I ran into an interesting problem:
A powershell commandlet failed when run on Azure Automation Services, but it worked for me on my local machine.
It was a simple command
if you’re not familiar with it, it brings back a list of all the subscriptions you have access to in Azure.
The problem is, it used to return properties named “SubscriptionName” and “SubscriptionID”
These were recently changed to “Name” and “ID” causing code that used the old properties to fail.
This brings to light the importance of keeping your azureRM modules up to date on your local workstation, so you’re testing the same thing. In my case, I was using version 3.8, but 4.1 was current.
My last post listed a few commands of interest for keeping up with installed modules, as a recap, here are a few of interest:
Update-module AzureRM -force #this will fetch the latest versions of all your azureRM.* modules
get-installedmodule #lists installed modules (with a twist - it only shows the highest version you have installed if you have more than one)
One problem I ran into today: After updating all my Modules, powershell was slow as can be. I had installed updated versions, but hadn’t removed the old ones.
Maybe there is a better way, and if so, please comment below, but I ended up creating a small script to remove prior versions. For findability, that’ll be in my next post.