Common errors deploying Azure Bicep and ARM templates

Recently, I deployed some Azure resources using ARM and Bicep templates for a few customers. I found I ran into the same problems with the same type of resources. The problem was: because too much time had elapsed between the moments I did this, I totally forgot what the solution was. I had even forgotten that I had run into the same problems before. The mysterious ways of how memory works! Long story short, I had to research everything twice! To stop me from forgetting, let me just post the problems and their solutions here. And if it helps someone else as well, that would be awesome as well!

Table of Contents

• Deploying Logic App connections that are using Managed Identities
  • The reason why
  • The solution (for Azure Storage Accounts)
  • The solution (for Office 365 Groups)
  • How do you know this?
• Deploying Storage Accounts with a File Share
  • The reason why
  • The solution
• Deploying an Azure Function App with deployments
  • The reason why
  • The workaround
• Deploying a Log Analytics Workspace with saved searches
  • The workaround

Deploying Logic App connections that are using Managed Identities

If you are deploying Logic Apps using Bicep or ARM templates, you might run into this error. The deployment of Microsoft.Logic/workflows fails with a BadRequest and shows the following error details:

{
    "status": "Failed",
    "error": {
        "code": "WorkflowManagedIdentityConfigurationInvalid",
        "message": "The workflow connection parameter 'someresourcename' is not valid. The API connection 'someresourcename' is not configured to support managed identity."
    }
}

The reason why

The problem here is not with the Logic App configuration, but with the connection resource that’s referenced. Connections are separate resources in your Azure Resource Group that get created when you connect to services in your Logic App. The problem occurs when having connections that use Managed Identity to connect to resources.

I have got this error using multiple service connections:

• Azure Storage Accounts
  Connecting to an Azure Storage Queue. The Logic App signs in to the Storage Account using Managed Identity and tries to access a queue.

• Office 365 Groups
  Connecting to the Microsoft Graph to query Office 365 Groups. The Logic App signs into the Graph using Managed Identity.

The ARM templates in both cases do not seem to have the correct properties when exporting such a connection from the Azure Portal.

The solution (for Azure Storage Accounts)

The way to fix this differs per connection type. For the Azure Storage Queue Connection. Checkout the following bicep snippet:

resource connections_azurequeues_resource 'Microsoft.Web/connections@2016-06-01' = {
    name: 'azurequeues'
    location: 'westeurope'
    properties: {
        displayName: 'Some Storage Queue Managed Identity'
        parameterValueSet: {
            name: 'managedIdentityAuth'
            values: {}
        }    
        // ... ommitted for brevity
    }
}

I’ve added the parameterValueSet object with the name property set to managedIdentityAuth and an empty values object. This is the correct configuration for this specific type of connection.

If you’ve installed the Bicep extension, like I did, you’ll get an intellisense warning, saying that:

The property "parameterValueSet" is not allowed on objects of type "ApiConnectionDefinitionProperties". Did you mean "parameterValues"?

I just ignored this warning though, the deployment succeeded anyway!

The solution (for Office 365 Groups)

For the Office 365 Groups Connection, checkout the following bicep snippet:

resource connections_office365groups_resource 'Microsoft.Web/connections@2016-06-01' = {
    name: 'office365groups'
    location: 'westeurope'
    properties: {
        displayName: 'Graph with managed identity'
        authenticatedUser: {}
        parameterValueType: 'Alternative'
        alternativeParameterValues: {}
        // ... ommitted for brevity
    }
}

I’ve added an empty authenticatedUser object and the parameterValueType: 'Alternative' with empty alternativeParameterValues object. This seems to be the correct configuration for this specific type of Managed Identity.

If you’ve installed the Bicep extension, like I did, you’ll get intellisense warnings on all lines. I just ignored these as well.

How do you know this?

If you want to know what the correct configuration is of a resource, you can check the JSON view in the Azure Portal. This sometimes offers more insights than the ARM export. This is the way I found out about the various properties that are needed. Adding those solved my problem.

You can find the JSON view when navigating to the overview blade of an Azure Resource:

The JSON-view shows the property settings for the Managed Identity Settings:

Deploying Storage Accounts with a File Share

When deploying an Azure Function, you’ll need to create a Storage Account as well. Azure will create an File Share on this Storage account. This is where the Function files are hosted. When deploying this using a Bicep or ARM template, you might run into the following error. The deployment of Microsoft.Storage/storageAccounts/fileServices fails with a BadRequest and the following error details:

{
    "status": "Failed",
    "error": {
        "code": "InvalidXmlDocument",
        "message": "XML specified is not syntactically valid.\nRequestId:ab83c272-401a-0053-3091-305efe000000\nTime:2023-01-25T07:45:32.8921964Z"
    }
}

The reason why

This happens because the exported template misses some settings that are necessary for the resource to be created. The culprit for me turned out to be an empty object in the properties of the File Share:

"protocolSettings": {
    "smb": {}
}

The File Share that Azure needs to create is an File Share running on the Server Message Block (SMB) protocol, which is an industry-standard network file-sharing protocol. It appears its default properties are missing, which causes the exception.

The solution

I checked out the default settings for SMB and updated my template. And I verified on my Storage Account File Share what settings where enabled. This can be done using the Azure Portal:

The following bicep snippet got my deployment running:

resource fileService 'Microsoft.Storage/storageAccounts/fileServices@2022-05-01' = {
    parent: storageAccount_resource
    name: 'default'
    sku: {
        name: 'Standard_LRS'
        tier: 'Standard'
    }
    properties: {
        protocolSettings: {
            smb: {
                authenticationMethods: 'NTLMv2;Kerberos'
                channelEncryption: 'AES-128-CCM;AES-128-GCM;AES-256-GCM'
                kerberosTicketEncryption: 'RC4-HMAC;AES-256'
                versions: 'SMB2.1;SMB3.0;SMB3.1.1'
            }
        }
        //...ommited for brevity
    }
    //...ommited for brevity
}

But it’s also possible to just remove the entire protocolSettings object. This will create the File Share with the default settings as well. For a template that might be the nicer route.

Deploying an Azure Function App with deployments

When deploying a Function App you might run into one or more errors saying Microsoft.Web/sites/deployments failed with a Conflict and it shows the following error details:

{
    "status": "Failed",
    "error": {
        "code": "BadRequest",
        "message": "The 'Performing deployment' operation conflicts with the pending 'Performing deployment' operation started at 2023-01-25T07:45:53.6166416Z.  Please retry operation later."
    }
}

The reason why

When deploying a Function App using VS Code or through an Azure DevOps pipeline, these deployments are registered on the Azure Function resource. You can see this when navigating to your Kudu portal https://some-function-app.scm.azurewebsites.net/api/deployments. It will show a list of your deployments, when you did them and how. This is all very interesting. But it also means that when you export that Function App as an ARM template, that those deployments will be added to the templte. The template, when applied, will try to add those deployment-registrations to the new Function app as well.

The workaround

I did not really find a solution, but a good workaround nonetheless: I just deleted the deployments from the bicep / ARM template. I figured I don’t really need to provision these things when I’m moving resources from a development environment to a production environment. I just want the Function App resource to be created, and I’ll deploy the code to that new Function App myself, using a pipeline or VS Code. I’m just interested in the Azure Resources, so removing them is perfectly fine. This solved it for me.

Deploying a Log Analytics Workspace with saved searches

When deploying a Log Analytics Workspace you might run into one or more errors saying: Microsoft.OperationalInsights/workspaces/savedSearches failed with a BadRequest and it shows the following error details:

{
    "status": "Failed",
    "error": {
        "code": "BadRequest",
        "message": ""
    }
}

The workaround

I could not find the reason or solution for this one. In the end i removed the Microsoft.OperationalInsights/workspaces/savedSearches entries from my Bicep template. It seemed to me these where not that relevant anyway. It seems they where default items, created when creating the Log Analytics workspace, and they where included in the exported ARM template. Removing them had no impact as I didn’t use them anyway.

Parting words

That’s it for today, folks. If you have any additional things you ran into that might be handy for people to know, do drop me a post, I could add them to this blog with your name on it. Peace out! ✌️