Plan for Azure Virtual Desktop Client Deployment
The Azure Virtual Desktop client helps end users to connect to the Azure Virtual Desktop instance assigned to them over the Internet/intranet. There are different Azure Virtual Desktop clients available based on the end-user device/operating system type. It is recommended to use a desktop client instead of a web client as a desktop client supports audio/video redirection on Azure Virtual Desktop.
The following are the clients available to access Azure Virtual Desktop:
•\ Windows Desktop clients
•\ Web clients
•\ Android clients
•\ macOS clients
•\ iOS clients
•\ Linux or thin clients
There are different ways to install a client on an end-user device.
•\ Domain-joined user device (automated deployment): SCCM can be used to push the Azure Virtual Desktop client on the end-user device, or the client can be published in the software center so that authorized users can deploy it on their devices/laptops. Alternatively, AD Group Policy can be used to deploy the Azure Virtual Desktop client on an end user’s laptop using a logon script, and Group Policy can be assigned to the security group created for each host pool.
•\ Nondomain-joined user device (automated deployment): An appropriate Azure Virtual Desktop client can be downloaded from a Microsoft site/other app store and installed on the user laptop/device manually.
Plan for User Profiles
A user profile is an important factor that needs to be considered during pooled Azure Virtual Desktop planning and designing. As we know by now, the pooled version is nonpersistent, and the Azure Virtual Desktop load balancer can send the session to any of the back-end session hosts on the pooled host pool. In this case, the user profile needs
to be available on all session hosts so that the user will get the same desktop/settings at every login, and that can be done using FSLogix. FSLogix allows you to store user profiles on the storage account so that FSLogix can attach the user profile to the VM where the user session is redirected by Azure Virtual Desktop.
FSLogix needs to be configured on all session hosts in the host pool, pointing to the same storage account where user profiles are stored. It is recommended to use a premium storage account for each host pool in each region. Storage account support failover so that the user profile data can be fail over to DR region in case of disaster recovery.
Figure 3-1 shows a typical pooled desktop user profile placement. The following are some recommendations:
•\ You need a separate virtual network with dedicated subnets for each host pool (pooled and personal) in each region, and you need to peer AVD vnet with hub virtual network in that region.
•\ You need a dedicated user profile storage for each pooled host pool.
•\ User profile storage access is restricted to a specific virtual network/subnet.
•\ Enable storage account access over a private endpoint from the virtual network.
•\ The same type of host pool in the same region (i.e. belongs to the same Business Unit) can use the same storage account for a user profile as far as there is no compliance/information security requirements.
•\ The storage account needs to join to the domain and allow specific users/groups to access the content.
•\ Consider GEO replication to a DR region if you are planning to enable disaster recovery for the pooled host pool. Premium file storage does not support GEO replication, so if you want to implement DR, then you must select the standard storage account tier or use an FSLogix cloud cache to store a user profile on multiple storage accounts in different regions.
Figure 3-1. Azure Virtual Desktop pooled user profile placement
Table 3-2 lists the workload types and recommended storage tier to achieve better performance of AVD.
