Use Json in PowerShell...Wahhhhh!

Whenever I speak with clients or peers, to truly gain that competitive edge I always think okay, this is the solution, this is what we, as a mutual partnership want to achieve (new application, landing zone…whatever) now how can I automate the deployment and make it repeatable?

Recently, I had to automate the creation and deployment of Azure portal dashboards and had to grab the contents of a Json file and utilise them in a PowerShell script.

By the way, I will be writing a blog on deploying the portal dashboards, but this blog will purely focus on using a Json file within PowerShell.

I have utilised getting the contents of a Json file in the past but not in anger.

The example

For this example, let's say you have some cool automation in Bicep that utilises a parameters file in Json.

It is so cool that it only creates a storage account with an epically crafted parameters file which looks like the below:

{
    "existing":{
        "storageAccount":{
            "name": "thfsatest22",
            "resourceGroup":{
                "name": "RG-Storage"
            }
        }
    }
}

After the bicep deployment, let’s say you need to get some details of a storage account you have just created to utilise somewhere or you maybe just want to check if it is there.

This is where the “Get-Content” powershell cmdlet comes into play.

Say, your parameters file was located in a parameters folder like the below:

Within your PowerShell script, you would create a variable let us call this $dep

The variable value would be something similar to:

get-content -path .\Parameters\parameters.json | ConvertFrom-JSON -Depth 30

One thing to note here is the depth. This is how many layers down the json object rabbit hole you can read from. Obviously, change this if you have some crazy, 40 level parameters file.

Actually, another thing to note here is the “ConvertFrom-Json”. Obviously, we are using a Json file, so we will convert from Json…*sigh*, we can also convert from CSV, if you really want to that is.

Anyway, within your script you should have something similar to the below.

$dep = get-content -path "C:\Temp\Blgs\parameters\parameters.json" | ConvertFrom-JSon -depth 30   

Let’s now run and see what the variable $dep contains.

existing
--------
@{storageAccount=}

With a larger parameters file, we would see more objects that we can expand on and utilise.

Now that we have got the content of the Json file in a variable, I can look for my storage account by running the following command using our newly created parameters object variable.

Note, we navigate into the Json object to retrieve the required value pair.

Get-AzStorageAccount -Name $dep.existing.storageAccount.name `
    	-ResourceGroupName dep.existing.storageAccount.resourceGroup.name

As long as we are connected to Azure in the right context we should be able to retrieve the storage account “thfsatest22” in the resource group “RG-Storage”

You could even wrap that bit of PowerShell in a variable and query the properties of the storage account as shown below.

$sa = Get-AzStorageAccount -Name $dep.existing.storageAccount.name `
    	-ResourceGroupName dep.existing.storageAccount.resourceGroup.name

Closing Thoughts

Yes, this is rather straightforward but yet, is hella useful when trying to deploy little fiddly things or amending resources outside of the traditional Arm or Bicep template.

Just think, if you have some complex automation modeling but need to leverage or modify existing resources in a Brownfield Azure deployment, by keeping it within your parameters model nothing will realistically change and you can link different types of automation and scripting seamlessly.

{

“SignOff”: {

“Cheers”: “THF”

}

}