Cross Platform Azure Az PowerShell Modules
In this post, I will discuss the preview “Az” PowerShell modules that are designed to be a replacement for the older AzureRM modules and AzureRM.Netcore.
Az, which is still in preview, is intended to replace AzureRM later this year.
PowerShell – Change Is Constant Here Too
Azure is constantly changing. And this is true of PowerShell too. Yes, with every month, there are new Azure features and a new set of AzureRM PowerShell modules to install or update to. But that’s not all.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
Last January Microsoft launched a new form of PowerShell called PowerShell Core 6.0, describing it as:
… cross-platform (Windows, Mac OS, and Linux), open-source, and built for heterogeneous environments and the hybrid cloud.
Imagine – PowerShell on Linux and MacOS and it’s the same PowerShell as on Windows. Sort of – because the PowerShell we have been using is “Windows PowerShell” and was built on .Net Framework which is only available on Windows. PowerShell Core is built on .NET Core (CoreCLR) which is cross-platform.
The Az Module
Microsoft wants Azure to be all things for all people, plus they want it to be efficient. Azure’s Cloud Shell, the Azure Portal experience of PowerShell or CLI, is built on an on-demand container:
- You start Cloud Shell
- Azure commissions a container
- You use PowerShell or CLI
In the original release of Cloud Shell, you could select a Linux (CLI) or Windows (PowerShell) experience. The Windows experience was funny; a notification would tell you that a container would be spun up within 30 seconds and 5 minutes later it was ready for you to work. This was because the Windows image for the container (probably a Hyper-V container) took much longer to copy than the much smaller Linux image. And this is probably partly why Microsoft removed the option for a Windows image and we now can run either CLI or PowerShell in a Linux container.
Being Linux, it could not run Windows PowerShell so Microsoft has created the Az PowerShell module which is built on PowerShell Core. We now can download and install Az on:
- PowerShell 5.1 – Windows 7 or greater with .Net Framework 4.7.2 or greater installed
- PowerShell Core 6.0 – Windows, Mac OS, Linux
- PowerShell Core 6.1 – Windows, Mac OS, Linux
Now there is a single PowerShell experience for users of Cloud Shell, Windows, Linux and Mac OS. Other features include:
- Az is always up to date with the latest tooling for Azure services.
- Az will simplify and normalize module names.
- There is compatibility with AzureRM – more on this later.
Installing the Az Module
The first thing to know is that Microsoft strongly discourages installing Az alongside AzureRM. If you have installed the AzureRM PowerShell modules then you should uninstall them.
You can install Az from the PowerShell gallery by running:
If you plan on using Az in Azure Automation then the PowerShell gallery has a pretty handy feature to deploy directly into an automation account. This will be useful when Azure Automation workers are able to support Az – they do not at this time.
If you are using AzureRM PowerShell then you probably have some scripts that you aren’t keen on re-writing in the near future. If that’s the case, then I have (mostly) good news for you.
All of the Az cmdlets change their names from -AzureRM to the shorter -Az format. For example, Get-AzureRMVM is now Get-AzVM. That’s great for the life of my keyboard but what about those scripts? You can enable aliases for the new cmdlets so the old naming standards work.
You can enable aliases for the current session by running:
If you want aliases to last beyond this session then you can run either:
Enable-AzureRmAlias -Scope CurrentUser
Enable-AzureRmAlias -Scope LocalMachine
In the below screenshot you can see that both Get-AzureRMVM and Get-AzVM produce the same results:
One important thing to note is that PowerShell Core does not support PSCredential so Connect-AzAccount (Login-AzAccount) cannot accept $pscredential.