Why has the "Auto generate unique domain name" toggle disappeared from Portal UI

Question

Hi,

To my dismay, this week (change possible happened last week), after I asked a colleague to deploy a dozen or more Function and Web Apps to App Service Plans, upon conducting a review of their activity I noticed that the private endpoints they had created had been private DNS zone integrated as requested, but that the records contained the app name as well as a unique string appended to it. Since the Portal was being used to deploy these apps, my first thought was that my colleague had forgotten to untick the Ensure unique default hostname toggle on the Basics page during creation.

Low and behold, that option is no longer visible.

I have 1000s of applications which I know the names of per our naming standards. It's therefore easy for me to derive the FQDN for these apps because it is standard practice for us to deselect the ensure unique toggle.

Now, the only solution through the portal is the final step, instead of clicking review and create, to download the template, look for the "autoGeneratedDomainNameLabelScope" line in the properties of the service and remove it entirely, before then deploying from template, which also requires some extra steps like selecting "Use 32-bit worker" to false etc.

Why did Microsoft think that it was a good idea to enforce this in the UI/UX? Luckily the ARM API doesn't enforce this behaviour.

I can't find anywhere where this change was communicated to customers.

I doubt I'm the only architect who gets annoyed at inconsistency, and losing this ability for DNS names to be predictable. We have a very specific naming standard and never run in to duplicate naming issues.

I'm quite sure there's a lot of architects / engineers out there using click-ops in many cases which are going to be very unhappy with this change. This isn't just about predictability or consistency, it's about changes being made in the Portal that have tangible impact to the way we operate without any prior notification. Personally, and I hope people would join me on this, I'd like to see that toggle returned!

Many thanks,

Jamie.

Answer 1

hi Evans, Jamie (Cognizant) & thx for sharing urs issue here at Q&A portal,

portal change appears to be deliberate, although I agree it’s poorly communicated. Microsoft is pushing secure unique default hostnames to reduce dangling DNS and subdomain takeover risk. The generated hostname includes a deterministic hash based on the selected reuse scope. The ARM API still supports autoGeneratedDomainNameLabelScope, and omitting that property preserves the traditional predictable <app-name>.azurewebsites.net hostname. So this isn’t currently enforced by the App Service platform itself; it’s the portal creation experience applying a safer default.

For an environment with thousands of resources and established naming standards, I wouldn’t use the portal workaround manually. This is exactly where Bicep, ARM, Terraform, or an internal deployment template should define the required behavior consistently.

I haven’t found a public announcement explaining why the toggle was removed or confirming whether it will return. It may be worth opening portal feedback and an App Service support request asking whether this is an intentional permanent UX change. The inconsistency between the portal and API should at least be documented clearly.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Answer 2

Hi @Evans, Jamie (Cognizant)

Greetings for the day, Thanks for contacting Q&A

Secure unique default hostnames are enabled by default in the Create Web App wizard and the toggle has been removed. If you need to create web app with the feature disabled or using different Hash scope, you need to use Azure CLI/PowerShell/REST API/ARM/Bicep instead.

Please click Accept Answer and upvote if the above was helpful.

Thanks