When you start automating Azure from the comfort of your desktop or laptop, things are slow going at first. You are constantly finding out things that do not work. Then you learn about the modules that you need to install, import. The dependencies that you need to take care of and the various ways of handling authentication to access the resources, you need.
Therefore, you put in the time, set up your PC/laptop (or multiple of those, you know how it goes as mobile, flexible IT professional) with the tools several editors from notepad++ over PowerShell ISE with or without plugins and Visual Code to full blown Visual Studio. You fight where you are with what you got, sometimes that is a lot, sometimes very little but it all takes time to set up.
Once you figured out how to automate with PowerShell against Azure, you learn not all code should live on premises and/or be run from there. There are solutions for that. You learn about run books, hybrid run books, workflows and Azure Automation accounts. For your comfort, you might integrate run books into your PowerShell ISE with Azure Automation ISE add-on.
Cool. You write your script, you test it, and decide you are golden and ready to use it. Happily, you deploy your run book only to find it does not work at all. You are beaten around the head with errors about missing functions like there is no tomorrow. Not because of authentication issues or so with ARM, you figured out already that an automation account with AzureRunAsConnections is how you get things done. Just plain missing function names like below.
Get-AzureRmLocalNetworkGateway : The term ‘Get-AzureRmLocalNetworkGateway’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At updatedynipvpn:27 char:27 + + CategoryInfo : ObjectNotFound: (Get-AzureRmLocalNetworkGateway:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException
Your automation account as a limited set of preconfigured modules available by default. However, you’ll often find you’ll need more. In our example case that is AzureRM.Network and AzureRM.profile on which AzureRM.Network has a dependency.
That is quite annoying when it happens but remember all the work you had to do to prep your scripting environment. Well there is a little extra work to do in Azure as well. You can add these modules or resources via “Shared Resources”, “Add a Module” under your automation account.
Once you have added them and they have been deployed you will find them under the CMDLETS tree branch of your run book, which gives you a handy list of what available to your automation account.
When you try to run your script now it should come alive. If it does not a little patience can do miracles. The portal test run-time environment is not always immediately up to speed with what has changed.
So remember, do not forget to prep the Azure automation environment just like your PC and remember to add the modules you need in order for your scripts to run. You might expect the entire library to be available out of the box but it is not.
Happy automating!
