Deployments failing before template is validated due to 'parTelemetryOptOut'

[brotheroneill]

What happened? Provide a clear and concise description of the bug, including deployment details.

We've recently update our upstream-releases folder to the 17.2 release, since doing so we're seeing an error in our pipelines at the point Bicep is validating templates suggesting that the parameter 'parTelemetryOptOut' cannot be matched to one found in the templates. The exact error is:

2024-03-19T10:27:11.0346154Z 
2024-03-19T10:27:33.8287454Z �[33;1mVERBOSE: Using Bicep v0.25.53�[0m
2024-03-19T10:27:38.4399797Z �[33;1mWARNING: D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\modules\resourceGroup\resourceGroup.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).
2024-03-19T10:27:38.4401156Z D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\CRML\customerUsageAttribution\cuaIdSubscription.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).
2024-03-19T10:27:38.4402706Z D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\modules\resourceGroup\resourceGroupLock.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).�[0m
2024-03-19T10:27:38.9132057Z ##[error]A parameter cannot be found that matches parameter name 'parTelemetryOptOut'.
2024-03-19T10:27:39.0457244Z ##[error]PowerShell exited with code '1'.

We're using AzurePowerShell@5 tasks within our pipelines, and we've observed this error now on both a policy assignment, and a resource group deployment (though, they're the only deployments we've ran since identifying this issue). Here's the resource group task for the above failure:

 # Deploy Resource Group
    - task: AzurePowerShell@5
      displayName: 'Deploy Network resource group'   
      inputs:
        azureSubscription: $(adoServiceConnAzure)
        ScriptType: InlineScript
        Inline: |
          $deployTime = (Get-Date -Format 'yyyyMMddTHHMMssffff')
          $tags = ConvertFrom-Json '$(networkResourceGroupTags)' -ashashtable

          Select-AzSubscription -SubscriptionName $(subscriptionName)

          New-AzSubscriptionDeployment `
          -DeploymentName ${{parameters.subscriptionServiceName}}-resourceGroup-$deployTime `
          -Location ${{parameters.location}} `
          -TemplateFile 'upstream-releases\$(alzReleaseVer)\infra-as-code\bicep\modules\resourceGroup\resourceGroup.bicep' `
          -Verbose `
          -parTelemetryOptOut $true `
          -parTags $tags `
          -parLocation ${{parameters.location}} `
          -parResourceGroupName $(appSubNetworkRgName)
        azurePowerShellVersion: LatestVersion
        pwsh: true
      enabled: true

Please provide the correlation id associated with your error or bug.

n/a - the deployment isn't happening, it's failing whilst validating the deployment.

What was the expected outcome?

The deployment should be validated and be submitted to ARM.

Relevant log output

2024-03-19T10:27:11.0346154Z 
2024-03-19T10:27:33.8287454Z �[33;1mVERBOSE: Using Bicep v0.25.53�[0m
2024-03-19T10:27:38.4399797Z �[33;1mWARNING: D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\modules\resourceGroup\resourceGroup.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).
2024-03-19T10:27:38.4401156Z D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\CRML\customerUsageAttribution\cuaIdSubscription.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).
2024-03-19T10:27:38.4402706Z D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\modules\resourceGroup\resourceGroupLock.bicep(1,1) : Info Bicep Linter Configuration: Custom bicepconfig.json file found (D:\a\1\s\upstream-releases\v0.17.2\infra-as-code\bicep\bicepconfig.json).�[0m
2024-03-19T10:27:38.9132057Z ##[error]A parameter cannot be found that matches parameter name 'parTelemetryOptOut'.
2024-03-19T10:27:39.0457244Z ##[error]PowerShell exited with code '1'.

Check previous GitHub issues

• I have searched the issues for this item and found no duplicate

Code of Conduct

• I agree to follow this project's Code of Conduct

[jtracey93]

Hey @brotheroneill,

Thanks for the issue, I have tried to repro this locally and have been unable to so far

To me this feels/smells like something to do with the ADO PowerShell task you are using. Are you able to try this without using the AzurePowershell task and just native pwsh inline script or az cli instead?

You can see how we do this in our accelerator here:

• https://github.com/Azure/ALZ-Bicep/blob/main/accelerator/.azuredevops/pipelines/alz-bicep-4a-hubspoke.yml
• https://github.com/Azure/ALZ-Bicep/blob/main/accelerator/pipeline-scripts/Deploy-ALZConnectivityResourceGroup.ps1

Thanks

[brotheroneill]

Hi @jtracey93, thanks for looking into this. I've ran a few more test, moving params around within out task and even excluding some params. It doesn't appear to be a problem with the parTelemetryOptOut param specifically, but the first inline param you pass in (-par...). I've also noticed this is only an issue when the MS hosted agent isn't the latest runner image, assuming of course this is then linked to the version of Bicep being used. Here's the version info from a failing pipeline run:  

2024-03-20T12:21:24.6396826Z ##[group]Runner Image
2024-03-20T12:21:24.6396955Z Image: windows-2022
2024-03-20T12:21:24.6397098Z Version: ​20240310.1.0
2024-03-20T12:21:24.6397352Z Included Software: https://github.com/actions/runner-images/blob/win22/20240310.1/images/windows/Windows2022-Readme.md
2024-03-20T12:21:24.6397662Z Image Release: https://github.com/actions/runner-images/releases/tag/win22%2f20240310.1
2024-03-20T12:21:24.6398014Z ##[endgroup]

When executing the same pipeline, without changing any of the underlying code, the pipeline succeeds, and here is the runner info:

2024-03-20T12:24:27.3706256Z ##[group]Runner Image
2024-03-20T12:24:27.3706360Z Image: windows-2022
2024-03-20T12:24:27.3706479Z Version: 20240317.1.0
2024-03-20T12:24:27.3706681Z Included Software: https://github.com/actions/runner-images/blob/win22/20240317.1/images/windows/Windows2022-Readme.md
2024-03-20T12:24:27.3706949Z Image Release: https://github.com/actions/runner-images/releases/tag/win22%2f20240317.1
2024-03-20T12:24:27.3707246Z ##[endgroup]

I guess we can fix this our side by ensure the pipelines use the latest version of Bicep, but perhaps something to consider either as guidance in the accelerator, or testing on the version of Bicep/runner image that most teams will be using, as I can't imagine we're the only ones to experience this.

[jtracey93]

@oZakari do we have anything in the accelerator or is this something we should add to our pipelines as a shared script that always runs to ensure the latest version of bicep is installed?

[oZakari]

I haven't seen this issue come up yet. We do use the ubuntu-latest runner by default, so seems possible that the windows and linux agents may be out of sync in terms of updates for the runners. Either way, something that we can fix no problem.

I'll plan on adding an additional script that will be included in the applicable workflows/pipelines to check/update the bicep version.

[brotheroneill]

@oZakari if it helps, this code (from here) worked for us on our windows hosted agent in a PowerShell@2 task:

    Write-Information "=====> Installing the latest version of Bicep............. <=====" -InformationAction Continue
    $installPath = "$env:USERPROFILE\.bicep"
    $installDir = New-Item -ItemType Directory -Path $installPath -Force
    $installDir.Attributes += 'Hidden'
    (New-Object Net.WebClient).DownloadFile("https://github.com/Azure/bicep/releases/latest/download/bicep-win-x64.exe","$installPath\bicep.exe")
    $currentPath = (Get-Item -path "HKCU:\Environment").GetValue('Path','','DoNotExpandEnvironmentNames')
    if (-not $currentPath.Contains($installPath)) {
      setx PATH ($currentPath + ";$env:USERPROFILE\.bicep")|out-null
    }
    if (-not $env:path.Contains($installPath)) {
      $env:path += ";$installPath"
    }
    $bicepVersion = bicep --version
    Write-Information "=====> Now installed Bicep version is: $bicepVersion <=====" -InformationAction Continue 

I also got this working with a check against the current version of Bicep before attempting the install, but it wasn't particularly clean and involved querying the repo where the bicep executable is downloaded from, observing where you're redirected to when calling /latest and then comparing that to the current version of Bicep. It also saved very little time, so figured it's best to just try installing the latest version each time. Either way, here's how I approached it:

$bicepVersion = bicep --version
Write-Information "=====> Currently installed Bicep version is: $bicepVersion <=====" -InformationAction Continue
$response = (Invoke-WebRequest -Uri "https://github.com/Azure/bicep/releases/latest/")
$version=$response.BaseResponse.RequestMessage.RequestUri.AbsolutePath
$version=($version.TrimStart("/Azure/bicep/releases/tag/v"))
if ($bicepVersion -match $version) { 
    ... } else {
        ...
}

[achechen]

I am having this issue while trying to pass a parameter during the deployment of a policy assignment like so:

$inputObject = @{
    DeploymentName        = 'alz-PolicyDenyAssignments-{0}' -f (-join (Get-Date -Format 'yyyyMMddTHHMMssffffZ')[0..63])
    ManagementGroupId     = 'mg-landingzones'
    Location              = 'westeurope'
    TemplateFile          = '../ALZ-Bicep/infra-as-code/bicep/modules/policy/assignments/policyAssignmentManagementGroup.bicep'
    TemplateParameterFile = '../ALZ-Bicep/infra-as-code/bicep/modules/policy/assignments/parameters/policyAssignmentManagementGroup.deny.parameters.all.json'
    parTelemetryOptOut = $true
  }
  New-AzManagementGroupDeployment @inputObject -whatif

Error:
New-AzManagementGroupDeployment: A parameter cannot be found that matches parameter name 'parTelemetryOptOut'.

The parameter exists in the bicep file. Tried with other parameters in the bicep file with the same result.

Also, this works fine while deploying a policy definition:

      $inputObject = @{
        DeploymentName        = 'ALZ-PolicyDefsDeployment-{0}' -f (-join (Get-Date -Format 'yyyyMMddTHHMMssffffZ')[0..63])
        Location              = "westeurope"
        ManagementGroupId     = "mg-main"
        TemplateFile          = "../ALZ-Bicep/infra-as-code/bicep/modules/policy/definitions/customPolicyDefinitions.bicep"
        TemplateParameterFile = "../ALZ-Bicep/infra-as-code/bicep/modules/policy/definitions/parameters/customPolicyDefinitions.parameters.all.json"
        parTelemetryOptOut    = $True
        parTargetManagementGroupId = "mg-main"
      }
      New-AzManagementGroupDeployment @inputObject -WhatIf

bicep is the latest version. What am I missing here?

Also, see this, also fails:

> New-AzManagementGroupDeployment -templatefile './infra-as-code/bicep/modules/policy/assignments/policyAssignmentManagementGroup.bicep' -parPolicyAssignmentName 'test' -whatif
New-AzManagementGroupDeployment: A parameter cannot be found that matches parameter name 'parPolicyAssignmentName'.

While the same command in az cli does not fail:

$ dateYMD=$(date +%Y%m%dT%H%M%S%NZ)
NAME="alz-alz-PolicyDenyAssignmentsDeployment-${dateYMD}"

PARAMETERS="@infra-as-code/bicep/modules/policy/assignments/parameters/policyAssignmentManagementGroup.deny.parameters.all.json"
LOCATION="eastus"
TEMPLATEFILE="infra-as-code/bicep/modules/policy/assignments/policyAssignmentManagementGroup.bicep"
$ dateYMD=$(date +%Y%m%dT%H%M%S%NZ)
NAME="alz-alz-PolicyDenyAssignmentsDeployment-${dateYMD}"

$ az deployment mg create --name ${NAME:0:63} --location $LOCATION --management-group-id mg-landingzones --template-file $TEMPLATEFILE --parameters $PARAMETERS --parameters parPolicyAssignmentName='test' --what-if

Note: The result may contain false positive predictions (noise).
You can help us improve the accuracy of the result by opening an issue here: https://aka.ms/WhatIfIssues

Resource and property changes are indicated with this symbol:
  + Create

The deployment will update the following scope:

Scope: /providers/Microsoft.Management/ManagementGroups/mg-landingzones

  + Microsoft.Authorization/policyAssignments/test [2022-06-01]

      apiVersion:                    "2022-06-01"
      id:                            "/providers/Microsoft.Management/managementGroups/mg-landingzones/providers/Microsoft.Authorization/policyAssignments/test"
      identity.type:                 "None"
      location:                      "eastus"
      name:                          "test"
      properties.description:        "This policy denies creation of Public IPs under the assigned scope."
      properties.displayName:        "Deny the creation of public IP"
      properties.enforcementMode:    "Default"
      properties.policyDefinitionId: "/providers/Microsoft.Management/managementGroups/alz/providers/Microsoft.Authorization/policyDefinitions/Deny-PublicIP"
      type:                          "Microsoft.Authorization/policyAssignments"

Resource changes: 1 to create.

RESOLVED.
I'm keeping this comment for anyone that happens to have the same issue. I just updated Az Powershell module to the latest version, which resolved the issue.

[oZakari]

Hey @achechen, thanks for sharing the solution you found. This issue has me curious as both the action and task we use in the pipelines should be using the latest version of PowerShell. Could you help me try to replicate by answering the following:

1. Are you using the GitHub Workflows or the Azure Pipelines?
2. Any idea which version of PowerShell was not working and what you updated to?
3. Are you using self-hosted agents/runners instead of Microsoft or GitHub hosted agents/runners?
4. Are you using the custom tasks/agents as we use in the respective pipeline/workflow files?

[achechen]

Hey @achechen, thanks for sharing the solution you found. This issue has me curious as both the action and task we use in the pipelines should be using the latest version of PowerShell. Could you help me try to replicate by answering the following:

1. Are you using the GitHub Workflows or the Azure Pipelines?
2. Any idea which version of PowerShell was not working and what you updated to?
3. Are you using self-hosted agents/runners instead of Microsoft or GitHub hosted agents/runners?
4. Are you using the custom tasks/agents as we use in the respective pipeline/workflow files?

Hi @oZakari , I was doing some tests by manually deploying the bicep templates using Az PowerShell installed on my laptop before implementing this in Azure Pipelines. Sorry, I can't remember the version of the Az module I updated from. I updated to the latest version, which fixed the issue. I've now also tried the same deployment using an Azure Pipeline too, and it worked without any issues probably because we use our own hosted build agents and we keep them up-to date.

[oZakari]

Hey @achechen, thanks for sharing the solution you found. This issue has me curious as both the action and task we use in the pipelines should be using the latest version of PowerShell. Could you help me try to replicate by answering the following:

1. Are you using the GitHub Workflows or the Azure Pipelines?
2. Any idea which version of PowerShell was not working and what you updated to?
3. Are you using self-hosted agents/runners instead of Microsoft or GitHub hosted agents/runners?
4. Are you using the custom tasks/agents as we use in the respective pipeline/workflow files?

Hi @oZakari , I was doing some tests by manually deploying the bicep templates using Az PowerShell installed on my laptop before implementing this in Azure Pipelines. Sorry, I can't remember the version of the Az module I updated from. I updated to the latest version, which fixed the issue. I've now also tried the same deployment using an Azure Pipeline too, and it worked without any issues probably because we use our own hosted build agents and we keep them up-to date.

Ah, that makes sense and thank you for letting me know!