Intermittent failures on App Service VNet integration via ARM template

Question

Hi all,

I'm trying to use the VNet integration feature for my app service in East US 2, however I'm running into intermittent problems whilst trying to deploy via ARM templates. I'm getting this "NotImplemented" status message on the Microsoft.Web/Sites/config resource about half the time I try to deploy (either to an empty or populated RG):

"statusMessage": { "Code": "NotImplemented", "Message": "Access is denied.", "Target": null, "Details": [ { "Message": "Access is denied." }, { "Code": "NotImplemented" }, { "ErrorEntity": { "ExtendedCode": "51000", "MessageTemplate": "Access is denied.", "Parameters": [], "Code": "NotImplemented", "Message": "Access is denied." } } ], "Innererror": null }
I'm following the ARM template sample detailed here: https://github.com/MicrosoftDocs/azure-docs/issues/20348#issuecomment-469147232

I have essentially replicated the ARM template described there, but I'm receiving the above error as if it were dictated by the toss of a coin. Also, instead of failing, the deployment just hangs until the it times out.

Initially I managed to whittle it down to a specific location where I was seeing the error. Namely, when I deployed to UK South, everything worked fine. When I deployed to East US 2, I got the above error.

I then updated all of the api versions in my ARM template, which seemed to do the trick to get the deployment to East US 2 working. But then, after nothing at all had changed in my ARM template, the deployments started failing again with the above error.

I then wondered whether it was a conflict between a siteConfig property I was setting on my Microsoft.Web/Sites resource and the virtualNetwork config resource, but I couldn't consistently recreate the same behaviour. Sometimes it worked fine, sometimes it didn't.

As mentioned, I now have pretty much exactly what is implemented on that GitHub page (without the storage account, but with the siteConfig app service resource property and a httpsOnly flag). I've checked the checklist on things that can cause the new VNet integration to fail, but everything I'm doing conforms to these constraints.

I'm not entirely sure where to go from here - is this a known bug, or am I doing something wrong? Has anyone else seen this behaviour?

Any help here would be appreciated!

Thanks,

Ed

Answer 1

Hi Ed,

Based on this Github thread, it looks like you got a response to your question after opening a support ticket. Posting your response here to help others who might come across the same issue. Thanks for sharing your response with the rest of the community.

"After opening a ticket, it transpires that some of our app service plans were being deployed to stamps (clusters of servers within datacenters) within East US 2 which didn't support the new preview integration feature. Some stamps do support it, some don't. Hence the inconsistency in our deployment results!

The docs list one of the limitations as:

The feature is only available from newer App Service scale units that support PremiumV2 App Service plans.

However, the only way you can ensure you're on this new infrastructure is if you initially deploy your app service plan as P1v2, P2v2, or P3v2. You can then scale it back down to a standard SKU, if you wish. There's no way to say "I want a Standard sku which supports scaling to a Premium V2 sku."

We've opted to deploy as a P1v2 initially, then use PowerShell to scale back down straight after. You could also use another ARM template, of course, or just do it manually in the portal :)"

Sourced from Github.

Answer 2

I have faced the same issue for eastus2 region but it worked for central us , As it is in preview feature Microsoft rolling out feature to datastamps across the data center it is not fully rolled out for lower sku. So i used P1V2 version then scaled down via portal