2024 Update: Windows Virtual Desktop (WVD) has been rebranded and it is now called Azure Virtual Desktop (AVD). I've updated this article to reflect the new name. However, I have not updated the title or URL of this article for SEO purposes.
Lately, I've been playing around with Azure Virtual Desktop (AVD) in my personal sandbox. I wanted to see if I could build a full AVD architecture using Terraform. Microsoft has a GitHub repository containing Terraform code, but it only focuses on the Session Hosts (2024 Update: this repo is now archived). Also, there's a few small problems with the repo. For one, it's using old Terraform resource types that have been superseded by newer resource types (for example, azurerm_virtual_machine vs. azurerm_windows_virtual_machine). Second, it's using the old-style Terraform expression syntax. In a nutshell, the repo was pretty much useless for me. So, I began to write some new Terraform code from scratch which would deploy everything involved with the new ARM-based version of AVD. In this article I plan to document some of the challenges I ran into as well as some of my findings.
AVD Building Blocks
Let's start with the basic building blocks of AVD. If you know AVD architecture then these are all pretty self-explanatory, but I have a couple of notes for each one.
azurerm_virtual_desktop_host_pool : Your standard host pool resource. Let's you define things like if this is a personal pool or a shared pool, the load balancing algorithm to use, etc.
azurerm_virtual_desktop_host_pool_registration_info : (Update 2024) This resource allows you to extract the registration info from the host pool. This will be needed by the Session Hosts in order to join the pool.
azurerm_virtual_desktop_application_group : Not much to note here. All you can do is create an Application Group. If you create a 'Desktop' Application Group, then it will automatically create the default desktop Application for you. If you create a 'RemoteApp' Application Group, then you must add your Applications separately, more on that below.
azurerm_virtual_desktop_workspace : This simply creates a Workspace, nothing to note here.
azurerm_virtual_desktop_workspace_application_group_association : This connects a Application Group to a Workspace, nothing to note here.
azurerm_virtual_desktop_application : (Update 2024) This resource allows you to create RemoteApp Applications in an Application Group.
AVD Session Hosts
Next, you will need to focus on getting your Session Hosts created and connected to your Host Pool. You can use Terraform to create your virtual machines using the standard azurerm_windows_virtual_machine module. You will also want to create 2 azurerm_virtual_machine_extension resources per VM. One extension will be used to join the VM to your Active Directory DS domain. The other extension will run PowerShell Desired State Configuration (DSC) on the VM to install the AVD agents and to register the machine to the Host Pool.
Here are the settings that you will need to configure for the domain-join extension. Please do NOT put plain-text passwords in your Terraform code. Also, you can set "OUPath" to an empty string, which will place the new computer objects into the default Computers container in AD.
Here are the settings you will need to configure for the PowerShell DSC extension. In order to figure out these settings, I ran through an AVD deployment using the Azure Portal, but then I saved the deployment as a template. I then reversed engineered the template to see what its doing. As you can see, it is calling out to the internet to an official Microsoft Storage Account to grab a Configuration.zip file. All of the magic is contained within this zip file, including the AVD Agents and the PowerShell scripts to make sure everything gets installed and configured correctly on the Session Host.
Putting it all together and final steps
By now you should be in pretty good shape. You have Host Pools created, Session Hosts created and registered with a Host Pool, Workspaces created, and Application Groups created and registered to Workspaces. You might also have some RemoteApp Applications that you created. So, what's left? There's only one step left and that's to assign users to Application Groups.
Assigning users to Application Groups can be done with Terraform by way of the azurerm_role_assignment module. Just assign an Entra ID user account / group to the "Desktop Virtualization User" role and scope it to the Application Group in question. Here's an example:
We're almost done, we have one scenario where you need to do one final step. If you are running a Host Pool of type "Personal" and you have it configured for "Direct" assignment, then you must also assign users to their dedicated Session Host. There's no way to do this in Terraform as of now. We'll have to fall back to PowerShell again, but this time it's the Update-AzWvdSessionHost cmdlet. See this Microsoft link for more details.
Did I miss anything?
Also, here's a link to my GitHub repo containing all of this example code.
Commenti