CODEWITHSUNDEEP
azureazure-devopsazure-resource-managerazure-functions
Kai Walter
Kai Walter

Reputation: 4041

"Parameter x-ms-client-principal-name is null or empty" when deploying a Function App with Source Control link in VSTS

I want to automatically deploy a Consumption Plan based Function App in my DEV/TEST/PROD instances. For that I started creating a Function App manually in the Portal, copy/pasted the automation script and incorporated it into my ARM template project. To have my source code automatically deployed to the Function App I integrated the link to the repo/branch in the template:

        "resources": [
            {
                "apiVersion": "2015-08-01",
                "name": "web",
                "type": "sourcecontrols",
                "dependsOn": [
                    "[concat('Microsoft.Web/sites/', parameters('name'))]"
                ],
                "tags": {
                    "displayName": "fnSourceControl"
                },
                "properties": {
                    "repoUrl": "[parameters('repoUrl')]",
                    "branch": "[parameters('repoBranch')]",
                    "isManualIntegration": false
                }
            }
        ]

That just works fine when deploying from VS or from command line. Resource Group is created with the Function App and code is deployed into it: Magic! However when deploying from a VSTS release definition, the deployment fails with:

Resource Microsoft.Web/sites/sourcecontrols 'myFunctionApp/web' failed with message '{
  "Code": "BadRequest",
  "Message": "Parameter x-ms-client-principal-name is null or empty.",
  "Target": null,
  "Details": [
    {
      "Message": "Parameter x-ms-client-principal-name is null or empty."
    },
    {
      "Code": "BadRequest"
    },
    {
      "ErrorEntity": {
        "Code": "BadRequest",
        "Message": "Parameter x-ms-client-principal-name is null or empty.",
        "ExtendedCode": "51011",
        "MessageTemplate": "Parameter {0} is null or empty.",
        "Parameters": [
          "x-ms-client-principal-name"
        ],
        "InnerErrors": null
      }
    }
  ],
  "Innererror": null
}

This question is related to my other question regarding the 'Microsoft.Storage/storageAccounts/providers/locks' deployment problem. I guess it goes into the same direction. I did not want to overload one question mixing both problems.

Upvotes: 0

Views: 2410

Answers (1)

David Ebbo
David Ebbo

Reputation: 43203

I talked to our expert, and the response is that VSTS setup with a Service Principal is not supported. The reason is, for VSTS, we impersonate the caller and call the VSTS api on user's behalf. For this to work, the caller needs to be a valid VSTS account. Put when using a Service Principal you have an identity which is not a valid VSTS account.

Note that it has nothing to do with the fact that you're deploying from a VSTS release definition. So same would happen when deploying locally using a Service Principal identity.

Upvotes: 1

Related Questions