Deploying an ILB App Service Environment

Microsoft recently changed the ILB deployment in a big way. You can no longer specify your own domain name for your ILB ASE, you will now be using the appserviceenvironment.net domain by default. The reason for this change is actually a great one. No more having to deal with the ILB Certificate. Yes, by using the default appserviceenvironment.net domain, Microsoft will be taking care of the SSL certificate. 

So let's summarize what changed:

• ILB ASE now uses the domain appserviceenvironment.net by default
• appserviceenvironment.net is still not a public domain and you need to take care of the DNS for it
• No need to provision the ILB Certificate, will be taken care of by Microsoft by default
• Using Custom Domains on Web Apps inside the ILB ASE will be on per Web App base, just like outside of the ASE. Remember that the DNS for these custom domains is still in your hands and within local DNS inside the VNET
• KUDU will now only be usable using the appserviceenvironment.net domain, a.k.a webappname.scm.asename.appserviceenvironment.net

So we will be deploying an ILB ASE and do the initial configuration

Let's start!

Table of Contents:

• Deploying an ILB App Service Environment
• Requirements
• ASE subnet creation
• Create the ASE
• Create and Configure DNS
• Creating a Web App inside the ASE
• Adding Custom domains to Web Apps inside the ASE
• ARM Deployment
• Troubleshooting ILB ASE

Requirements

• Understand the concept behind App Service Environment. It is fine if you have never deployed an ASE but to fully understand this tutorial you need to have an idea of the ASE is in general. I suggest you get familiar with the official docs
• Existing VNET or a new VNET
• VM inside that VNET from which we can test access

If you want to create the resources necessary to start this lab, you can do it with 1 click with my 1-click ready Deployment

https://github.com/Djongov/ARM-templates/blob/master/README.md#ilb-app-service-environment-v2---deploy-the-basic-requirements--a-vm-to-test-it

ASE subnet creation

First let's create an empty subnet for our ASE(requirement). I will be choosing a VNET where i already have a deployed VM (in another subnet) so i can do tests from it.

Create the ASE

Let's start creating the ASE

Use this link to directly get started: https://portal.azure.com/#create/Microsoft.AppServiceEnvironmentCreate

Basics tab

• Choose a resource group
• Choose Internal Virtual IP Type
• Give it a name
• Go to next tab - Networking

Networking tab. The subnet should usually autofill with an empty subnet in that VNET.

Review and Create tab

Your ASE is ready to be deployed now. Create it. It should take around 1h-1.5h

Create and Configure DNS

Now, while the ASE is being deployed, let's take care of the DNS

We will be using Private DNS zone in this tutorial. You can of course use normal Windows Server DNS if you want to, just make sure that the VNET's DNS Servers are specified and pointing to your DNS server, instead of the default Default (Azure-provided).

Use this link to directly get started: https://portal.azure.com/#create/Microsoft.PrivateDnsZone-ARM

It's a simple configuration - Choose subscription and resouce group and then for name give it - asename.appserviceenvironment.net

Create it. Now, let's link it to our VNET. Browse to the newly created Private DNS Zone and click "Virtual network links" and then Add.

Disclaimer! If you already use Custom DNS Servers on the VNET, these links will not work! The VNET DNS Servers should be set on "Default (Azure-provided)".

Give it a name and show it the VNET you want to link it to

Add the link. It should start working immediately without having to restart anything.

Make sure the link is in Completed state

Let's add some records

Go back to the Overview tab on the Private DNS Zone

Let's create these three A Records:

Name: *

Type: A

IP Address: ILB Address (usually the subnet's range .11, in my case 192.168.11.11)

We use wildcard (*) so we cover all the possible web app names that you might create in the future. Another choice is just to create the records with the web app names you know you will have

Example: webappname.asename.appserviceenvironment.net but because i am still not sure what my apps will be named I will be using wildcards in this tutorial

Note that we only have to give it a name of *.azuretechguyase as the rest of the domain (.appserviceenvironment) is already covered by the zone's domain

Here is how the record will look like during creation:

Let's also cover SCM (KUDU). Another record:

Name: *.scm

Type: A

IP Address: ILB Address (usually the subnet's range .11)

Now, time for our third DNS record. Let's cover the naked domain for the ASE domain (asename.appserviceenvironment.net):

(without this record, logging into KUDU will fail)

Name: @

Type: A

IP Address: ILB Address (usually the subnet's range .11)

So after creating the three records my zone looks like this:

Now the only thing we need to do is just wait for the ASE to be deployed

Once the ASE is deployed and ready, make sure that the ILB IP Address is the one we predicted and if not adjust the DNS records

Creating a Web App inside the ASE

Now it's time to create an App Service Plan which will host our web apps

Use this link to directly get started: https://portal.azure.com/#create/Microsoft.AppServicePlanCreate

Make sure that the Region is the ASE and not any other nornal region, that way you will be able to get the Isolated App Service plan tiers

Once the App service Plan is deployed successfully (can take up just a minute or two but can stay in Provisioning state for longer) let's create our first Web App in this Isolated App Service plan

Use this link to directly get started: https://portal.azure.com/#create/Microsoft.WebSite

Again make sure that the region is the ASE so the app will get deployed to the newly created Isolated App service plan within the ASE. You will notice when the .azurewebsites.net changes to your ase domain

When the Web App is deployed let's try to browse it from a VM inside that VNET 

My web app is called webapp, so the URL is https://webapp.azuretechguyase.appserviceenvironment.net. Did it work? if not try out my Troubleshooting section below

Try the KUDU as well. URL is https://webappname.asename.appserviceenvironment.net. In my case https://webapp.scm.azuretechguyase.appserviceenvironment.net. If you hit a Microsoft authentication page, it means it's working. If you can't login using a Microsoft account you can try with Basic Authentication by adding /basicauth in the end - https://webapp.scm.asename.appserviceenvironment.net/basicauth. This will prompt you with a pop up basic authentication window for which you can use the crednetials stored in the Publishing profile of the app. You can get these from the Web Apps' Overview blade and by clicking "Get Publishing profile" button.

Remember! KUDU is only accessible with the appserviceenvironment.net domain. Later when we add custom domains to the Web App - you will not be able to access KUDU using these domains like we used to in previous builds - webappcustomdomain.scm.asedomain.com

Adding Custom domains to Web Apps inside the ASE

Adding a custom domain to a Web App hosted in an ASE is as easy as adding one on a normal Azure App Service Web App. However, we need to remember that we still need to take care of the DNS privately as the ILB ASE is still entirely accessible through private IPs away from the public. The rule still applies where you can add any custom domain to your ASE Web apps without any verification. 

Let's use contoso.com

First, we will need to create another Private DNS Zone that will deal with contoso.com. Do the same steps as with appserviceenvironment.net but this time just name the Private DNS Zone - contoso.com. Create a Virtual Network link to the VNET as well.

Add two DNS records in the contoso.com Private DNS Zone:

Name: @

Type: A

IP Address: 192.168.11.11 (in your case your ILB IP Address)

and

Name: www

Type: CNAME

Alias: contoso.com

Browse to your Web App and go to Custom Domains. Add contoso.com and www.contoso.com.

Go back to your VM. Do a ipconfig /flushdns in a CMD just in case and try to browse http://contoso.com and http://www.contoso.com. Did it work? If not, the same rules apply to troubleshoot this as if you had problems browsing with the appserviceenvironment.net domain

Now if you want to use HTTPS, that's another story. Then what you need to do is the same as what you would do outside of the ASE. Provision a proper SSL certificate, make sure you convert it to a .pfx. Go to your Web App TLS/SSL settings, go to Private Key Certificates  (.pfx) tab, upload your certificate, create the bindings and your app will be accessible with HTTPS. I obviously won't be able to do it as i don't own the contoso.com domain.

If you want to use a self-signed certificate make sure to use the official documentation - https://docs.microsoft.com/en-us/azure/app-service/environment/certificates

ASE ARM Deployment

If you are looking to make an ARM deployment for the new ASE you might want to look at some of my ready templates

https://github.com/Djongov/ARM-templates

For example, I have a template that deploys the whole environment needed to to have a fully configured and ready to use ASEv2. Refer to the diagram below for example:

Troubleshooting ILB ASE

Most common issues are DNS resolution. Try the resolution by pinging your web app's URL in CMD. If it returns an IP address even if it doesn't get any successful replies, it means your name resolution is fine. If not you will receieve "Ping request could not find host XXXX. Please check the name and try again." This means that your web apps are not resolvable and DNS needs fixing .Try one of these methods to confirm DNS issue or not:

• Review your DNS configuration for any spelling mistakes on the DNS zone or the individual DNS Records. The appserviceenvironment.net is a hard to write down domain so mistakes can happen and copy/paste should be used instead.
• To eliminate issues with your DNS configuration, use the hosts file to confirm that DNS is in fact the sole issue here. Open your hosts file as an Administrator with either Notepad or Notepad++ (C:\Windows\System32\drivers\etc) and the following entries (tailored to your web app URLs and IPs) and Save:

192.168.11.11 webapp.asename.appserviceenvironment.net
192.168.11.11 webapp.scm.asename.appserviceenvironment.net

192.168.11.11 asename.appserviceenvironment.net

• Open CMD, do ipconfig /flushdns and try to ping your web app again. If it starts to return an IP (even if no reply) then try browsing the web app from a browser. If it works, it means that DNS configuration on your DNS server/zone needs fixing
• Make sure that the VNET is either using Custom DNS servers on the VNET or a Private DNS Zone via Virtual Networkin Link and the VNET's DNS Server is set to Default (Azure-provided) - but not both.
• if you use your own DNS Server, make sure that other domains hosted on this DNS server are resolvable and not only your appserviceenvironment.net domain has issues