Debugging ARM template deployments

We added a new feature to make it easier for you to debug template deployment failures. With this new ability, you can get the request content, the response content, or both, for each deployment operation associated with your deployment. This information is really helpful in many scenarios as you can see the exact content sent or returned back for each deployment operation.

You can enable this from either PowerShell or CLI while creating a new deployment. In PowerShell, we have added a new parameter on New-AzureRmResourceGroupDeployment to enable this setting.

As you can see above, there are three main supported options.

• RequestContent: If this value is set,  the content associated with the http request for each deployment operation will be logged. The type of content is JToken. The content of the write request of the operation will be logged. The content of the following requests to check the status of async operation will not be logged.Example – the content for PUT in case of create resource, POST for listKeys etc..
• ResponseContent: If this value is set, the content associated with the http response for each deployment operation will be logged. It will be the content of the last response of that operation.
• All – If this value is set, both the request content and response content for each deployment operation will be logged.

Note: Be careful when logging debug details. You can potentially log and expose secrets like passwords used in the resource property or listKeys operations that are then returned when you retrieve the deployment operations.

In CLI, you can apply the same setting as follows:

azure group deployment create --debug-setting

Lets deploy a simple template to see how you can use this additional information for debugging.  In this example, I used this template from quick start gallery which provisions a Windows Virtual Machine. I made some changes to it and tried to deploy it.

The deployment failed with the following message:

From above message, it’s clear that there was something wrong with the size of the Virtual Machine. But it doesn’t tell you what size was chosen and why it failed as a result. Now with this new feature, you can get the request content that was sent with each operation in the deployment. So, if this setting was enabled when creating the deployment as described above, we can run the following command to get the operations:

$operations = Get-AzureRmResourceGroupDeploymentOperation –DeploymentName –ResourceGroupName

This will give you all the operations that were part of this deployment. The request and response content for each operation could be retrieved from the property bag as follows:

$operations[0].Properties.Request
$operations[0].Properties.Response

Instead of going through the property of each operation to figure out the issue, you can get the request and response content for every deployment operation as follows:

foreach($operation in $operations)

{
    Write-Host $operation.id
    Write-Host "Request:"
    $operation.Properties.Request | ConvertTo-Json -Depth 10
    Write-Host "Response:"
    $operation.Properties.Response | ConvertTo-Json -Depth 10
}

For one such operation, the request and response looks like below-

Request: 

{
    "Content": {
        "Location": "westus",
        "Properties": {
            "HardwareProfile": {
                "VmSize": "[concat(u0027Standardu0027,u0027_D1u0027"
            },
            "OsProfile": {
                "ComputerName": "SimpleWindowsVM"
            },
            "StorageProfile": {
                "ImageReference": {
                    "Publisher": "MicrosoftWindowsServer",
                    "Offer": "WindowsServer",
                    "Sku": "2012-R2-Datacenter",
                    "Version": "latest"
                },
                "OsDisk": {
                    "Name": "osdisk",
                    "Vhd": {
                        "Uri": "https://xxyy.blob.core.windows.net/vhds/osdiskforwindowssimple.vhd"
                    },
                    "Caching": "ReadWrite",
                    "CreateOption": "FromImage"
                },
                "DataDisks": [{
                    "Name": "datadisk1",
                    "DiskSizeGB": "100",
                    "Lun": 0,
                    "Vhd": {
                        "Uri": "https://xxyy.blob.core.windows.net/vhds/datadisk1.vhd"
                    },
                    "CreateOption": "Empty"
                }]
            },
            "NetworkProfile": {
                "NetworkInterfaces": [{
                    "Id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGro
                               ups/ravdeleterg4/providers/Microsoft.Network/networkInterfaces/myVMNic"
                }]
            },
            "DiagnosticsProfile": {
                "BootDiagnostics": {
                    "Enabled": "true",
                    "StorageUri": "https://xxyy.blob.core.windows.net"
                }
            }
        }
    }
}
Response:

 {
    "Content": {
        "Error": {
            "Code": "InvalidParameter",
            "Target": "vmSize",
            "Message": "The value of parameter vmSize is invalid."
        }
    }
}

The above clearly shows the value that was being set for the VmSize. This was a very basic scenario. But such information could be extremely valuable when debugging complex templates which includes nested deployments, complex objects etc.

Please let us know if you find this useful and any feedback you might have!

To get more information troubleshooting deployment failures, read this documentation article.