A common question we hear from MSPs exploring Windows Virtual Desktop (WVD) is “what do I need to do to get started?” In this article, we will review the Windows Virtual Desktop prerequisites for getting started and explain how to go about checking off each box. The assumption for this article is that you will be deploying WVD using the Windows 10 Enterprise multi-session desktop OS and not Windows Server 2019 with RDS (which is technically also supported).
To get started with WVD you need to be ready with the following 5 items:
- Subscription to Windows 10 Enterprise for each WVD user
- Azure Active Directory (AAD) tenant
- Active Directory Domain Services (AD DS) deployment
- Azure subscription
- File Server
Subscription to Windows 10 Enterprise
WVD Management Service and Windows 10 desktop OS are licensed via a subscription to Windows 10 Enterprise. The following licenses can be used for WVD:
- Microsoft 365 – E3/E5/A3/A5/Business
- Windows (via CSP) – E3/E5/A3/A5
Note that Windows 10 Professional, OEM, or any non-subscription version of Windows are not entitled to use WVD.
You can purchase a subscription to the above products through any channel: CSP, EA, MCA, etc. The same per-user subscription license entitles the user to whom it is assigned to connect to multiple WVD desktops whether they are Windows 10 Enterprise multi-session, single-session, or even Windows 7.
Azure Active Directory (AAD) tenant
To deploy and manage WVD as an administrator and to assign users to desktops and applications there must be an Azure AD (AAD) tenant. AAD is Microsoft’s cloud directory service that is the highest-level object in the hierarchy when dealing with Microsoft Cloud services (O365, D365 and Azure). Everything ties to an AAD tenant. The tenant is generally associated to a unique domain name: tenant.onmicrosoft.com. It is also something referred to as “Directory” or “Account”.
If you are already using Office 365, then by definition you have an Azure AD tenant and that is the tenant you will need to use to deploy WVD. An AAD tenant gets created when you sign up for Office 365. You will need a Global Administrator account that has access to the AAD tenant.
An AAD tenant is free. It is a directory of users, groups, contacts, and other services. The members of an AAD tenant can be paid. For example, a user in AAD may have an Office 365 E3 license assigned and that license is paid. There are also paid add-ons for AAD. For example, Azure Active Directory Premium (P1 and P2) is a per-user license that extends the functionality of AAD with advanced features like multi-factor authentication (MFA) and conditional access (CA).
The good news is that as far as WVD is concerned it is quite simple: your Office 365 tenant is your Azure AD tenant in almost all scenarios since that is where the user objects that will be assigned to desktops reside.
Active Directory Domain Services (AD DS)
While Azure AD is a container of user objects, the actual WVD session hosts – the virtual machines running Windows 10 Enterprise multi-session – must join an Active Directory Domain Services (AD DS) forest. The terminology is somewhat confusing:
- Active Directory Domain Services (AD DS) – what is often called “Active Directory”
- Plain, vanilla Active Directory role on a traditional Windows Server machine that is managed with tools like Active Directory Users and Computer, Sites and Services, Domains, and Trusts.
- Contains user, group, contact, and computer objects
- Traditional Windows desktops and servers join AD DS
- Users and Groups can be synchronized with Azure AD using ADConnect
- Azure Active Directory (AAD) – Microsoft Cloud Directory services
- Despite its similar name to traditional Active Directory, this is a different service that is hosted by Microsoft and is the top-level object in Microsoft Cloud (O365, D365 and Azure)
- Contains user, group, and contact objects
- Windows 10 computers can join AAD while older operating system machines cannot
- Can be synchronized with an AD DS (#1 above) via ADConnect tool so the same username and password can be used for both
- Azure Active Directory Domain Services (AAD DS)
- An Azure hosted, Microsoft managed AD DS
- Most of the same capabilities as traditional, on-premises AD DS with some limitations due to lack of administrative access to the actual domain controller (Microsoft manages that)
- Synchronizes with AAD (which is synchronized with on an on-premises AD DS) and allows VMs running in Azure to join it regardless of the type of Windows OS (e.g. Windows 10/8/7 or Server 2008/2012/2016/2019)
Why all this detail? WVD requires that the session host VMs (desktop VMs) be joined to either AD DS (#1) or AAD DS (#3). This means that you must have an Active Directory deployment accessible to the WVD session host VMs. It is not possible to use only AAD (#2) for a WVD deployment.
Bottom line: with WVD you need both AAD (contains user objects) and AD DS (contains computer objects) and AD DS should be synchronized with AAD via ADConnect for best user experience.
Now that we have licensing and directory covered, the next thing you need is a place to create and run your WVD session host VMs that are going to be serving the Windows 10 Enterprise multi-session OS as a desktop to your users. This requires an Azure subscription.
An Azure subscription can be purchased via any channel: CSP, EA, MCA, etc. Typically, this Azure subscription will be inside of the Azure AD tenant mentioned above.
The subscription will contain the following:
- WVD Management Service
- WVD Tenant will be registered and added to the Azure subscription
- Inside of the WVD Tenant you will create Host Pools
- Inside of Host Pools you will have session hosts – Windows 10 VMs
- During Public Preview, the WVD Management Service is available only in the East US 2 region. Once WVD is generally available, this service will be scaled out to other regions.
- Windows 10 VMs and infrastructure
- Session hosts are VMs with Windows 10 Enterprise multi-session OS installed
- Each VM will have an OS and sometimes data disks. These disks can use any managed disk in Azure (Standard HDD, Standard SSD, Premium SSD)
- There will be a Virtual Network and subnets with VMs connected to those subnets
- There will be internet connectivity and bandwidth transfer costs
- There is no need for any network ports to be open for inbound traffic like you need with RDS. WVD uses an agent installed on each session host VM that leverages Reverse Connect technology to establish connectivity without opening any inbound ports.
- Session hosts can be running in any Azure region. Since WVD desktop users originate at the WVD Management Service first and then get routed to the VM running the desktop, it is important to keep the VMs and Management Services as close as possible – preferably in the same Azure region.
One of the new exciting features of WVD is the profile management technology from FSLogix. WVD desktop users’ Windows profiles are encapsulated in VHD files and stored on a file server independent of the Windows 10 session host VMs. This way, if a user is assigned to a pooled (i.e. non-persistent) desktop the profile (including Windows Search cache) can follow the user no matter what virtual desktop VM they log into.
In order to take advantage of this new functionality, there must be a file server accessible to the session host VMs to store these profile disks. It is best to have the file server and desktop VMs in the same Azure region, so the connectivity is fast. This will ensure good end-user performance. Eventually, it will be possible to use Azure Files instead of a file server but for now a Windows file server VM is recommended.
In conclusion, taking these 5 WVD prerequisites into account before diving into a deployment will save time and help make the deployment go smoothly. It will also allow for a properly architected infrastructure, directory, and licensing to ensure that your users will love the performance, usability and flexibility of their new virtual desktops in Azure.