Warnings:
"Azure Stack HCI" has been re-branded/renamed to "Azure Local"
ECC RAM might be a hard requirement now, where it wasn't before. That means, it may not be possible to use the MS-01 workstations to build a cluster anymore. I need to do some testing on this, and I will update this post when I do.
If you haven't already please check out the other parts of the series first:
Azure Virtual Desktop on Stack HCI
There are multiple components that make up AVD, such as Host Pools, Application Groups, Workspaces, and Session Hosts. When it comes to running AVD on your Stack HCI cluster, only one piece actually runs on your cluster: Session Hosts. The rest of the component run in Azure. You'll also need to store the OS images used by the Session Hosts on your cluster's storage.
Architecture of AVD
Let's quickly discuss the architecture of AVD.
Let's start with Host Pools, which come in 2 flavors. We have a "Personal" Host Pool, where each Session Host is assigned to a single user and provides them their own dedicated desktop. The other option is a "Pooled" Host Pool where a user is not assigned to a particular Session Host, they could potentially get a different one on each logon.
For each Host Pool you need to create 1 or more Application Groups. An Application Group is just a logical grouping of any apps that are installed on the Session Hosts. For "Personal" Host Pools, the only option is to create a "Desktop" Application Group. For "Pooled" Host Pools, you can create both "Desktop" and "RemoteApp" Application Groups.
You then assign users to Application Group(s). A user can only be assigned to 1 type of Application Group (Desktop or RemoteApp) PER Host Pool.
Finally, Application Groups need to be assigned to a Workspace. A Workspace is just a logical grouping of Application Groups. Oddly enough, a User won't see any Application Groups until those Application Groups are first assigned to a Workspace.
Installing AVD on Stack HCI
Let's start the process of installing AVD onto our cluster.
We can see that we don't meet the prerequisites (screenshot 1 above). When we click for more details we can see that we're missing a supported Windows image on our cluster (screenshot 2 above). So, let's install an image.
We need to go to our cluster, go to the blade for VM Images, and then Add a VM Image (screenshot 1 above). There are a couple of places where you can source the image from, but for this post we'll pick an image from the Azure Marketplace. Next, you'll need to provide some details about the new image (screenshot 2 above). Give it a name, pick the Custom Location that is tied to your cluster, pick which image to download from the Marketplace, and finally, you must pick which Storage Path on your cluster to use for storing the downloaded image. When you finally deploy the image it will begin the download process. This took quite some time for me, as it has to download an image that was 127 GB in size, which is quite large.
Once our image if fully downloaded, we can begin the AVD install (see above). The first tab is for "Basics" and it lets us configure our first Host Pool. As discussed earlier, you can pick either a "Personal" or "Pooled" Host Pool, depending on your needs.
The next tab is for "Virtual Machines" and this lets us configure the Session Hosts that will be tied to our first Host Pool. On screenshot 1 above, it is important that you pick "Azure Stack HCI Virtual Machine". Otherwise, if you don't pick this, the Session Hosts will be created in Azure and not your cluster. Make sure to pick the Custom Location tied to your cluster, and then pick your newly download Image. On screenshot 2 above, we'll be configuring the virtual hardware for the Session Host VMs. For "Security Type" the only option I could pick when using the portal was "Standard." I was not given the option to pick "Trusted Launch" or "Confidential." It is important that you already have a Logical Network created on your cluster, because you will need to pick one here for your VMs to use. If you need more details about Logical Networks, then see Part 4 of this series where I discuss creating one. Lastly, on screenshot 3 above, you'll need to provide details about your Active Directory domain. Your Session Host VMs will be automatically joined to the domain provided.
The next tab called "Workspace" is shown above. This will let you create a new Workspace, as well as assign a Application Group of type Desktop to the new Workspace.
The last tab that I'm going to show is the "Advanced" tab (above). This lets you configure Diagnostic Settings, if desired.
After the deployment is complete, the only resources that you should see on your cluster will be 1 VM per Session Host.
IaC and Wrap Up
That's pretty much it for Azure Virtual Desktop. I have been working on some Bicep code to do all of this through Infrastructure As Code, but it's proven to be a little tricky.
Back in 2021 I wrote another blog post where I show how to deploy AVD using Terraform. At that time, Microsoft was using PowerShell Desired State Configuration (DSC) in order to deploy and configure the agent onto the Session Host VMs.
It seems they have moved away from this method. I dissected the AVD deployment that I recently completed and found that now they running a PowerShell script by way of a VM Custom Script Extension. It's taking me a little longer to convert this into Bicep, but when I am done I will update this post and include links to my GitHub.
Next up in the series I will detail how to deploy standard VMs to Stack HCI, stay tuned!
Comments