PART I: Enable PaaS (Web Apps) in Azure Stack TP1
Welcome back at part 2 of the Web App Service deployment in Azure Stack. We left off on the part where the deployment of the SQL VM is finished and the WebSites VM’s are being deployed. When that’s finished log in to the portal and go to the WebsitesSQL resource group. In the resources section select the front-end loadbalancer and make note of the IP address:
Create an DNS wildcard record for the websites on the ADVM. The A record should be *.webapps.azurestack.local:
Go back to the portal and select the ManagementServerLoadBalancer and take note of the IP address:
Create for the IP an A record management.azurestack.local:
If you have followed the SQL tutorial there is already a *.azurestack.local wildcard certificate. Grab it from D:\SQLRP\AzureStack.SqlRP.Deployment.5.11.61.0\content\Deployment\Certificate. If you haven’t follow it, create one on the PORTALVM using the first part of the SQL Provider blog post. Also grab the Root CA from the ADVM (\\advm\c$\Windows\System32\CertSrv\CertEnroll\ADVM.AzureStack.local_AzureStackCertificationAuthority.crt) When done open on the Hyper-V host the console session to the MN0-VM (you can see in the description in Hyper-V manager what the machine name is. The VM names are all guids for Web Apps. When logged in the VM copy from the portal or CLIENTVM the certificate to the box and import it:
Place the RootCA in the Trusted Root:
On the Controller VM (CN0-VM) run this script:
|
1 2 3 4 5 6 7 8 9 |
Import-Module Websites $password="P@ssw0rd!" Set-WebSitesConfig -Type Global -ManagementServerCertificateFileName "C:\Users\admin\Desktop\_.azurestack.local.pfx" -ManagementServerCertificatePassword $password Set-WebSitesConfig -Type Global -ArmEndpoint "https://api.azurestack.local" Set-WebsitesConfig -Type Global -ArmResourceProviderUri 'https://management.azurestack.local/' Get-WebSitesServer -ServerType ManagementServer | Repair-WebSitesServer Get-WebSitesServer -ServerType LoadBalancer | Repair-WebSitesServer Get-WebSitesServer -ServerType WebWorker | Repair-WebSitesServer |
You can check the websites installation by opening the MMC and verify that the status under Managed Servers is ready :
In my install I had a continues repair of the Management VM and the FrontEnd VM. It turned out they needed a reboot for a windows feature installation. In my opinion this should have happen automatically as I can recall the same behavior when installing websites in Windows Azure Pack. When a failed attempt is reach to many times a reboot is initiated. This didn’t happen in my case. So if you experience issues with the website roles – reboot.
When all servers are in a “Ready” state open the Azure Stack Portal and log in as Service Admin and register the resource provider:
Or use Powershell:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 |
# Azure Active Directory tenant directory name [string]$AadTenantDirectoryName = "azurestackeu.onmicrosoft.com" # resource provider manifest endpoint. [System.Uri]$manifestEndpoint = "https://management.azurestack.local/" # resource provider manifest basic authorization credential. [PSCredential]$manifestCredential = get-credential Import-Module -Name AzureRM.Profile -ErrorAction Stop -Verbose:$false function Get-AzureRmProviderRegistrationInfo($azResourceProvider) { $rpInfo = [PSCustomObject]@{ Name = $azResourceProvider.Name DisplayName = $azResourceProvider.Properties.DisplayName ManifestEndpointUri = $azResourceProvider.Properties.ManifestEndpoint.EndpointUri Location = $azResourceProvider.Location Enabled = $azResourceProvider.Properties.Enabled } return $rpInfo } $azEnvironment = Add-AzureRmEnvironment -Name "AzureStack" ` -ActiveDirectoryEndpoint "https://login.windows.net/$AadTenantDirectoryName/" ` -ActiveDirectoryServiceEndpointResourceId "https://azurestack.local-api/" ` -ResourceManagerEndpoint "https://api.azurestack.local/" ` -GalleryEndpoint "https://gallery.azurestack.local:30016/" ` -GraphEndpoint "https://graph.windows.net/" $azEnvironment = Get-AzureRmEnvironment "AzureStack" $azAccount = Add-AzureRmAccount -Environment $azEnvironment if (-not $manifestCredential) { $manifestCredential = Get-Credential -Message "Manifest credential" -UserName "sqlRpUserName" } Add-AzureRMResourceProviderRegistration -Name "WebApp-LOCAL" -DisplayName "Microsoft.WebApps" -Location "local" ` -ManifestEndpoint $manifestEndpoint -UserName $manifestCredential.UserName -Password $manifestCredential.GetNetworkCredential().Password ` -ArmLocation "local" -ResourceGroup "System" -Verbose $azResourceProviders = Get-AzureRMResourceProviderRegistration -ResourceGroup "System" $azResourceProviders | %{ Get-AzureRmProviderRegistrationInfo -azResourceProvider $_ } | Sort-Object Name | Format-Table -AutoSize |
When the resource provider is registered deploy a A2 VM in the same Resource group as the WebSitesSQL resource group and in the same network as the other websites machines (ServicesVirtualNetwork should be listed as default network when you select that resource group). This VM will be a shared website worker role that we will add to the deployment as no workers are deployed at this moment. We need at least one for websites to run on and I never found the parameter in the script for the # shared workers (it should have according to the documentation), so will do it now manually. Now we also know how to scale workers in the future.
When the deployment is finished log in to the VM and rename the admin account you specified to admin. This is required as the deployment credentials we specified in the deployment didn’t allowed to be “admin”. Now back in the Azure Stack Portal as Service Admin look up the IP address from the VM:
Next go to the Resource Providers blade and choose the WebApp-LOCAL. Then go to the Resource Provider Management and go to Roles. Then choose Add Role:
Notice we need to run one command on the worker before we can install the worker. Run this command, after it, reboot the vm.
So before click on OK run this on the worker VM and reboot:
Back in the portal click OK. But very short after the creation I got this error:
But when I looked in the Controller VM I see it is added and deploying the worker role. So I waited the installation to be finished installing the worker role from the console:
In the meantime i was checking back in the portal. I also see there that the worker role is added:
In the meantime the worker is being deployed(Can take up to 60 min) I added the Web App service to a plan. Go to the “POCPlan” we created after the initial deployment of Azure Stack. Choose services and add Microsoft.WebApps. Configure quota’s (I used unlimited).
And finally login as tenant user and create a Web App. But… before you do, make sure the deployment is finished for the shared web worker role:
Create a web app:
And voila:
UPDATE 15-2: Florent mentioned to me that when you try to deploy websites with dependencies on SQL that the deployment failed. The cause was that the Worker VMs where not able to resolve the DB server name. Its trying to resolve on netbios name only. We had the same issue in Azure Pack when adding SQL AO to the Admin site for DBaaS. The solution is simple. On the worker vm open the network settings and go to properties:
Select Advanced and under the DNS tab add the azurestack.local to the search suffix.
Have fun with your Web App Service!
Mark Scholman
@MarkScholman