Cloud Computing

Deploying a JSON Template in Azure Using a Parameters File

This “how to” post will show you how to deploy a JSON template in Azure using PowerShell and a parameters JSON file.

The JSON template that I will use has been built up using a series of previously published posts:


Sponsored Content

Passwords Haven’t Disappeared Yet

123456. Qwerty. Iloveyou. No, these are not exercises for people who are brand new to typing. Shockingly, they are among the most common passwords that end users choose in 2021. Research has found that the average business user must manually type out, or copy/paste, the credentials to 154 websites per month. We repeatedly got one question that surprised us: “Why would I ever trust a third party with control of my network?


The Parameters

The JSON template that was built in the above posts, MultipleResources.JSON, includes several parameters that are used to customize the deployment of:

  • A storage (Standard Storage) account
  • A VNet with 2 subnets
  • An availability set

Some of these parameters require completion and some include default values that you might want to override:

  • Storage Account Name: The default value is null (empty) and is used to provide a unique name to the new storage account.
  • Storage Account Resiliency: You can choose between LRS (Standard_LRS) and GRS (Standard_GRS). The default is LRS (Standard_LRS).
  • Network Name: The name of the new VNet, which has a default of nw-petri.
  • Network Address: The IPv4 address scope of the new VNet, which is set to by default.
  • Subnet-1 Name: The name of the first subnet, which is sn-petri-01 by default.
  • Subnet-1 Address: By default, the address scope of the first subnet is
  • Subnet-2 Name: The name of the second subnet, which is sn-petri-01 by default.
  • Subnet-2 Address: By default, the address scope of the second subnet is
  • Availability Set Name: The name of the new availability set, which is as-petri-01 by default.

Create a Parameters JSON File

We will use the New-AzureRmResourceGroupDeployment cmdlet to send the JSON file to Azure and start the deployment. There are two ways that we can manipulate the parameters of the JSON using this cmdlet:

  • Use a JSON parameters file, which we will cover in this post.
  • Use the names of the JSON parameters as parameters to the cmdlet, which can be a bit unwieldy for even a small JSON template. We will not cover this approach in this post.

I’m going to use a JSON parameter file, which I’ve shared below, to customize the deployment of the JSON template. I created this file by copying the parameters section from the JSON template that we want to deploy into a new JSON file in VS Code. Each parameter has a single setting, called value. I simply renamed the original defaultValue setting to value, edited the parameter value that was being passed to override the default settings, and deleted the other unnecessary settings from each parameter.

    "$schema": "",
    "contentVersion": "",
    "parameters": {
        "Storage Account Name": {
            "value": "sapetri2abcd"
        "Storage Account Resiliency": {
            "value": "Standard_LRS"
        "Network Name": {
            "value": "nw-petri2"
        "Network Address": {
            "value": ""
        "Subnet-1 Name": {
            "value": "sn-petri2-01"
        "Subnet-1 Address": {
            "value": ""
        "Subnet-2 Name": {
            "value": "sn-petri2-02"
        "Subnet-2 Address": {
            "value": ""
        "Availability Set Name": {
            "value": "as-petri2-01"

The above parameters file was saved as Parameters.JSON, which must not be larger than 64KB.

Deploy JSON Using PowerShell

All deployments of a JSON template are done to a resource group; this can be an existing or a new resource group. If you are using a new resource group, then you must create that resource group. But before we do that, we need to sign into Azure and select the correct subscription.

We are working with ARM, so we’ll be using the ARM PowerShell cmdlets, identifiable by the “RM” in the noun part of the cmdlets. We will log into Azure as follows:


A window will appear; sign into this window with your assigned credentials for the desired Azure subscription. Then we will retrieve the list of subscriptions that this account has access to:

Copy the SubscriptionID of the desired subscription and use it in the below cmdlet to select the subscription:
Select-AzureRmSubscription -SubscriptionId <Your subscription ID>

Now we can create a resource group if a new one is required, and store details of the resource group in a variable called $rg:
$rg = New-AzureRmResourceGroup -Name "rg-petri2" -Location "East US"

Alternatively, if we are deploying the template to an existing resource group, we can store the details of that resource group in a variable called $rg:
$rg = Get-AzureRmResourceGroup -Name "rg-petri2"

Now I can execute the deployment and use the parameters JSON file to configure the deployment:
New-AzureRmResourceGroupDeployment -Name FirstDeployment -ResourceGroupName $rg.ResourceGroupName -TemplateFile C:\Temp\MultipleResources.json -TemplateParameterFile C:\Temp\parameters.json

Note that the deployment is given a name; this is because you can do multiple deployments into a resource group using the same JSON template or a combination of JSON templates, and you’ll need the ability to track your deployments.

Deploying an Azure JSON template using a parameters file [Image Credit: Aidan Finn]
Deploying an Azure JSON template using a parameters file [Image Credit: Aidan Finn]
A minute or so later, the storage account, the virtual network (with subnets), and the availability set are deployed, as specified using the template JSON file and the settings included in the parameters JSON file.

Related Topics:


Don't have a login but want to join the conversation? Sign up for a Petri Account

Comments (0)

Leave a Reply

Aidan Finn, Microsoft Most Valuable Professional (MVP), has been working in IT since 1996. He has worked as a consultant and administrator for the likes of Innofactor Norway, Amdahl DMR, Fujitsu, Barclays and Hypo Real Estate Bank International where he dealt with large and complex IT infrastructures and MicroWarehouse Ltd. where he worked with Microsoft partners in the small/medium business space.
13 Email Threat Types to Know About Right Now

As email threats evolve and multiply, keeping track of them all—and staying protected against the many different types—becomes a complex challenge. Today, that requires more than just the traditional email gateway solution that used to be good enough.

In this eBook you will learn:

  • What are the most common and challenging email attacks for organizations?
  • How to defend against sophisticated email threats, such as spoofing, social engineering, and fraud
  • How to protect employees at the inbox level with the right technologies and security-awareness training
  • How to use a multilayered protection strategy to reduce susceptibility to email attacks and better defend your business and employees

Sponsored by: