By Katy Nicholson, posted on December 24, 2021
Azure Virtual Desktop (previously called Windows Virtual Desktop) is exactly what it sounds like: a Virtual Desktop solution on Azure! While many of us are familiar with Windows Server Remote Desktop roles, and if we think hard enough, Terminal Services, AVD is an exciting cloud-based version.
So the first question I think we need to address is "Why do I need this?" - Why can't we just use some Server 2022 VMs in Azure running the standard RDS roles: session hosts, brokers, gateways, etc.? Well, you can if you want, but then you're paying the compute costs of your session hosts, brokers, and gateways, setting up a public IP address, and opening ports. With AVD, the agent and gateway are provided on Azure and are free; all you pay is the cost of the session host virtual machines.
Another point here is that with AVD you can use Windows 10 (or 11) Multi-session Edition, designed for virtual desktops. You no longer have to try to fit Server with Desktop Experience instead.
The following discussion would arise: "What about Windows 365 Cloud PC? Why should we use AVD instead?". The answer to this is "It depends". You need a clear view of what your usage will look like: are you dedicating hosts to users in a 1:1 ratio? Do you need to run your hosts 24/7? The main cost differences here are that Windows 365 is a fixed price per user, regardless of whether that user logs in for one hour a day or 20 hours a day. With AVD, you're paying for the virtual machines on the host, and you can grow and grow your host pool based on expected demand.
Finally, Windows 365 is technically in a different product group than AVD, so it will have a slightly different target market. Windows 365 meets Microsoft Endpoint Manager and is designed to be easy to configure from the MEM. AVD sits with Azure - not as easy to set up, but more flexible. You can read more about the differences between AVD and Windows 365 atthe Microsoft docs page.
Since this post is called 'AVD: Getting Started', I'll obviously have chosen AVD over those other options here. I'll go over setting up a basic host pool and posting the session desktop, along with a couple of different methods of accessing it.
previous requirements
If you want to join an Active Directory domain, you'll need domain join credentials and connectivity to a domain controller. This could be an Azure VM running on the same virtual network or another virtual network with the appropriate network rules, or a domain controller running locally if you have ExpressRoute or a VPN between your site and your virtual network. Azure.
More recently, Azure AD join was implemented in AVD. There are no prerequisites as such for this, however there are a few additional steps along the way that are required for users to be able to sign in to an AzureAD joined host.
For both options, your users must be in Active Directory and synced with Azure AD. At some point in the future, this requirement will be removed for Azure AD joined hosts, which support cloud-only user accounts.
License
AVD can run a few different versions of Windows, each with its own license requirement:
- Windows 10 (o 11) Enterprise multisession: Windows A3/A5/E3/E5 o M365 A3/A5/E3/E5/F3/Business Premium
- Windows 7 Enterprise: Same as Windows 10/11
- Windows Server 2012R2 y superior: RDS CAL con Software Assurance
Create the host group
Our first step is to create the host group. Open the Azure portal and go toAzure Virtual Desktop > Host Groupsand click Create.
For the production environment, I would recommend creating a new resource group for this. If you're going to join AzureAD, there are some settings we need to apply to all host VMs a bit later, one that's easier if we can just apply them at the resource group level and let inheritance happen.
I usually set the host group type to Pooled; this will allow multiple users to log in to each host, rather than dedicating a host to one user.
There are two load balancing algorithms to choose from:
- First in Breadth: Distributes new connections to all hosts in the pool
- Depth First: Distributes new connections by filling each host to its maximum count before starting on the next host
Finally, maximum session limit: If you're using depth-first load balancing, or plan to use autoscaling, you'll need to enter a number here indicating the maximum number of concurrent sessions you want on each host.
Moving on to the next page, Virtual Machines. Here we will configure the resource group, VM name prefix, location, and availability options for our VMs. Select the image you want from the gallery (you can upload a custom image and select it here, but I'll cover that in a future post), along with the size of the virtual machine you want to use and the number of virtual machines.
When considering the size of the VM you want to use, I tend to go for several smaller VMs rather than one or two large VMs, as it makes it easier to take a host VM offline for maintenance without massively reducing Disponibility. Another factor to consider with sizing is what type of load you are expecting and how much you want to see in the budget. With multiple smaller virtual machines, you can shut down most of your host pool overnight to save cost and start them again when the workload is expected to be heaviest. With the 'Start on connect' feature, you can even shut down the ENTIRE host pool and it will automatically start a virtual machine when a user tries to connect.
Scrolling down, fill in the network details and domain join type. If you're joining an AD domain, you'll need the UPN and password for an account that can create computer objects in the domain. If you join Azure AD, you can also enroll the virtual machines with Intune if you want.
Finally, set up the VM's local administrator account credentials and complete the setup process.
After you've spent some time deploying the servers in the host pool, you should be able to click on the host pool and see an overview screen like the one below.
configure apps
For the purposes of this post, all we are going to do is set up the session desktop. In a future post, I will fully cover remote applications. Hopefully the setup process has created an app pool and app for you - go toAzure Virtual Desktop > Application Pools, and click on the application pool, in my case called KatyAVD-DAG.
Your application pool should have 1 application: Session Desktop. Click Assignments to assign this to the users or groups you want to have access to.
Create a workspace
now go toAzure Virtual Desktop > Workspacesand create a workspace. Complete the Getting Started screen and then skip to Review + Create. Then go to the workspace, then App Pools and add your app pool.
Configure other settings
GonnaAzure Virtual Desktop > Host Groupsand click on your host group. WithinPropertiesscreen, you can modify the load balancing algorithm and maximum session limit, as well as toggle the Start VM on connection feature.
clicking onRDP Propertiesyou can set the properties used for the connection, e.g. session behavior, redirected resources, etc.
If you have Azure AD joined to your host group, you'll need to clickAdvancedand add 'targetisaadjoined:i:1' in the RDP properties.
Another element to take into account is the scaling plan. I'm not going to cover this here, but this is where I would specify which scaling plan to use for this group of hosts. These are currently in preview and are not available in all regions.
If you are using AD domain-joined hosts, you will need to ensure that users have permission to log on to the host, for example, by placing the user group within each host's local Remote Desktop Users group.
Azure AD role assignment
When I ran a hybrid combo setup, logging in as a user worked fine. With Azure AD joined, I got an error message: To fix this, each host VM will need the 'VM User Login' RBAC role assigned to the groups you want to be able to log in to. Ideally, you'd do this at the resource group level, assuming you've used a new resource group for AVD.
Evidence
now you're going toRemote Desktop Web Client (microsoft.com)and hopefully the app pool you assigned will appear. Click SessionDesktop to load the web client. This URL is not specific to your installation and is the global URL used to access AVD.
If you receive a login error, it is likely that you are using AzureAD joined hosts and have not configured RDP properties or assigned the VM user login role.
Within the Web Client Settings, you can configure it to download an RDP connection file instead of opening it in the web client. This will give you an rdpw file, which requires the newWindows desktop client.
The web client has a logging tool for troubleshooting: Click menu > About > Capture Support Info > Start Recording. You can then try connecting again and then return to that menu to stop recording. It will then give you a log file to examine. Another method I used when troubleshooting the RBAC functions and the RDP file was to try connecting to the host directly using RDP, bypassing the AVD gateway/agent entirely. Once I got this working I knew the problem was with the web client itself and not the virtual machine.
Host Administration
You can manage individual hosts by going to your host group and clicking Session Hosts. Here you can assign a host to a user (if you are not using pooled mode) and enable/disable drain mode. Drain mode is used to prevent new connections to a host server, if you want to do some maintenance on a host VM you can use this in conjunction with logging out existing users.
By clicking on a specific host, you will be able to see the currently connected sessions and interact with them, for example by sending a notice or disconnecting them.
From the Session Hosts page you can also add additional session hosts. This process takes you through the same steps you completed above, where you can specify the gallery image, VM size, number of VMs, etc.