This chapter provides information on Azure Virtual Desktop’s high-level architecture, including cost-saving options, user session flow with and without RDP shortpath, Azure platform/Azure Virtual Desktop limitations, VM sizing, network capacity requirements, operating system recommendations, DNS for Azure Virtual Desktop, Azure Virtual Desktop host pool placement, and resource groups.
You learned about the basics of Azure Virtual Desktop in Chapter 1, so let’s get into the details of the Azure Virtual Desktop architecture and the user connection flow to Azure Virtual Desktop.
Azure Virtual Desktop Architecture
Azure Virtual Desktop high-level architecture
- Hub-and-spoke architecture: It is recommended you use a dedicated virtual network and subscription for Azure Virtual Desktop resources to isolate Azure Virtual Desktop as well as avoid Azure subscription-level limitations. If it’s a greenfield deployment (new to Azure), then you must consider a hub-and-spoke architecture and a dedicated hub virtual network. The following are the typical resources needed in a hub-and-spoke architecture:
Hub resources: You can use a hub virtual network per region to place all common/shared services such as an extended ADDS, DNS, SCCM, and firewall. A hub virtual network needs to be connected to an on-premises datacenter via ExpressRoute or a site-to-site VPN so that the on-premises services/application will be accessible in Azure. The hub subscription must have all the security controls in place, including a firewall to validate all outgoing traffic from the Azure virtual network’s to on-premises or the Internet.
Spoke resources: All the Azure Virtual Desktop resources including VMs, log analytics, and storage can be created in a spoke subscription/virtual network. It is recommended to create different subnets as well as a resource group for different types of host pools/business units. Spoke virtual networks can be peered with hub virtual networks, and user-defined routing (route table) can be configured to send all traffic via a hub virtual network firewall to on-premises or the Internet. For easy management, you must create a separate host pool for different VM sizes so that it will be easy to manage user access and advance autoscaling. Personal and pooled are the two different types of desktop options that Azure Virtual Desktop provides, so you must consider having a separate host pool for a pooled setup as well as a separate host pool for a personal setup. The Azure Virtual Desktop control plane handles web access, gateway, broker, diagnostics, and REST APIs and is managed by Microsoft, so you just have to manage AD DS and Azure AD, virtual networks, Azure Files or Azure NetApp Files, and the Azure Virtual Desktop host pools, session host, and workspaces. The Azure Virtual Desktop control plane is available in the United States (US), Europe (EU), United Kingdom (UK), and Canada (CA) regions as of September 2021; however, a host pool can exist in any other Azure region, but it will impact user performance if the control plane is not in the same or nearby region.
Authentication: You can use Azure AD for Azure Virtual Desktop authentication and ADDS for domain joins of the Azure Virtual Desktop session host. You can user Azure AD Connect to integrate the on-premises Active Directory Domain Services (AD DS) with Azure Active Directory (Azure AD) so that the same credentials can be used to log in to Azure Virtual Desktop. It is recommended to extend on-premises ADDS to the Azure hub to avoid authentication traffic over a VPN or ExpressRoute.
Network: Azure Virtual Desktop uses a reverse connect transport, which means you don’t need any inbound connection to an Azure Virtual Desktop session host from the Azure Virtual Desktop control plane or RD client. You need specific outbound IP/ports for Azure Virtual Desktop to work in case you are planning to block the Internet on the Azure Virtual Desktop session host. Azure Virtual Desktop users can connect the Azure Virtual Desktop gateway/broker over the Internet to access the Azure Virtual Desktop app (refer to the user connection flow Figure 2-2 for details) and reverse the connect transport from the session host to the Azure Virtual Desktop gateway/broker. If you have Azure Virtual Desktop shortpath enabled, then the user session traffic can go over a private IP address (refer to the “Azure Virtual Desktop User Session Traffic Flow with RDP Shortpath” section for details).
How Does the User Connect to Azure Virtual Desktop?
It is important to understand the user session connection flow from the Azure Virtual Desktop client to Azure Virtual Desktop so that you can consider all the session requirements in the Azure Virtual Desktop design phase and set up the network accordingly. Understanding user session flow can also help to troubleshoot the Azure Virtual Desktop access and performance issues.
The Azure Virtual Desktop client is available for all devices and operating systems so that users can log in to Azure Virtual Desktop from anywhere using any device. Connecting from Azure Virtual Desktop client to your host pool (session host) works differently with Windows Virtual Desktop than other VDI sessions. Azure Virtual Desktop uses a reverse connection, which means no inbound IP/ports are required on the session host (back-end VM) to set up the Azure Virtual Desktop connection.
Azure Virtual Desktop user session flow
The user launches an RD client and enters credentials that connect to Azure AD for sign-in. If third-party MFA is enabled, then the authentication request will go to the MFA server/provider as well. Clients get a token after successful authentication (flow 1 in Figure 2-2).
The client presents a token to Web Access to determine the resources authorized for the user from the Azure Virtual Desktop metadata; currently the Azure Virtual Desktop metadata is available in limited regions, so you must select a nearby metadata region for better performance if the metadata is not available in the region selected for Azure Virtual Desktop (flow 2 in Figure 2-2).
The user gets the authorized resources (Azure Virtual Desktop/application) to select in the RD client. See Figure 2-3.
Azure Virtual Desktop’s Remote Desktop client view
The user selects a resource by clicking the workspace name visible in the RD client.
The RD client connects to the gateway and gateway contact broker from the same region (flows 3 and 4 in Figure 2-2).
The broker orchestrates a connection from the host agent to the gateway (flows 4 and 5 in Figure 2-2).
RDP traffic now flows between the RD client and session host VM over connections 6 and 3 shown in Figure 2-2 (only if RDP shortpath is not enabled on AVD).
If RDP shortpath is enabled, then it establishes the direct connectivity between the Remote Desktop client and the session host. Direct connectivity reduces the dependency on the Azure Virtual Desktop gateways, improves the connection’s reliability, and increases the bandwidth available for each user session.
Once the connection flow proceeds, bidirectional communication between your session hosts/host pool will go over port HTTPS (443).
Azure Virtual Desktop User Session Traffic Flow with RDP Shortpath
As you know, by default Azure Virtual Desktop traffic goes through the RD gateway over port 443, but that increases the dependency on the Azure Virtual Desktop control plane, and if the gateway is not in the same region as the session host, then it impacts the end-user performance. Microsoft provides an RDP shortpath option to avoid performance issues and dependency on the RD gateway. RDP shortpath needs a direct line of sight to the session host from the RD client. A direct line of sight means that firewalls aren’t blocking UDP port 3390, and the client can connect directly to the session host using RDP over a private (or public) IP.
ExpressRoute
A site-to-site or point-to-site VPN
Public IP address assignment on the session host (not recommend)
Azure Virtual Desktop user session flow with RDP shortpath
Setting up the Azure Virtual Desktop client authentication and selecting authorized resources flow are the same with/without RD shortpath.
The session host sends IPv4 and IPv6 addresses (private or public, whichever is applicable) to the client after authentication.
The client starts a parallel UDP-based transport connection directly to one of the host’s IP addresses (private or public, whichever is applicable).
While the client is probing the provided IP addresses, it continues the initial connection establishment over the reverse connect transport to ensure no delay in the user connection (default flow).
If the client has a direct line of sight and the all-firewall configuration is correct, the client establishes a secure TLS connection with session host (flow 6 in Figure 2-2).
After establishing the shortpath transport, RDP moves all dynamic virtual channels (DVCs), including remote graphics, input, and device redirection, to the new transport.
If a firewall or network topology prevents the client from establishing direct UDP connectivity, RDP continues with a reverse connect transport.
Azure Virtual Desktop User Session Connectivity and Security
Azure Virtual Desktop uses TLS 1.2 for all connections from the clients to Azure Virtual Desktop session hosts, which is same as Azure Front Door. The client and session host connect to the Azure Virtual Desktop gateway with the reverse connect transport and establishe the TCP connection. The client or session host validates the Azure Virtual Desktop gateway’s certificate after the TCP connection. Finally, RDP establishes a nested TLS connection between the client and session host using the session host’s certificates. By default, the certificate used for RDP encryption is self-generated by the operating system, but you can use an enterprise certification authority certificate as well.
Azure Virtual Desktop Design Considerations for Cost Savings
Windows 10 multisession: A Windows 10 multisession desktop can be used for users who have identical compute/application requirements. You can let multiple users log onto a single VM at once and share the compute resources, resulting in considerable cost savings. Windows 10 multisession can be used in a pooled host pool.
Azure Hybrid Benefit (Windows Server): You can use Azure Hybrid Benefit for Windows Server and SQL if you already have the licenses. See Figure 2-5.
Azure Hybrid Benefit for Windows Server
Azure Reserved Instances: If you need a specific number of VMs running for a specific number of years, then you can prepay for your VM usage and save money. Combine Azure Reserved Instances with Azure Hybrid Benefit for up to an 80 percent savings over list prices.
Autoscaling and session host load-balancing (pooled): When setting up pooled session hosts, breadth-first is the standard default mode, which spreads users randomly across session hosts. Depth-first mode fills up a session host with the maximum number of users before it moves on to the next session host, which allows autoscaling to stop/shut down unused session hosts to save costs. You can adjust this setting for maximum cost benefits.
Autostart VM on connect (personal): You can set up the “Start VM on Connect” setting when setting up personal session hosts, which will allow you to stop/shut down session hosts during nonbusiness hours. The VM will get started whenever the user tries to connect to the session host. This can help you to save money on personal session hosts as well.
Azure Virtual Desktop Limitations
The Azure platform and Azure Virtual Desktop control plane have some limitations that need to be considered during the design phase to avoid changes in the scaling phase. The Azure Virtual Desktop service can scale more than 10,000 session hosts per workspace, but it is recommended to deploy 5,000 or fewer VMs per Azure subscription per region. This recommendation applies to both personal and pooled host pools based on Windows 10 Enterprise single and multisession. Most customers use Windows 10 Enterprise multisession, which allows multiple users to log on to each VM. You can increase the resources of individual session host VMs to accommodate more user sessions. To manage enterprise environments with more than 5,000 VMs per Azure subscription in the same region, you can create multiple Azure subscriptions in a hub-and-spoke architecture and 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.
Other limitations are related to automation and APIs. Azure Resource Manager (ARM) subscription API throttling limits don’t allow more than 600 Azure VM reboots per hour via the Azure portal. You can reboot all your machines at once via the operating system using PowerShell remoting, which doesn’t consume any Azure Resource Manager subscription API calls. Additionally, for automated session host scaling tools, the limits are around 2,500 VMs per Azure subscription per region, because VM status interaction consumes more resources.
If you are planning to automate session host creation, then you should know that you can currently deploy up to 399 VMs per Azure Virtual Desktop ARM template deployment without availability sets, or 200 VMs per availability set. Also, the Azure VM session host name prefixes support only 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, so you have to place resource group structure accordingly. Azure compute doesn’t have this limit.
There are some prerequisites and considerations that need to be checked before admins start deploying AVD. The following are some high-level prerequisites that are explained in subsequent chapters.
Assess Existing Physical and Virtual Desktop Environments
It is important to choose the correct user profile size for the Azure Virtual Desktop to avoid performance issues. The Azure Virtual Desktop user profile size can be determined from the existing environment in case a user is already using any other VDI platform or physical devices. There are a few assessment tools available (i.e., Lakeside, EG innovations) that provide insight into your current IT environment by giving a thorough analysis of end-user activity and resource usage on the current VDI solution.
You can generate a VDI assessment report for the last few months to find out the resource usage on the existing VDI platform including CPU and RAM and accordingly finalize the Azure Virtual Desktop profile size for users. There might be different usages for each user, so group the users with different usage and finalized VM sizes for each group of users.
Assess Network Capacity and Speed Requirements for Azure Virtual Desktop
Azure Virtual Desktop performance is mainly dependent on network capacity as the session host will be running on the cloud platform. Azure Virtual Desktop uses Remote Desktop Protocol to provide remote display and input capabilities over network connections. RDP dynamically adjusts various parameters to deliver the best user experience based on the availability of computing resources and network bandwidth.
Azure Virtual Desktop client to Azure Virtual Desktop session host: It is recommended to place the Azure Virtual Desktop session host near the user location to get better performance. The user location and Azure Virtual Desktop region can affect the user experience as much as the network conditions. Check out the Azure Virtual Desktop experience estimator (https://azure.microsoft.com/services/virtual-desktop/assessment/) to find out the correct Azure region for specific users and the estimated round-trip time (RTT) from the user location to the Azure region. Additionally, the Azure Virtual Desktop user session always goes via Azure Virtual Desktop gateway, so you have to make sure that the Azure Virtual Desktop control planes (gateway, broker) are in the same region or a nearby region.
On-premises to Azure bandwidth: This is important when there are applications hosted on an on-premises datacenter that need to be accessed via Azure Virtual Desktop. In this case, Azure to op-prem bandwidth (S2S/ER) is important, and the application bandwidth requirement needs to be considered to calculate the required bandwidth. See Figure 2-6.
Azure Virtual Desktop network connections
It is difficult to predict bandwidth usage for Azure Virtual Desktop’s Remote Desktop Protocol because user activities generate most of the remote desktop traffic. Every user is unique, and differences in their work patterns may significantly change network use. The amount of data sent over the network via RDP depends on the user activity. For example, a user may work with Visual Studio Code to write code for a full day and consume minimal bandwidth, but then another user may use more bandwidth in less time by sending a 200-page print to the local printer.
The best way to identify network bandwidth requirements is to monitor real user connections by the built-in performance counters in Perfmon or by the network equipment. However, in many cases, you may be able to estimate network utilization by understanding how Remote Desktop Protocol works and by analyzing your users’ work patterns.
The Remote Desktop Protocol delivers the graphics generated by the remote server to display it on a local monitor. Sending a desktop bitmap is not simple task and requires a significant number of resources. For example, a 1080p desktop image in its uncompressed form is around 8 MB in size, and displaying this image on the locally connected monitor with the refresh rate of 30 Hz requires a bandwidth of about 237 MB/s. To reduce the amount of data transferred over the network, RDP uses the combination of multiple techniques like frame rate optimizations, screen content classification, content-specific codecs, progressive image encoding, and client-side caching.
When using a remote Windows session, your network’s available bandwidth greatly impacts the quality of user experience. Different applications and display resolutions require different network configurations, so it’s important to make sure your network is configured to meet your needs.
Bandwidth Recommendations
Workload Type | Recommended Bandwidth |
|---|---|
Light | 1.5 Mbps |
Medium | 3 Mbps |
Heavy | 5 Mbps |
Power | 15 Mbps |
The bandwidth requirements may change depending on application workloads and your display resolution, voice or video conferencing, real-time communication, or streaming 4K video.
Recommended Operating Systems for an Azure Virtual Desktop
Azure Virtual Desktop License Requirement
OS | Required License |
|---|---|
Windows 10 Enterprise multisession or Windows 10 Enterprise | Microsoft 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5 |
Windows 7 Enterprise | Microsoft 365 E3, E5, A3, A5, F3, Business Premium Windows E3, E5, A3, A5 |
Windows Server 2012 R2, 2016, 2019 | RDS Client Access License (CAL) with Software Assurance |
Windows 10 Enterprise multisession: Windows 10 multisession is recommended for pooled host pools when we have users with the same application/software requirements and they don’t rely on any system-specific setting/configuration. Multiple users can log in (different session) on a Windows 10 multisession operating system, which helps to optimize costs. You have a pooled desktop support application with user-centric installation so that any user log in to the session host can access the application and the application configuration gets stored in user profile.
Windows 7 Enterprise/10 Enterprise: Both are recommended for personal Azure Virtual Desktop where users are dependent on a system-specific configuration or need a highly intensive or dedicated system configuration to perform certain tasks. Windows 7 is still supported by Azure Virtual Desktop in case the user wants to use an application supported on a legacy operating system.
Windows Server 2012 R2, 2016, 2019: All server operating system are recommended if the user is going to use an application supported only on a server system or services available on a server for day-to-day work. If your organization already has RDS CALs and want to use them instead by buying other Azure Virtual Desktop supported licenses, then the server operating system can be used in AVD.
Azure Virtual Desktop doesn’t support x86 (32-bit), Windows 10 Enterprise N, Windows 10 LTSB, Windows 10 LTSC, Windows 10 Pro, or Windows 10 Enterprise KN operating system images. Windows 7 also doesn’t support any VHD or VHDX-based profile solutions hosted on managed Azure Storage due to a sector size limitation.
Plan and Configure Name Resolution (DNS) for Active Directory (AD) and Azure Active Directory Domain Services (Azure AD DS)
DNS is important for Azure Virtual Desktop to work because the session host is always joined to an ADDS domain, and if the DNS is not working, the session host won’t be able to resolve a domain name for authentication or resolve external domain names for Internet access on Azure Virtual Desktop.
Self-hosted DNS: Most enterprises are using Microsoft AD DS integrated DNS or third-party DNS on on-premises, and the same can be used for Azure Virtual Desktop as well. This is a recommended option as you can manage all the DNS records in one place.
Depending on the DNS traffic, the on-premises DNS server can be extended to an Azure hub subscription or point Azure Virtual Desktop resources to use on-premises DNS. DNS server IP address and port 53 need to be opened on the firewall between the DNS server and Azure Virtual Desktop. The virtual network uses on-premises DNS for name resolution. Additionally, change the virtual network’s DNS setting to point to the DNS server IP address, as shown in Figure 2-7.
Azure Virtual Desktop DNS setting on Azure Virtual Desktop Virtual Network
Azure private DNS zone: The Azure private DNS zone can be used to resolve Azure resource names. This provides a reliable and secure DNS service for your virtual network. Azure private DNS zones manage and resolve domain names in the virtual network without the need to configure a custom DNS solution. By using private DNS zones, you can use your own custom domain name instead of the Azure-provided names during deployment. Using a custom domain name helps you tailor your virtual network architecture to best suit your organization’s needs. It provides a naming resolution for virtual machines (VMs) within a virtual network and connected virtual networks. Additionally, you can configure zone names with a split-horizon view, which allows a private and a public DNS zone to share the name.
Azure-provided name resolution: Azure-provided name resolution provides only basic authoritative DNS capabilities. If you use this option, the DNS zone names and records will be automatically managed by Azure, and you will not be able to control the DNS zone names or the life cycle of DNS records. If you need a fully featured DNS solution for your virtual networks, you must use Azure DNS private zones or customer-managed DNS servers.
Plan a Host Pool Architecture and Recommendations for Resource Groups, Subscriptions, and Management Groups
We’ll cover several topics in this section.
What Are Host Pools?
A host pool is a collection of Azure virtual machines with the same configuration. An Azure VM can be registered to Azure Virtual Desktop as session hosts when you run the Azure Virtual Desktop agent on the Azure VM. All session host virtual machines in a host pool should be sourced from the same image for a consistent user experience.
Personal, where each user gets assigned to an individual session host.
Pooled, where session hosts can accept connections from any user authorized to an app group within the host pool
You can set additional properties on the host pool to change its load-balancing behavior and the number of sessions each session host can take. You control the resources published to users through app groups. Refer to the “Configure host pool settings” section in Chapter 8 for a detail hostpool configuration.
What Are App Groups?
RemoteApp: Users access RemoteApp (a single application like Word or Excel) to individually publish to the app group. To publish to RemoteApp, you must create a RemoteApp app group. You can create multiple RemoteApp app groups to accommodate different worker scenarios. Different RemoteApp app groups can also contain overlapping RemoteApp instances.
Desktop: Users access the full desktop. By default, a desktop app group is automatically created whenever you create a host pool. You can’t create another desktop app group in the host pool while a default desktop app group exists, but you can delete the default desktop group and create new one with a different name or use PowerShell/ARM to create a desktop group as per the naming standards you want.
A user can be assigned to both a desktop app group and a RemoteApp app group in the same host pool. However, users can’t launch both types of app groups at the same time in a single session.
A user can be assigned to multiple app groups within the same host pool, and their feed will be an accumulation of both app groups.
What Is a Workspace?
A workspace is a logical grouping of application groups in Azure Virtual Desktop. Each Azure Virtual Desktop application group must be associated with a workspace for users to see the remote apps and desktops published to them.
Azure Virtual Desktop host pool, session host, resource group placement
A dedicated subscription is recommended for Azure Virtual Desktop resources for easy management and scaling on-demand.
A separate virtual network is recommended with multiple subnets for pooled and personal in each region and peering with a hub virtual network in that region.
A virtual network scope range needs to be decided on, considering the number of VMs for pooled as well as personal and future growth.
Multiple host pools of the same type can use the same subnet as far as there is no compliance/InfoSec requirement. Each subnet can be restricted with a set of NSG rules.
You need a separate host pool for each VM size, each region, and each type (pooled/personal).
You need a dedicated resource group for each host pool to manage RBAC on the host pool–specific resources.
RDP properties can be a set of host pool levels, so if we have a set of users that need different RDP properties, then we have to create different host pools. For example, some users need to copy the Azure Virtual Desktop option and some not.
A separate pooled host pools for users who need a different set of applications.
Configure a Location for the Azure Virtual Desktop Metadata
United States (US) (generally available)
Europe (EU) (generally available)
United Kingdom (UK) (generally available)
Canada (CA) (generally available)
Just remember that your performance using a host pool outside of the previous locations might vary until the control plane is added to other regions because all Azure Virtual Desktop client traffic goes through the control plane (if not using shortpath). If you set up a host pool in a non-metadata location with a previous control plane location, you will automatically switch to the local control plane when it’s rolled out for your region.
If RDP shortpath is enabled, then RDP shortpath establishes the direct connectivity between the Remote Desktop client and the session host. Direct connectivity reduces the dependency on the Azure Virtual Desktop gateways, improves the connection’s reliability, and increases the bandwidth available for each user session
Calculate a Configuration for Performance Requirements
Azure Virtual Desktop performance is dependent on multiple factors such as the application, user Internet connection, user location and host pool region, Azure Virtual Desktop management service location, network bandwidth to on-premises if the application/AD/ANS is on-premises, and the application. All of these aspects need to be considered while designing the Azure Virtual Desktop architecture.
The appropriate VM size needs to be selected (based on assessment) for Azure Virtual Desktop.
If there are application servers in the on-premises datacenter that need to be accessed from Azure Virtual Desktop, then the application bandwidth recommendation needs to be followed.
If there are custom/third-party applications that need to be installed on Azure Virtual Desktop, then the application sizing recommendation needs to be followed.
Round-trip (RTT) latency from the client’s laptop to the Azure region (where host pools have been deployed) should be less than 150 ms. Use the Experience Estimator to view your connection health and recommended Azure region.
To optimize for network performance, Microsoft recommends that the session host’s VMs are collocated in the same Azure region as the Azure Virtual Desktop management service.
Make sure to load test these scenarios in your deployment using simulation tools like Login VSI. Vary the load size, run stress tests, and test common user scenarios in remote sessions to better understand your network’s requirements before moving into production.
Calculate a Configuration for Azure Virtual Machine Capacity Requirements
Pooled sizing example: Consider you have 100 users who want Azure Virtual Desktop and as per the VDI assessment report all users require two CPUs and 4 GB memory. All users are from same region and want to go with a pooled desktop since they are using same set of applications for their day-to-day work. We can go with a D8s_v4 size VM, which comes with eight CPUs and 16 GB memory, and it will allow you to assign four users per VM. Table 2-3 shows the reference size and per user cost calculation.
Azure Virtual Desktop Pooled Sizing Example
Workload Type | Users per CPU | Assessment Recommendation | Total Users per VM | Total Users | Total VM | Size - vCPU/RAM/OS Storage Minimum | Profile Storage per User | Total Cost per Month | Cost per User per Month |
|---|---|---|---|---|---|---|---|---|---|
Power+ | 2/user | 2 CPUs/user | 4 | 100 | 25 | D8s_v4 - 8 vCPUs, 16 GB RAM, 128 GB storage | 30 GB/user | $3,564.23 | $35.64 |
For cost optimization, you can select a higher VM size so that fewer session hosts are required, and operating system disk cost can be saved. Also, the costs shown in all the examples are based on the Azure calculator result as of November 2021 and do not include any discount.
Personal sizing example: Consider you have 100 users who want a new Azure Virtual Desktop, and as per the VDI assessment report, all users require two CPUs and 4 GB memory. All users are from the same region, but they need a different set of application/software for their day-to-day work. In this case, you can create a personal desktop with a D2s_v3 size VM, which comes with two CPUs and 8 GB memory. Table 2-4 is the reference size and per user cost calculation.
Azure Virtual Desktop Personal Sizing Example
Workload Type | Users per CPU | Assessment Recommendation | Total Users per VM | Total Users | Total VM | Size - vCPU/RAM/OS Storage Minimum | Profile Storage per User | Total Cost per Month | Cost per User per Month |
|---|---|---|---|---|---|---|---|---|---|
Power+ | 2/user | 2 CPUs/user | NA | 100 | 100 | D2s_v3 - 2 vCPUs, 8 GB RAM, 128 GB storage | 30 GB/user | $ 4,672 | $46.72 |
General Virtual Machine Recommendations
You must follow the VM requirements to run the operating system; see the Windows 10 computer specifications and system requirements article for detailed requirements.
It is recommended to use premium SSD storage for the OS disk for production workloads.
Graphics processing units (GPUs) are a good choice for users who regularly use graphics-intensive programs for video rendering, 3D design, and simulations.
B-series burstable VMs are a good choice for users who don’t always need maximum CPU performance. D-series is recommended for general users.
Azure Virtual Desktop Workload Types
Azure Virtual Desktop Workload Types
Workload Type | Example Users | Example Apps |
|---|---|---|
Light | Users doing basic data entry tasks | Database entry applications, command-line interfaces |
Medium | Consultants and market researchers | Database entry applications, command-line interfaces, Microsoft Word, static web pages |
Heavy | Software engineers, content creators | Database entry applications, command-line interfaces, Microsoft Word, static web pages, Microsoft Outlook, Microsoft PowerPoint, dynamic web pages |
Power | Graphic designers, 3D model makers, machine learning researchers | Database entry applications, command-line interfaces, Microsoft Word, static web pages, Microsoft Outlook, Microsoft PowerPoint, dynamic web pages, Adobe Photoshop, Adobe Illustrator, computer-aided design (CAD), computer-aided manufacturing (CAM) |
Azure Virtual Desktop Multisession (Pooled) Sizing Recommendation
Azure Virtual Desktop Pooled Sizing Recommendation for POC
Workload Type | Maximum Users/ vCPU | Example Azure Instances | Profile Storage Minimum |
|---|---|---|---|
Light | 4 | D4s_v4, F4s_v2, D4as_v4 | 30 GB |
Medium | 4 | D4s_v4, F4s_v2, D4as_v4 | 30 GB |
Heavy | 2 | D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 | 30 GB |
Power | 1 | D4s_v4, F4s_v2, D4as_v4, NV12, NVv4 | 30 GB |
Azure Virtual Desktop Pooled Sizing Recommendation
Workload Type | Maximum Users/ vCPU | Example Azure Instances | Profile Storage Minimum |
|---|---|---|---|
Light | 6 | D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 | 30 GB |
Medium | 4 | D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 | 30 GB |
Heavy | 2 | D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4 | 30 GB |
Power | 1 | D8s_v4, F8s_v2, D8as_v4, D16s_v4, F16s_v2, D16as_v4, NV12, NVv4 | 30 GB |
It is always recommended to consider the application/software recommendations while deciding on the usage profile for pooled instances.
Azure Virtual Desktop Pooled Sizing Example
Workload Type | Users per vCPU | App Recommendation | Total Users per VM | Total Users | Total VM | Size - vCPU/RAM/OS Storage Minimum | Profile storage per User | Total Cost per Month | Cost per User per Month |
|---|---|---|---|---|---|---|---|---|---|
Power | 1 | 1 CPU/user | 8 | 100 | 13 | D8s_v4 - 8 vCPUs, 16 GB RAM, 128 GB storage | 30 GB | $1,935.23 | $19.35 |
It is recommended that you limit the VM size to between 4 vCPUs and 24 vCPUs. Microsoft doesn’t recommend using fewer than 2 cores or more than 32 cores for standard and larger environments.
Azure Virtual Desktop Single-Session (Personal) Sizing Recommendations for Greenfield Deployment
For VM sizing recommendations for single-session scenarios, we recommend at least two physical CPU cores per VM (typically four vCPUs with hyperthreading). If you need more specific VM sizing recommendations for single-session scenarios, ask the software vendors specific to your workload. VM sizing for single-session VMs will likely align with physical device guidelines.
Test Pooled/Personal Azure Virtual Desktop Workload
Microsoft recommends using simulation tools (such as LoginVSI) to test your Azure Virtual Desktop with both stress tests and real-life usage simulations. Make sure your system is responsive and resilient enough to meet user needs, and remember to vary the load size to avoid surprises after moving into production.
Summary
In this chapter, you learned about the Azure Virtual Desktop architecture including user session flow, session security, and RDP shortpath. Additionally, you learned about AVD limitations and other cost-saving options that need to be considered during Azure Virtual Desktop design.
Most important, you learned about the host pool, resource group, subscription, management group recommendations for Azure Virtual Desktop, which will definitely help you to design and implement a secure and cost-effective solution for big enterprises.