How Does AVD Secure the Connection? – Microsoft AZ-140: Configuring and Operating Microsoft Azure Virtual Desktop

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.

Set Up Azure Monitor for Azure Virtual Desktop – Implement and Manage Networking for Azure Virtual Desktop

Set Up Azure Monitor for Azure Virtual Desktop

To set up or open the Azure Monitor for Azure Virtual Desktop, follow these steps:

\ a.\ First you need to log in to the Azure portal. After you are logged in to the Azure portal, search for and select Azure Monitor from the Azure portal.

\ b.\ Select Insights Hub under Insights, and then select Azure Virtual Desktop. See Figure 4-39.

Figure 4-39. Azure Monitor

\ c.\ Once you have the page open, enter the subscription, resource group, host pool, and time range of the environment you want to monitor.

\ d.\ As an additional step, you will need to set up the log analytics setting, because before you start using the Azure Monitor for Azure Virtual Desktop, you will need at least one Log Analytics workspace. Use a designated Log Analytics workspace for your Azure Virtual Desktop session hosts to ensure that performance counters and events are only collected from session hosts in your Azure Virtual Desktop deployment.

How Do I Set Up Resource Diagnostic Settings on a Virtual Desktop Workspace?

To gather information on your Azure Virtual Desktop infrastructure, you will need to enable several diagnostic settings on your Azure Virtual Desktop host pools and workspaces (this is your Azure Virtual Desktop workspace, not your Log Analytics workspace). To set your resource diagnostic settings, follow these steps:

\ 1.\ Select the Diagnostic settings host pool.

\ 2.\ Under Monitoring, select “Diagnostic settings.”

Log Analytics Workspace for Azure Monitor

It is important to have an analytics workspace, because you will need at least one Log Analytics workspace to start using Azure Monitor for Azure Virtual Desktop. Utilize a designated Log Analytics workspace for your Azure Virtual Desktop session hosts to ensure that performance counters and events are collected only from session hosts in your Azure Virtual Desktop deployment.

If you are new to Azure monitoring and it’s the first time you’re opening Azure Monitor for Azure Virtual Desktop, you will need set up the Azure Monitor for your Azure Virtual Desktop environment. To configure your resources, follow these steps:

\ 1.\ Log in and open Azure Monitor for Azure Virtual Desktop in the Azure portal at https://aka.ms/azmonwvdi, and then select configuration workbook.

\ 2.\ Select an environment to configure under Subscription, Resource Group, and Host Pool.

The configuration workbook sets up your monitoring environment and lets you check the configuration after you have finished the setup process. It’s important to check your configuration if items in the dashboard aren’t displaying correctly or when the product group publishes updates that require new settings. You need to enable the supported diagnostic tables such as Checkpoint, Error, Management, Connection, HostRegistration, and AgentHealthStatus.

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

Azure Virtual Desktop Multisession (Pooled) – Design the Azure Virtual Desktop Architecture

Azure Virtual Desktop Multisession (Pooled)

Sizing Recommendation

Table 2-6 are the reference usage profiles and VM sizes available for pooled/multisession AVD. The table shows an example of a smaller, proof-of-concept scenario with a user workload of fewer than 20 users.

Table 2-6. Azure Virtual Desktop Pooled Sizing Recommendation for POC

Table 2-7 shows an example of a smaller, proof-of-concept scenario with a user workload of more than 20 users.

Table 2-7. Azure Virtual Desktop Pooled Sizing Recommendation

It is always recommended to consider the application/software recommendations while deciding on the usage profile for pooled instances.

Multisession (Pooled) sizing example: Consider you have 100 users who want to use application “xyz” on a pooled host pool, and all users are from the same region. The application xyz recommendation is to have minimum one CPU and 2 GB memory. In this case, you can go with a D8s_v4 size VM, which comes with eight CPUs and 16 GB memory, and it will allow us to assign eight users per VM. D4s_v4 can be used, but it will increase the number of VMs, which results in additional cost for the OS disk. Table 2-8 is the reference size and per user cost calculation.

Table 2-8. Azure Virtual Desktop Pooled Sizing Example

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.

Select an Appropriate Licensing Model for Azure Virtual Desktop Based on the Requirements – Design for User Identities and Profiles

Select an Appropriate Licensing Model for Azure Virtual Desktop Based on the Requirements

Azure Virtual Desktop requires a per-user or per-device license to access the desktop, so you must plan the licensing model before you plan the Azure Virtual Desktop deployment. Azure Virtual Desktop (AVD) supports Windows 7/10 and Windows Server licenses as well, and you can select the appropriate licenses based on the operating system you want to use for AVD. The following are the supported licenses for Azure Virtual Desktop:

•\ BYOL Windows 10 and Windows 7: You are eligible to access Windows 10 and Windows 7 with Azure Virtual Desktop if you have one of the following per-user licenses:

•\ Microsoft 365 E3/E5

•\ Microsoft 365 A3/A5/Student Use Benefits

•\ Microsoft 365 F3

•\ Microsoft 365 Business Premium

•\ Windows 10 Enterprise E3/E5

•\ Windows 10 Education A3/A5

•\ Windows 10 VDA per user

•\ BYOL Windows Server: You are eligible to access Windows Server with Azure Virtual Desktop if you have a per-user or per-device RDS CAL license with active Software Assurance (SA).

•\ Per user access pricing for external users: You can also pay a monthly per-user fee to access Azure Virtual Desktop for external users.

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.

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.

How the AVD Client Connection Sequence Works – Implement and Manage Networking for Azure Virtual Desktop

How the AVD Client Connection Sequence Works

It is important to understand the client connection sequence, which will help you to troubleshoot the client connections. Based on the startup of the Azure Virtual Desktop session host, the Remote Desktop Agent Loader service determines the Azure Virtual Desktop broker’s persistent communication channel. This communication channel is layered on top of a secure TLS connection and serves as a bus for service message exchange between the session host and Azure Virtual Desktop infrastructure.

\ 1.\ As the first step, a user utilizing a supported Azure Virtual Desktop client subscribes to the Azure Virtual Desktop workspace.

\ 2.\ Then Azure Active Directory authenticates the user and returns the token used to enumerate resources available to the user.

\ 3.\ The client passes the token to the Azure Virtual Desktop feed subscription service.

\ 4.\ The Azure Virtual Desktop feed subscription service validates the token.

\ 5.\ The Azure Virtual Desktop feed subscription service passes the list of available desktops and RemoteApps back to the client in the form of a digitally signed connection configuration.

\ 6.\ The client stores the connection configuration for each available resource in a set of .rdp files.

\ 7.\ When a user chooses the resource to connect to, the client uses the associated .rdp file, establishes a secure TLS 1.2 connection to the closest Azure Virtual Desktop gateway instance, and passes the connection information.

\ 8.\ The Azure Virtual Desktop gateway validates the request and asks the Azure Virtual Desktop broker to orchestrate the connection.

\ 9.\ The Azure Virtual Desktop broker identifies the session host and uses the previously established persistent communication channel to initialize the connection.

\ 10.\ The Remote Desktop stack initiates the TLS 1.2 connection to the same Azure Virtual Desktop gateway instance as used by the client.

\ 11.\ After both the client and session hosts connect to the gateway, the gateway starts relaying the raw data between both endpoints; this establishes the base reverse connect transport for the RDP.

\ 12.\ After the base transport is set, the client starts the RDP handshake, and the user can access the Azure Virtual Desktop.

Important Consideration: Host Pool Outbound Access to the Internet – Implement and Manage Networking for Azure Virtual Desktop

Important Consideration: Host Pool Outbound Access to the Internet

Based on your organization’s requirements, you may need to enable secure outbound Internet access for your end users. In instances where the list of allowed destinations is well-defined (for instance, Microsoft 365 access), you can use Azure Firewall applications and network rules to configure the required access. This routes end-user traffic directly to the Internet for the best performance.

If you want to filter outbound user Internet traffic using an existing on-premises secure web gateway, you can configure web browsers or other applications running on the Azure Virtual Desktop host pool with an explicit proxy configuration. These proxy settings only influence your end-user Internet access, permitting the Azure Virtual Desktop platform outbound traffic directly via Azure Firewall.

Manage Azure Virtual Desktop Session Hosts by Using Azure Bastion

In this section you’ll learn about Azure Bastion.

Configure AVD Session Hosts Using Azure Bastion

Azure Bastion offers secure connectivity to all VMs in a virtual network in which it is provisioned. Utilizing Azure Bastion protects your virtual machines from exposing RDP/ SSH ports to the outside world, while still offering secure access utilizing RDP/SSH.

It is important to verify the criteria that you need to meet. Here is the list:

•\ You need a VNet with the Bastion host already installed. Make sure that you have set up an Azure Bastion host for the virtual network in which the VM is located. Once the Bastion service is provisioned and deployed in your virtual network, you can make use of it to connect to any VM in the virtual network.

•\ You need a Windows virtual machine in the virtual network.

•\ The required roles are as follows: Reader role on the virtual machine, Reader role on the NIC with the private IP address of the virtual machine, and Reader role on the Azure Bastion resource.

•\ To connect to the Windows VM, you must have the inbound port RDP (3389) open on your Windows VM.

Category: How Does AVD Secure the Connection?