What Is a Workspace? – 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.

How Do I Resolve Azure Advisor Recommendations? – Implement and Manage Networking for Azure Virtual Desktop

How Do I Resolve Azure Advisor Recommendations?

This section describes how you can resolve recommendations that appear in Azure Advisor for Azure Virtual Desktop. Resolving recommendations involve “No validation environment enabled,” “Not enough production (non-validation) environments enabled,” and “Not enough links are unblocked to successfully implement your VM.” Here are the details for resolving each mentioned recommendation:

No Validation Environment Enabled

This recommendation is under Operational Excellence. The recommendation should also show you a warning message like this: You don’t have a validation environment enabled in this subscription. When you made your host pools, you selected No for “Validation environment” in the Properties tab. To ensure business continuity through Azure Virtual Desktop service deployments, make sure you have at least one host pool with a validation environment where you can test for potential issues.

You as an admin can make this warning message disappear by allowing a validation environment in one of your host pools. To enable the validation environment, follow these steps:

\ 1.\ Log in to your Azure portal home page and choose the host pool you want to change.

\ 2.\ Choose the host pool you want to change from a production environment to a validation environment.

\ 3.\ In your host pool, select Properties on the left column. Next, scroll down until you see “Validation environment.” Select Yes, and then select Apply.

Note These changes won’t make the warning disappear immediately. Allow enough time for the recommendations to disappear on their own.

As a best practice, you can check the Azure Advisor updates twice a day.

Not Enough Production (Non-validation) Environments Enabled

Not enough production environment is another recommendation that appears under Operational Excellence. For this recommendation, the warning message appears because you have too many host pools in your validation environment or you don’t have any production host pools. Microsoft recommends users have fewer than half of their host pools in a validation environment. To resolve this warning, follow these steps:

\ 1.\ Log in to the Azure portal home page.

\ 2.\ Choose the host pools you want to change from validation to production.

\ 3.\ In your host pool, select the Properties tab in the column on the right side of the screen. Next, scroll down until you see “Validation environment.” Select No, and then select Apply. See Figure 4-41.

Figure 4-41. Nonproduction environment recommendation

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

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.

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.

How Do I Monitor Communication Between a Virtual Desktop and an Endpoint? – Implement and Manage Networking for Azure Virtual Desktop

How Do I Monitor Communication Between a Virtual Desktop and an Endpoint?

You as an admin must know how to monitor the communication between an endpoint and the virtual desktops. Endpoints can be another virtual machine (VM), a fully qualified domain name (FQDN), a uniform resource identifier (URI), or an IPv4 address.

Another tool is the Connection Monitor 2.0, which monitors communication at a regular interval and informs you of reachability, latency, and network topology changes between the VM and the endpoint.

If an endpoint becomes unreachable, connection troubleshooting informs you of the reason. Potential reasons are a DNS name resolution problem; the CPU, memory, or firewall within the operating system of a VM; the hop type of a custom route; or a security rule for the VM or subnet of the outbound connection.

Additionally, the Connection Monitor provides the minimum, average, and maximum latency observed over time. After learning the latency for a connection, you may find that you’re able to decrease the latency by moving your Azure resources to different Azure regions.

How Do I View Resources in a Virtual Network and Their Relationships?

As resources are added to a virtual network, it can become difficult to understand what resources are in a virtual network and how they relate to each other. The topology capability enables you to generate a visual diagram of the resources in a virtual network and the relationships between the resources. Figure 4-38 shows an example topology diagram for a virtual network that has three subnets, two VMs, network interfaces, public IP addresses, network security groups, route tables, and the relationships between the resources.

Figure 4-38. An Azure virtual network, topology diagram

How Do I Diagnose Network Traffic Filtering Problems to or from a VM?

After you implement a VM, Azure applies various default security rules to the VM that allow or deny traffic to or from the VM. You as an admin might override Azure’s default rules or create additional rules. If you see a VM that may become unable to communicate with other resources, because of a security rule, the IP flow verify capability enables you to specify a source and destination IPv4 address, port, protocol (TCP or UDP), and traffic direction (inbound or outbound). IP flow verifies the tests the communication and informs you if the connection succeeds or fails.

Important If the connection fails, IP flow checks and tells you which security rule allowed or denied the communication so that you can resolve the problem.

Differences Between Azure AD DS and Self-Managed AD DS – Design for User Identities and Profiles

Differences Between Azure AD DS and Self-Managed AD DS

There are two ways to provide AD DS traditional authentication mechanisms (Kerberos or NTLM) in the cloud for cloud-based applications and services:

•\ Managed domain (Azure AD DS): Microsoft manages the required resources for Azure AD DS, and you can still use all the traditional AD DS features such as domain joins, Group Policy, LDAP, and Kerberos/ NTLM authentication. You don’t deploy, manage, patch, and secure the Azure AD DS infrastructure for components such as Windows Server OS or domain controller (DC) VMs. See Figure 3-3.

Figure 3-3. Azure Active Directory Domain Services (AAD DS) for Azure Virtual Desktop

•\ A self-managed domain (AD DS service on VM): You can create and configure traditional AD DS on Azure virtual machines (VMs) with Windows Server guest OS, and you can use Active Directory Domain Services (AD DS) to extend your on-premises AD DS to the cloud or use on-premises AD DS as is for cloud as well. There’s additional maintenance overhead with a self-managed AD DS environment, but you have ability to do additional tasks such as extend the schema or create forest trusts. See Figure 3-4.

Figure 3-4. On-premises AD DS for Azure Virtual Desktop

Common deployment models for a self-managed AD DS in cloud include the following:

•\ Stand–alone cloud-only AD DS: This option is mostly used when you don’t have on-premises AD DS and just want to create new self-managed AD DS for the Azure cloud. Azure VMs can be configured as domain controllers to create a cloud-only AD DS environment.

•\ Resource forest deployment: This option is mostly used when you have an on-premises AD DS forest and just want to create a new AD DS domain in an existing on-premises forest for the Azure cloud. Azure VMs can be configured as domain controllers and AD DS domains as part of the existing on-premises forest. A trust relationship is then configured to an on-premises AD DS environment so that other Azure VMs can domain-join to this resource forest in the cloud. User authentication runs over a VPN/ExpressRoute connection to the on-premises AD DS environment.

•\ Extend on-premises domain to Azure: This option is mostly used when you have an on-premises AD DS domain and forest and just want to add a cloud-based domain controller in an existing on-premises domain. An Azure virtual network needs to be connected to an on-premises network using a VPN/ExpressRoute connection for this model as well. Azure VMs connect to this Azure virtual network, which lets them domain-join to the on-premises AD DS environment.

Table 3-3 outlines the differences between a managed Azure AD DS domain and a self-managed AD DS domain.

Table 3-3. Differences Between a Managed Azure AD DS Domain and a Self-Managed AD DS Domain

Implement Azure Virtual Network Connectivity – Implement and Manage Networking for Azure Virtual Desktop

Implement Azure Virtual Network Connectivity

As you know, Azure Virtual Desktop is a desktop and application virtualization service that runs in the Azure cloud. Azure Virtual Desktop works across devices (Windows, Mac, iOS, Android, and Linux) with apps that you can use to access remote desktops and apps.

First you need to understand how this works before digging in more. Azure offers a cloud service that accesses a container for all the virtual machines in your deployment. All the virtual machines in this cloud service are talking to each other and are on the same network.

What Is Azure Virtual Network?

Azure Virtual Network (VNet) is the foundation for a private network in Azure. VNet allows various kinds of Azure resources, including virtual machines, to firmly communicate with each other, the Internet, and on-premises networks. VNet facilitates Azure resources to securely communicate with each other, the Internet, and on-premises networks.

By linking Azure Virtual Desktop host pools to an Active Directory domain, you can specify the network topology to gain access to virtual desktops and virtual apps from the intranet or Internet, based on company policy. You can connect an Azure Virtual Desktop instance to an on-premises network utilizing a virtual private network (VPN) or, with the help of Azure ExpressRoute, expand the on-premises network into the Azure cloud over a private connection.

There are a number of scenarios that you can achieve by using a virtual network, such as communicating with Azure resources with the Internet, communicating between Azure resources, communicating with on-premises resources, filtering network traffic, routing network traffic, and integrating with Azure services. Let’s discuss each scenario in detail starting with communicating with the Internet. The communication between Azure resources is accomplished through a network such as a virtual network, virtual network service endpoint, or virtual network peering. Figure 4-1 shows the access to Azure PaaS and IaaS and on-premises connectivity.

Figure 4-1. Azure VNet

Communicate withtheInternet

All resources in a virtual network can communicate outbound to the Internet by default. You can communicate inbound to a resource by assigning a public IP address or a public load balancer. You can also use a public IP or public load balancer to manage your outbound connections.

When using only an internal standard load balancer, outbound connectivity is not available until you define how you want outbound connections to work with an instance-level public IP or a public load balancer.

Connect to Azure Resources

Azure resources communicate securely with each other in one of the following ways:

•\ Through a virtual network: You can deploy VMs and several other types of Azure resources to a virtual network, such as Azure app service environments, Azure Kubernetes Service (AKS), and Azure Virtual Machine Scale Sets.

•\ Through a virtual network service endpoint: Extend your virtual network private address space and the identity of your virtual network to Azure service resources, such as Azure Storage accounts and Azure SQL Database, over a direct connection. Service endpoints allow you to secure your critical Azure service resources to only a virtual network.

•\ Through VNet peering: You can connect virtual networks to each other, enabling resources in either virtual network to communicate with each other, using virtual network peering. The virtual networks you connect can be in the same or different Azure regions.

Category: What Is a Workspace?