Part 3: Deploy App Service as PaaS on Azure Stack

Previous Post in Series:  Part 2: Deploy MSSQL and MySQL as PaaS on Azure Stack

20/07/2017:  UPDATED for the Azure Stack Dev Kit

Ahoy there folks! In the last part of this series (see link above) we deployed both the MSSQL and MySQL resource providers to our Azure Stack POC environment. Now we’re going to go through the process for offering the App Service as PaaS, this isn’t too involved and should make for a fairly short guide. So without further ado…

Here’s a quick breakdown of what we’ll be covering:

Overview and Prerequisites

If you’re familiar with the App Service in public Azure, then you’ll already have a good idea about what we’re going to deploy as it’s built on the same code. On top of this, the App Service in Azure Stack uses the same UI as public Azure, both front end and back end, so if you have any experience here, you’re off to a flyer

We’ll go over the roles (VM instances) that will be deployed into our Azure Stack environment in a minute but first I’d like to go over what a web worker is, the different types and what they’ll do in the POC.

In the POC we’ll have the ability to deploy additional web workers as required, there are as follows:

A shared web worker will allow you the ability to deploy high-density multitenant applications. These applications will share the underlying resources of the VMs provisioned as shared web workers.

Unlike a shared web worker, a dedicated web worker can only server a single tenant and can be deployed as either small, medium or large size VMs.

NOTE:  Additional worker VMs can be deployed into the above tiers to scale out as required. It’s also worth noting that in TP3 a worker tier can have a maximum of 10 instances (worker VMs).

We also have the ability to create custom worker tiers in Azure Stack if the default ones don’t meet our tenants needs. These can be offered out to tenants by creating SKUs, these SKUs can be tailored to control features and resources offered. The screenshots below show some of the configurable options:


There is a lot more information on this out there, I just want to give you a quick overview before continuing on, and as mentioned above, if you’ve got previous experience with public Azure, you’re good to go.

The table below lists the VMs that will be deployed by the App Service installer and gives a little information on their place within the environment:

VM NameRole NameRole Description
CN0-VMControllerManages and maintains the health of the App Service cloud.
FE0-VMFront EndResponsible for routing requests to App Service hosted applications
WW0-VMShared WorkerResponsible for hosting Web/Mobile and API applications. It also hosts Azure Function Apps.
FTP0-VMPublisherResponsible for publishing content via FTP and Web Deploy
MN0-VMManagementResponsible for the App Service ARM and API endpoints, Portal Extensions (Admin, Tenant, Functions Portal), and the Data Service.

NOTE:  Additional web workers you deploy yourself will be named, WW1-VM onwards

NOTE:  A file server VM is also deployed named FS-VM. This VM serves as a file share target for the app service farm.


This guide assumes that you’ve already deployed MSSQL as PaaS on your Azure Stack infrastructure. You can find instructions for that HERE if you’ve yet to do it.

This guide also assumes that you’ve uploaded a Windows Server 2016 image to Azure Stack, this is also a prerequisite of deploying MSSQL and was covered in PART 1 of the guide.

Install PowerShell for Azure Stack

You’ll also need to have PowerShell for Azure Stack installed on the server you’re deploying the App Service from. If you’ve been following this guide from the beginning, then you’ll have already done this on both the host and the MAS-CON01 VM (this VM no longer exists in ASDK, use the physical host instead). If you haven’t, launch an elevated PowerShell console and paste in the following code, clicking “Yes” when prompted:

Set-PSRepository -Name "PSGallery" -InstallationPolicy Trusted

# Install the AzureRM.Bootstrapper module
Install-Module -Name AzureRm.BootStrapper

# Install and import the API Version Profile required by Azure Stack into the current PowerShell session
Use-AzureRmProfile -Profile 2017-03-09-profile -Force

# Install Azure Stack specific PowerShell modules
Install-Module -Name AzureStack -RequiredVersion 1.2.10

Turn off Internet Explorer Enhanced Security (IEESC)

Launch an elevated PowerShell console and run the following code to disable IEESC for both Admins and Users:

# Disable IE ESC
Write-Host "Disabling IE ESC" -ForegroundColor Yellow
$AdminKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-4b3f-8CFC-4F3A74704073}"
$UserKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-4b3f-8CFC-4F3A74704073}"
Set-ItemProperty -Path $AdminKey -Name "IsInstalled" -Value 0
Set-ItemProperty -Path $UserKey -Name "IsInstalled" -Value 0
Stop-Process -Name Explorer

Enable Cookies

In my experience, this step can be skipped as it’s already done if every deployment I’ve done so far. Here are the steps involved anyway, just in case.

  • Click the “Start Menu” and type “iexplore”
  • Right click “Internet Explorer” and select “Run as Administrator” (This can also be done by holding down “CTRL”, “Shift” and pressing enter).
  • Click the “Tools” icon in the top right, select “Internet Options”, “Privacy”, then “Advanced”
  • Make sure both options have “Accept” selected

If you already have PowerShell ISE open, close and reopen it.

Download Required Software

Most of the App Service deployment is taken care of by running the “App Service on Azure Stack preview installer”, get it HERE

You’ll also need to download the “Azure Stack deployment helper scripts”, get them HERE. This will be downloaded as an archive, extract it to C:\Temp\

Deploy App Service Resource Provider

As with most things, the getting ready takes more time than the actual doing, but we’re now done with that so let’s get on with the deployment.

Log onto the POC host as AzureStack\AzureStackAdmin

Create Certificates

The first thing we’ll want to do is create the certificates that will be used by the App Service during its installation and later when configuring Single Sign-On for Azure Stack functions etc.

Launch an elevated PowerShell console and change to the directory where you expanded the deployment helper scripts to earlier.

Now run:

cd C:\Temp\AppServiceHelperScripts\
.\Create-AppServiceCerts.ps1 -DomainName local.azurestack.external -CertificateAuthority AzS-CA01.azurestack.local

Enter a password for the .pfx certificates when prompted.

This will create 4 certificates, these are named as follows:

  • _.appservice.local.azurestack.external.pfx
  • api.appservice.local.azurestack.external.pfx
  • AzureStackCertificationAuthority.cer
  • sso.appservice.local.azurestack.external.pfx

Run the App Service Installer

NOTE:  The screenshots below were taken from TP3 but they’re identical to RC1 for the most part.

Run the AppService.exe and click “Yes” when prompted by UAC

On the first screen, select “Deploy App Service on your Azure Stack cloud”


Accept the license agreement and click “Next” for the next two screens, alternatively, just sit and stare at the greyed out “Next” button instead


The next screen should be populated automatically, review and click “Next”


Click “Connect” and enter the AAD account details you used during the deployment of Azure Stack


Now, it’ll look like nothing just happened, however, you can now click the drop down menus. Select the only available option under both and click “Next”


You’ll now be asked for your SQL server credentials. Enter the “sa” account details you used when deploying the MSSQL resource provider and click “Next”.


Browse and select the correct certificates, entering the PFX password you set when running the Create-AppServiceCerts script earlier. See the screenshot below to see what cert maps to each field.

Now click “Next”


Review the resources being allocated to each VM about to be deployed and click “Next”

NOTE:  You can allocate additional resource to some of the roles here, but I think that resource is better used for deploying tenant services etc. for testing purposes.


Select a platform image, this will likely be the “2016-Datacenter” image you uploaded to Azure Stack earlier. Click “Next”


Enter a username and password that will be used for the local administrator account on the VMs about to be deployed and click “Next”


Place a tick in “Select and click next to start the deployment”, then do as it says


Now go make yourself a coffee as this may take a while.

NOTE:  Contrary to the impression my guides probably give, I am not addicted to coffee.
CORRECTION:  It’s very likely I’m addicted to coffee

Here’s what the installer looks like as it goes through the early stages.


It seems quite common in my experience that one of the steps may fail on the first attempt, if this happens, clicking “Retry” usually sorts it out.

…and after 60 – 90 minutes, you’ll hopefully see the following:


Validate App Service Deployment

Now as far as the installer is concerned, our deployment was successful but let’s have a quick look ourselves to be sure.

  • Log into the Azure Stack admin portal using the AAD account you used during the deployment of Azure Stack
  • Navigate to “Virtual Machines”, click on “CN0-VM” and select “Connect”
  • Allow popups if prompted and click on “Connect” again
  • Log into the VM using the “AppServiceAdmin” account you created during the deployment of the App Service
  • Now launch the “Web Cloud Management Console” from the icon on the desktop
  • Now navigate to “Managed Servers”
  • Assuming all servers other than the “Web Worker – Shared (Shared)” show as “Ready”, then your deployment is good to go.

NOTE:  If your web worker also shows as “Ready”, all the better but it’s not a requirement to consider the deployment successful

NOTE:  Make sure at least one web worker shows as “Ready” before trying to deploy a Web/Mobile/API app or Azure function

Keep the RDP connection open as we’ll be using this server again to configure Single Sign-On in the next section.


Configure AAD Single Sign-On for Azure Functions Portal and Advanced Developer Tools

NOTE:  It is now possible to enable single sign-on for ADFS, this guide will be focusing on AAD though

So why configure Single Sign-On in our POC deployment? It will enable us to use the advanced developer tools (KUDU) within the App Service. It’s also required to enable the use of Azure Functions in the Azure Stack portal…so yeah let’s do it.

Log into your POC host as AzureStack\AzureStackAdmin and launch an elevated PowerShell console

Now paste the following code into the editor, edit as required and run it.  If you’re interested, here’s what it’s doing:

  • Prompts for your AAD Tenant Credentials (The ones used when deploying ASDK)
  • Prompts for your AAD tenant name (The one used when deploying ASDK)
  • Prepares PowerShell environment and logs into ASDK admin environment
  • Runs Create-IdentityApp.ps1 script with all required parameters (update “CertificatePasword” field before running)

NOTE:  The “CertificatePassword” field should be the password you used when creating the certificates during the AppService deployment.

# Get azure Active Directory Tenant Credentials (the ones you used during deployment)
$Creds = Get-Credential

# Your AAD tenant name
$AADTenantName = Read-Host "Enter your Azure Active Directory Tenant Name ("

# Import Required PowerShell Module
Import-Module C:\AzureStack-Tools-master\Connect\AzureStack.Connect.psm1

# Register Azure Stack environment
Add-AzureRMEnvironment -Name "AzureStackAdmin" -ArmEndpoint "https://adminmanagement.local.azurestack.external"

# Set GraphEndpointResourceId
Set-AzureRmEnvironment -Name "AzureStackAdmin" -GraphAudience ""

# Get Azure Active Directory tenant GUID
$TenantID = Get-AzsDirectoryTenantId -AADTenantName $AADTenantName -EnvironmentName "AzureStackAdmin"

# Log in to Azure Stack admin environment
Login-AzureRmAccount -EnvironmentName "AzureStackAdmin" -TenantId $TenantID -Credential $Creds

# Create-IdentityApp Script Parameters
$FilePath = "C:\Temp\AppServiceHelperScripts\"
$IdentityAppDetails = @{

    DirectoryTenantName              = "$AADTenantName"
    CertificateFilePath              = "$FilePath\sso.appservice.local.azurestack.external.pfx"
    CertificatePassword              = "Password used when creating certificate"
    TenantARMEndpoint                = "management.local.azurestack.external"
    DomainName                       = "local.azurestack.external"
cd $FilePath
.\Create-IdentityApp.ps1 @IdentityAppDetails -AzureStackCredential $Creds

So what actually just happened? The script created an application in your Azure Active Directory and generated a new PowerShell script based on your inputs. We’ll be running that script in a few moments.

Take a note of the “Application ID” the script spits out as we’ll need it later (See screenshot)

If like me you’re a complete fanny and accidentally closed the window before grabbing it, don’t worry.  Open up the PowerShell script that was just created (C:\Temp\AppServiceHelperScripts\UpdateConfigOnController.ps1) and look for the following line:

That’s your Application ID 🙂

Copy the following two files to C:\Temp\ on CN0-VM (these will be located in the directory you ran the last script from):


  • Now log into the public Azure portal using the AAD account you used when deploying Azure Stack
  • Navigate to “Azure Active Directory”, click “App registrations” and paste the ApplicationClientId into the search bar (it should still be in your clipboard)
  • Select the “App Service” that’s returned from the search and click “Keys”
  • Type “FunctionsPortal” into the “Key description” field
  • Select “Never expires” from the “duration” drop down menu and click “Save”
  • Copy the contents of the “VALUE” field to the clipboard

NOTE:  Navigating away from this blade will stop you being able to retrieve the key you just created. If this is the case, you’ll have to recreate it and remember to copy it to the clipboard

  • Now click on “Required Permissions”
  • Now click “Grant Permissions”, then click “Yes”
  • Back on CN0-VM, open the “Web Cloud Management Console” again and navigate to “Settings”
  • Right-click “ApplicationClientSecret” and select “Edit”
  • Now paste in the key you copied to the clipboard above and click “Ok” and “OK”
  • Now launch an elevated PowerShell console and run the following code (update the CertificatePassword value)
cd C:\Temp
.\UpdateConfigOnController.ps1 -CertificateFilePath C:\Temp\sso.appservice.local.azurestack.external.pfx -CertificatePassword "Password used when creating certificates during App Service deployment"

NOTE:  This script will update the configuration of the App Service on Azure Stack and then kick off a repair operation on all front end servers i.e. FrontEnd and Management VMs


Nice! That’s almost everything for this guide but let’s do one last thing, add an additional web worker VM.

Add Additional Web Worker VMs

There are two ways you can add additional web workers to your Azure Stack POC, these are as follows:

  • Using the App Service Resource Provider in the Azure Stack admin portal
  • Creating and configuring VMs manually and then adding them to the App Service Resource Provider

…we’re going with option 1

  • Log into the Azure Stack admin portal using the AAD account you used when deploying Azure Stack
  • Navigate to “Resource Providers”, “App Service” and click “Roles”
  • Now click “New Role Instance”
  • Under “Role Instances”, adjust the slider to deploy between 1 and 10 (maximum in TP3) new worker VMs
  • Under “Worker Tier”, select from “Shared”, “Small”, “Medium” and “Large” and click “OK”

NOTE:  Small, Medium and Large web workers are deployed to be dedicated to a single tenant.


Believe it or not, that’s pretty much all there is to it. The deployment itself will take a good long while, at least 60 minutes or so before it shows in the “Web Cloud Management Console” and a good long while after that while it installs all the required software it needs. Still though, I’m very impressed that it does all of that with so little administrative effort…anyway

Congratulations, we’re all done for the time being. Have fun playing about with the App Service on Azure Stack.

Time permitting, I’ll be creating a guide on Azure Stack management from both the admin and tenant perspectives, I hope to see you then.

2 Replies to “Part 3: Deploy App Service as PaaS on Azure Stack”

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.