We will start this book by looking at the design of Azure Virtual Desktop. Design is an integral part of any suitable technology solution, and in this chapter, we will look at the areas you should consider when designing Azure Virtual Desktop.
In this chapter, we'll cover the following topics:
Before we can look at the components of Azure Virtual Desktop, we need to understand the current environment, the requirements, and other information that would be useful.
When tackling the design of Azure Virtual Desktop, the first thing we must do is look at the current desktop estate within the organization's environment. The desktop estate could be purely physical, virtual, or a mixture of both physical and virtual. Suppose your organization is deploying a virtual desktop environment for the first time (greenfield deployment). In this case, you should still assess your physical desktop estate to understand the applications, data, and profile usage within your organization.
The desktop assessment should evaluate areas including the user's persona, consistent host pool types of virtual machines, applications, and user profiles. The data that's gathered from this assessment can be used to scope the deployment of new infrastructure and Azure Virtual Desktop migration.
When preparing your planning methodology, you can use Microsoft's best practices on cloud adoption. They will help you document your technology strategy and current desktop state:
Another helpful tool that can be used to plan is a digital estate assessment, which enables you to measure your desktop estate changes based on the organization's desired outcomes:
Using the data you have collected and analyzed will help you create the migration plan. You may need to carry out workload assessments to capture specific requirements. For an Azure Virtual Desktop migration deployment plan, you will require data about the desktops, users, and workloads used by each user.
Let's look at some tools available to you.
Movere is a product designed to help you migrate resources to Microsoft cloud services. It improves business intelligence by reporting on entire IT environments within a single day. As organizations grow, change, and digitally optimize, Movere helps IT admins to see and control their IT environment.
You can access Movere through Microsoft Solution Assessment and Microsoft Cloud Economics Program. You can use these tools when you're planning and deploying an Azure Virtual Desktop environment. You can find out more about Movere at https://www.movere.io/.
Azure Migrate is used to discover, assess, and migrate on-premises servers, apps, and data to Microsoft Azure:
Lakeside is also integrated with Azure Migrate within the virtual desktop infrastructure migration goals section to assess your current state. This vendor can help you map out an Azure Virtual Desktop deployment plan, including personas, host pools, applications, and user profiles specific to a Virtual Desktop environment.
User personas are the specifications for a particular group of users within a physical or virtual desktop environment with common characteristics or working methods. You may have multiple user personas in an Azure Virtual Desktop environment.
Once you have completed the required data capture, you will see the resources and workloads being used within your environment. You can then use this data to group user personas based on the following criteria:
The following table shows responses to populating a completed assessment or design document:
Each persona/grouping, or each group of users with distinct business functions and technical requirements, would require a specific host pool configuration.
The end user assessment helps you realize the required data: pool type, density, size, CPU/GPU, Landing Zone region, and so on.
Important Note
You can read more about Azure Landing Zones here: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/landing-zone/.
The host pool configuration assessment maps that data to a deployment plan. Aligning the technical requirements, business requirements, and cost will help determine the host pools' proper number and configuration.
Pricing examples are available for Microsoft Azure in the East US (https://azure.com/e/448606254c9a44f88798892bb8e0ef3c), West Europe (https://azure.com/e/61a376d5f5a641e8ac31d1884ade9e55), and Southeast Asia (https://azure.com/e/7cf555068922461587d0aa99a476f926) regions.
Both Movere and Lakeside assess the current on-premises environment and provide data about the applications that are run on end user desktops. Using the data you have collected, you should create a list of all the applications that are required for each persona. For each required application, the answers to the following questions will help shape deployment iterations:
Unless the persona uses 100 percent web-based software as a service application, you will most likely need to create and configure a custom master VHD image (https://docs.microsoft.com/en-us/azure/virtual-desktop/set-up-customize-master-image) for each persona. You will then need to work out which applications are typical applications and group/departmental applications. Common applications should be installed on the master image.
Tip
You can create custom images within the Azure portal or use Hyper-V, as suggested in the preceding paragraph.
If an application isn't compatible, a personal pool (https://docs.microsoft.com/en-us/azure/virtual-desktop/configure-host-pool-personal-desktop-assignment-type) may be required to run the custom VHD image.
If this is the case – and it is likely to be the case – you may want to consider migrating the backend systems that support the application to Azure.
These answers may require the plan to include remediation to the desktop images or support application components before desktop migration or deployment.
In this section, we looked at application groups and some of the tools available, as well as some questions to help you gather the requirements for your future Azure Virtual Desktop solution.
Now, let's look at the network capacity and speed requirements for Azure Virtual Desktop.
In this section, we will look at assessing the network requirements for Azure Virtual Desktop and some of the considerations you should factor into your design.
A remote desktop protocol (RDP) session relies on network bandwidth. Problems with bandwidth will impact your user experience within a Windows session. Depending on the applications and display resolutions, you may require different network configurations for specific groups within your organization. Incorrectly configuring your network to meet your remote desktop needs and requirements can lead to project failure and users not being able to carry out their required tasks within Azure Virtual Desktop.
Before we understand how applications affect bandwidth, let's look at what user-specific bandwidth recommendations are available:
The preceding table provides guidance on the minimum recommended bandwidths for an acceptable user experience. The listed recommendations are based on the guidelines in Microsoft's guide to Remote Desktop workloads (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-workloads).
Important Note
The recommendations in the table apply to networks with less than 0.1% loss. These recommendations apply regardless of how many user sessions you are hosting on your virtual machines.
Remember, application workload outputs, frame rate, or display resolutions will apply stress to your network. As framerates increase, your bandwidth requirement will change.
A good example is when you add Microsoft Teams video conferences without any audio/visual redirection to a typical light workload with a high-resolution display – your bandwidth requirement will increase. We will look at how to improve user experience and performance using Teams AV redirect in Chapter 13, Implementing and Managing Microsoft Teams AV Redirect.
Some of the other typical use cases that have changing bandwidth requirements are as follows:
Load testing the applicable use cases and scenarios in your deployment using tools such as Login VSI and PC Mark, which simulate load, is recommended. When load testing or benchmarking, it's important to vary the load sizes and run specific stress tests to simulate your future environment. It is also recommended that you test typical user scenarios in remote sessions to understand your network's requirements and capabilities.
Your required display resolution will determine the required bandwidth. The following table provides an example of the required bandwidths Microsoft recommends you have for a display resolution with a frame rate of 30 frames per second (FPS). Following these guidelines will help you provide a smooth user experience. The same recommendations apply to both single and multiple user scenarios. Remember, scenarios involving a frame rate under 30 FPS, such as reading static text, will require less available bandwidth than any graphically intensive applications:
We now move on to looking at the experience estimate for Azure Virtual Desktop.
Latency can be defined as the delay before data transfer begins after following an instruction for its transfer. Latency does not have to be geographic – it can also be based on your company's network topology. The distance you are from a Microsoft Azure data center can have an impact on the user experience. You can check the round trip time (RTT) of each Azure region using Windows Virtual Desktop Experience Estimator (https://azure.microsoft.com/services/virtual-desktop/assessment/):
Windows Virtual Desktop Experience Estimator is a great tool to help you pick the appropriate Azure regions in terms of the closest region to deploy your Azure Virtual Desktop environment in. You can also use this tool to understand the best location for a possible Azure Virtual Desktop disaster recovery solution.
Assistive Technologies
The phrase assistive technology is used to describe products or systems that support and assist individuals with disabilities, restricted mobility, or other impairments.
It is important to note that, when using assistive technology workloads, you will need to ensure that the round trip time is less than 20 milliseconds (ms) to achieve a good user experience.
Azure Virtual Desktop uses RDP as the connection method to provide remote display and input capabilities over network connections. RDP was initially released with Windows NT 4.0 Terminal Server Edition and has continuously evolved with every future Microsoft Windows and Windows Server release.
From the very beginning, RDP was developed to be independent of its underlying transport stack, and today, it supports multiple types of transport.
RDP is a complex technology that uses different techniques to deliver the server's remote graphics to the client device. Depending on the use case, scenario, availability of the compute resources, and network bandwidth, RDP dynamically adjusts various parameters to deliver the best remote user experience.
RDP multiplexes (multiple messages) multiply Dynamic Virtual Channels (DVCs) into a single data channel sent over different network transports. Did you know that there are separate DVCs for remote graphics, input, device redirection, printing, and others? The total amount of data that's sent over RDP depends on the user's activity – for example, a typical user working with basic textual content for most of the user's session. The bandwidth is low until the user generates a printout of a 100-page document to a printer. The print job will use more network bandwidth compared to the typical textual content that's used within the session.
A network's available bandwidth impacts the remote session's quality of experience. It is important to note that each application and display resolution can require different network configurations. It is essential to ensure that your network configuration meets your needs. It is recommended that you profile your network requirements based on user activity.
RDP uses various compression algorithms for different types of data. The following table details some estimates for the data transfers:
This table has been taken from Microsoft (https://docs.microsoft.com/azure/virtual-desktop/rdp-bandwidth#estimating-bandwidth-utilization).
As discussed in the previous section, Assessing the network capacity and speed requirements for Azure Virtual Desktop, you need to consider bandwidth changes when you're doing the following:
Now, let's look at estimating bandwidth for users who require remote graphics.
It is difficult to predict remote desktop bandwidth usage. The bandwidth usage depends on the user's activities and those activities that generate the most remote desktop traffic. Every individual user is different, and differences in their work patterns may change network usage.
One of the recommended ways to assess network bandwidth requirements is to monitor real user session connections. You can monitor connections using the built-in performance counters, network equipment, or third-party tooling.
In most cases, you would estimate network utilization by understanding how RDP works by analyzing your organization's user work patterns.
The remote protocol delivers the remote server's graphics to be displayed on a local client monitor. This process's technical definition is the remote protocol provides the desktop bitmap entirely composed on the server. Sending a desktop bitmap may seem like a simple task. However, it does require a significant amount of resources to achieve. For example, a 1,080p desktop image in an uncompressed format is circa 8 MB in size. Displaying this image on a locally connected monitor with a screen refresh rate of 30 Hz requires approximately 240 MB/s of bandwidth.
RDP uses a combination of different techniques to reduce the amount of data that's transferred over a network, including, but not limited to, those mentioned in this table:
To understand remote graphics, you should consider the following:
Please note that the stress you apply to your network depends on both the application workload's output, framerate, and display resolution. If the framerate or display resolution increases, the bandwidth requirement increases. One example is a light workload with a high-resolution display requiring more available bandwidth than a light workload with regular or low resolution. When using high display resolutions, expect to see the bandwidth requirements increase.
The following table provides examples of the data that's used by different graphic scenarios. These figures apply to a single monitor configuration with a 1,920 x 1,080 resolution and with both default graphics and H.264/AVC 444 graphics modes:
This table has been taken from Microsoft (https://docs.microsoft.com/en-us/azure/virtual-desktop/rdp-bandwidth#estimating-bandwidth-used-by-remote-graphics).
RDP is designed to dynamically adapt to the changing network conditions. Instead of using the hard limits on bandwidth utilization, RDP uses a capability called continuous network detection, which actively monitors the available network bandwidth and packet round-trip time.
Based on what's been detected, RDP dynamically selects the graphic encoding options and allocates bandwidth for device redirection and other virtual channels.
This technology allows RDP to use the entire network pipe, when available, and can quickly back off when the network is required for other services. RDP can detect this and adjust the image quality, frame rate, or compression algorithms if other applications request the network bandwidth.
There's no need to limit bandwidth utilization as limiting may affect the overall user experience in most scenarios. However, in constrained networks, you may want to restrict or limit network utilization to prevent service degradation. Another good example is leased networks (mobile hotspots or pay as you consume connectivity), which charge for the amount of traffic/bandwidth used.
In these cases, the advice is to limit RDP outbound network traffic by specifying a throttle rate in a Quality of Service (QoS) policy.
Important Note
Throttle rate limiting is not supported for reverse connect transport with Azure Virtual Desktop. Microsoft details how to enable this here: https://docs.microsoft.com/en-us/azure/virtual-desktop/shortpath.
Azure Virtual Desktop uses reverse connect transport to establish the remote session and carries RDP traffic from the session host to the broker. The client then connects to the broker. Unlike the traditional on-premises Remote Desktop Services deployments, reverse connect transport doesn't use a TCP listener to receive incoming RDP connections. Instead, it uses outbound connectivity to the Azure Virtual Desktop infrastructure over the HTTPS connection, hence the term reverse connect.
Upon starting the Azure Virtual Desktop session host, the installed Remote Desktop Agent service establishes a connection to the AVD broker's persistent communication channel. This communication uses a secure Transport Layer Security (TLS) connection. This serves as a bus for service message exchange between the session host and Azure Virtual Desktop infrastructure. Essentially, this allows Azure Virtual Desktop to know when a session host is available, offline, or has any issues.
The following client connection sequence is used for Azure Virtual Desktop:
You can read more here: https://docs.microsoft.com/en-us/azure/virtual-desktop/network-connectivity#client-connection-sequence.
Azure Virtual Desktop Infrastructure, session hosts, and clients all use TLS 1.2 to initiate connections.
Azure Virtual Desktop uses the same TLS 1.2 ciphers, just like Azure Front Door (https://docs.microsoft.com/en-us/azure/frontdoor/front-door-faq#what-are-the-current-cipher-suites-supported-by-azure-front-door).
Important Note
Make sure both the client computers and session host the required TLS 1.2 ciphers; otherwise, you will have connection issues.
For reverse connect transport, both the client and session host connect to the Azure Virtual Desktop gateway. After establishing the TCP connection, the client or session host validates the Azure Virtual Desktop gateway's certificate. Once the base transport has been established, RDP establishes a nested TLS connection between the client and session host using the session host's certificates. By default, the certificate that's used for RDP encryption is self-generated by the OS during the deployment. If desired, customers may deploy centrally managed certificates that have been issued by the enterprise certification authority.
You can also read more about the concept of the Fish tank here: https://ryanmangansitblog.com/2020/01/24/wvd-reverse-connect-the-fish-tank-analogy/.
For more information about configuring certificates, see Microsoft's Windows Server documentation: https://docs.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-desktop-listener-certificate-configurations.
This section covered how to assess and plan for the required network bandwidth. This could be in main offices and home workers. Ensuring you have the correct bandwidth is important to ensure your users have a good user experience when using Azure Virtual Desktop.
Now, let's look at the operating system images you can use for an Azure Virtual Desktop implementation.
In this section, we will cover the different operating systems available to you.
Azure Virtual Desktop supports the following operating system images:
Importantly, Azure Virtual Desktop does not support x86 (32-bit) operating systems or any of the following:
Depending on the OS and version you choose, different OSes and versions have different automation and deployment options, as shown in the following table:
This support table has been taken from Microsoft (https://docs.microsoft.com/azure/virtual-desktop/overview#supported-virtual-machine-os-images).
Windows 10 multi-session, also known as Windows 10 Enterprise Multi-Session and Microsoft Windows 10 Enterprise for Virtual Desktops (EVDs), is a new Remote Desktop Session host offering that allows multiple concurrent remote user sessions. Previously, you had no option but to use multi-session using Windows Server operating systems.
Important Note
Windows 11 multi-session support for Azure Virtual Desktop was announced on October 5, 2021. You can read more here: https://techcommunity.microsoft.com/t5/azure-virtual-desktop/windows-11-is-now-generally-available-on-azure-virtual-desktop/ba-p/2810545.
This new version gives users the same Windows 10 desktop experience rather than a server desktop UI. Organizations can also benefit from multi-session cost benefits and use existing per-user Windows licensing rather than the traditional RDS Client Access Licenses (CALs). For more information about licenses and pricing, see the Azure Virtual Desktop pricing page at https://azure.microsoft.com/pricing/details/virtual-desktop/.
Windows 10 multi-session is a virtual edition of Windows 10 Enterprise for use only on Microsoft Azure. The key difference when using Windows 10 multi-session compared to traditional Windows 10 is that this OS reports ProductType as having a value of 3. This is the same value that's used by the Windows Server OS. This property allows the OS to be compatible with existing host management tools, host multi-session-aware applications, and performance optimizations for session hosts.
It is important to note that some application installers can block the installation on Windows 10 multi-session through the installer. If your app doesn't install, contact your application vendor for an updated version or packaging company to repack it into a suitable format.
Windows 10 Enterprise Multi-Session is not to be used with on-premises production environments. This is because it has been optimized for Azure Virtual Desktop using Microsoft Azure.
Important Note
It's against the Microsoft licensing agreement to run Windows 10 Enterprise Multi-Session outside of Azure for production purposes. Furthermore, Windows 10 Enterprise Multi-Session will not activate against on-premises Key Management Services (KMSes).
It is currently impossible to upgrade an existing VM running Windows 10 Professional or Enterprise to Windows 10 Enterprise Multi-Session. When using Windows 10 Enterprise Multi-Session, you may decide to update the product key to another edition. You will not be able to switch back to Windows 10 Enterprise Multi-Session. You will need to redeploy the VM.
You would customize the image just like any image outside of Azure Virtual Desktop. You would deploy the VM in Azure with Windows 10 multi-session and customize it with the required line of business (LOB) applications, settings, and customizations, including optimizations. You can then proceed with Sysprep/generalize, ready to create an image template.
You can find the Windows 10 multi-session images in the Azure gallery. To find the available image templates, navigate to the Azure portal and search for Windows 10 Enterprise for Virtual Desktops. There are two options for integration with Microsoft 365 Apps for enterprise and a plain image, and Microsoft Windows 10 + Microsoft 365 Apps for enterprise and Microsoft Windows 10.
These Windows 10 releases follow the same support life cycle policy as the traditional Windows 10 Enterprise operating system. This means that the March release is supported for 18 months and that the September release is supported for 30 months.
Important Note
Windows 10 Enterprise Multi-Session versions 1809 and later are supported. You can find the supported versions in the Azure gallery. The end of support for Windows 10 can be found here: https://docs.microsoft.com/en-us/lifecycle/products/windows-10-enterprise-and-education.
You should consider using FSLogix profile containers when deploying Azure Virtual Desktop environments, especially on non-persistent deployments or other specific use cases requiring a centrally stored profile.
One of the key benefits of using FSLogix is that you can centralize your user profiles and provide a seamless experience for users accessing Azure Virtual Desktop resources.
Azure Virtual Desktop entitled users can use FSLogix at no additional cost. FSLogix comes pre-installed on all Windows 10 Enterprise multi-session images. However, you still need to configure the FSLogix profile container via the registry or group policy for a storage share location and any customizations required specifically for your environment.
We will cover FSLogix profile containers in more detail in Chapter 12, Implementing and Managing FSLogix.
Check out the Azure Virtual Desktop pricing page for a complete list of applicable licenses: https://azure.microsoft.com/pricing/details/virtual-desktop/.
Azure Virtual Desktop can be used in a cloud-only organization or a hybrid environment. Hybrid is an approach that's used within IT where some of your IT resources are in-house and others are cloud-based services. You need to ensure that the following is configured/set up before proceeding with an Azure Virtual Desktop project.
For hybrid environments that use Azure AD and Active Directory services, you'll need the following:
For cloud-only organizations, you'll need the following:
The Azure VMs you create for Azure Virtual Desktop must be as follows:
We will cover Active Directory and the various deployment configurations in more detail in Chapter 3, Designing for User Identities and Profiles, and Chapter 8, Azure AD Join for Azure Virtual Desktop.
A host pool is one or multiple virtual machines within Azure using the same image. These are registered as AVD session hosts that have a configured Azure Virtual Desktop agent. It is recommended that all session host virtual machines be deployed from the same template image for optimal user experience in a host pool.
There are two types of host pools:
There are several additional properties available for configuration for host pools. You can also configure the host pool's load balancing behavior, which includes how many sessions each session host can handle and what the user can do while connected to session hosts in the host pool. You control the resources that have been published to users through app groups, as mentioned previously.
Important:
Please see the link for Azure Virtual Desktop service limits to help when planning and designing your environment: https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-virtual-desktop-service-limits
The best way to describe an app group is that it's a logical grouping of applications configured for use with a session host pool. There are two app group types:
The host pool deployment automatically creates a desktop app group (named Desktop Application Group). App groups can be removed at any time. It is important to note that you cannot have multiple desktop app groups in a host pool.
When publishing a RemoteApp, first, you need to create a RemoteApp app group. Once created, you can create multiple RemoteApp app groups to cater to the possible different user scenarios required. You can have multiple RemoteApp app groups with overlapping RemoteApps.
When publishing remote resources to users, you should assign the users to specified app groups. When assigning users to app groups, you should consider the following things:
Important Note
A workspace is described as a logical grouping of application groups in Azure Virtual Desktop. Each AVD app group must be associated with a workspace to see the remote apps and desktops published to users.
Once you've assigned users to the required app groups, they can connect to an Azure Virtual Desktop deployment with any supported Azure Virtual Desktop clients.
Before you can provision Azure Virtual Desktop resources, you need to register the required subscription(s) with the Microsoft.DesktopVirtualization resource provider once. Follow these steps to complete this process:
Once the registration has been completed and shows as Registered, you can deploy Azure Virtual Desktop components within your subscription.
The following steps detail the process of registering the provider using PowerShell:
Get-AzResourceProvider -ProviderNamespace "Microsoft.DesktopVirtualization"
Register-AzResourceProvider -ProviderNamespace "Microsoft.DesktopVirtualization"
You'll see the following output:
Register-AzResourceProvider -ProviderNamespace "Microsoft.DesktopVirtualization"
You'll see the following output:
In this section, we showed you how to register the Microsoft.DesktopVirtualization provider using both the GUI within the Azure portal and using Powershell. In the next section, we will look at the resource groups, subscriptions, and management groups limits.
You can scale an Azure Virtual Desktop environment to over 10,000 sessions hosted per workspace.
It is advised that you consider the Azure Virtual Desktop control plane limitations during the initial design to limit any changes that may be required later:
Tip
You can reboot all your virtual machines via the operating system by using scripting or third-party products that do not consume any Azure Resource Manager subscription API calls.
Tip
You can increase the number of virtual machines per deployment by turning off availability sets in the ARM template or the Azure portal host pool enrolment.
Important Note
For more information about Azure subscription limitations, see Azure subscription and service limits, quotas, and constraints at https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits.
Azure Virtual Desktop is currently available for deployment in all Azure regions. IT admins can select the geographical location to store metadata in when creating their host pool virtual machines and associated services. You would want to store the metadata locally to your organizations for data soverancy purposes.
You can find out more about Azure geographies using the Azure data center map: https://azuredatacentermap.azurewebsites.net/. There is no region restriction or limit to where you can access user- and app-specific data.
Azure Virtual Desktop metadata is collected, and the information that's captured includes host pool names, app group names, workspace names, and user principal names in a data center.
When an admin creates a service object, they will be asked to select a location for the service object. The location that's selected essentially determines where the metadata for the object will be stored. As part of its design, you will need to decide where you would like to store your metadata.
For a list of all Azure-associated regions and geographies, see Azure geographies: https://azure.microsoft.com/global-infrastructure/geographies/.
Microsoft currently only supports storing metadata in the following locations:
Important Note
When you select a region to create Azure Virtual Desktop service objects in, you will see regions under both US and EU geographies. It is recommended that you understand which region would work best for your deployment. To find out more, take a look at Microsoft's Azure global infrastructure map: https://azure.microsoft.com/global-infrastructure/geographies/#geographies.
Metadata is encrypted and stored at rest, and georedundant mirrors are kept within the geography.
It is understood that Microsoft is working on more geographies that will become available as the service grows.
Important Note
Microsoft replicates service metadata within the Azure geography for disaster recovery purposes.
This section provides a high-level set of recommendations for sizing Azure Virtual Desktop. This will help you to plan and also calculate the costs of what the compute resource may look like. It is advised that you load test all the workloads, even when following guided recommendations.
The following examples should be used as guidance for initial performance estimates. As you build out your Azure Virtual Desktop environment, you will need to tweak and adjust these configurations to meet the requirements of your user base.
The following table shows the number of users per vCPU and the suggested VM hardware configuration for each workload. It also provides an example of session host sizing recommendations based on the number of users per vCPU and workload type. This example is suitable for 20 users or less:
This table was taken from the Microsoft document Remote Desktop workloads: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-workloads.
The following article shows some real-life examples of different performance results from testing different Azure Virtual machine sizes for use with Azure Virtual Desktop: https://ryanmangansitblog.com/2021/09/20/results-from-benchmark-tests-completed-on-avd-and-cloud-pc-virtual-machines/.
The following table provides an example of session host sizing recommendations based on the number of users per vCPU and workload type. The following table shows that this example would be suitable for more than 20 users:
This table was taken from the Microsoft document Remote Desktop workloads: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remote-desktop-workloads.
Microsoft recommends using VM sizes between 4 vCPUs and 24 vCPUs. It is not recommended to use less than two cores or more than 32 or more cores per session host.
Tip
Windows 10 require a minimum of two parallel threads for the heavier rendering operations. Having multiple users on a two-core or fewer VM could lead to a poor user experience. It's advised for stability that you use four or more cores when using a multi-user VM.
When increasing the number of virtual machine cores, it's important to note that the overhead of the VM will increase (system synchronization). For most workloads, it's advised that you stick to no more than 16 cores per session host. As the CPU number increases, the lower the return on investment. The additional capacity is negated by the synchronization overhead.
Microsoft, as per their best practices, states that you should stay in the range of 4 to 24 vCPU cores per session host.
Tip
It is suggested that a 1.75 ratio scenario offers improved burst capacity for applications that have short-term CPU demands.
When you have 20 or more user session connections on a single VM, it is advised that multiple smaller VMs would show better results than one or two larger VMs. It is also recommended that you have used smaller VMs instead of larger ones so that shutdown management is simpler. This is particularly useful for update management. From my testing and field experience, I have always found AMD Azure Virtual Machine skews to offer better performance and user experience compared to the Intel equivalent skews.
A common resource that is sometimes forgotten when sizing resources is the session host virtual disk and associated input/output operations per second (IOPS, pronounced eye-ops). Poor performing storage can result in a degraded user experience.
For persistent VMs (single user/single session), it is recommended that you use VMs with a minimum of two CPU cores per VM. However, for the best results, Microsoft recommends four vCPUs with hyperthreading enabled.
Microsoft recommends using premium storage (SSD) for Azure Virtual Desktop Session hosts as they offer high-performance and low-latency disk support for the session host virtual machine.
Tip
For a production workload requiring a service-level agreement (SLA), you will need to assign your VM's premium storage (SSD). For more details, see the SLA for virtual machines: https://azure.microsoft.com/support/legal/sla/virtual-machines/v1_8/.
You can enhance the user session experience even further using graphics processing units (GPU), which lets you use graphic-intensive programs such as 3D design, video rendering, and simulation software. You can read more about graphics acceleration by going to the Remote Desktop Services – GPU acceleration guide: https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-graphics-virtualization.
You can read more about the Microsoft Azure graphics acceleration deployment options that are available, as well as the GPU VM sizes offered, by going to the GPU optimized virtual machine sizes page: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-gpu.
Tip
B-series burstable VMs are helpful for users who don't always need maximum CPU performance. However, these are not so good if you use all the burstable resources. These are also useful for older applications that are delivered via RemoteApp. Just remember to benchmark usage before using it as burstable storage has a very limited use case.
You can find out more about VM types and sizes by going to the Sizes for Windows virtual machines in Azure document: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.
You can find the pricing information on Microsoft's Virtual Machine Series page: https://azure.microsoft.com/pricing/details/virtual-machines/series/.
Before rolling out any new desktop virtualization project to production, it is recommended that you run several tests, including simulation tests, to stress test for real-life usage. This will help provide a baseline and ensure that the environment you plan to release offers the resilience and responsive performance required to meet the current and future needs.
Load testing is a really good way to understand the limitations of the desktop environment, which helps with capacity planning as well as managing and maintaining a good user experience.
Tip
You can use tools such as LoginVSI, which can automate load tests for your Azure Virtual Desktop Environment, to help you understand performance, capacity management, and potential user experience issues. You can read more about LoginVSI here: https://www.loginvsi.com/.
In this chapter, we discussed assessing your current desktop estate to understand current baselines for performance, data, and user experience. We then looked at the considerations for Azure Virtual Desktop, including network bandwidth planning, sizing, and Windows 10 multi-session. Throughout this chapter, tips and recommendations were provided for you to get the most out of your Azure Virtual Desktop environment.
The next chapter will look at the design for user identities and profiles, where we will look at selecting an appropriate licensing model for Azure Virtual Desktop based on our requirements. Here, we will recommend an appropriate storage solution, plan for Azure Virtual Desktop client deployments and user profiles, and recommend a solution for network connectivity and planning for Azure AD Connect for user identities.
Here are a few questions to test your understanding of this chapter:
You can refer to the following links for more information regarding the topics that were covered in this chapter:
Planning and configuring name resolution for Active Directory and Azure Active Directory Domain Services
3.21.104.72