Many businesses are reducing the need for PC’s with Azure Virtual Desktop. With the growth of telework for many businesses, there comes a requirement for workers to access company data, participate in teleconferences, and remotely work with other employees as a group from anywhere at any time. Not only for the obvious COVID-related issues but also for the many fully remote companies or companies that allow some employees to work remotely. Microsoft offers an Azure Desktop-as-a-Service service called Azure Virtual Desktop (AVD).
AVD offers the following capabilities:
- Implement multi-session Windows 10 and 11 deployments that deliver full Windows 10 and 11 desktops with scalability
- Provide Office 365 applications for the enterprise as individual streaming applications or installed on the virtual desktop
- Import or replace existing Remote Desktop Services (RDS)
- Virtualize both desktops and applications
- Monitor performance and perform diagnostics in the Azure portal
- Microsoft manages a large portion of the AVD infrastructure. Users only need to manage the images (multi-session hosts and host pools).
- Users receive a new Desktop image each time they connect, or they can be assigned a Virtual Desktop permanently.
Typical AVD deployment
This is a standard AVD deployment.
This diagram shows a typical architectural setup for Azure Virtual Desktop.
- Application endpoints are in the customer’s on-premises network. ExpressRoute extends the on-premises network into the Azure cloud, and Azure AD Connect integrates the customer’s Active Directory Domain Services (AD DS) with Azure Active Directory (Azure AD).
- Azure Virtual Desktop control plane handles Web Access, Gateway, Broker, Diagnostics, and extensibility components like REST APIs.
- The customer manages AD DS and Azure AD, Azure subscriptions, virtual networks, Azure Files or Azure NetApp Files, and the Azure Virtual Desktop host pools and workspaces.
- To increase capacity, the customer uses two Azure subscriptions in a hub-spoke architecture, and connects them via virtual network peering.
AVD Scaling Architecture
The Azure Virtual Desktop service is scalable to more than 10,000 session hosts per workspace. You can address some Azure platform and Azure Virtual Desktop control-plane limitations in the design phase to avoid changes in the scaling phase. Use the standard Azure organization matrix of Management Groups, Subscriptions, Resource Groups, and Resources.
AVD Limitations and design notes:
- Microsoft recommends deploying no more than 5,000 VMs per Azure subscription per region. This recommendation applies to both personal and pooled host pools based on Windows 10 Enterprise single and multi-session.
- For automated session host scaling tools, the limits are around 2,500 VMs per Azure subscription per region. VM status interaction consumes more resources.
- To manage enterprise environments with more than 5,000 VMs per Azure subscription in the same region, create multiple Azure subscriptions in a hub-spoke architecture. Then connect them via virtual network peering, as in the preceding example architecture. You could also deploy VMs in a different region in the same subscription to increase the number of VMs.
- Azure Resource Manager (ARM) subscription API throttling limits don’t allow more than 600 Azure VM reboots per hour via the Azure portal. All machines can be rebooted at once via the operating system, which doesn’t consume any Azure Resource Manager subscription API calls.
- Deployment of 399 VMs per Azure Virtual Desktop ARM template without Availability Sets is allowed, or 200 with Availability Set. The number of of VMs per deployment by switching off Availability Sets in either the ARM template or the Azure portal host pool enrollment.
- Azure VM session hostname prefixes can’t exceed 11 characters, due to auto-assigning of instance names and the NetBIOS limit of 15 characters per computer account.
- By default, you can deploy up to 800 instances of most resource types in a resource group. Azure Compute doesn’t have this limit.
A key point to consider is Microsoft does not allow other Venders to use the Windows 10 or 11 multi-session operating system. Other DaaS providers must use Windows Server 2016 or higher with the Desktop Experience option. Vmware and Nutanix are moving to a Cloud option that will use Azure AVD resources.
Network considerations
Unlike on-premises VDI systems, DaaS is easily scalable. Perceived DaaS performance degradation is nearly always related to network issues. For optimal performance, make sure your network meets the following requirements:
- Round-trip (RTT) latency from the client’s network to the Azure region where host pools have been deployed should be less than 150 ms. The Microsoft Experience Estimator allows you to view your connection health and recommended Azure region.
- To optimize for network performance, Microsoft recommends that the session host’s VMs are in the Azure region that is closest to the user.
As you can see below, the Microsoft Experience Estimator website displays the lowest RTT by region. This is from the user’s perspective from any global location. As such, you must consider latency when planning your AVD deployment.
Conclusion
Microsoft AVD is easy to configure, and since Microsoft manages a great deal of the environment, it is much easier to maintain than a complete on-premises VDI environment. Therefore, the planning phase of the AVD deployment is the most important. The AVD documentation can be found here.
