Each ISE has its own dedicated storage and other resources that are kept separate from the "global" multi-tenant Logic Apps service. Internally It consists of four services: a Cloud Service, an App Service Environment (ASE), an API Management Service (APIM), and a Cache Service (note: The Dev Sku ISE does not have a Cache service and now you know why Dev Sku is not for production.). When we deploy an ISE, we are actually deploying these four services in the background. Any one of the four service fails to deploy, the ISE deployment deems a failure.
Most of the deployment failure was due to network configuration issues.
- Please understand and follow the main ISE deployment guide: https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment. It has the list of required inbound and outbound ports.
- If you are using forced tunneling, please be aware of its strict and long list of requirements: https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#forced-tunneling-requirements.
- Forced tunneling lets you redirect or force all traffic back to a firewall for inspection and auditing. It can be configured through UDR or ExpressRoute BGP. Basically the default route 0.0.0.0/0 is set with your firewall (instead of Internet) as the next hop.
- You must take care of the UDR requirement to avoid asymmetric routing.
- You shall enable the required service endpoints (Azure SQL, Storage, Service Bus, KeyVault, and Event Hubs) on all four subnets. Otherwise you will need to whitelist wildcard URIs such as *.vault.azure.net on your firewall.
- please pay attention to the ‘Other inbound and outbound dependencies’ requirement under https://docs.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment#forced-tunneling-requirements. For example, if a firewall blocks some seemingly unrelated URIs such as prod3.metrics.nsatc.net or www.thawte.com etc, it may cause the deployment to fail or render the deployed ISE unhealthy.
- Some may ask why there are so many requirements for using forced tunneling. Again, it is the combined requirements of the four internal components. Forced tunneling is where we have seen most deployment failures.
- If your virtual network uses custom DNS servers, you will need to add a DNS forwarder to Azure DNS server (188.8.131.52) or add Azure DNS server (184.108.40.206) directly to the list of the DNS servers for the virtual network.
- ISE requires four subnets. For testing purpose, you may want to create a test subnet on the same virtual network and apply the same NSG and UDE of the four ISE subnets. Then you can deploy a virtual machine (VM) to this subnet. You can log into the virtual machine to perform some tests. For example:
- Run “nslookup <YourAzureDBServer>.database.windows.net” to see whether DNS resolution is working to any of your Azure SQL instance.
- Run “telnet YourAzureDBServer>.database.windows.net:1433” to see whether destination port 1433 is open.
- View Effective Routes on the network interface of the VM and verify whether they meet the requirements from the main deployment guide: https://docs.microsoft.com/en-us/azure/virtual-network/manage-route-table#view-effective-routes
- ISE deployment can take up to 5 hours. There is no charge for failed deployment. There is no charge until an ISE is successfully deployed.
- When a deployment fails, you may want to delete the failed ISE. Deleting the ISE does not delete the four subnets. You will need to delete the subnets separately. But it may take up to nine hours before these subnets can be deleted. So if you want to retry the ISE deployment right away, you may want to create and use four new subnets.