Editor's Note: John Savill contributes Frequently Asked Questions about Azure, PowerShell, and other Microsoft products and services three times each week here at Windows IT Pro. He is a well-respected member of the Microsoft tech community and a frequent speaker at industry events.

His training classes through our e-learning portal will help you become more knowledgeable about these various technologies. This tip is just one example of what he will be teaching in an upcoming Master Class.


Often when people start using Azure they are using the portal and why not? It's intuitive and I can do most things. I can create resources, easily see configuration, perform operational duties and much more however many experts (and me :-) ) will tell you that shouldn't be using the portal. Why?? The way I look at the portal is its a great interface to use when getting started. Because of its intuitive nature it makes it easy to see the services available, what options are available and even features wizard driven interfaces for some types of activity so why not always use the portal?

There are a number of reasons.

  1. Azure is the embodiment of "cloud cadence". New features are constantly being added and as new features are added, their interaction is exposed typically first via the REST API, then PowerShell module/Azure CLI and finally the portal. That means that if you want the latest and greatest capabilities then you may need to go outside the portal.
  2. Consider creating one VM. I can click through the wizard and create it pretty quickly. Now consider creating 10 or 100. The time to create using the portal icnreases proportionally to the number of instances you create. 100 VMs will take 100 times as long. If you utilize PowerShell, Azure CLI or JSON templates then the time to create 100 takes the same time as creating 1 (with maybe a little bit of extra time tweak the code a little).
  3. I can't automate using a portal. When I use a scripting environment I can automate those actions which means based on a schedule, based on a trigger I can execute the commands and perform actions. This is a critical ability in the real world.
  4. Similar to the above but using the portal is a human clicking buttons, sliding sliders and dropping drop downs. Hopefully they pick the same things each time but human error can creep in and resources can be deployed in an inconsistent fashion which can lead to support challenges and production problems.
  5. If there is a problem and I have to recreate a whole bunch of resources that's very difficult if they were created with the portal. Very easy if created with pretty much any of the other options available.

There are other reasons but those are good to start with. So what should you use. There are a few options

  • PowerShell - A great all round option to manage and also create resources (but not the best to create). Very popular for Windows administrators used to PowerShell. PowerShell also has the benefit of being usable directly from Azure Automation, the Azure runbook engine to execute directly in Azure which can be triggered or scheduled.
  • Azure CLI - A command line interface which can run on macOS, Linux and Windows (plus the portal itself) based on Bash so very good for those familiar with Linux environments. Once again good for management and creating resources.
  • JSON templates - Azure is built on JSON (at least the Azure Resource Manager). A JSON template provides an idempotent method to deploy resources in a highly prescriptive manner. This is the BEST way to deploy resources but not suitable for general operational activities like stopping and starting VMs.

So what should you use? A combination. Think about picking PowerShell or the CLI as your primary shell method of interacting with Azure. Which really comes down to personal preference and perhaps what else you want to interact with. PowerShell has modules for pretty much everything and also has PowerShell DSC which is a great way to declaratively apply configuration to OS instances. Then for the resource deployment define these deployments using JSON then trigger using PowerShell or CLI.

As you can see variety is the spice of life. I'm not sure there is really a right or wrong answer. Sometimes I'll still create resources using PowerShell instead of JSON because I'm more comfortable with PowerShell and I can script it out very quickly. Sometimes I'll use the portal as its easier to get a high level picture of the resources and state, than a sequence of PowerShell commands (although with PowerShell I can create sequences of commands to give me exactly what I want to see then trigger actions based on those results). In the end use what works for you but hopefully some of the points I've raised will at least get you away from the portal for most of your resource deployment activities.

We'll cover things like this and more in the Master Class so hope to see you there!