Today I want to write about a product that I like very much: Windows Virtual Desktop, WVD for friends!
WVD is a revolutionary Azure PaaS for Virtual Desktops: let’s imagine a very complicated infrastructure as RDS is. Do you feel pain and terror now? Trash all! Azure manages all connection infrastructure giving the possibility to IT Department to start with Virtual Desktops Infrastructure in days not in weeks.
But I haven’t told you everything yet: in Azure we have the possibility to use a new OS named “Windows 10 Enterprise Multisession”, in addition to classical Windows Server OS with RDS Role.
This OS is only available for use in Azure Environment and gives to users the same experience of a normal Windows 10 client but with the advantage of a centralized environment under the IT Department control.
Let’s talk about Pre-Requisites:
1. License for Windows 10 Enterprise Multisession
Microsoft 365 E3, E5, A3, A5, F3, Business Premium
Windows E3, E5, A3, A5
2. Azure Active Directory
3. Windows Server Active Directory in synchronization with Azure Active Directory (or Azure Active Directory Domain Services)
4. Session Host must be AD-Joined or Hybrid AD-Joined: at this moment Azure AD Joined machines are not allowed.
But another killer feature is the connection method to session hosts: we don’t have to configure port forwarding for RDP, certificates, etc… It’s all managed by Azure!
Microsoft has created a new “Remote Desktop” client that allows users to connect to session hosts with Azure AD Credentials (with Conditional Access, MFA and all the security procedures configured in the tenant).
This new connection experience is present on Windows, MacOS, iOS, Android and also via HTML5 browsers.
For Linux systems, there are some Microsoft Partners available with custom solutions (here some infos).
I think we have talked very much: it’s time to create our WVD Host Pool.
Go to Azure Portal, and search for “Windows Virtual Desktop”.
Now, we are in Windows Virtual Desktop, Overview Page: let’s click on “Create a host pool”
Now, we have similar requests as when we create Azure VMs.
We must specify the “Host Pool Name” and the location of WVD Host Pool Metadata (at this moment only US locations are available).
We can also configure this host pool as a personal machine (assigned to one user) or for multiple users (pooled), the max session limits (based on Azure VM size and utilization scope) and the load balancing algorithm for user distribution.
Breadth distributes users on all available session hosts, Depth distributes users on a single machine until the fixed threshold configured in “Max Session Limit” parameter is reached and then pass to another available session host.
Now, click “Next: Virtual Machines” to confirm your settings and continue with configuration.
Ok: we are now configuring VM Size. For correct VM number and sizing I suggest you to check this link.
We must choose Resource Group, VM location, the number of VMs, the name prefix of our session hosts (if we choose VDI as in example, VMs name will be VDI-0, VDI-1 etc…), the image type (in our example I’ve chosen Windows 10 Enterprise Multisession with Microsoft 365 Apps and the OS disk type.
In the second part of the page we must select Azure Virtual Network, the Public IP of each Session Host, the NSG and the domain to join.
Pay attention to Vnet DNS configuration: specify correct DNS Servers to allow Session Host to join correctly to Active Directory.
We also have the possibility to specify an AD Organizational Unit where to put Session Hosts.
We are ready to click “Next: Workspace”.
It’s the moment to create a Workspace and register Desktop Application (if you want) that will be visible in “Remote Desktop” application after user sign-in. Give it a name and click “Review + Create” (or “Next: Tags” if you want to assign Tags to your new resources).
“Review + Create”: here we are. Double check your configuration and start your WVD Deployment pressing “Create”. For a single D-Series machine, the deploy took about 10 minutes.
After Host Pool successful creation we should do some other works to make things work for our users.
First of all, assign Apps to some of them: the Desktop app could be a good application to try. Let’s see how to make this assignment. Go to Azure Portal, search for “Windows Virtual Desktop”, select “Application Group” and choose our Application (the Desktop Application Group created some paragraphs ago).
Now select “Assignments” and click “+ Add”: we should choose Users or Security Group that contains Users to allow them to access to Desktop of our Session Hosts. My recommendation is to use a robust naming convention.
Now, using the “Remote Desktop” application, users should be able to find their resources.
There are two ways for configuring the tool: with a DNS Record (recommended) or with a URL.
With the DNS Record, users, only typing their credentials have instant access to their assigned Application.
The DNS record that we should publish on our public domain DNS is a TXT:
If we don’t want to publish this DNS record, we must subscribe with a URL. The URL that users must configure is:
In HTML5 version, instead, there is no particular configuration: users access via website with Azure AD Credentials.
After login, here is what the user finds.
Les Jeux Sont Fait: click on the icon and enjoy your new Virtual Desktop!
In the next weeks I’ll write about WVD Monitoring, FSLogix for user profiles archiving, RDP Properties and some other useful things on this argument.
I hope that my post can help some of you that want to begin their adventure in Windows Virtual Desktop.
See you soon!