Category: Microsoft AZ-140

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.

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.

How Does AVD Secure the Connection? – Implement and Manage Networking for Azure Virtual Desktop

How Does AVD Secure the Connection?

Azure Virtual Desktop utilizes TLS 1.2 for all connections initiated from the clients and session hosts to the Azure Virtual Desktop infrastructure components. For reverse connect transport, both the client and session hosts 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. After establishing the base transport, RDP establishes a nested TLS connection between the client and session host using the session host’s certificates. By default, the certificate used for RDP encryption is self-generated by the OS during the deployment.

Implement and Manage Network Security

Before understanding how to manage network security in a Azure Virtual desktop, you as an Azure Virtual Desktop admin must remember that when an end user connects to an Azure Virtual Desktop environment, their session is run by a host pool. A host pool is nothing but a collection of Azure virtual machines that register to Azure Virtual Desktop as session hosts.

Since you will connect these virtual desktops remotely in your virtual network, they are subject to the virtual network security controls. They need outbound Internet access to the Azure Virtual Desktop service to operate properly and might also need outbound Internet access for end users. Azure Firewall is an essential part of the network security, and it can assist you in locking down your environment and filtering outbound traffic.

The “Filtering outbound traffic” option allows only required connections, and unwanted traffic you can drop at the firewall level. Figure 4-33 shows the Azure Virtual Desktop Security system.

Figure 4-33.  Azure Virtual Desktop Security system

Additionally, Figure 4-33 provides additional protection for your Azure Virtual Desktop host pool using Azure Firewall.

Host Pool Outbound Access to Azure Virtual Desktop – Implement and Manage Networking for Azure Virtual Desktop

Host Pool Outbound Access to Azure Virtual Desktop

The Azure virtual machines you build for Azure Virtual Desktop must have access to several fully qualified domain names (FQDNs) to function properly. Azure Firewall provides an Azure Virtual Desktop FQDN tag to simplify this configuration. Use the following steps to allow outbound Azure Virtual Desktop platform traffic:

\ 1.\ Deploy an Azure Firewall and configure your Azure Virtual Desktop host pool subnet user-defined route (UDR) to route all traffic via the Azure Firewall. Your default route now points to the firewall.

\ 2.\ Create an application rule collection and add a rule to enable the WindowsVirtualDesktop FQDN tag. The source IP address range is the host pool virtual network, the protocol is HTTPS, and the destination is WindowsVirtualDesktop.

\ 3.\ The set of required storage and service bus that accounts for your Azure Virtual Desktop host pool is deployment specific, so it isn’t yet captured in the WindowsVirtualDesktop FQDN tag. You can address this in one of the following ways:

\a.\ Allow HTTPS access from your host pool subnet to *xt.blob.core. windows.net, *eh. servicebus.windows.net, and *xt.table.core. windows.net. These wildcard FQDNs enable the required access but are less restrictive.

\b.\ You can use the following log analytics query to list the exact required FQDNs and then allow them explicitly in your firewall application rules:

\c.\ AzureDiagnostics | where Category == “AzureFirewallApplicationRule” | search “Deny” | search “gsm*eh.servicebus.windows.net” or “gsm*xt.blob.core. windows.net” or “gsm*xt.table.core.windows.net” | parse msg_s with Protocol “request from “SourceIP “:” SourcePort:int “to “FQDN “:” * | project TimeGenerated,Protocol,FQDN

\d.\ Create a network rule collection to add the following rules: for Allow DNS, allow traffic from your ADDS private IP address to * for TCP and UDP ports 53, and for Allow KMS, allow traffic from your Azure Virtual Desktop virtual machines to Windows Activation Service TCP port 1688.

Note  Certain implementations may not require DNS rules; for instance, Azure Active Directory domain controllers forward DNS queries to Azure DNS at 168.63.129.16.

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.

What Is a Workspace? – Design the Azure Virtual Desktop Architecture

What Is a Workspace?

A workspace is a logical grouping of application groups in Azure Virtual Desktop. Each Azure Virtual Desktop application group must be associated with a workspace for users to see the remote apps and desktops published to them.

Figure 2-8 shows the reference architecture for host pool placement.

Figure 2-8.  Azure Virtual Desktop host pool, session host, resource group placement

This diagram shows a typical Azure Virtual Desktop host pool placement recommendations are as follows:

•\   A dedicated subscription is recommended for Azure Virtual Desktop resources for easy management and scaling on-demand.

•\   A separate virtual network is recommended with multiple subnets for pooled and personal in each region and peering with a hub virtual network in that region.

•\   A virtual network scope range needs to be decided on, considering the number of VMs for pooled as well as personal and future growth.

•\   Multiple host pools of the same type can use the same subnet as far as there is no compliance/InfoSec requirement. Each subnet can be

restricted with a set of NSG rules.

•\   You need a separate host pool for each VM size, each region, and each type (pooled/personal).

•\   You need a dedicated resource group for each host pool to manage RBAC on the host pool–specific resources.

•\   RDP properties can be a set of host pool levels, so if we have a set of users that need different RDP properties, then we have to create different host pools. For example, some users need to copy the Azure Virtual Desktop option and some not.

•\   A separate pooled host pools for users who need a different set of applications.