How to deploy the Azure Stack Hub ASDK inside a nested Azure VM

The Azure Stack Hub ASDK is very useful for learning Azure Stack Hub and getting a general idea of how it works and how it differs from Azure Global. It does have its limitations, and is not suitable for any kind of production workload. Most people do not have a physical server laying around which can accommodate the heavy infrastructure needs of the ADSK. It is possible to nest the entire thing within an Azure VM, with that said, most people don't have access to an Azure subscription with no spending limit either. 

The Azure VM SKU selected below is Standard_E32s_v3 which has 32 vCPUs and 96GB of memory. This SKU also supports the ability to run nested virtualization. 

• Open Azure Shell from the Portal - setting PowerShell as the language of choice.

• Run Find-Script Deploy-AzureStackonAzureVM | Install-Module -Force to install the module to deploy a suitable VM to host the ASDK. 

• From here run Deploy-AzureStackonAzureVM -ResourceGroupName myResourceGroup -Region 'West Europe' -VirtualMachineSize 'Standard_E32s_v3

• Once the VM is deployed, RDP to it and open Powershell ISE as an Administrator.

• Run cd C:\CloudDeployment to change directory.

• Run .\Install-AzureStackPOC.ps1 to kick off the deployment/install of ADSK.

By default the script will assume you want to deploy the ASDK in "connected" mode integrated with an Azure AD instance. During the first steps of the script you will be promoted to sign up to Azure AD. This is the instance which will be used to authenticate to this ASDK. Please note that the authentication mode cannot be changed, post deployment and a redeployment would be required. 

***During the first steps of the script you will be prompted for a password - this should match the local admin password of the Azure VM.***

The local admin password of the Azure VM will eventually become the Domain Admin password for the AD DS domain which is created as part of the ASDK deployment. As part of the script a domain AZURESTACK is created. 

The entire installation takes ~10h to complete and needs attention at various points throughout. 

The script will run for approximately 3-4 hours and then the RDP connection to the VM will break. Hard reboot the VM from the Azure Portal and log back in via RDP. 

As the script has not completed 100% at this point, we must rerun the script to ensure it picks up from where it left off. 

To do this cd C:\CloudDeployment and run the .\Install-AzureStackPOC.ps1 -Rerun

Once it is completed, login to the Azure VM using AZURESTACK\azurestackadmin and the original Azure VM local admin password. You will then be able to launch Hyper-V Manager and see all the VM's which are running to make the ADSK operate. 

Create and Configure Certificates for Azure Gateway P2S VPN Connection

Azure offers the ability to create Site to Site and Point to Site VPN connections to Azure Virtual Networks using the native Azure Virtual Network Gateway. It is becoming increasing irritating to have VMs exposed to the Internet on port 3389 for RDP, therefore P2S VPN connections can be useful to remove the need to have these rules created on your NSGs. You can of course you Azure Bastion, but some people prefer a VPN-like connection. Authentication for P2S VPNs can be either AAD or by a pair of certificates. A root certificate installed at the VNG, with a subordinate client certificate from that root installed on the incoming, connecting device.

Create the root certificate using the following code, you can change the Subject field if you like. This is how the certificate will be identified within the local certificate store on the machine you generate the certificate on. You will notice that this command creates the root certificate under the CurrentUser context.

$rootcert = New-SelfSignedCertificate -Type Custom -KeySpec Signature ` -Subject “CN=RPBP2SRootCert” -KeyExportPolicy Exportable ` -HashAlgorithm sha256 -KeyLength 2048 ` -CertStoreLocation “Cert:\CurrentUser\My” -KeyUsageProperty Sign -KeyUsage CertSign

Create the client certificate from the root certificate, the linkage here is done by the Subject name, so ensure they match to avoid any problems with the trust chain. 

New-SelfSignedCertificate -Type Custom -KeySpec Signature ` -Subject “CN=RPBP2SClientCert” -KeyExportPolicy Exportable -NotAfter (Get-Date).AddYears(1) ` -HashAlgorithm sha256 -KeyLength 2048 ` -CertStoreLocation “Cert:\CurrentUser\My” ` -Signer $cert -TextExtension @(“2.5.29.37={text}1.3.6.1.5.5.7.3.2”)

Once the commands have completed you will notice both the certificates within the Current User trust store, the next step is to export the root certificate so that it can be imported into the VNG. 

The correct format is Base-64 (CER) as we must be able to open the exported root certificate with Notepad to copy the code onto the VNG.

Copy the content of the root certificate, excluding the BEGIN CERTIFICATE part. 

Head to the Azure Portal, then to the VNG. From here click on Point to Site Configuration and configure the connection pane as follows.

• Address Pool - this is an address block which is required to assign to incoming VPN clients. This pool is virtual in nature and has no bearing on the address space used on the VN. 

• Tunnel Type - select IKEv2 and OpenVPN (SSL) by default this configuration will attempt to connect via IKEv2 first, then fall back to SSL.

• Authentication type - Azure certificate should be selected, it is possible to use AAD as well. 

The VPN Client comes pre-packaged with the correct certificate configuration once you make changes to the Azure Portal, be sure to redownload the client package if you have made changes here.