Azure VMs Explained: Understanding VM SKUs and Attributes

In part 1 of Explaining Azure VM Sizing, we talked about the four common VM series that all MSPs must know, and know well, to maximize their Azure investment. To recap, they were: 

  • B-series for light use burstable workloads  
  • D-series for standard, well balanced compute/memory workloads  
  • E-series are memory focused VM sizes (ie: it has double the amount of memory compared to the D-series machine) 
  • F-Series are CPU focused VM sizes (ie: it has double the CPUs compared to a D-series machine) 
  • NV-series are VMs that have GPUs in them to support GPU-based workloads. 

With those basics in mind, it’s important to really understand the specifics of each VM SKU, specifically focusing on the attributes of each VM.  

What Are Attributes?  

Attributes are letters that come after the VM family and number of cores. Let’s take for example: D8ads_v5  

Just by looking at this sequence, the SKU indicates that it’s a D-series, Standard 8 Core 32GB RAM machine that sports an AMD Milan Chip, that has a NVMe Temp Disk as well as support for Premium Remote Storage. 

How to Decode Attributes 

Obviously, no one can look at a sequence and know what every character in it means without learning the fundamentals. This Microsoft document shows the total breakdown of how this works. However, to learn the basics, the below subheadings and bullets points break down what each character represents concisely:  

[Family] + [Number of Cores] + [Number of Constraint Cores] + [Attributes] + [Version Number] 

Family  

  • The family indicates the family VM size: These will fall under the following:   
  • B, D, E, F, NV 

Number of Cores:  

  • The number of cores is how many cores the CPU uses to run. These will be one of the following numbers:  

2, 4, 8, 16, 32, 64 

Number of Constraint Cores:  

  • This number is usually signified by a “– “symbol and a number of CPU that’s lower than the initial number of cores.  
  • Take, for example, “E8-4as_v4”. This lower number denotes the number of vCPU’s that VM is constraint to but since the number of cores on this SKU is still 8 cores, you will retain the amount of memory and every other property of that 8 core E series machine, but you are limited to the number of reduced cores.  
  • The reason for this for SQL workloads as an example, is that a user might want a lot more memory that would typically be in a E8 machine (64GB of RAM) but don’t need the extra CPUs since it is not needed and/or simply don’t want to license them using the SQL Server per core model of licensing. If you can get away with running with less cores, you ought to pay less for the SQL licensing since SQL licensing is charged by the number of vCPU’s and not by the Use CAL model in Azure. 

Attributes 

  • While there are plenty of attribute options, many of them will not be seen in the most common use cases. Some of the most common attributes are:   
  • a – AMD chip instead of default Intel 
  • s – Supports mounting of Premium SSD’s 
  • d – VM itself comes with Temp Disk which can be used for log storage or Ephemeral OS disk 

Version Number 

  • This denotes the version of the VM family series. Versions of a VM family can encompass multiple CPU chip architectures. For example, a v3 VM can have one of these Intel chip technologies: 3rd Generation Intel (Ice Lake), Intel (Cascade Lake), Intel (Skylake), Intel (Broadwell), or the Intel (Haswell) processors. Unfortunately, you can’t pick which one you want. Microsoft decides which one you get during the VM allocation process. 

How to Decide Which to Pick 

This is how you should decide which VM family to start with for your particular VM workload. 

  1. Start with the D – Series for a well-balanced CPU/Memory ratio machine 
  1. Would that workload benefit from having extra memory? If yes, pick an E-Series machine, it’s only 15% more for 2x the memory compared to a D-Series. If not, Stay on D-Series 
  1. Would that workload be very low CPU consumption and a light workload most of the time? If yes, pick a B-Series for the same CPU/Memory ratio but pay 56% less than a D-Series. 
  1. Would that workload require highly intensive CPU more so than RAM? If yes, pick a F-Series, otherwise stay with the D-Series 
  1. Does that workload require GPU capability? If yes, Pick a NV-Series (NVv4 or NVv5) machine 

Understanding and decoding VM SKUs is useful knowledge to have. Not only can this understanding save you money and increase your clients’ performance exponentially. Always make sure you are using the latest and greatest VM family and version for the job.  

AVD Identity Management Part 2: Active Directory Options Explained

In Part 1 in our series on Active Directory, I discussed the history of Active Directory and where identity management in Azure is heading with Azure Active Directory.  

In this next part of the series, we look into the three different types of Active Directory options (all supported within Nerdio) and call attention to some things you need to be aware of when managing identity in Azure.  

There are three different types of Active Directory options are:  

  • Active Directory Domain Services (AD DS) 
  • Azure Active Directory Domain Services (Azure AD DS) 
  • Azure Active Directory (Azure AD) 

Let’s discuss these at a high-level as well as the need-to-knows and differences between them.  

It’s also worth mentioning that you can absolutely use a combination if you want to, although you still need to pick a primary authentication mechanism.  For example, if we want to use a combination of AD DS to authenticate the users and use Azure AD to “manage” the devices, we can absolutely do that by performing a “Hybrid” Domain Join. In this scenario the session hosts are “joined” to AD DS, but are “registered” against Azure AD. 

Active Directory Domain Services (AD DS)  

AD DS is the option most people think of when thinking about Active Directory. AD DS was introduced in 2000, over 20 years ago, by Microsoft as part of Windows 2000.  I have very fond memories of the offering as I have worked on some of the largest Active Directory deployments (100,000 seat deployments and more) in the world! 

AD DS consists of a database (NTDS.DIT) and uses something called LDAP (Lightweight Directory Access protocol).  This is how services integrate with Active Directory, they perform LDAP Lookups. AD DS provides many services including authentication (using Kerberos and NTLM), Directory lookup (using LDAP), Group Policy to apply settings, and much more.  

To enable AD DS, you must install it on a Windows Server (which can be physical or virtual), and then enable a feature called “Active Directory Domain Services.”  

This will enable your Windows Server to operate as a domain controller for your domain.  Typically, when deploying Azure Virtual Desktop (AVD) solutions, we often see customers deploy multiple Active Directory domain controllers inside their Azures subscription and synchronise the Active Directory database with their on-prem deployments. This is by far the most common use case we see.  This ensures that any LDAP or authentication traffic is contained within Azure, rather than having to traverse VPN links. This can be a poor user experience, and also a security risk.  

Azure Active Directory Domain Services (Azure AD DS)  

As we have seen so far, there is work we need to do to get Active Directory up and running. We must deploy a server, deploy a role, manage that server etc, what if there were a better way? Enter Azure AD DS.  Azure AD DS is an Azure service is a managed domain in which Azure manages everything for you. You don’t need to worry about deploying servers, managing servers, installing Active Directory etc.  

However, this type of managed domain is a brand-new Active Directory domain, you cannot join your existing Active Directory domain. You can still use Azure AD Connect to synchronise your user accounts into this separate Active Directory domain if required.  

However, because we don’t actually have access to the domain controllers via Azure AD DS, there are a few limitations that you need to be aware of:  

  • No Hybrid Azure AD Join  
  • No Enterprise or Domain Admin  
  • No Active Directory Certificate Services Support  
  • Schema Cannot be Extended 
  • Limited Group Policy Support  
  • Limited Redundancy  
  • Azure AD DS has a different DNS Name  
  • No Forest Trusts 
  • No MSIX App Attach Support  
  • Not available in all regions  

From an AVD perspective, the biggest limitations are the lack of support for MSIX App Attach and Hybrid AD Join. This will stop you from being able to manage your hosts using Microsoft Endpoint Manager (MEM)/Intune in the future.    

For simple solutions, Azure AD DS works well, but as you get into more complicated deployments its limitations start to become more apparent. I would only recommend choosing Azure AD DS unless you have to, as the cost of the service, compared to deploying a few domain controllers as VMs, is about the same.  

Azure Active Directory (Azure AD)  

So where does Azure AD fit into this??  Microsoft describes Azure AD as an “Enterprise identity service that provides single-sign-on, MFA (multifactor authentication), and conditional access”.  So, you are probably thinking, “…well isn’t that what Active Directory is also?” And yes, you are correct, Active Directory provides user authentication. However, when we authenticate to any Azure services (i.e., Office 365) we authenticate against Azure AD, not AD DS.   

But most user accounts are held in AD DS. To fix this authentication issue, you can use something called Azure AD Connect which synchronises AD DS users with Azure AD.  This means your users will appear in your Azure AD, and we can also sync the password.  So, when I authenticate against Azure AD, I can use the same password that I use for my on-prem environment as they synchronise.  

Let’s think about this from an AVD perspective. AVD is an Azure service that IT authenticates with Azure AD accounts. That’s authentication point number one. Once we have authenticated against the AVD service, we then authenticate against the AVD session host (VM) which is part of our Active Directory domain – that’s authentication point number two.  

What we can also do now, is utilize a tool called Azure AD Join. This means that we can join our session hosts directly to Azure AD.   

This unlocks a whole set of capabilities including Single Sign-on for AVD (SSO), Windows Hello Authentication and also password-less authentication for AVD. To enable the single sign on (SSO) capability you just need to ensure you are running the September 2022 Cumulative Update. 

This capability is also available if you are using Hybrid Join also. To read more about the update please view the Microsoft guidance here – Configure single sign-on for Azure Virtual Desktop – Azure | Microsoft Learn 

Let’s finish up by answering a few frequently asked questions (FAQs) around these three Active Directory options in Azure.  

Can I get rid of my Domain Controllers if I’m Using Azure AD? 

Not quite yet, your users still need to be synced from a full Active Directory, but that limitation will be lifted soon when Azure AD Join goes GA. 

So, what’s Hybrid Azure AD Join all about then? 

You have probably heard about Hybrid Azure AD Join.  This is where your session hosts are “registered” against Azure AD, but not joined to Azure AD.  If you want to be able to still join them to your AD DS domain, but also manage them via Intune, then this is where you would use Hybrid Azure AD Join.  

Does Nerdio support all of the above identity options in Azure?  

The good news is that using Nerdio, you can use all of the above scenarios and pick which one best suit your needs.  

Hope you enjoyed this article and I look forward to seeing you in Part 3 which will go into detail about how to manage a native Azure AD environment.