First published on MSDN on May 13, 2016
When creating a new Azure App Service Environment (ASE) there are certain scenarios that will make the deployment fail after about 5 hours with an error similar to the following in the Audit logs:
Resource ID: /subscriptions/{Subscription ID}/resourceGroups/Default-Networking/providers/Microsoft.Web/hostingEnvironments/{ASE name}
Error: {“error”:{“code”:”ResourceDeploymentFailure”,”message”:”
The resource provision operation did not complete within the allowed timeout period.
”}}
Note:
Audit logs can be accessed in the
Azure Portal
by clicking in Browse and then Audit logs.
Although we are working on improving the experience for these scenarios in the meantime it’s useful to be aware of the following scenarios that you should be careful about when creating a new ASE:
DNS not able to resolve public hostnames.
Update:
ASE now defaults to Azure DNS whenever is not able to resolve a public hostname of any of its resources, so DNS shouldn’t be an issue anymore.
Issue:
If the DNS server(s) configured on the VNET that you choose when creating the ASE is/are not able to resolve public hostnames, then the ASE will fail during and after creation:
From
How To Control Inbound Traffic to an App Service Environment
:
“The DNS configuration for the virtual network must be capable of resolving all of the endpoints and domains mentioned in the earlier points. If these endpoints cannot be resolved, App Service Environment creation attempts will fail, and existing App Service Environments will be marked as unhealthy.”
Solution:
To verify if this is the case, you can test it from an Azure VM on the same VNET that will be used for the ASE or from an on-premise machine configured to use the same DNS servers:
1. In a command prompt type ”
nslookup
” and hit enter
2. You will get a > prompt. In there, type the following command and then hit enter:
server
<IP ADDRESS of DNS Server>
where <IP ADDRESS of DNS Server> is one of their DNS servers configured on their VNET
3. Type each one of the following names and hit enter afterwards:
management.core.windows.net
mscrl.microsoft.com
crl.microsoft.com
ocsp.msocsp.com
If successful, the response should contain the IP Address for that name. If unsuccessful, it will report and error saying it can’t find it followed by “Non-existent domain”
If that’s the case, try one of the following:
Remove the custom DNS server(s) from your VNET. The default Azure DNS servers will be used.
If you need to use your own DNS servers, make sure they can resolve public host names. In order to do that you will have to configure your DNS servers to either use root hints or to use forwarders.
Change the DNS server to use some public DNS (like Google’s 8.8.8.8 for example).
Subnet used by ASE is too small
Issue:
If the VNET selected doesn’t have enough room for all the instances that the ASE will use, the deployment will fail. Make sure your subnet range is big enough to allow current and future growth of your ASE.
Solution:
Provide a subnet range big enough. If not sure how many IP addresses are available, try using an
IP calculator
.
For more information see:
How to Create an App Service Environment
ExpressRoute issues
Issue:
When using ExpressRoute, if ExpressRoute is not allowing connectivity to any of the endpoints required by ASE, it will make the ASE deployment fail.
Solution:
Change your ExpressRoute configuration so that it allows the network connectivity requirements of an ASE:
See the following article for network requirements when using ExpressRoute in an ASE:
Network Configuration Details for App Service Environments with ExpressRoute
For more information, see:
ExpressRoute routing requirements
Bad Network Security Group (NSG)
Issue:
When using Network Security Groups (NSGs), if they block communication to or from the machines within the ASE, this will prevent ASE creation and ASE will become unhealthy if the conflicting NSG is configured after creation.
Solution:
Change the NSG(s), so that it doesn’t affect the ASE environment.
How To Control Inbound Traffic to an App Service Environment
Forced Tunneling enabled
Issue:
If the VNET used for the ASE has Forced Tunneling enabled, it will force for all Internet-bound traffic from the ASE to go back to on-premises location via a Site-to-Site VPN tunnel, which will change the source IP address to one of the NAT IP addresses. When this traffic reaches Azure resources needed for the ASE (like the Azure SQL database), it will fail as we only allow traffic coming from Azure to access it in those resources.
Note: Forced Tunneling can be enabled via a User Defined Route (UDR) for a Site-to-Site VPN tunnel or as a default route view ExpressRoute BGP peering session for ExpressRoute.
Solution:
Turn off Forced Tunneling or use a different VNET. For more information see:
Network Configuration Details for App Service Environments with ExpressRoute
Configure forced tunneling using the classic deployment model