Azure Stack Update 1905 - Additional Resource Requirements

As I’ve been away on holiday (vacation) I missed out on a fairly crucial piece of information from the release notes for Integrated systems.



How many people picked up on this?

So, be prepared after you’ve run the update to lose some of the capacity that was previously available to tenants.

I confess to not having any insight into how the Infrastructure Ring will work, and was at first dubious to the claim of reducing overall consumption at first, but my guess is that on each hardware node there will be a VM which will be running Service Fabric, and from within there, they will run containerized versions of the XRP, ACS (Azure Consistent Storage), WAS (Admin management endpoint & portal), WASP (User management endpoint & portal). I’m not sure if the Network Controllers, Gateway or SLB’s could move to the containerized platform.

Doing some rough calculations by looking at the Infrastructure Roles Blade in the Admin Portal, I calculated that currently the VM’s hosting the roles I guessed would be moving currently consume 102 GB and 36 vCPU.

Example of where to find out the VM sizes of infra roles in the Admin Portal:


So, in reality it looks like vCPU consumption will in fact increase, but Memory decrease, and you know what, I’m OK with that. Memory is the most precious resource in my opinion, as it is not over-committed. You’re likely to run out of that before Compute.

Hopefully we can see the benefits of the new architecture soon.

ARM Template deployment bug in Azure Stack

I came across an interesting situation at a client when trying to deploy an ARM template that I have deployed a few times in the past successfully on both Azure and Azure Stack.  What the template deploys does'nt matter, but I came across a problem that you might encounter when deploying a Template with parameters, more specifically, how they're named.

I tried to deploy a template I modified back in January to a customer's Azure Stack stamp that was at the latest update version (1905) at the time of writing. 

The parameters looked like this:

2019-06-18 21_58_50-Parameters - Microsoft Azure Stack.png

When I tried to do a custom deployment, I got the following:

2019-06-18 22_00_05-Deploy Solution Template - Microsoft Azure Stack.png
2019-06-18 22_00_56-Errors - Microsoft Azure Stack.png

I tried to deploy the same template to Azure and it worked, so I knew the template was OK.  I also tried on a 1902 system and it worked.  Testing on a 1903 system and I got the error above again, so whatever change is causing the problem was introduced with that update and continues onwards.

After some trial and error,  doing a find/replace renaming the parameter to remove the '_' before the _artifactslocation &  _artifactsLocationSasToken in my templates. It wasn’t so obvious from the error message what the issue was, one of the joys of working with ARM!

Hopefully this issue gets fixed as _artifactsLocation and _artifactsLocationSasToken are classed as standard parameters per

Simplifying Kubernetes deployments on ADFS Azure Stack systems

Simplifying Kubernetes deployments on ADFS Azure Stack systems

he public preview template for Kubernetes on Azure Stack has been out for a few months now, but the ability/guidance has only been available for a short while to deploy on systems using ADFS as the identity provider. That guidance is here:

Feel free to follow the instructions provided, as they do work, but they are fiddly.

Before you start, you have to ensure the following pre-reqs are met before running the template (taken from the doc, but with further comments from me) :

Azure Stack User Defined Routing Problem

Azure Stack User Defined Routing Problem

I'm writing this post to highlight a problem I've encountered with User Defined Routes/Route Tables, and their implementation on Azure Stack. I'll not go into detail on when to use UDR's; the official documentation does a great job of that:

Typically you would use a UDR within an Azure Stack tenant's VNet when you want to direct internet bound traffic via a third party network virtualized appliance (e.g. Firewall).