Part 4: Deploy App Service Resource Provider into ASDK

Previous Post in Series:  Part 3: Deploy MySQL Resource Provider into ASDK

So the last thing I want to cover in this series is the App Service RP deployment. Again, this is being deployed on the ASDK so all single-node rules apply.

Here’s a high level list of what we’ll be covering in this guide:

• Deploy File Server ARM Template
• Create App Service Certificates for Azure Stack
• Create an AAD Application
• Deploy App Service Resource Provider
• Test the App Service Deployment

The current version of the App Service requires access to a file server, luckily there is an ARM template online that’ll deploy a fully configured one for us.

 

Deploy File Server ARM Template

• Select “+ New”, “Custom” and “Template Deployment”

• Click “Edit Template”

• Click “Quickstart template” and select “appservice-fileserver-standalone” from the drop-down and click “OK”
• Now click “Save”

• Click “Parameters”
• Populate all required parameters and click “OK”

• Create and new resource group or use an existing one and click “Create”

Your template will now be validated and assuming everything is as expected will deploy without issue.

You can view your new File Server by looking in the “Virtual Machines” blade

 

Create App Service Certificates for Azure Stack

First, launch an elevated PowerShell ISE console, paste in the following code and run it to download and extract the App Service Helper scripts.

# Download and extract App Service helper scripts
Invoke-WebRequest -Uri https://aka.ms/appsvconmashelpers -OutFile C:\Temp\AppServiceHelperScripts.zip
Expand-Archive -Path C:\Temp\AppServiceHelperScripts.zip -DestinationPath C:\Temp\AppServiceHelperScripts
cd C:\Temp\AppServiceHelperScripts

The following code will create the PFX certificates required when deploying and configuring the App Service, update the $PFXPassword value before running.

# Create App Service certificates
$PFXPassword = ConvertTo-SecureString "Password here" -AsPlainText -Force
.\Create-AppServiceCerts.ps1 -PfxPassword $PFXPassword -DomainName local.azurestack.external

This will create the following 4 certificates:

Certificate Name	Purpose
_.appservice.local.azurestack.external.pfx	App Service default SSL certificate
api.appservice.local.azurestack.external.pfx	App Service API SSL certificate
ftp.appservice.local.azurestack.external.pfx	App Service Publisher SSL certificate
sso.appservice.local.azurestack.external.pfx	App Service Identity Application certificate

Now we need to grab the Azure Stack root CA certificate (CER format). Run the code below and enter your “AzureStack\AzureStackAdmin” credentials when prompted

cd C:\Temp\AppServiceHelperScripts
.\Get-AzureStackRootCert.ps1 -PrivilegedEndpoint "IP Address for Azs-ERCS01" -CloudAdminCredential (Get-Credential)

 

Create an AAD Application

Not everyone will need to complete this section but I’d suggest you run through it anyway, no point limiting some of the capabilities of your ASDK environment.

NOTE:  Although this whole guide is geared towards an Azure AD deployment of the ASDK, this step in particular is ONLY for Azure AD deployments.

However, completing this section will net you the following capabilities:

• Virtual machine scale set integration on Worker tiers
• SSO for Azure Functions portal
• SSO for the advanced developer tools in the App Service (Kudu)

In an elevated PowerShell console:

• Run the C:\Temp\AppServiceHelperScripts\Create-AADIdentityApp.ps1 without parameters and specify them as you’re prompted. The script doesn’t appear to prompt for your AAD credentials otherwise and will fail as a result.

The table below lists the expected values for each parameter you’ll be asked to input:

Parameter	Expected Value
DirectoryTenantName	Your AAD directory name you've used throughout the ASDK deployment e.g. mydirectory.onmicrosoft.com
AdminArmEndpoint	adminmanagement.local.azurestack.external
TenantArmEndpoint	management.local.azurestack.external
CertificateFilePath	C:\Temp\AppServiceHelperScripts\sso.appservice.local.azurestack.external.pfx
CertificatePassword	Whatever you used when creating the certificates earlier

You’ll now be prompted to enter your AAD credentials by means of a pop-up.

Success looks like…

NOTE:  Take a note of the App ID number output in PowerShell (marked above in red) as you’ll need it in an upcoming step

Now we want to associate the required permissions with the application the above script just created in our Azure AD. With that in mind log into your account at https://portal.azure.com

• Select “Azure Active Directory” and “App Registrations”
• Paste the App ID you saved from the PowerShell output earlier into the search bar, you should see a single result, click it

• Click “Required permissions”, “Grant Permissions” and then “Yes”

…and that’s it for this section, let’s crack on and install the App Service RP.

 

Deploy App Service Resource Provider

Now that all the prep work is out of the way, let’s launch the App Service installer on our ASDK host. You can download it HERE

• Once launched, click “Deploy Add Service on your Azure Stack cloud”

• Accept both license agreement screens by placing a tick in the box and clicking “Next”
• The next screen will be auto-populated, review the details and click “Next”

• Click “Connect” and you’ll be prompted for the AAD credentials you used to deploy the ASDK. Once you enter them it’ll look like nothing happened, but it did.
• Click the “Azure Stack Subscriptions” drop-down and select “Default Provider Subscription”
• Click the “Azure Stack Locations” drop-down and select “local”
• The remaining two fields will now self-populate, click “Next”

• Now you’ll need the FQDN (or IP address) of the file server you’ll be using with the App Service. If you used the ARM template deployment earlier in this guide, you’ll find the FQDN location in the screenshot below:

• In the “File Share UNC Path” box, enter your file server “\\FQDN\Websites“
• Enter the credentials you set for the “File Share Owner” and “File Share User” and click “Next”

• In “Identity Application Id”, enter the App ID you saved from the earlier PowerShell output
• In “Identity Application certificate file”, browse to the “sso.appservice*” PFX certificate you created earlier and enter its password below
• In “Azure Resource Manager” browse to the “CertificateAuthority” CER certificate you created earlier in this guide
• Now click “Next”

• Browse to the correct certificates using the screenshot below as a guide.
• Enter the password you set for the PFX certificates earlier
• Click “Next”

• Enter the FQDN of the SQL Server we set up earlier in the guide
• Enter “sa” for the username
• Enter the password for the “sa” account

NOTE:  This will FAIL and it’s not because you’ve done anything wrong, it’s because the deployment of the SQL VM also creates a Network Security Group on the SQL subnet that blocks all traffic inbound to the default SQL port 1433. Let’s correct that.

You can check this by running the following from PowerShell

TNC sqlvmname.local.cloudapp.azurestack.external -Port 1433

The output will look something like this:

NOTE:  Take a note of that source address, you’ll need its subnet in a minute e.g. 192.168.200.0/24

From that we can see that traffic from our Azure Stack host management NIC is blocked to our SQL VM on port 1433, as above, let’s attend to that.

• From the Azure Stack Admin portal, select “More services”, type “Network security groups” into the search bar and click it

• Select “SqlVM11**-SSG”

• Select “Inbound security rules” and click “Add”

• Enter a name for the new rule e.g. “AllowSQLFromManagement”
• Enter a “Priority” of “245”
• Change the “Source” to “CIDR block” and enter the management subnet you noted above e.g. 192.168.200.0/24
• Select “MS SQL” from the “Service” drop-down
• Make sure the “Action” is set to “Allow”
• Click “OK”

NOTE:  If you don’t see a drop-down for “Service”, click “Advanced” or “Basic” at the top of the blade, whichever is showing, I’ve noticed this sometimes displays the wrong value, but the button still does its job

Once you receive a notification advising the rule has been successfully created, repeat your connectivity test in PowerShell, it should succeed.

With that sorted, let’s go back to our App Service installer, you should now be able to click “Next” on the SQL configuration page.

• Click “Next” to accept the default SKUs presented, making sure your physical host has the required cores and RAM available to continue with the deployment

NOTE:  I actually changed the size of the “Controller Role” VM to a “Standard_A2” as I was getting repeated timeouts during the deployment. This appeared to resolve my issue.

• Click “Next” to accept the default image. It should be “2016-Datacenter – latest” if you’ve been following this guide.

NOTE:  You cannot use a core image here as it’s not a supported deployment for the App Service

• Choose and enter a username and password that’ll be used when deploying the App Service roles. Ideally you would use a different username and password set for the “Admin” and “Other Roles”, I’m using the same as this is a lab deployment.
• Click “Next”

• Place a tick in the box labelled “Select and click next to start the deployment”
• Click “Next”

Now go have lunch or something as this deployment will take at least 60 minutes, in my experience it’s a good while longer than that.

When complete, you should be looking at something similar to the screenshot below:

• Now click “Exit”

OK, so the installer says that we have a successful deployment, let’s go confirm that in the portal, shall we?

• Select “More Services”, then “App Service”

• Under status, it should read “All roles are ready”

If you’re curious, you can also have a look at the available roles and the number of instances deployed.

• Select “Roles”

 

Test the App Service Deployment

That pretty much completes our ASDK deployment but being that we’ve spent so much time getting to this point, we’re going to want to test things, right?

Well before we continue, it’s worth pointing out that we’ll need to be logged in as a tenant before we can deploy a web app to our shiny new App Service, and before we can do that we’re going to need to create an offer our tenant can subscribe to…so let’s do that.

You can find out a little more about quotas, plans, offers and subscriptions HERE as I covered it in an earlier guide.

 

Create a Plan

From within the ASDK Admin Portal: https://adminportal.local.azurestack.external:

• Select “More Services”, “Offers + Plans” and “Plan”

• Give your new plan a name in “Display name”
• “Resource name” will be auto-populated based on the name you gave above
• “Provider subscription” will be auto-populated
• Create a new “Resource Group” or use an existing one
• Select “Microsoft.Compute”, “Microsoft.Network”, “Microsoft.Storage”, “Microsoft.Web”, “Microsoft.SQLAdapter”, “Microsoft.MySQLAdapter” and click “Select”
• Select existing “Quotas” or create new for each of the services you listed above and select “OK”
• Now select “Create” to create the plan

 

Create Offer

Now that we have a plan containing the services we want to provide to our tenant, we need to create an “Offer” to…well…offer it out.

• Select “+New”, “Offers + Plans” and “Offer”

• Give your new Offer and name in “Display name”
• “Resource name” will be auto-populated based on the name you provided above
• “Provider subscription” will be auto-populated
• Create a new “Resource Group” or use an existing one
• For “Base plans”, select the plan we created earlier and click “Select”
• Click “Create” to create our new offer

NOTE: In a production setting, it’s likely I’d have separated out SQL, MySQL and the App Service into their own plans and added them as “Add-On” plans but for the purpose of this guide bundling them all together is fine.

 

Creating a Tenant

Just to keep things separate, I created a tenant user within my Azure Active Directory for this purpose, if you want to do the same, here’s how:

• Log into the AAD account you deployed the ASDK into https://portal.azure.com
• Select “Azure Active Directory” and click “Add a user”

• Enter a name for the new user
• Enter a username for the new user
• Place a tick in “Show Password” and copy the value to the clipboard by clicking the button
• Click “Create”

 

Create Tenant Subscription

Armed with a new tenant, we’re going to jump back across to ASDK admin portal and subscribe them to the offer we created earlier.

• Click “Offers” and select the offer we created earlier

NOTE:  Offers by default are private and cannot be seen by tenants. For this example that’s OK as we’ll be creating the subscription on behalf of our tenant.

• Select “User subscription”

• Enter friendly name for the subscription
• Enter the username for the user you created in the last section e.g. user@AADDirectory.com
• Click “OK”

Let’s jump across to the tenant portal and sign-in as our tenant https://portal.local.azurestack.external using the temporary password you copied from the portal when creating the user.

You’ll now be prompted to reset your password as the one given at the point of user creation was temporary

Once logged in, select “More Services” and “Subscriptions” and you’ll see that we already have a subscription due to the steps we took above.

 

Create New Web App

OK, we should now have everything in place that will allow us to deploy a web app as a tenant on our ASDK environment. Let’s get to it.

• Select “+ New”, “Web + Mobile” and “Web App”

• Enter a name for your Web App
• Create a new “Resource Group” for your Web App
• Select “App Service plan/Location” and “Create New”
• Enter a name for your “App Service plan”
• Select “Pricing Tier”, select “D1 Shared” and click “Select”
• Click “OK” to create your “App Service plan”
• Click “Create” to create your Web App

Once you receive the successful deployment notification, let’s go and confirm it by browsing to it

• Select “App Services”, “Deployed App Name” and click the “URL” to launch your Web App in the default browser

Nicely done, you can now drop some test website files in there and maybe even setup a DB and connect the two.

Well that’s it for this series folks, I hope it helps make your ASDK deployments a little more seamless…at least until the process changes again, and if that happens, I’ll see you in the next guide 🙂