Category Archives: Cloud Computing

Using Azure CLI to query Azure DevOps

Coding CatIn previous posts, I have touched upon the use of Azure Cloud Shell for generic querying of Azure resources and I thought it would be useful to quickly document its use for something a little more specific such as querying or manipulating Azure DevOps through the command line.

For my example, I will focus on something as mundane and straight-forward as querying the Azure DevOps repository meta-data (so that I can look at and compare branch settings against each other) but I hope you get the idea that this is just scratching the tip of the iceberg and the Azure CLI is a powerful tool to add to your arsenal of scripting languages.

The whole end-end process required to query Azure DevOps is itself is a relatively straight-forward affair -especially when you know exactly what you are doing (isn’t everything!) but before we get there, you will first need to have access to the Azure CLI. You have two ways of using it, the first being to install it locally -and instructions to do this can be found via an earlier post titled “AzureRM, Azure CLI and the PowerShell Az Module“. Alternatively, you may also use the Azure CLI through Azure Cloud Shell (i.e. directly from Azure) as detailed in another of my posts titled “Introduction to Azure Cloud Shell“.

Configure az devops pre-requisites

Once you are up and running with the Azure CLI and have access to its az command, there are a few pre-requisites needed before you can query Azure DevOps directly. These are detailed as follows:
1. You must ensure that you are running Azure CLI version 2.0.49 or higher. You can check this by simply running the following command:
az --version
az version
2. Your Azure CLI must have the azure-devops extension added to it. To check if this is already available run the following command to list your extensions:
az extension list
az extension
If the extension is not listed you can add it as follows:
az extension add --name azure-devops
added extension
For further information on this extension, you can view the Microsoft documentation titled “Use extensions with Azure CLI“.
3. Your az session must be signed in to your Azure tenant, and to do this use the az login command and provide the relevant credentials:
az login
4. Finally, to avoid having to provide a project context every time you run an az devops command you should set a default project context as follows (obviously use your own organization and project):
az devops configure --defaults organization= project="ACME Corp"

You are now ready to go!

Querying DevOps through Azure CLI

In order to find out all the commands now made available to you with your new extension, you can execute the following command:
az devops -h

By doing so, you will note that the extension provides devops subgroup commands such as teams -for example to list your current devops teams:
az devops team list

As the help context shows, the extension also provides “related groups” (such as repos) to manage other facets of Azure DevOps. In our specific example, we want to query all available repos for our Azure DevOps project. We can do this as follows:
az repos list
json results
Notice that your results come back in JSON format by default. We can override this and return results in tabular format by using the output parameter:
az repos list --output tabletable output
The Azure CLI also provides a query option so that you can provide a JMESPath query string to filter your results. For instance, in the most basic scenario we can return the first element from our results (using zero-based index notation):
az repos list --query [0]

That is clearly not so useful, so instead, I want to return specific properties from all repos. In this case, I want to return its name, Azure repo url path, and the default branch that is set:
az repos list --query [].[name,webUrl,defaultBranch]

In our final example we will return the results in a tabular format and alias our property names (for our column headings):
az repos list --query "[].{Name:name, Url:webUrl, DefaultBranch:defaultBranch}" --output tablewith aliases


Being able to programmatically query Azure DevOps through the Azure CLI is incredibly useful and powerful and could help you keep your environment standardized (for example ensure branch policies across repos are identical) or even provides a method that you can easily track change. Obviously we are not just restricted to the Azure DevOps repos, we can look at all facets of the environment. For example, to list all current builds in a project we can issue the following command:
az pipelines build list -o table

As a final point of note, I confess to finding JMESPath to query and filter my results far less intuitive or simple than with other languages (especially given the semi-structured nature of the data you are filtering), but with a little bit of trial and error, you can eventually get there!

I hope you find my post useful and please feel free to provide feedback in the comments.

Further References

Azure subscription is not registered to use Cosmos DB namespace

It is usually the simplest things that often leave me feeling like I am a complete dummy. One such issue I ran into fairly recently when trying to deploy Cosmos DB into an Azure subscription.

From Azure DevOps I received the following error:

2019-05-31T16:28:55.4288261Z ##[error]MissingSubscriptionRegistration : The subscription is not registered to use namespace ‘Microsoft.DocumentDB’. See for how to register subscriptions.
2019-05-31T16:28:55.5005526Z ##[section]Finishing: Deploy Cosmos Account and Database with Shared Capacity

I initially assumed that the error was Azure DevOps related so I attempted to deploy using PowerShell and ran into an almost identical error.

I had deployed this Cosmos DB template successfully many times in our other subscriptions and could not understand why a simple deployment to an alternative subscription would fail. Looking back at the error message I followed the link provided which took me to a Microsoft doc titled Troubleshoot common Azure deployment errors with Azure Resource Manager and linked within I ended up on Resolve errors for resource provider registration.

It turns out that the Azure resource providers, which you can almost think of as Class libraries, can (like their programmatic counterparts) be in either Registered or NotRegistered state. When they are in a NotRegistered state, this means that we are unable to call that provider to create a specific resource (such as Cosmos DB in my case).

We can use PowerShell Az or the Azure CLI (both talked about elsewhere in this blog) to report what resources are available. In this specific example, I am going to return all providers that match the wildcard pattern of Microsoft.D*. The code searches for and sets the relevant subscription using Azure Cloud Shell (for simplicities sake), but you can do this through a remote Azure CLI or PowerShell Az session if you would prefer (and connectivity allows).

$subscription = Get-AzSubscription | Where-Object Name -Match "MySubscription1*"
Select-AzSubscription $subscription 
$providers = Get-AzResourceProvider -listavailable |Select-Object ProviderNamespace, RegistrationState
$providers  | Where-Object ProviderNamespace -Match "Microsoft.D*"

We get the following results:

ProviderNamespace               RegistrationState
-----------------               -----------------
Microsoft.DBforPostgreSQL       Registered
Microsoft.DevTestLab            Registered
Microsoft.Databricks            Registered
Microsoft.DataLakeStore         Registered
Microsoft.DataLakeAnalytics     Registered
Microsoft.DBforMySQL            Registered
Microsoft.DevSpaces             Registered
Microsoft.Devices               Registered
Microsoft.DataFactory           Registered
Microsoft.DataBox               NotRegistered
Microsoft.DataBoxEdge           NotRegistered
Microsoft.DataCatalog           NotRegistered
Microsoft.DataMigration         NotRegistered
Microsoft.DataShare             NotRegistered
Microsoft.DBforMariaDB          NotRegistered
Microsoft.DeploymentManager     NotRegistered
Microsoft.DesktopVirtualization NotRegistered
Microsoft.DevOps                NotRegistered
Microsoft.DigitalTwins          NotRegistered
Microsoft.DocumentDB            NotRegistered
Microsoft.DomainRegistration    NotRegistered

Notice that the Microsoft.DocumentDB namespace is disabled. If you are wondering, DocumentDB was the precursor name of the Cosmos DB SQL API (before Cosmos DB supported multiple APIs). Like many other Microsoft products, early names tend to stick with the products :).

To register this namespace we can simply run the following line of code against the subscription using the Register-AzResourceProvider cmdlet.

Register-AzResourceProvider -ProviderNamespace Microsoft.DocumentDB

The following output is returned:

ProviderNamespace : Microsoft.DocumentDB
RegistrationState : Registering
ResourceTypes     : {databaseAccounts, databaseAccountNames, operations, operationResults…}
Locations         : {Australia Central, Australia East, Australia Southeast, Canada Central…}

If it is not obvious you would unregister a provider namespace (if you wanted to make it unavailable) using the Unregister-AzResourceProvider cmdlet as follows:

UnRegister-AzResourceProvider -ProviderNamespace Microsoft.DocumentDB

Once I had registered the Microsoft.DocumentDB namespace, I was able to deploy my Cosmos DB template into my subscription without error!


Depending upon your subscription and region, your enabled provider namespaces may vary, however in my case someone had explicitly un-registered Microsoft.DocumentDB from it. You might ask why someone might do that? Well, it is a good way to prevent deployments of certain resource types if they go against your company policy.

As you can see, if you run into a similar problem or want to start using resource types that are by default NotRegistered you can register and start using them incredibly easily.

Introduction to Azure Cloud Shell

Azure Cloud ShellIn my last couple of posts, I have described the remote management of Azure through the command line from what was essentially a fat (or thick) client. This gives you an awful lot of scripting and automation control over the platform by using either the Azure CLI or PowerShell through the PowerShell Az Module. This is perfect for most cases, but what if you are using an unsupported Operating System or you only have access to the browser (perhaps via a thin client)?

Thankfully a solution to this problem already exists and the good folks at Microsoft have made it easy for you to have full scripting ability over your Azure subscription through your web browser of choice! Enter Azure Cloud Shell…

Accessing Azure Cloud Shell

There are two ways to access Azure Cloud Shell, the first being directly through the Azure Portal itself. Cloud Shell PromptOnce authenticated, look to the top right of the Portal and you should see a grouping of icons and in particular, one that looks very much like a DOS prompt (have no fear, DOS is nowhere to be seen).

The second method to access Azure Cloud Shell is by jumping directly to it via which will require you to authenticate to your subscription before launching. There is an ever so slight difference between each method. Accessing the Shell via the Azure Portal will not require you to specify your Azure directory context (assuming you have several) since your Portal will have already defaulted to one, whereas with the direct URL method that obviously doesn’t happen.


Select your Azure directory context through

For both methods of access, you will need to select the command line environment to use for your Cloud Shell session (your choice is Bash or PowerShell) and the one you choose will partially depend upon your environment of preference.


I will explain the difference later, however, for now, I am going to select the Bash environment.

Configuring Azure Cloud Shell storage

When using Azure Cloud Shell for the first time you will need to assign (or create) a small piece of Azure storage that it will use.  Unfortunately, this will incur a very small monthly cost on your subscription.

ACS storage

The storage is used to persist state across your Cloud Shell sessions.  To get a little more visibility about what is going on I am going to click Show advanced settings:


It is slightly disappointing that at the time of writing there are only 7 available Cloud Shell storage regions -which means that your Shell storage might not be able to live in the same region as your other resources (depending upon where they are).


Would it really matter that your Cloud Shell blob might live in a different region? I think it is probably very unlikely that you will consume egress data into your Shell region since it is management that is the purpose of Cloud Shell, not data staging, but I suppose you might want to bear in mind when you are scripting.

In my specific case (as you will see above) I decided to use an existing resource group named RG_CoreInfrastructure and within create a new storage account named sqlcloudcloudshell [sic] under the North Europe region and within this create a new cloudShellfs file share.

I don’t really like this dialog box since it is not very intuitive and allows you to submit incorrectly named or existing resources -both leading to creation failure. I’d rather they are caught and reported on at input time. For the record, the general rules for our Cloud Shell are that the storage account name needs to be in lowercase letters and numbers, must begin with a letter or number, be unique across Azure, and between 3 to 24 characters long (phew!). The file share can only contain lowercase letters, numbers, hyphens, and must begin with a letter or number and cannot contain two consecutive hyphens. It is a little frustrating, but you will get there in the end with a bit of trial and error!

Whilst it is possible that you could pre-stage all of these things upfront and select an existing storage account (assuming it was in one of the 7 Cloud Shell regions), I was particularly interested in what Azure was going to provision, being mindful about not choosing storage that was more expensive than it needed to be. As it turns out, Azure created my storage as follows:

Performance/Access tier: Standard/Hot
Replication: Locally-redundant storage (LRS)
Account kind: StorageV2 (general purpose v2)

Other things of note were creation tagged this storage resource with the name-value pair of ms-resource-usage/azure-cloud-shell and set a file storage quota of 6GiB.

Running Azure Cloud Shell

Once setup has completed, the Azure Cloud Shell will launch as follows:


If you look at the menubar at the top of your Azure Cloud Shell window you will note that there is a dropdown currently set to Bash -which was the type of shell session chosen earlier. If we change this to PowerShell it will reconnect back into the Cloud Shell Container, this time using PowerShell as your entry point of choice.


Within a few seconds, you will now have entered into a PowerShell session.


Bash or PowerShell?

If you can remember when we first launched Azure Cloud Shell we had to select Bash or PowerShell as our environment of choice. The question is, which should you choose?

The real answer to this question is that it doesn’t really matter, and is simply down to your preference – especially since you can easily switch between the two. However, I would probably argue (especially for Linux fanboys like myself) that Bash (and therefore Azure CLI via Cloud Shell) is probably easier and more intuitive, and you could always directly enter a PowerShell Core for Linux session using the pwsh command in Bash (see also my previous post) if you wanted.

Whichever way you enter a PowerShell Cloud session, the Az module cmdlets are then directly available to you and you do not require any further configuration to your environment. I have specifically found that PowerShell does seem to favour more scripted hardcore Azure deployments since you can very easily use its OOP potential -such as assigning a resource object to a variable and accessing its properties/ methods/ collections programmatically through the object.

Basically, have a play and see what works for you.

Pre-Installed Software

The Azure Cloud Shell thankfully is also deployed with many pre-installed tools and runtimes. This is possibly a subject for another day, but just know that the following are available for your use all within your browser session(!!!):

Development Runtimes available include PowerShell, .NET Core, Python, Java, Node.js, and Go.

Editing tools installed include code (Visual Studio Code), vim, nano, and emacs.

Other tools you can use are git, maven, make, npm, and many more.

I fully expect these lists to consistently get bigger over time.


I hope you have found this post very useful and if you haven’t already done so please start testing Azure Cloud Shell now! It is the perfect place to quickly configure Azure using Azure CLI or the Azure PowerShell module (through scripting or simple commands) through your browser so that you don’t need to install those runtimes on your local machine.


AzureRM, Azure CLI and the PowerShell Az Module

There is now a variety of Microsoft provided command line tools available to connect to (and manage) Azure Resources and the situation is quite confusing to new-comers or those individuals who have not kept up to date with new developments. This post is designed to rectify this situation.

It is probably also worth me mentioning that I am focusing on the usage and deployment of these tools with Linux in mind, however, the following explanation is also applicable to Windows and macOS environments.

##PowerShell Core (on Linux)
If you are running a Linux machine, to use AzureRM or the new PowerShell Az module you will first need to install PowerShell Core for Linux. Installation is fairly easy to perform and you can follow this post using the relevant section for your particular distribution and release. In my specific case, I am running Linux Mint 18.1 Serena, however, to get my Ubuntu version I first run the following:

more /etc/os-release

This returns:

NAME=\"Linux Mint"
VERSION="18.1 (Serena)"
PRETTY_NAME="Linux Mint 18.1"

As you can see, the UBUNTU_CODENAME is xenial. So if I visit the Ubuntu list of releases page, I can see that xenial equates to version 16.04.x LTS. This means that (for me at least) I can follow the PowerShell on Linux installation section titled Ubuntu 16.04 (instructions provided below simply as an example):

# Download the Microsoft repository GPG keys
wget -q
# Register the Microsoft repository GPG keys
sudo dpkg -i packages-microsoft-prod.deb
# Update the list of products
sudo apt-get update
# Install PowerShell
sudo apt-get install -y powershell

To enter a PowerShell session in Linux, you simply type the following within a bash prompt (in Windows you instead use the powershell executable):



AzureRM module (aka Azure PowerShell)

Before you read further, you should understand that AzureRM is deprecated, and if you are currently using it to manage to Azure resources, then you should seriously consider migrating to one of the other options described in the next sections (and removing AzureRM from your system).

I first came across the AzureRM PowerShell Module many years ago when I wanted to manage Azure Resources from my Windows laptop through PowerShell. At the time, this was the only way of doing so from the command line, and the functionality of AzureRM was provided by (in Windows at least) a downloadable installer to make the module available to PowerShell. You can check out the latest version and instructions for AzureRM by visiting this link, but as mentioned earlier, you should avoid attempting this and instead use the Azure CLI or PowerShell Az module as described in the next sections. At the last time of trying, attempts to install AzureRM via PowerShell Core in Linux resulted in failure with warning messages pointing to the PowerShell Az module, so you are forced to go to the newer options anyway.

Upon import into your PowerShell environment, the AzureRM module provided up to 134 commandlets (in version 2) so that you could manage all your Azure subscription resources via PowerShell.

Azure CLI

The Azure CLI was intended as the defacto cross-platform command-line tool for managing Azure resources. Version 1 was originally conceived and written using node.js, and offered the ability to manage Azure resources from Linux and macOS, as well as from Windows (prior to PowerShell Core being available on macOS and Linux). Version 2 of the Azure CLI was re-written in python for better platform compatibility and as such, there is now not always direct one-one compatibility between commands across those versions. Obviously, you should use version 2 where possible.

Head over to Microsoft docs article titled Install the Azure CLI for instructions on installing the CLI for your operating system of choice, or you might also be interested in how to do so on my personal Linux distribution of choice (Linux Mint) in my post titled Installing Azure CLI on Linux Mint. Installing the Azure CLI will enable the ability to use the az command syntax from within your Windows command prompt, or via your PowerShell prompt, or through bash (if you are specifically using Linux).

Once installed, to use the Azure CLI you will prefix any instruction with the az command. Thankfully there is strong contextual help so you can simply run az for a full list of available subcommands, or provide a specific subcommand for help on that.

To execute an az command, you will first need to login to your Microsoft account (that you use to access your Azure subscription/s) as follows:

az login

This will return the following message:

Note, we have launched a browser for you to login.
For old experience with device code,
use "az login --use-device-code"

A browser window will be automatically launched for Azure and require you to log in with your credentials. Alternatively (as you can see in the message), you can use the old authentication method (which is especially useful if your machine does not have a browser). In this case, you would run the following command:

az login --use-device-code

Then log into your account from a browser entering the device code provided.

Either way, after you have done this, we can issue our az commands against our Azure resources, for example:

az vm list

Would list out all current Azure IaaS VMs in your subscription.
Another useful tip with az is to use the find subcommand to search through command documentation for a specific phrase. For example if I want to search for Cosmos DB related commands I would use the following:

az find --search-query cosmos

Returns the following list of commands:

`az cosmosdb database show`
    Shows an Azure Cosmos DB database

`az cosmosdb database create`
    Creates an Azure Cosmos DB database

`az cosmosdb database delete`
    Deletes an Azure Cosmos DB database

`az cosmosdb collection create`
    Creates an Azure Cosmos DB collection

`az cosmosdb collection delete`
    Deletes an Azure Cosmos DB collection

`az cosmosdb collection update`
    Updates an Azure Cosmos DB collection

`az cosmosdb database`
    Manage Azure Cosmos DB databases.

`az cosmosdb collection`
    Manage Azure Cosmos DB collections.

`az cosmosdb delete`
    Deletes an Azure Cosmos DB database account.

`az cosmosdb update`
    Update an Azure Cosmos DB database account.

Az PowerShell module

You might have already questioned that if PowerShell already had a way to manage Azure resources (through the AzureRM module) and we now have the Azure CLI (providing the cross-platform Az functionality), how could there be any synergy between those two environments?

The answer is that there isn't. This is one reason why AzureRM is deprecated.

With the arrival of PowerShell Core on Linux and macOS, it became possible to import the AzureRM module also into those environments, and yet as we have already found out, the Azure CLI was the newer mechanism to manage Azure resources. The problem is that both used different commands to do so (however subtle). In December 2018, Microsoft addressed this situation by introducing the new PowerShell Az module to replace AzureRM which gave a level of synergy between managing Azure resources through the Azure CLI and managing resources through PowerShell. This really means that if you understand one command line environment, your scripts will be relatively easily transferable into the other.

If you are looking to migrate from AzureRM to the new Azure Az module then you should check out this excellent post by Martin Brandl. It is also worth you checking out this announcement from Microsoft titled Introducing the new Azure PowerShell Az module.

To install the PowerShell Az module you can follow the Microsoft article titled Install the Azure PowerShell module. As you will read, you must install this module in an elevated prompt, otherwise, the installation will fail. On PowerShell Core for Linux this means that from bash you would first elevate your PowerShell session as follows:

sudo pwsh

Then you can run the following PowerShell Install-Module command:

Install-Module -Name Az -AllowClobber

Once installed and imported, you are now able to utilize this new PowerShell Az module
but must first login to your Azure account using the following PowerShell command:


This will return a message similar to the one below:

WARNING: To sign in, use a web browser to open
the page and
enter the code D8ZYJCM2V to authenticate.

Once you have performed this action, your Az module in PowerShell will be ready to use. For instance, we can now list IaaS VMs in PowerShell as follows:


As you may note, there is a correlation between this command and the Azure CLI command (az vm list) that we ran earlier. However, it is important to realize that the functionality and behavior of the PowerShell Az module and Azure CLI are not identical. For instance, in this specific case, the Azure CLI will return a verbose result set in YAML format by default whereas the PowerShell Az module returns the results in a shortened tabular format.


Hopefully, it is clear by now that the AzureRM module is redundant across all environments and if you need the ability to manage resources in Azure through PowerShell then the Az module is what you should be using. However, given the ease of multi-platform deployment and use of the Azure CLI, it is probably something you should not ignore and arguably might prefer over PowerShell Az (or at very least run both alongside each other). For example, at the time of writing, exporting an Azure resource template to PowerShell results in code that uses AzureRM rather than PowerShell Az whereas exporting to CLI uses (of course) the Azure CLI itself.

There is also an argument that the Azure CLI is far better suited to Azure automated deployments over ARM templates due to its brevity, and this is discussed in detail by Pascal Naber in his excellent post titled Stop using ARM templates! Use the Azure CLI instead.

Whether you eventually decide to favor Azure CLI over PowerShell Az (or use both), I sincerely hope this post has helped clear up any confusion you may have between all the available command line options to manage Azure resources -I know it had confused me!

Installing Azure CLI on Linux Mint

The Azure CLI (or Azure Command Line Interface) allows provides an easy way to create and manage your Azure resources on macOS, Linux, and Windows. If you (like me) are using Linux and wish to use and control Microsoft Azure easily through the command line, then it is probably something you should have.

I wanted to write a very quick post in order to explain the very simple steps you must follow to get the Azure CLI working for you if are using an Ubuntu derivative distribution such as Linux Mint. Microsoft’s basic installation guide Install Azure CLI with apt has one specific problem for those distros, so let’s take a look at the Ubuntu section of that guide:

Install Azure CLI

If you run steps 1 to 3 you will not observe a problem at the time of execution but will hit an error on running the first line of step 4. We see the following error:

Ign:13 serena/main Translation-en
Reading package lists... Done
W: The repository ' serena Release' does not have a Release file.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
E: Failed to fetch  404  Not Found
E: Some index files failed to download. They have been ignored, or old ones used instead.

In the highlighted line we can quite clearly see the 404 Not Found error, and if we take a look inside the /etc/apt/sources.list.d/azure-cli.list file (created in step 2), you will see that it contains that repository path generated, which is, of course, the problem.

Linux Mint uses its own release codenames and so the default script (provided by Microsoft) picks this up rather than the (required) Ubuntu release name for the Microsoft software repository. See the $(lsb_release -cs) piece of code in their script. So before we first start with the Microsoft code, you will need to find the Mint release name and replace this with the correct Ubuntu package base.

Find out your Linux Mint short codename by running the following:

lsb_release -cs

In my case, I am running Linux Mint Serena. Next, so I now need to find out the short codename of the Ubuntu base build that my edition of Mint is derived from. To do this, visit the Linux Mint Releases page.

From this page, I can see that Serena uses the Xenial package base (as below):

All we need to do is add the right repository path for the right package base. There are two ways to do this. The first you can simply edit /etc/apt/sources.list.d/azure-cli.list and replace (in my case) serena with xenial as we have done below.

Alternatively, you can edit (and hard code) the variable substitution within script 2 and rerun (this programmatically does the same thing we performed manually above):

echo "deb [arch=amd64] $AZ_REPO main" | \
    sudo tee /etc/apt/sources.list.d/azure-cli.list

And that’s it, once the right package base has been corrected, you can rerun the step 4 script which should no longer error. Azure CLI is now ready for you to manage and deploy your Azure resources from your lovely Linux Ubuntu derivative distribution! Check out Common Azure CLI commands for managing Azure resources for some guidance on how to use it.

I’ll give it a try and attempt to list all my Azure resource groups in tabular format:

az group list --output table

Which gives me:

Name                                      Location     Status
----------------------------------------  -----------  ---------
cloud-shell-storage-westeurope            westeurope   Succeeded
future_decoded_demo                       eastus2      Succeeded
Gothenburg                                northeurope  Succeeded
mysql                                     northeurope  Succeeded
sql2014sp1                                northeurope  Succeeded
sqlonlinux                                uksouth      Succeeded
stretchgroup-gothenburg-northeurope       northeurope  Succeeded
stretchgroup-hhserverf-sql01-northeurope  northeurope  Succeeded
stretchgroup-techdaysvm-northeurope       northeurope  Succeeded
techdays                                  northeurope  Succeeded
Testing                                   eastus       Succeeded

As you can see, Azure CLI is very cool and you should start using it now, so don’t let minor configuration difficulties stop you!

Create multiple dashboards in the Azure Portal

Several years ago I wrote a very quick post on the Azure Portal user-experience called Using the new Azure Dashboard favourites and tiles which demonstrated how Microsoft is improving the usability of the Azure Portal. As such, It is probably worth a very quick mention that I recently noticed the Microsoft Azure Portal now supports multiple dashboards, and according to my Google-Bing-Fu seems to have done so for a couple of years.

Strange that I had missed (or ignored) it until now, and because of that reason, it is probably worth me highlighting this usability feature it in case I am not alone.

Creating dashboard

At the top of your screen, click the Dashboard menu item to jump to your current dashboard. Now you will see the menu panel provides the ability to create a new dashboard, import a dashboard (from a JSON document), save an existing dashboard (to a JSON document), or even share a dashboard.

Click the New dashboard menu item and a new dashboard will open in edit mode. Simply provide your dashboard with a new name (in my case I will call it Demos), and from the Tile Gallery on the left-hand pane you can add and resource types required onto your new panel.

Each of these resource tiles should be configured simply by clicking on the Configure tile text for those where it is available (otherwise your resource tile will sit unconfigured until you do). This will allow you to filter this tile down to a specific resource binding, but once you have done this the binding to the tile in question cannot (at this time of writing) be altered.

Click Done customizing to create your new panel (you can re-edit this at any time) and you can now switch quickly between dashboards using the Dashboard dropdown.

Pinning resources

In addition to adding tiles to the dashboard through the Tile Gallery, you can also pin a filtered resource group to your currently selected dashboard simply by navigating to a resource type, selecting those you require and clicking the Pin blade to dashboard icon found in the top right of your screen. Instead, you might prefer to pin individual resources to the dashboard simply by drilling down into a resource and hitting the pin icon like before. Any pinned items will be pinned to the dashboard in view.

Once you are happy with your dashboard, you might find it useful to make a backup of this view by hitting the Download menu item (from your dashboard view). This will simply save a local JSON file that describes your dashboard configuration. If you delete your existing dashboard and want to restore it, all you need to do is import the JSON file (through the Upload menu item) and a new dashboard will be created from this template. It is possible to import this file as many times as you want since the Azure Portal will auto-name new dashboards if there are any conflicts. Azure Portal will prevent you from deleting all dashboards (so you must at least have one).


While most of us might only ever need a single dashboard view, I can see lots of potential benefits to creating multiple dashboards as our Cloud estate grows and we need to limit what we see. This could be very useful for delivering clearer demos to your audience and will prevent you from constantly fiddling with your current dashboard. You can very easily backup and restore dashboards should you make a mistake, so there is really no reason why you shouldn’t investigate what other UX improvements are available to you in the Azure Portal!

Using the new Azure Dashboard favourites and tiles

The new Azure Portal represents a huge improvement over the old Classic Azure Portal in terms of User eXperience and performance.

If you were used to the old portal you’ll most probably have got to like the quirks and simplicity, but the new portal has a lot to offer and does a great job in providing a more customised and colourful end-user experience.

In this post I shall discuss some of the functionality that will make your Azure UX experience more productive and enjoyable.

Favourites sidebar

Favourites can be dragged up or down to your preferred position.


The Portal sidebar at first seems like a cluttered mess, but what items appear on it is completely under your control.

The items on display can be removed (or added) by clicking on the the Browse option and navigating to the item you wish to add/ remove.

When the item in question is visible in the browse list, you can simply tick the star (to its right) to add as a favourite (see below) -the star is highlighted yellow to add as a favourite or cleared to remove from your favourites bar.


The favourite will be placed at the bottom of your sidebar list, but you can order these simply by hovering your mouse pointer over them and dragging and dropping into position.

Once you have customized your menu to your satisfaction it is worth minimizing the favourites list by clicking on the minimize button just beneath the Microsoft Azure logo. This will hide (or display) the favourite titles leaving only the icons on your screen real estate.

Navigation bar

Your Azure experience will consist of many click-select-click-select operations and each time you will navigate further and further down the resource tree in order to make changes required to your resources. This could pose a problem when trying to step back up the tree if it wasn’t for the presence of the Menu Ribbon (found at the top of the Azure Portal). Every sub-menu that is selected will cause a new item to appear to the right of the ribbon (see below).

menu ribbon

In order to step or jump back one or more levels, simply click at that specific item on the tree. If the ribbon cannot fit all the item names on the screen, it will place the earlier ones into a drop down menu accessible by clicking the far left back-arrows item (as seen in the ribbon above).


Tiles are cool right? Well they are even cooler when you can move them around and resize them (just like Windows 8-10).


In order to drag a tile somewhere else within the dashboard surface area you can either switch the dashboard into edit mode by clicking edit on the Portal Menu ribbon, or hover the mouse pointer over the tile you wish to move until its menu bar appears. Simply drag the tile to the position you desire (other tiles will automatically adjust their position to accommodate). You will probably get better mileage from laying the tiles to fit either a vertical or horizontal layout if you commonly use different screen orientations.

select tileFrom this menu it is also possible to remove the tile (by clicking the close cross) or by clicking the ellipses (three dots!) and selecting Unpin from dashboard option from its drop-down menu.

The ellipses menu option will also provide the ability to resize the tile but tile sizing is tile sensitive. In other-words specific tile types can only be resized to specific dimensions (or not at all). For instance, a Virtual Machine tile can be resized only to 1×1, 2×1 and 2×2 dimensions but subscription tiles cannot be resized at all. Once you have selected the tile dimensions from the ellipses drop down menu click the Done button at the top of the Azure Portal.

Newly created resources will be automatically added (by default) onto the Azure dashboard (unless you deselect that option on creation). If you have existing resources you wish to add to the dashboard, simply search for the one you want and select the ellipses option to its right in the resource list and select Pin to dashboard.


If you are not crazy about the default colours used in the Azure Portal you can easily change to another pre-defined theme by clicking the settings settings button on the Portal Menu ribbon. This will give you the option to select (currently) 1 of 4 themes, turn Animations on or off and enable or disable Toast notifications. Personally I like the default theme and I don’t really see any point in turning off animations or toast notifications, but you can if you want to…


microsoft azureIf you are busy making changes to different resources, one useful feature to assist navigation is the history recorder. It will remember the last 10 previous locations visited in the Azure Portal. These can be accessed by the drop-down list (located next to the Microsoft Azure logo). I think it is a shame that this list does not remove duplicates, nor is the list size (currently) configurable, but you may find it an easy way to travel around to commonly accessed resources and options.

Well that concludes my introductory post on the new Azure Portal UX, and if you have any other tips then I would really love to hear them!