Multiple Deployment Issues

[Q-Cmack]

I was granted subscription owner permissions and should be able to deploy all the required components, but I receive multiple failures.

The one I see every time on CodeDeploy:
message": "Repository 'UpdateSiteSourceControl' operation failed with System.TimeoutException: Operation GET https://waws-prod-blu-387.api.azurewebsites.windows.net/api/sshkey?ensurePublicKey=True exceeded 50000ms timeout!\r\n at Microsoft.Web.Hosting.Administration.Utilities.WebRequestHelper.

in Deploy, I get this error:
At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "ResourceDeploymentFailure",
"target": "/subscriptions/313d7f51-dac1-4d25-8b81-487dd107fa95/resourceGroups/rg-teamsvoice-demo-eastus-01/providers/Microsoft.Resources/deployments/kustoConfigure",
"message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
},

And on KustoConfigure:

"At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",
"details": [
{
"code": "RoleAssignmentUpdateNotPermitted",
"message": "Tenant ID, application ID, principal ID, and scope are not allowed to be updated."
},

[adthom]

Thanks for the detailed report @Q-Cmack, we've been able to reproduce the root cause here.

You're actually hitting two related issues that cascade:

1. Source control timeout (codeDeploy): The UpdateSiteSourceControl timeout is a transient Azure platform issue where App Service's internal SSH key provisioning exceeds its own 50s timeout. Unfortunately because this step is part of the main deployment, when it fails it takes the whole deployment down with it.

2. RoleAssignmentUpdateNotPermitted (kustoConfigure): This can happen when you re-run the deployment after a partial failure. The Kusto cluster's managed identity gets a new principalId on re-creation, but Azure won't let you update an existing role assignment's principal — so re-deployment fails.

What you can do right now

1. Delete the conflicting role assignment before re-deploying:

   PowerShell:

   Get-AzRoleAssignment -ResourceGroupName "rg-teamsvoice-demo-eastus-01" | 
     Where-Object { $_.ObjectType -eq "Unknown" } | 
     Remove-AzRoleAssignment

   Azure CLI:

   az role assignment list --resource-group "rg-teamsvoice-demo-eastus-01" \
     --query "[?principalType==''].id" -o tsv | \
     xargs -I {} az role assignment delete --ids {}

2. Re-run deploy.ps1 — the source control timeout is intermittent, so a retry usually succeeds. If it continues to fail, you can configure source control manually via the Azure Portal under Function App -> Deployment Center.

Fix incoming

We have a fix in progress that addresses both issues:

• Retry logic for the source control step so a timeout doesn't fail the entire deployment
• Role assignment GUIDs that include the identity, so re-deployments create new assignments instead of trying to update old ones

Will update this issue when the fix is merged.