Microsoft 365


Active Directory


Windows Server



Microsoft Azure

Everything You Need to Know About Azure Infrastructure – April 2021 Edition

Aidan Finn


I’ve been drowning in project deadlines for the last month and I’ve not had a chance to keep up with the improvements in Microsoft Azure IaaS. So this month’s article is as much for me as it is for you!

New General Purpose VMs

The most common virtual machine family that I use in Microsoft Azure is the D-series family from the general-purpose category. These are machines with high-spec Intel processors that come with 4x RAM, for example, 2 virtual CPUs (1 core with Multithreading) and 8 GB RAM. The E-series family are the same machines but with more RAM assigned to each machine for higher memory workloads. These machines are ideal for database and application workloads with consistent pressure on CPU – otherwise consider the B-Series where available.

For a long time, the newest machines were the D_v3/E_v3 series. In June of last year, Microsoft announced the D_v4/E_v4 machines running on hosts with Intel Xeon Platinum 8272CL (Cascade Lake) processors; this processor runs at a base speed of 2.5GHz and can achieve all-core turbo frequency of 3.4GHz.
In April, Microsoft announced a preview for D_v5/E_v5 virtual machines running on hosts with 3rd Gen Intel Xeon Platinum 8370C (Ice Lake) processors; this processor offers a Turbo clock speed of 3.5GHz and up to 15% better performance over the D_v4/E_v4 machines.
The new D_v5 offers between 2-96 virtual processors and 8-384 GB RAM. The E_v5 offers between 2-96 virtual processors and 16-672 GB RAM. As with the _v4 SKUs, the “d” designations will be machines that do not use a local temp/caching drive on the host.

Naming Gets Some Sanity

Have you ever tried to build a naming standard for your employer’s or customers’ usage of Microsoft Azure? I have – and the platform-forced implementation of exceptions becomes so common that calling the result a “standard” seems like a lie.
Most naming standards will include a resource group name, a role name, an incremental counter, and a resource type in the resource name, separated by hyphens to make the whole thing legible. And then you get Azure Key Vault, Log Analytics, and other resource types that force global uniqueness. And so you end up creating some “random” string in the middle of the resource name because your desired name is already used.
Maybe you deploy a Storage Account. Storage Accounts, along with resources such as Web Application Firewall, demand that hyphens are not used in the resource names! Storage Account names must also be globally unique so there’s a mash up of strings, some randomness, and no hyphenation for legibility.
Some resources have restrictions on length, so your random string becomes short and less random. And by the way, there is no “random” function in ARM, so you have to hash on some other values that other parts of your organization or other customers may also be using.
But at least some sanity is coming: Microsoft announced the general availability of Log analytics workspace name uniqueness is now per resource group; this means that a Log Analytics (Azure Monitor Logs) resource name need only be unique in a resource group. For Microsoft Partners, especially managed services providers leveraging infrastructure-as-code, you can deploy consistently across many customers without any negative impact.

Other Announcements from Microsoft

Azure Storage


Azure Virtual Machines

App Services

Azure Backup & Site Recovery


Azure Security Center


Windows Virtual Desktop

And Now for Something Different

I’ve been working on a complex migration project with a customer for about a year. We have finally reaching the point where user-acceptance testing has begun. That has meant the need to deploy thick clients for legacy applications in Microsoft Azure; the chosen solution was Citrix Cloud, but what I’m going to share could equally be used with Windows Virtual Desktop.
We needed a solution that will allow us to rapidly build worker pool (virtual machine) images at least every month for several worker pools. The image factory would have to deploy the latest Microsoft updates and the latest client application versions, ideally, from a storage location that was shared with Microsoft Intune administrators/consultants – we chose Azure Files for that.
Microsoft Deployment Toolkit and a daisy chain of PowerShell scripts were originally used but I felt that it was too fragile and there were skills challenges with less mature (old) staff members. I decided that we needed a more modern approach.
I considered Azure Image Builder. I tried some hands-on examples but I found that the solution was needlessly complicated. Azure Image Builder is based on an open-source solution from Hashicorp called Packer. I did some reading and testing and Packer was a good fit. A colleague wrapped the build process up with Azure DevOps and some PowerShell scripts allowed us to map a drive to Azure Files and install the software. We now have a factory that allows us to run a DevOps pipeline to create a new image that will be ingested by Citrix Cloud to build a new machine catalog (worker pool) or update an existing one.
What I like about Packer is:

  • It is free – who doesn’t like free?
  • It leverages PowerShell for the automation and that makes it very flexible
  • You can keep it simple or you can wrap things up in an automated release process like DevOps/GitHub

Packer is suitable for any scenario where you need to create an image frequently and deploy it at scale, such as a worker pool (Citrix Cloud or Windows Virtual Desktop) or a Virtual Machine Scale Set.

Article saved!

Access saved content from your profile page. View Saved