If you’re developing an Azure based application, chances are you make frequent visits to the Azure portal. Now hopefully you don’t use it exclusively – at the very least your deployment should be automated (ideally with ARM templates) so you have a reliable and repeatable way to provision your application.

However, if you’re like me, you often find yourself needing to dive into the portal to check the status or configuration value of some resource or other. And if you have a lot of resources in your subscription(s) it can take a lot of clicking around, changing subscription, and filtering by resource type and group before you find the information you’re after.

This is where the Azure CLI can really help you out.

This week I kept needing to RDP into some virtual machines. So I needed to get the public IP address, the port numbers from a load balancer, and the password from a key vault secret. After manually doing this a few times, it dawned on me that the Azure CLI would be ideal to automate this.

To get the public IP address, I just needed to use the az network public-ip show command, and query for just the ipAddress property with a simple --query parameter. For commands like this returning a single value, I use the tab separated output option, as there is no need for it to be formatted as JSON.

az network public-ip show -n mypublicip -g myresourcegroup --query ipAddress -o tsv

Getting the value of the secret from the keyvault is just as simple. It’s az keyvault secret show, and asking for the value property:

az keyvault secret show --vault-name mykeyvault --name mysecret --query value -o tsv

The only slightly tricky command was asking the load-balancer for the port values. The inboundNatRules property of the output from az network lb show is a JSON array, and I wanted to pick out just the frontendPort properties from each object in that array. The JMESPath syntax for that is inboundNatRules[].frontendPort. And with the tsv output option, I’ll get each port number on a separate line:

az network lb show -n myloadbalancer -g myresourcegroup --query "inboundNatRules[].frontendPort" -o tsv

And so with three simple Azure CLI commands, I’ve automated the task of getting the RDP connection settings from the portal. It may not seem like a big deal, but the time saved by automating these simple repetitive tasks can add up over time.

What task do you keep visiting the Azure portal for that you could automate?

Want to learn more about the Azure CLI? Be sure to check out my Pluralsight course Azure CLI: Getting Started.


One of the great things about Azure is that there is an incredible amount of choice about how you go about managing your resources. Whether you want to create a new web app, configure a network security group, or stop a virtual machine, there’s plenty of choices for how to accomplish that.

Here’s a quick summary of what your options are, and why you might choose them:

1. Use the Portal

The first option is actually two, because there’s a “new” portal (portal.azure.com) and the “classic portal” (manage.windowsazure.com). Thankfully, there’s very little reason to visit the classic portal anymore – almost everything can be done in the new portal.

The Azure portal is a great choice when you’re just wanting to explore. You can look around the resources you have deployed, navigate into their various property pages, and quite often you’ll discover settings to configure features you didn’t even know were there. Here’s just a few of the things you can set up for a web-app for example.


The portal’s also great for things like browsing the list of available images for Virtual machines.

But! While the portal is great for experimenting and exploring, it’s not the best choice for deploying of application, or any task you need to implement repeatedly. For those sort of things, it’s much better to use a technique that can be automated.

And that’s where the other options come in.

2. Use Azure PowerShell

Azure PowerShell is a comprehensive collection of PowerShell cmdlets that let you do pretty much anything with Azure. The commands uses the conventional PowerShell prefixes of New-, Get-Set- and Remove-, for create, read, update and delete operations.

For example, here’s a sample Azure PowerShell script that creates a web app and deploys code from GitHub

$location="West Europe"

# Create a resource group.
New-AzureRmResourceGroup -Name myResourceGroup -Location $location

# Create an App Service plan in Free tier.
New-AzureRmAppServicePlan -Name $webappname -Location $location -ResourceGroupName myResourceGroup -Tier Free

# Create a web app.
New-AzureRmWebApp -Name $webappname -Location $location -AppServicePlan $webappname -ResourceGroupName myResourceGroup

# Configure GitHub deployment from your GitHub repo and deploy once.
$PropertiesObject = @{
    repoUrl = "$gitrepo";
    branch = "master";
    isManualIntegration = "true";
Set-AzureRmResource -PropertyObject $PropertiesObject -ResourceGroupName myResourceGroup -ResourceType Microsoft.Web/sites/sourcecontrols -ResourceName $webappname/web -ApiVersion 2015-08-01 -Force

All the major Azure services have PowerShell cmdlets available, so pretty much anything you can do in the portal can be automated with it. For more examples of Azure PowerShell in action, check out Elton Stoneman’s Pluralsight course Managing IaaS with PowerShell.

Of course, not all developers know PowerShell and it does have its quirks, but if you already know some PowerShell or are willing to learn, this is a great way to automate your resource management. And its not necessarily a Windows only thing now – Azure PowerShell is available on Mac and Linux (currently in beta).

3. Use the Azure CLI

Alternatively, if you’re a Max or Linux user, or just prefer a bash shell to PowerShell, the Azure CLI 2.0 might be for you. It’s a fully cross-platform command-line experience, and despite being newer, already has capabilities on a par with Azure PowerShell.

The commands typically take the form az command subcommand options which makes the API very easy to explore. Just type az and get a list of the main commands. Type az webapp and see what you can do with webapps. There’s even an interactive mode which gives you a sort of intellisense experience at the command prompt!

By default the commands will emit JSON, although it supports a few output formats. To give a feel for how it compares to PowerShell, here’s an Azure CLI bash script to perform the same task of creating a web app and deploying code from GitHub:


# Replace the following URL with a public GitHub repo URL

# Create a resource group.
az group create --location westeurope --name myResourceGroup

# Create an App Service plan in `FREE` tier.
az appservice plan create --name $webappname --resource-group myResourceGroup --sku FREE

# Create a web app.
az webapp create --name $webappname --resource-group myResourceGroup --plan $webappname

# Deploy code from a public GitHub repository. 
az webapp deployment source config --name $webappname --resource-group myResourceGroup \
--repo-url $gitrepo --branch master --manual-integration

Obviously the capabilities and use cases for the Azure CLI and Azure PowerShell are very similar so its a hard call which one to use. Azure CLI would probably be a better choice if you prefer bash to PowerShell, if you’re working cross-platform, and also has the benefit of being open source, so it is picking up plenty of community contributed features.

4. Use the Azure Management Libraries for .NET

The Azure management libraries for .NET allow you to write code in C# (or your favourite .NET language) to manage your Azure resources. This is a great choice if you’re more comfortable with C# than scripting language and there is a lot of business logic surrounding the task you want to automate.

The libraries are available on NuGet and support a fluent interface allowing you to write code looking like this:

var sql = azure.SqlServers.Define(sqlServerName)

As you can see, it’s very easy to work with. The down-sides are that it doesn’t have the same comprehensive coverage of Azure features and services that the CLI and PowerShell have, although hopefully that will change in the future (they’re open source too).

You will also need to go through the somewhat convoluted process of creating a service principal (instructions here) to create credentials your code can log in with.

But if you wanted to create say an Azure Function that ran on a timer to start or stop virtual machines, this would be a great choice.

5. … or for your favourite language

If you’re a Java programmer, there’s an Azure Java API. There’s also a node.js Azure SDK, a set of Azure Python libraries, and an Azure client library for Ruby. Like with the .NET libraries, you’ll want to create a service principal to use for login purposes, but then you’ll be able to manage Azure resources using your language of choice.

6. Use the Azure REST API directly

So far we’ve discussed five ways to manage your Azure resources – the portal, PowerShell, the CLI and the SDKs for a whole host of popular programming languages. But what they all have in common is that under the hood, they’re making calls to the Azure REST API.

What this means is that you can access the full range of capabilities of Azure, using any language that can make HTTP requests, by calling the REST API directly yourself. Obviously its a little less user-friendly than the other options we’ve discussed so far, but the documentation is quite comprehensive so you should be able to work out the correct headers and payload for each request.

Here’s a sample request to the REST API:

PUT /subscriptions/03f09293-ce69-483a-a092-d06ea46dfb8c/resourcegroups/ExampleResourceGroup?api-version=2016-02-01  HTTP/1.1
Authorization: Bearer <bearer-token>
Content-Length: 29
Content-Type: application/json
Host: management.azure.com

  "location": "West US"

Bonus 7 - Use ARM Templates

Finally, this isn’t really an alternative to the previous options, but should be used in conjunction with them.

For example, creating a new virtual machine often involves creating several resources – a virtual network, a public IP address, a network security group, a storage account for the disk, and the virtual machine itself. Whilst you could write a script with a separate command for each of these items, a better approach is to create a single Azure Resource Manager template, which can be deployed with a single command.

There are several benefits here – the template can be parameterized and Azure can create resources in parallel for faster deployment. Deploying a template will also only create resources that are missing in the target resource group so can greatly simplify incremental deployments.

To get an idea for the sort of thing you can achieve with an ARM template, check out these samples – there are some very impressive demos, which you can try yourself easily simply by clicking the “deploy to Azure” button for each sample, and within minutes you have the sample deployed. If you’re worried about cost – cleaning up is really easy – just delete the resource group and everything that you created is gone. And since pricing in Azure is per minute, you’ll often end up paying hardly anything for a quick experimental deployment of a template.

Each of the six previous techniques we’ve discussed offer you a way to deploy using an ARM template, so whichever of those you use, once you’ve finalised what resources make up a deployment, it’s well worth your time creating a template to make deployments simple and repeatable.

Want to learn more about the Azure CLI? Be sure to check out my Pluralsight course Azure CLI: Getting Started.


I recently created a video showing how you can use the Visual Studio Tooling for Azure Functions which is a great way to create and debug C# functions.

But you can also use the Azure Functions CLI to create new function apps and functions, test them locally and even debug them in Visual Studio Code. In this video I run through the steps to do exactly that, creating a JavaScript HTTP triggered function, and attaching the VS Code debugger to step through.

Read more about local development and debugging of Azure Functions.

Want to learn more about how easy it is to get up and running with Azure Functions? Be sure to check out my Pluralsight course Azure Functions Fundamentals.


The Azure Functions team recently asked everyone to check the versions of their Function Apps in preparation for the forthcoming 2.0 release.

Basically you need to check the app settings for each function app and specifically see if the FUNCTIONS_EXTENSION_VERSION setting has any value other than ~1.

Now you can do this fairly easily in the portal, but if, like me, you have a lot of function apps, you might be wondering if there is a way to automate this. And, thanks to the Azure CLI (about which I recently posted a short introductory video), you can do just that.

The main two commands we need are az functionapp list to list all function apps and az functionapp config appsettings list to list all the app settings for a function app.

However, the output of az functionapp list is a very large JSON array as it contains all kinds of information about each application. And I only need to know the name and resource group of each function app.

So I can use the --query switch which allows me to narrow down the output to just the data I want using a powerful query language called JMESPath.

In this case I’ve got a JSON array of objects each of which has a name and resourceGroup property and so I can use the following syntax to trim down the output to just the properties I’m interested in with the following command: az functionapp list --query "[].{Name:name,Group:resourceGroup}"

This produces the following output (showing some function apps I created for my Building Serverless Applications in Azure course):

    "Group": "TestDeploy1",
    "Name": "whosplayingdeploy-zq2obg"
    "Group": "WhosPlayingAdmin",
    "Name": "whosplayingadminfuncs"
    "Group": "WhosPlayingFuncs",
    "Name": "whosplayingfuncs"

Now I could manually use the values here to get the settings with commands like az functionapp config appsettings list -g WhosPlayingAdmin -n whosplayingadminfuncs, but wouldn’t it be nice if I could automate this and loop through the output?

Well, if we can parse the JSON we can do that, but my bash skills are somewhat limited so I wanted to find an easier way, and we can make the output of az functionapp list even easier to parse by switching to tab separated output with the --output tsv switch.

Now when we run we get the following output:

PS C:\Users\markh> az functionapp list --query "[].{Name:name,Group:resourceGroup}" --output tsv
whosplayingadminfuncs    WhosPlayingAdmin
whosplayingfuncs    WhosPlayingFuncs
whosplayingdeploy-zq2obg    TestDeploy1

By the way, another format you should know about if you’re using the Azure CLI is the --output table format, which gives you a nicely formatted table like this:

PS C:\Users\markh> az functionapp list --query "[].{Name:name,Group:resourceGroup}" --output table
Name                      Group
------------------------  ----------------
whosplayingadminfuncs     WhosPlayingAdmin
whosplayingdeploy-zq2obg  TestDeploy1
whosplayingfuncs          WhosPlayingFuncs

But the tab separated output is what we want. This allows us to parse them into a $name and $resourceGroup variable and get the app settings for that app with the az functionapp config appsettings list -n $name -g $resourceGroup command.

But when we run this we have the same problem: too much output. And the --query flag again comes to our rescue. We can use it just to narrow it down to the setting we are interested in:

PS C:\Users\markh> az functionapp config appsettings list -n $name -g $resourceGroup --query "[?name=='FUNCTIONS_EXTENSION_VERSION']"
    "slotSetting": false,
    "value": "~1"

And we can even pick out just the value of that setting with another change to the JMESPath query and choosing tab separated output:

PS C:\Users\markh> az functionapp config appsettings list -n $name -g $resourceGroup --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" --output tsv

So we have all the bits in place for automating checking the versions of all the function apps in our subscription. I decided to do this with the Windows Subsystem for Linux (WSL or Bash on Windows), since the Azure CLI is designed to be used from bash (although you are perfectly free to use it from PowerShell too if you prefer). Instructions for installing the WSL can be found here and you then use apt-get to install the CLI as described here.

With that in place, we can write a simple bash script to loop through all the function apps, query for the value of the FUNCTIONS_EXTENSION_VERSION app setting and print them out. My bash skills are very basic, so do let me know in the comments if there are better ways to accomplish this:

az functionapp list --query "[].{Name: name,Group: resourceGroup}" -o tsv |
while read -r name resourceGroup; do
   version=$(az functionapp config appsettings list \
      -n $name -g $resourceGroup \
      --query "[?name=='FUNCTIONS_EXTENSION_VERSION'].value" -o tsv)
   printf 'N:%s R:%s V:%s\n' "$name" "$resourceGroup" "$version"

When we run this in our bash shell, we see the following output for this subscription. Looks like all my settings had the right value anyway:

mheath@DESKTOP-R7KVMG5:~$ ./funcappversion.sh
N:whosplayingfuncs R:WhosPlayingFuncs V:~1
N:whosplayingdeploy-zq2obg R:TestDeploy1 V:~1
N:whosplayingadminfuncs R:WhosPlayingAdmin V:~1

But my point in sharing this post wasn’t really to show you how to check function app versions, but to highlight just how powerful using the --query switch and JMESPath query language along with the  --output tsv switch to get tab separated output. The JMESPath website has plenty of great examples and I found it surprisingly quick to learn the syntax I needed for my queries.

Want to learn more about how easy it is to get up and running with Azure Functions? Be sure to check out my Pluralsight course Azure Functions Fundamentals.


If you’re like me, you may have ignored the Azure CLI, since I had invested a fair amount of time in learning the Azure PowerShell commandlets, and there didn’t seem to be much benefit in learning another command line approach.

But I gave it a try a while back, and was really impressed. It’s got a very simple, easily discoverable syntax, and it has the benefit of being cross platform. Another great thing about it is that there is an Azure CLI console built right into the Azure Portal, so you don’t even have to install it to give it a try.

In this short video I show the basics of using it both from the command line and the Azure portal.

Want to learn more about the Azure CLI? Be sure to check out my Pluralsight course Azure CLI: Getting Started.