Making the decision to use Azure Virtual Desktop (AVD) is a great first step to changing the way your team works. We discussed why you would use Azure WVD in a previous post. However, the next, more challenging step is figuring out how to implement it. As an Azure Gold Partner, in this post, we share what you need to know to set up Azure Virtual Desktop for your organisation (formerly called Azure Windows Virtual Desktop – WVD).
Got a question about Azure Virtual Desktop? Give us your email address using the link below and one of our Azure experts will answer by return:
Before you implement Azure Virtual Desktop, our Azure experts advise that you need to consider your user groups. Who in your organisation do you want to provide with a AVD?
Here are some questions that can help you define your user groups:
Will everyone get one or just a selected group of users?
Are these staff all based in the same country or are some on the other side of the world? You need to think about round trip latency for the end users and choose an Azure data centre region accordingly.
Will everyone get the same AVD or will different groups of users need different ones? For example, admin staff get a lower spec AVD with just Office and the engineering staff get a higher spec Azure WVD with Office and a CAD application.
Also how will these users access their Azure VDs? Will they use existing work or personal PCs / Macs using the available Azure WVD clients? Or will you be providing them with thin clients?
Once you define what your organisation’s needs are, our Azure experts highlight that you will need to make sure you have all the necessary components. Here’s what you need to set up WVD:
● Azure AD
● An Azure subscription
● A Domain Controller that is synced with Azure AD
● A virtual network for the session hosts
● Azure VD session hosts
● FSLogix for user profile containers
● A central storage location for the FSLogix user profile disks
You may already have some of these critical components. For example, when you sign in to the Azure VD service, it authenticates against Azure AD. If you’re using Office 365 (O365) or Microsoft 365 (M365), you already have Azure AD.
See our blog post on the difference between Azure AD and AD if you’re not familiar with Azure AD.
You will also need licensing for:
● Office with shared computer activation (if you’re planning to use Office)
● W10 Enterprise
The licensing for Office, FSLogix and W10 Enterprise is all included in the M365 Business Premium plan. If you are using a lower plan, then you can upgrade your license and pay the additional amount.
Your Azure VDs need to be joined to a domain, which is why you need a domain controller (DC). Our Azure experts outline three options:
● Azure Active Directory Domain Services (Azure AD DS)
● An Azure Virtual Machine configured as a DC
● An existing on-premises DC with a site to site VPN from on-premises to the Azure Vnet
Whichever option you choose they need to synchronize with Azure AD. For either of the Domain Controller options you install and configure Azure AD Connect, whereas Azure AD DS synchronizes with Azure AD directly.
Which option is best will depend on your existing set up and requirements.
For cloud based organisations we usually recommend Azure AD DS because it is simple to set up, there is no ongoing management (it is a Platform as a Service offering), it is resilient and it costs about the same as having a pair of Domain Controller Virtual Machines.
If you use Azure AD DS, then in order to set up any Group Policies for fine grained control of the Virtual Desktops (for example to deny user access to Control Panel) you need an additional Azure VM which is domain joined and has the Active Directory administrative tools installed. These policies are then synced to Azure AD DS, and you can then shut down this VM to save money, and spin it up again next time you want to edit or create any Group Policies.
Microsoft recommends FSLogix profile containers as the user profile solution to use with Azure WVD. At sign-in, this container is dynamically attached to the session host. Then, the user profile is immediately available. It appears in the system exactly as a native user profile would.
To create your image, you deploy a normal Azure VM and use this to create the image for your Azure VD Session Hosts. If you want the Office suite on your image, then deploy the VM from the Azure gallery image for Windows 10 Enterprise multi-session with Office, and it comes pre-installed.
Once the VM is created and joined to the domain, you install and configure the following:
● Access and rights for the users that will use this
● Your applications
Then you sysprep the VM and create an image from this. At this point the VM can no longer be used and you can delete it.
If you want a different image (say with different applications on) for different groups of users then you would create a second image for them in the same way.
You now have your image(s) from which you will create your session hosts.
The WVD Session Hosts are Azure VMs and they host the Virtual Desktop sessions.
You can dedicate an individual session host to each user – so in this instance there would just be one Virtual Desktop session running on the Session Host. But in most cases people choose to have multiple Virtual Desktop sessions supported on each Session Host.
You need to decide how much computing power to allocate to each AVD. This will depend on what the users’ workloads require.
Say for example each user needed 0.5 vCPUs and 2 GB of RAM, and you wanted 8 users per Session Host, then you would choose a VM size with 4 vCPUs and 16 GB of RAM for the Session Host. If you had 32 users then your hostpool would need to contain 4 of these Session Hosts.
Host pools are a collection of one or more identical virtual machines (Session Hosts) within the AVD environment.
Creating and deploying the host pool all happens in the Azure portal. You choose your image, the size and number of session hosts. Then, you decide which virtual network to add them to and which domain to join. Azure will then deploy the host pool for you.
This usually takes about 5 minutes and then your session hosts will be up and running.
An Application Group is associated with a host pool. The default app group created for a new host pool publishes the full desktop. So you can now assign users to that app group (again in the Azure portal GUI), and once you’ve done this they can sign into the WVD service to access their virtual desktop session.
If you have a number of different applications on the image and you would like to publish one of them as a remote application (e.g. Outlook, Chrome, or one of your Line of Business apps), then you just create a remote app group (in the GUI) for that application. You then assign users to that remote app group and it will be visible and available to them when they sign in to the Azure WVD service. You can do this for some or all of the available applications on the session host image.
Now the setup is complete, and users can access AVD. There are clients for AVD that you can install on Windows, Macs, iOS and Android devices, and there is also a web client. Or you may be using a Thin Client solution.
All users have to do is sign in with their Azure AD credentials and they can get to work.
AVD can benefit organisations of any size. If you’re interested in AVD and would like to understand how it could work for you and find out more about AVD pricing, then please contact us for a free discussion with one of our Certified Azure experts.
You can work with us to implement AVD. We are Azure Gold Partners and will provide free guidance on the Azure and Microsoft Office 365 elements. The only IT knowledge you will need to implement and manage this environment are traditional desktop management skills.
Got a question about AVD? Give us your email address using the link below and one of our Azure experts will answer by return: