Set-AzWebApp: Case of The Unexplained 409 Conflict When Adding HostName

tldr;

With Azure App Service, you could have the same Custom Domain assigned to multiple App Services at the same time. With one condition though: The same custom domain could not be assigned to two app services if there are in the same Deployment Unit <Scale Unit>.

When you call Set-AzWebApp with an updated Custom Domain Name (HostName), you expect the commandlet Set-AzWebApp to add the HostName to the desired web app. In case of a whatever error, you expect the Set-AzWebApp to throw an exception if the addition of the HostName failed.

Set-AzWebApp meticulously and miserably notifies you with a warning – not an error, a warning in a specific case that goes deep in to the Deployment Units (previously called Scale Units) and the App Service Plan you have chosen.

“

Microsoft.Azure.Management.WebSites.Models.DefaultErrorResponseException:

Operation returned an invalid status code ‘Conflict’

”

Here’s a screenshot of Azure Release Pipelines silently ignoring the warning as it was supposed to (and Set-AzWebApp should have thrown an error in possible senses instead of a warning), and letting the further dependent tasks fail.

With advise from one of my colleagues, when looked at the WebApp to which we were trying to add the host name to, it revealed another detailed error.

"statusMessage": "{\"Code\":\"Conflict\",\"Message\":\"The host name redacted is already assigned to another Azure website: redacted.\",\"Target\":null,\"Details\":[{\"Message\":\"The host name redacted is already assigned to another Azure website: redacted.\"},{\"Code\":\"Conflict\"},{\"ErrorEntity\":{\"ExtendedCode\":\"54004\",\"MessageTemplate\":\"The host name {0} is already assigned to another Azure website: {1}.\",\"Parameters\":[\"redacted\",\"redacted\"],\"Code\":\"Conflict\",\"Message\":\"The host name redacted is already assigned to another Azure website: redacted.\"}}],\"Innererror\":null}",

With Azure App Service, you could have the same Custom Domain assigned to multiple App Services at the same time. With one condition though: The same custom domain could not be assigned to two app services if there are in the same Deployment Unit <Scale Unit>.

Here’s some additional documentation from msdn that details out the condition.

https://docs.microsoft.com/en-us/azure/app-service/manage-custom-dns-migrate-domain#migrate-domain-from-another-app

You can migrate an active custom domain in Azure, between subscriptions or within the same subscription. However, such a migration without downtime requires the source app and the target app are assigned the same custom domain at a certain time. Therefore, you need to make sure that the two apps are not deployed to the same deployment unit (internally known as a webspace). A domain name can be assigned to only one app in each deployment unit.

You can find the deployment unit for your app by looking at the domain name of the FTP/S URL <deployment-unit>.ftp.azurewebsites.windows.net. Check and make sure the deployment unit is different between the source app and the target app. The deployment unit of an app is determined by the App Service plan it’s in. It’s selected randomly by Azure when you create the plan and can’t be changed. Azure only makes sure two plans are in the same deployment unit when you create them in the same resource group and the same region, but it doesn’t have any logic to make sure plans are in different deployment units. The only way for you to create a plan in a different deployment unit is to keep creating a plan in a new resource group or region until you get a different deployment unit.