Category: General Virtual Machine Recommendations

Plan a Host Pool Architecture and Recommendations for Resource Groups, Subscriptions, and Management Groups – Design the Azure Virtual Desktop Architecture

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.

A host pool can be one of two types.

•\   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?

An app group is a logical grouping of applications installed on session hosts in the host pool. An app group can be one of two types.

•\    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.

To publish resources to users, you must assign them to app groups. When assigning users to app groups, consider the following:

•\   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.

Calculate a Configuration for Azure Virtual Machine Capacity Requirements – Design the Azure Virtual Desktop Architecture

Calculate a Configuration for Azure Virtual Machine Capacity Requirements

The Azure Virtual Desktop session host size is the main factor that can impact Azure Virtual Desktop performance, so the session host size needs to be calculated based on the existing VDI usage (refer to the assessment) or based on the user application requirement. The following are some of the examples and recommendations for pooled as well as personal desktops:

•\    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.

Table 2-3.  Azure Virtual Desktop Pooled Sizing Example

•\    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.

Table 2-4.  Azure Virtual Desktop Personal Sizing Example

Not Enough Links Are Unblocked to Successfully Implement Your VM – Implement and Manage Networking for Azure Virtual Desktop

Not Enough Links Are Unblocked to Successfully Implement Your VM

Another recommendation occurs under Operational Excellence. You need to unblock specific URLs to make sure that your virtual machine (VM) functions properly. You can find the list on the Safe URL list. If the URLs aren’t unblocked, then your VM won’t work properly. To resolve the recommendation, make sure you unblock all the URLs on the Safe URL list and use the Service Tag or FQDN tags to unblock URLs.

Azure Virtual Desktop Common Issues and Their Troubleshooting

Problem: Unable to open remote virtual desktop client or its stops responding for Windows 10.

Solution: You as an admin can reset the user data from the About page or use the msrdcw.exe /reset [/f] command. Use this command to remove your user data, restore default settings, and unsubscribe from all workspaces.

Problem: Unable to open web client.

Solution: There are multiple reasons for being unable to open the web client.

\ a.\ As a first step, test your Internet connection by opening another
website in your browser or using different browser.
\ b.\ Additionally, you can use nslookup to confirm DNS can resolve
the FQDN or use a command prompt to run the command
nslookup rdweb.AVD.microsoft.com.

\ c.\ You can try connecting with another client, for instance, Remote
Desktop client for Windows 10 to see if you can open the web client.

Problem: The Virtual Desktop web client keeps prompting for credentials.

Solution: If the web client keeps prompting for credentials, do the following:

\ 1.\ Check and confirm the web client URL is correct. If there is any typo, then correct the URL and try accessing the correct URL.

\ 2.\ If the issue persists, then check and confirm that the credentials you are entering are for the Azure Virtual Desktop environment tied to the URL.

\ 3.\ If issue persists, then clear the browser cookies and browser cache.

\  4.\  You can open your browser in private mode.

Troubleshoot application issues related to AVD using User Input Delay.

The User Input Delay counter can assist in discovering the root cause for bad end-user RDP experiences. Do the following if you see issues:

•\   First check the counter measures how long any user input remains in the queue before it is picked up by a process.

•\   The User Input Delay counter measures the max delta between the input being queued and when it’s picked up by the app in a message loop. Figure 4-42 shows input relay.

Figure 4-42.  AVD using input relay

Troubleshoot Graphic Performance and Quality Issues – Implement and Manage Networking for Azure Virtual Desktop

Troubleshoot Graphic Performance and Quality Issues

You as an admin must know how to detect and troubleshoot experience quality issues with your remote desktop sessions. Counters are offered under the “RemoteFX Graphics” section of Performance Monitor. Below question assists you in identifying and resolving graphics-related performance bottlenecks during Remote Desktop Protocol (RDP) sessions using these counters.

•\    How Do I Find the Remote Session Name?

It is important to find the remote session name to find the graphics performance counters. Follow these steps to identify your instance of each counter:

\ 1.\ First open the Windows command prompt from your remote session and then run the qwinsta command and find your session name.

If your session is hosted in a multisession virtual machine (VM), your instance of each counter is suffixed by the same number that suffixes your session name, such as rdp-tcp 37.

If your session is hosted in a VM that supports virtual graphics processing units (vGPUs), your instance of each counter is stored on the server instead of in your VM. Your counter instances include the VM name instead of the number in the session name, such as “Win8 Enterprise VM.”

•\    How Do I Access Performance Counters?

Once you have decided your remote session name, then perform these steps to collect the RemoteFX Graphics performance counters for your remote session:

\  1.\  First click Start ➤ Administrative Tools ➤ Performance Monitor.

\ 2.\ In the Performance Monitor dialog box, expand Monitoring Tools, select Performance Monitor, and then select Add.

\  3.\  In the Add Counters dialog box, from the Available Counters

list, expand the section RemoteFX Graphics. Then choose the counters to be monitored.

\ 4.\ In the “Instances of selected object” list, select the specific instances to be monitored for the selected counters and then select Add. To select all the available counter instances, select All instances, and then after adding the counters, select OK.

Finally, the chosen performance counters will appear on the Performance Monitor screen.

•\    How Do I Diagnose the Graphics-Related Performance Issues?

Remember, the graphics-related performance problem normally fall into four types:low frame rate, random stalls, high input latency, and poor frame quality.

To address low frame rate, random stalls, and high input latency, first check the Output Frames/Second counter. This measures the number of frames made available to the client. If this value is less than the Input Frames/Second counter, frames are being skipped. To identify the bottleneck, use the Frames Skipped/Second counters. There are three types of Frames Skipped/Second counters.

•\   Frames Skipped/Second (Insufficient Server Resources)

•\   Frames Skipped/Second (Insufficient Network Resources)

•\   Frames Skipped/Second (Insufficient Client Resources)

A high value for any of the Frames Skipped/Second counters implies that the problem is related to the resource the counter tracks. If the Output Frames/Second counter matches the Input Frames/Second counter, you will still notice unusual lag or stalling, and Average Encoding Time may be the culprit. Encoding is a synchronous process that occurs on the server in the single-session (vGPU) scenario and on the VM in the multisession scenario. Average Encoding Time should be less than 33 ms.

Since RDP supports an Average Encoding Time value of 33 ms, it supports an input frame rate up to 30 frames/second. Note that 33 ms is the maximum supported frame rate. In many cases, the frame rate experienced by the user will be lower, depending on how often a frame is provided to RDP by the source.

•\    How to Check the Poor Frame Quality?

Make use of the Frame Quality counter to diagnose frame quality issues. This counter expresses the quality of the output frame as a percentage of the quality of the source frame. The quality loss may be due to RemoteFX, or it may be inherent to the graphics source. If RemoteFX caused the quality loss, the issue may be a lack of network or server resources to send higher-fidelity content.

General Virtual Machine Recommendations – Design the Azure Virtual Desktop Architecture

General Virtual Machine Recommendations

Here are the 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

See Table 2-5.

Table 2-5.  Azure Virtual Desktop Workload Types

Recommended Storage Solution (Including Azure NetApp Files vs. Azure Files) – Design for User Identities and Profiles

Recommended Storage Solution (Including Azure NetApp Files vs. Azure Files)

Azure Virtual Desktop performance is dependent on the storage type you are using, so it is important to select the appropriate storage for the operating system disk as well as the user profile data. Here are two different storages required for Azure Virtual Desktop:

•\    Operating system storage: For optimal performance, it is recommended that you use premium SSD storage for the Azure Virtual Desktop session host’s operating system disk for production workloads. The operating system disk size depends on the operating system and applications installed on the C: drive.

•\    User data storage

•\    Storage for personal desktop: A personal desktop is a persistent desktop, meaning the user will get the same desktop every time they log in to Azure Virtual Desktop. The user can store data on the local VM. Additional standard or premium storage can be attached to the personal Azure Virtual Desktop instance to store user data or install applications.

•\    Storage for pooled desktop user profile (pooled): Since pooled desktops are not persistent desktops, the user will not get the same VM every time they log in to Azure Virtual Desktop.

Therefore, the user profile must be stored on remote storage using FSLogix. Pooled Azure Virtual Desktop supports FSLogix, which helps to store user profiles on Azure Files as well as Azure NetApp Files. Both Azure Files and NetApp Files support ADDS authentication as well as secure access over a virtual network, and it is recommended that you restrict the profile storage to a specific virtual network with a private endpoint. You can use a storage domain join so authorized users can access storage and user profiles.

Table 3-1 compares the major differences between Azure Files and NetApp Files to help you make a decision.

Table 3-1.  Differences Between Azure Files and NetApp Files

Table 3-1.  (continued)

Table 3-1.  (continued)

Table 3-1.  (continued)

Plan for Azure Virtual Desktop Client Deployment – Design for User Identities and Profiles

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.

Recommended Solution for Network Connectivity – Design for User Identities and Profiles

Recommended Solution for Network Connectivity

Azure networking products and services support a wide variety of networking capabilities, so it is important to correctly identify the network requirements for your Azure Virtual Desktop deployment. How you structure these services and the networking architectures you choose depend on your organization’s workload, governance, and connectivity requirements.

The decision tree (common assessment framework) in Figure 3-2 can help you determine the networking tools or services to use for Azure Virtual Desktop.

The following questions can help you make decisions based on the Azure networking services:

•\   How many IP addresses do you need in your virtual network (based on the size of Azure Virtual Desktop virtual network)?

The number of IP addresses needed in the virtual network will mainly depend on the number of session hosts you want to deploy in the virtual network plus a buffer IP address for future growth. Use appropriate address ranges as defined in your existing networking architecture to be able to scale out your Azure virtual network infrastructure.

•\   Will your workloads require connectivity between virtual networks and your on-premises datacenter?

You need on-premises connectivity in case you want to extend your Active Directory on-premises domain in Azure or allow an application that runs on your Azure Virtual Desktop deployment to reach on-premises resources.

•\   Will you need to inspect and audit outgoing traffic by using on-premises network devices?

Your security policies might require Internet-bound outgoing traffic to pass through centrally managed devices in the cloud or on-premises environment. This can be achieved by using forced tunneling to direct all traffic to a specific firewall/device.

•\   Do you need multiple virtual networks?

The number of virtual networks you will need depends on the number of regions you want to deploy Azure Virtual Desktop session hosts in. If you are planning to deploy Azure Virtual Desktops in multiple regions, then you need a virtual network in that region with all the connectivity and security.

•\   Do you need to connect multiple virtual networks?

You can use virtual network peering to connect services in another Azure virtual network. For example, you have all the shared services such as extended ADDS and DNS present in a hub virtual network, and you want Azure Virtual Desktop to use the shared services for name resolution and authentication.

•\   Will you need custom DNS and a domain join?

Yes, Azure Virtual Desktop supports domain join for session hosts so that you can apply an organization-specific compliance policy to the session host. AVD virtual network DNS settings can be changed to custom DNS and can point it to organization-specific DNS server so that it can help to resolve Active Directory domain names and join the session host to the domain.

Plannig Azure AD Connect for User Identities – Design for User Identities and Profiles

Plannig Azure AD Connect for User Identities

Azure Virtual Desktop supports desktop authentication with Active Directory Domain Services. The AD DS directory can be synchronized with Azure AD to enable it to authenticate on-premises users.

There are two levels of authentications for Azure Virtual Desktop, one at the Azure Virtual Desktop access level and another at desktop login. The Azure Virtual Desktop session host can join to the AD domain, and domain credentials can be used to log in to the desktop, whereas Azure Virtual Desktop authentication can be done by Azure AD, but AD DS needs to be synced with Azure AD if you want to use same credentials for both logins.

Note  Azure AD domain services (AAD DS) and Active Directory Domain Services (AD DS) are two different services.

There are two different AD DS options available and supported by Azure Virtual Desktop. You can select the appropriate AD DS solution based on your organization requirements.

Identity Design Considerations

The following are some identity design considerations:

•\   Azure Virtual Desktop users must be sourced from either the same instance of on-premises Active Directory Domain Services that is synchronized to Azure Active Directory (Azure AD) and the session host needs to be joined to same Active Directory Domain Services (AD DS), or an instance of Azure AD Domain Services (Azure AD DS) synchronized from Azure AD.

Note  Azure Virtual Desktop does not support business-to-business or Microsoft accounts.

•\ A domain join account can’t have multifactor authentication or
interactive prompts, and it needs permission on the ADDS OU to add
a computer account.
•\ Azure Virtual Desktop supports AD DS or Azure AD DS, and an
appropriate identity provider needs to be selected based on the
application requirement.
•\ When joining to an Azure AD DS domain, the account must be part
of the Azure AD DC administrators’ group, and the account password
must work in Azure AD DS.
•\ Azure AD DS (AAD DS) is a supported option, but there are
limitations:
•\ You must have password hash synchronization enabled
(uncommon when federating Azure AD).
•\ You can project Azure AD DS into only a single virtual network
(and single Azure region) that uses a nonpublic IP address range.
You can’t add domain controllers to an Azure AD DS domain.
•\ You cannot use a hybrid join for Azure Virtual Desktop VMs
to enable Azure Active Directory seamless single sign-on for
Microsoft 365 services.

•\ Always specify an organizational unit distinguished name (DN) fordomain joining without quotation marks.

•\ The user principal name used to subscribe to Azure Virtual Desktop must exist in the Active Directory domain where the session host virtual machine is joined.

•\ Smart cards and Windows Hello authentication need a direct connection (line of sight) with an Active Directory domain controller for Kerberos.

•\ Using Windows Hello for Business requires the hybrid certificate trust model to be compatible with Azure Virtual Desktop.

•\ Single sign-on can improve user experience, but it requires additional configuration and is supported only using Active Directory Federation Services.

Configure a Location for the Azure Virtual Desktop Metadata – Design the Azure Virtual Desktop Architecture

Configure a Location for the Azure Virtual Desktop Metadata

Azure Virtual Desktop can be used as a worldwide service depending on your location and the location of the VMs. The control plane is available in the following locations (as of September 2021); however, the host pool can exist in any other Azure region:

•\   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 following are the recommendations for optimal performance:

•\ 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.