Deploy Azure Stack Development Kit on an Azure VM

[Update on 18/10/17] With the new version of the ASDK, this blog post had been updated.

With the recent release of V3 VMs on Azure, you’ve now the possibility to do Nested Hyper-V, running a VM in an Azure VM.

Azure Stack Development Kit just released, it was the opportunity for me to deploy the last version in Azure, because I don’t have the necessary hardware at home to run it.

Be careful, the following article is not supported by Microsoft and can be used only for test.

Daniel Neumann, TSP Azure at Microsoft provided a version for his installation, on L2 nested virtualization:

I will use some parts of his blog for my installation. The difference is that he is deploying Azure Stack in a VM, on the Azure VM. In my case, we will deploy Azure Stack directly on the Azure VM.

Before starting, create an Azure AD account who is Global Admin. This account will be used to connect your Azure Stack to your Azure AD.

To start, deploy a VM on Azure, with the image Windows Server 2016 and with the minimum size E16s v3 (16 cores, 128 GB memory). It’s prerequisites to be able to run Azure Stack:

When the VM is deployed, do not apply any updates, just ignore them. We will rename the local administrator to Administrator, so we don’t have to modify scripts:

Stop the VM through the Azure Portal, and go to Disks. Expand the OS disk to 256GB and add 4 disks for the Storage Spaces Direct part, with 256GB each:

Start the VM and initialize disks. Modify the timezone with your time zone and deactivate the IE Enhanced Security Configuration parameter. You can connect and install prerequisites to gain time for the next part:

Restart the server:

You can now download Azure Stack Development Kit:

When extracted, mount the disk CloudBuilder.vhdx and copy folders CloudDeployment, fwupdate and tools in the root of your C drive. You can eject the disk CloudBuilder. Open a PowerShell console and do:

For IP addresses, use IP addresses that are not used in your Azure VNet and in your Azure Stack environment. You’ll have a first error who will be that your server is not physical. Don’t worry, you need to modify the file C:\CloudDeployment\Roles\PhysicalMachines\Tests\BareMetal.Tests.ps1 and to find $isVirtualizedDeployment. This variable is present 3 times in the file.

Remove the -not before each variable. Launch the installation again with the following command:


If you’ve an error with CredSSP when the script is modifying the number of maximum joined computer, follow this procedure. On the DC server, execute the following command:

On the Hyper-V server, execute the following command:

Open the gpedit.msc console and navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Credential Delegation.

Activate Allow Delegating Fresh Credentials with NTLM-only Server Authentication and add the value WSMAN/*. Launch the script again:


When the BGPNAT VM is deployed, execute the following script on the Azure VM to create a new virtual switch that will give Internet access to your VM, by adapting IP addresses with IP that you used when you launched the installation:

Go in the parameter of the BGPNAT VM and change the virtual switch for the network card NAT from PublicSwitch to NATSwitch:

You can now ping external IP addresses:

The deployment of the infrastructure continues:

After few hours, the deployment is finished and you can connect to the admin and user interfaces:

If you’ve the following error message during the deployment of certificates on the Hyper-V host for the Monitoring Agent deployment:

VERBOSE: 1> [MonitoringAgent:Configure] Installing MA Certificate on FLOAPP-ASDK from \\SU1FileServer\SU1_Infrastructure_1\AzureStackCertStore\Internal\Current\MA\MonitoringAgentSsl.pfx – 10/18/2017 12:49:59 PM

VERBOSE: 1> [MonitoringAgent:Configure] Caught error Connecting to remote server FLOAPP-ASDK failed with the following error message : The WinRM client cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server.  To use Kerberos, specify the computer name as the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To use Basic, specify the computer name as the remote destination, specify Basic authentication and provide user name and password. Possible authentication mechanisms reported by server:     Negotiate Kerberos For more information, see the about_Remote_Troubleshooting Help topic. : retrying… – 10/18/2017 12:49:59 PM

Execute the following command and rerun the installation:

winrm set winrm/config/service/auth @{CredSSP=”true”}

Thanks to Ned for this solution:

Spread the word. Share this post!