1
votes

When using PowerShell and ARM library for creating a new WebApp (app service), you must supply a Name, ResourceGroupName and a Location. An App Service Plan is optional.
https://msdn.microsoft.com/en-us/library/mt619250.aspx

If you create a WebApp with the required parameters and without specifying an AppServicePlan then a new AppServicePlan will be created with the name 'Default_n' and having the same location as the WebApp.

Now If you 'do' specify an AppServicePlan with a different location than the WepApp:
PS New-AzureRmWebApp -Name TestWebApp -ResourceGroupName -DefaultResourceGroup -AppServicePlan MyServicePlan -Location EastAsia

The generated output will state that the location of the 'newly created' WebApp is East Asia although the AppServicePlan has a different location.

But if you watch the result in the ARM Portal then you'll see that the WebApp did inherit the location of its AppServicePlan. Which is to be expected...
And indeed if you look up the resource using PS:
Find-AzureRmResource -ResourceNameContains TestWebApp
Then you'll find that the WebApp's location is the same as its Container AppServicePlan..

Furthermore, if you try to create a new WebApp using the ARM Portal then you can not specify the location; but you 'must' specify the App Service Plan. The location of the App Service Plan determines the location of the WebApp, which seems logical.

So, what's the point of specifying a location when creating an Azure WebApp?

2

2 Answers

1
votes

While not directly an answer to your question, I feel like its significant enough to be provided here. I've been experimenting with an ARM Template that container a WebApp and an App Service Plan. So the template had something like:

{ # App Service Plan Starts here
   ...
   "location": "[parameters('location')]",
   ...
},
{ # WebApp Starts here
   ...
   "location": "[resourcegroup().location]"
   ...
}

So that was a copy-paste error on my part, which costed me a LOT of hours of troubleshooting. The behavior was exactly as you describe. So if I would deploy the template, the WebApp would correctly get assigned the location of the App Service Plan (because it doesn't make sense otherwise), but if I tried redeploying this template, it would fail, saying that my WebApp exists in another location and, therefore, can't be created in the location I was trying to create it (that's because the WebApp itself took location of the Resource Group, which was northeurope, while the App Service Plan was deployed to West Europe, so the ARM engine considered that these 2 WebApps are 2 different resources).
All of that being sad, I do believe its (at the very least) an overlook on the Microsoft Part (if not to say a bug in ARM logic).
Just like I said, this is not a direct answer to your question, but I think it shines some light on the question.

1
votes

The behavior is indeed quirky. Here is the deal:

ARM requires all tracked resources to have a location, which is why you get a failure is you don't specify it.

However, once the location gets to the Websites resource provider, it ignores it at creation time since the location is driven by the App Service Plan. But then on later updates it behaves differently and will fail it it's a mismatched.

The bottom line is that while it doesn't really make sense, you just need to always specify a matching location in the Web App.