<img height="1" width="1" src="https://www.facebook.com/tr?id=152309752858854&amp;ev=PageView &amp;noscript=1">

How to deploy Azure Stack Development Kit (ASDK) – Part 1

Welcome to our series on deploying, configuring and utilising Microsoft's Azure Stack Development Kit. 

Azure Stack has been in general release for over 12 months now I thought would be an appropriate time to provide a series on how to get it up and running (even in cases where you might not fully meet the hardware requirements).

I’ve been playing with Azure Stack since Technical Preview 1 and its amazing to see its evolution to what it is now.  There is no equivalent on the market that provides the platform consistency Azure and Azure Stack provide.

What will we cover in our Azure Stack series

  • Part 1 - Installing the Azure Stack Development Kit – Microsoft have done an excellent job of automating the deployment of ASDK provided you have the correct hardware but there are some tips and tricks to avoid some of the common issues that crop up as well as some customisations that we’ve captured in the last 12 months of testing to make it more functional. The key focus of Part 1 is to get you up and running, without issues.
  • Part 2 – Configuring the Environment for use by Tenants – In this post we’ll cover the provisioning of the Initial OS images, Offers and Plans required to start using the environment.
  • Part 3 – Installing the PaaS Components – In this step we’ll deploy the optional PaaS components (App Service and Functions, SQL and MySQL). This step can be skipped if you don’t plan to use these components or simply don’t have enough memory to support the additional components (A minimum of 128GB is recommended by Microsoft).
  • Part 4 – Tools of the Trade – In this post we’ll cover setting up the tools for managing and deploying workloads on the environment. Specifically, we’ll cover the Azure Storage Explorer, Visual Studio and PowerShell.
  • Part 5 – Optimisations and Advanced Scenarios – In this post we cover off some more advanced scenarios, tweaks and hacks to get the most out of your Azure Stack deployment.


What we’re using for this post

Azure Stack’s Hardware Requirements are quite hefty and not for the faint of heart.   The table below states Microsoft’s minimum requirements for running the Azure Stack Development Kit:

Component Minimum Recommended
Disk drives: Operating System 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD) 1 OS disk with minimum of 200 GB available for system partition (SSD or HDD)
Disk drives: General development kit data* 4 disks. Each disk provides a minimum of 140 GB of capacity (SSD or HDD). All available disks will be used. 4 disks. Each disk provides a minimum of 250 GB of capacity (SSD or HDD). All available disks will be used.
Compute: CPU Dual-Socket: 12 Physical Cores (total) Dual-Socket: 16 Physical Cores (total)
Compute: Memory 96 GB RAM 128 GB RAM (This is the minimum to support PaaS resource providers.)
Compute: BIOS Hyper-V Enabled (with SLAT support) Hyper-V Enabled (with SLAT support)
Network: NIC Windows Server 2012 R2 Certification required for NIC; no specialized features required Windows Server 2012 R2 Certification required for NIC; no specialized features required
HW logo certification Certified for Windows Server 2012 R2 Certified for Windows Server 2012 R2


Our test box configuration

Component Specification
Disk drives: Operating System 1 OS Disk – 136GB System Parition
Disk drives: General development kit data 5 x 300GB 10K SAS Disks
Compute: CPU 2 x AMD Opteron Quad Core (8 Cores Total)
Compute: BIOS SLAT Enabled
Network: NIC Standard IP Onboard NIC
HW logo certification Certified for Server 2012 R2


As you can already tell, we don’t meet the minimum requirements in a few places. Under normal circumstances, the Azure Stack Development Kit installer will run its validation kits and not proceed - and for good reason.

Microsoft is trying to ensure users receive a consistent and reliable experience when using Azure Stack and it cannot be guaranteed if the recommended minimum hardware requirements are not met.  This is the reasoning behind the decision to allow production systems to be rolled out on a limited number of integrated hardware stacks.

That doesn’t mean we can’t get around it, it just means that if we do it won’t be supported.  We’ll touch on how to get around it when we start deploying Azure Stack in the next step.  Rest assured we will be able to deploy Azure Stack and in most instances, it runs fine even with less than the minimum specifications.  You just can’t run as much.


Getting ready to deploy Azure Stack

If you haven’t already, head to the Microsoft Azure Stack Download page and register your interest.

You’ll then be given the link to the Azure Stack Downloader. 

Download and extract the CloudBuilder.vhdx file as per the instructions and copy it to the server/disk that you plan to use as your Azure Stack host and operating system partition. 

Make sure you have at least 60GB of free disk space on that drive after you’ve copied the file, otherwise it simply won’t mount.


Let’s go!

Once your files are copied, the server has rebooted, and you’ve opened a remote session to your Azure Stack Host, we’re almost ready to start deploying.  Before you start make sure you’ve done the following:

  • Disable all network interfaces except the one that you’re using to connect (our server has four onboard NICs).
  • Make sure you have access to a running, working NTP server; I use the domain controller from my lab but there’s not hard and fast rule.
  • The only rule is you must specify it when you install Azure Stack, or the installation will fail.
  • Make sure you have a Global Administrator account for the Azure AD Tenant you’ll be using for the install. We’ll cover the disconnected scenario in another post.

Step 1.
Open PowerShell as an administrator and head to the CloudDeployment\Setup folder on the host.


Step 2.
Pre-define your credentials using the following commands:
$adminCred = Convertto-SecureString -AsPlainText -Force -String “yourLocalAdminPassword” # Local Admin Credentials
$aadCred = Get-Credential # Prompt for your Azure AD Global Admin
$aadTenant = “youtenant.onmicrosoft.com”


Step 3.
Run the following command to start the installation:
ps1 -AdministratorCredential $adminCred –


Step 4.
If you’re running the reference hardware, at this point you’re done for a few hours. If not the next couple of steps should get you out of trouble.


Step 5.
The first error I usually come across is the Hardware Validation as shown above. To be fair, we knew this would occur as I’ve already conceded I’m not running the reference hardware.

There are a couple of ways around this which we’ll cover off now.  The first is to simply restart the installation after the validation step, and the installation will continue from the next step in the deployment phase. 

The other is to simply make sure the error never occurs in the first place.  Head to the C:\ECEStore<RandomGuid>  folder on the Azure Stack host, in here you’ll find yet another randomly named file.  This file contains the Enterprise Cloud Engine configuration file that’s referenced by the deployment. 

This file is an XML file and can be opened using notepad, in here we’ll find all of the deployment actions.  Local the section below in your configuration file and you’ll see that each step is indexed.

The validation step is 12, so it stands to reason that if we simply restart the installation from step 13 it will continue to run.


Head back to your PowerShell window where the installer script has failed and issue the following command to resume the installer.

invoke-eceaction -RolePath Cloud -Start 13 -ActionType Deployment-Phase0-DeployBareMetal


Step 6.
If all as gone to plan, we’ll see the installer restart and continue from the Configure Physical Machines networking for POC, and just like that we’re underway again.


Step 7.
To ensure this doesn’t happen in the first place, there a few edits we can make to the configuration and validation scripts to ensure that the installer believes we’re running on supported hardware.

For this to work, you really need to complete this before you start the installation process, you can do it afterwards, but result may vary as the configuration is pulled into the ECE Store from the role configuration files.


Step 7 A.
If you haven’t already, head to the C:\CloudDeployment\Setup folder and run the ps1 to extract the installation content.


Step 7 B.
Locate the C:\CloudDeployment\Configuration\Roles\Infrastructure\PhysicalMachines\OneNodePoc.xml file and open it with notepad or another text editor. The lines we’re looking for are highlighted in the image above.  In my case, my System Disk was only 135GB in size and the installer is expecting it to be at least 180GB.  Changing the value gets me out of trouble but while I’m here I might as well make a few other changes to ensure I don’t get stuck in other places.  I’ll change the CPU core count to 2 but we’ll basically bypass this check in the next step anyway but I like to be thorough.  You can modify the RAM to match the amount installed in your server or less if you feel like it.


Step 7 C.
With the configuration file updated, we now head to the C:\CloudDeployment\Roles\BareMetal\Tests folder. Once here we’ll edit the baremetaltests.ps1 file. I’ve tabled the changes we need to make below.  Simply search for each line in the script and replace it with the appropriate line below:


[dt_code]{   $physicalMachine.Processors += (New-Object Processor -Property @{ NumberOfEnabledCores=$_.NumberOfEnabledCore;
SupportsSecondLevelAddressTranslation=$_.SecondLevelAddressTranslationExtensions })

[dt_code]{    $physicalMachine.Processors += (New-Object Processor -Property @{ NumberOfEnabledCores=12;
SupportsSecondLevelAddressTranslation=$True })

This will tell the installer that we meet the Processor Requirements and basically skip that check. Handy if you don’t meet the minimum core count.


[dt_code]if (-not $isVirtualizedDeployment)
foreach ($physicalMachine in $physicalMachines)
It ($BareMetalLocalizedStrings.TestNotVirtualMachine -f @($physicalMachine.ComputerName)) `
$physicalMachine.IsVirtualMachine | Should Be $False



[dt_code] if (-not $isVirtualizedDeployment)
foreach ($physicalMachine in $physicalMachines)
It ($BareMetalLocalizedStrings.TestNotVirtualMachine -f @($physicalMachine.ComputerName)) `
$physicalMachine.IsVirtualMachine | Should Be $True


If you’re running this in a Virtual Machine using Paravirtualization this will allow you get past the “is this a virtual machine  check”


Step 7 D.
With those changes made we can now run the installer normally and (provided the hardware can run Azure Stack) simply wait for the installation to complete.


Step 8.
Everything going to plan and a few hours later, log on to the Azure Stack host, turn of Internet Explorer Enhanced Security and browse to https://adminportal.local.azurestack.external.

As of ASDK version 1712, logging into to the Administration Portal to configure settings is done using the cloudadmin@azurestack.local account and the administrative password you selected at installation time. Congratulations, you’ve made it through part 1 and have a working Azure Stack installation.



In Part 1 we’ve walked through the process for installing Azure Stack (even if you don’t meet the requirements). 

I haven’t provided an exhaustive list on everything that can go wrong but if you do run into issues please feel free to post a comment on the blog and I’ll do my best to respond. 

Alternatively, if you’d like more information on Azure Stack or are looking for help installing it into your environment don’t hesitate to contact our team and get familiarised with our Azure Cloud service offerings.

In Part 2 we’ll look at the post installation activities to get you up and running.

Until next time; stay calm and use the Stack!

Tags: Azure Cloud, Product Transformation, Azure Stack