Microsoft AZ-140: Azure Virtual Desktop Architecture and Service Design — Study Guide

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

Part of the Microsoft Azure Virtual Desktop Specialty AZ-140 — Study Guide. Practice with verified answers in the Microsoft exam hub, or take timed practice tests on ExamRoll.io.

Overview

Azure Virtual Desktop (AVD) is a Microsoft-managed desktop and app virtualization service that separates the service control plane from your tenant-specific data plane. The service brokers secure connections, while you own and operate the session host virtual machines, identity, storage, and networks. Designing an effective architecture means mapping user experience, identity, application delivery, capacity, resilience, and cost controls into a cohesive deployment model that can be validated and rolled out in stages without user disruption.

Service Architecture: Control Plane vs Data Plane

• Control plane (Microsoft-managed):

  • Web Access, Gateway, and Broker services authenticate users, enumerate resources, and orchestrate reverse-connect sessions over TLS 443. They’re globally distributed and updated by Microsoft.
  • Diagnostics and Insights services collect connection telemetry, health, and agent status.
  • ARM-based management APIs define host pools, application groups, and workspaces, including scaling plans and “Start VM on Connect.”

• Data plane (customer-managed):

  • Session hosts (Windows 10/11 Enterprise multi-session or single-session) in your subscriptions and VNets.
  • Identity and name resolution via AD DS, Azure AD DS, or Entra ID with appropriate join mode. Session hosts must resolve domain services; configure VNet DNS to domain controllers or Azure AD DS IPs rather than public DNS.
  • User state and cache (FSLogix profile and Office containers) on Azure Files Premium or Azure NetApp Files (ANF), or less commonly on IaaS file servers or Storage Spaces Direct (S2D).
  • Networking (VNets, peering, VPN/ExpressRoute, NSGs, UDRs, egress), with QoS and path steering to minimize latency and jitter on UDP/TCP 443.
  • Image management with Azure Compute Gallery and Azure Image Builder, and operational controls such as autoscaling and maintenance windows.

Control-plane traffic is outbound from session hosts; no inbound public endpoints are required on host VMs. This reduces exposure and simplifies firewall rules.

Core Constructs and Application Delivery

• Host pool: A logical set of session hosts with a defined resource location (metadata region), load-balancing policy, and assignment mode (pooled or personal). A host pool contains one Desktop application group by default and can have multiple RemoteApp groups.

• Application group (app group):

  • Desktop: Presents a full Windows desktop from the pool. Only one desktop app group is allowed per host pool.
  • RemoteApp: Publishes individual apps. You can create multiple RemoteApp groups per pool.
  • A user must not be assigned both the Desktop and a RemoteApp group from the same host pool. Use separate pools to avoid app/desktop experience conflicts.
  • An app group is associated with exactly one workspace. The workspace and app group must share the same AVD resource location.

• Workspace: The user-facing container that aggregates app groups across pools into resource feeds for AVD clients. RBAC on app groups controls who sees which apps/desktops. Keep metadata locations aligned when registering app groups to workspaces.

• Image strategy: For pooled multi-session, use Windows 10/11 Enterprise multi-session marketplace images or a generalized custom image in an Azure Compute Gallery. For personal pools, use Windows 10/11 Enterprise single-session images. Always generalize source VMs before capturing images to remove user- and machine-specific state.

Host Pool Types, Assignment, Updates, and Power Management

• Pooled vs personal host pools:

  • Pooled: Multiple concurrent users per VM. Optimize for density and cost with Breadth-first or Depth-first load balancing. Use FSLogix for profiles.
  • Personal: One user per VM with dedicated state. Assignment methods:
    • Automatic: The first connection permanently binds a user to an unassigned VM.
    • Direct: Admin maps users to specific session hosts.

• Validation vs production pools:

  • Validation pool flag opts the pool into pre-release AVD agent rings. Use a small validation pool per image/region to test AVD agent, OS, and app updates with pilot users.
  • Staged rollout model:
    1. Validate image and agent in a dev/test pool.
    2. Pilot in a validation pool with a subset of users.
    3. Gradually expand to production pools region by region.
    4. Drain and patch hosts incrementally to avoid downtime.

• Autoscale and Start VM on Connect:

  • Autoscale (scaling plans) schedules capacity, enforces session thresholds, drains idle hosts, and deallocates VMs to minimize cost while preserving user experience.
  • Start VM on Connect powers on deallocated VMs when a user attempts to connect. Operational requirements:
    • Enable a system-assigned managed identity on the host pool and grant the Desktop Virtualization Power On Off Contributor role on the session host resource group or VMs.
    • VMs must be deallocated to save compute cost; “stopped” but allocated still accrues charges and offers no cold-start benefit.
    • Works with pooled and personal pools; cold-start adds minutes of connection delay.
    • Only client-initiated connections through AVD apply; direct RDP is not supported.
    • Coordinate with autoscale to ensure minimum hosts are pre-warmed for peak periods.

Load Balancing, Capacity Planning, Registration, and Health

• Load balancing algorithms:

  • Breadth-first: Distributes sessions evenly across available hosts. Best for consistent performance and memory headroom.
  • Depth-first: Fills one host to its Max session limit before using the next. Maximizes deallocations for cost savings but risks noisy-neighbor effects if limits are too high.

• Max session limit and user density:

  • Set Max session limit per VM to cap concurrent sessions and protect UX, especially with Depth-first.
  • Estimate density by benchmarking target workloads: CPU often limits multi-session density. As a rule of thumb:
    • Light productivity: 6–10 sessions/vCPU on modern multi-session SKUs when properly tuned.
    • Medium productivity: 4–6 sessions/vCPU.
    • Graphics or data-heavy: 1–3 sessions/vCPU.
  • Capacity planning:
    • Required hosts = ceil((Users × concurrency) ÷ sessions-per-host).
    • Add N+1 reserve or a percentage headroom for failover and patch windows.
    • Network: Estimate 300–500 Kbps per light session, 1–2 Mbps medium, 3–5+ Mbps heavy. Only office-based users hairpin through corporate internet; remote users connect directly to AVD.
    • QoS: Prioritize UDP/TCP 443 to AVD gateways; insufficient allocation causes slow responses and connection errors.

• FSLogix storage selection:

  • Azure NetApp Files delivers the highest IOPS and lowest latency at enterprise scale (for tens of thousands of users) with minimal management overhead.
  • Azure Files Premium offers SSD-backed SMB shares with AD-based auth or Entra Kerberos, balancing performance and cost for most deployments.
  • IaaS alternatives (S2D SOFS) require at least three VMs without Cloud Witness and impose operational overhead; use only when PaaS options are not viable.

• Registration tokens, session host registration, and agent health:

  • Before adding existing VMs to a host pool, generate a registration token. The AVD agent and boot loader register the VM using this token; afterward, the host is bound to the pool and the token can expire.
  • Keep agent health green by monitoring service status, SxS stack version, and heartbeat via AVD Insights and Log Analytics. Drain mode hosts during patching to prevent new sessions.
  • Short troubleshooting tip: Within a user session, use Performance Monitor’s RemoteFX Graphics counters (Frames Skipped/Second) to isolate server vs network vs client rendering issues.

Example PowerShell for registration and health:

# Generate a time-limited registration token
New-AzWvdRegistrationInfo `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' `
  -ExpirationTime (Get-Date).AddHours(8)

# Review host state, drain mode, and session counts
Get-AzWvdSessionHost `
  -ResourceGroupName 'rg-avd' `
  -HostPoolName 'hp-pooled' |
  Select-Object Name, Status, AllowNewSession, Sessions

• DNS and domain join considerations:

  • When using Azure AD DS, set the VNet’s DNS servers to the managed domain IPs so session hosts can locate domain controllers for Windows enrollment and Kerberos/NTLM.
  • For AD DS via hybrid, configure each VNet hosting session hosts to use on-premises DC IPs (at least two for resilience). Ensure conditional forwarders or resolvers support Azure private endpoints if used.

• Regional design and the Experience Estimator:

  • Choose host pool regions based on the lowest round-trip latency from user locations measured with the Azure Virtual Desktop Experience Estimator. Run tests from real user subnets at peak and off-peak times.
  • Co-locate FSLogix storage and domain services with session hosts to minimize SMB roundtrips. Avoid cross-region profile mounts.
  • For multi-region deployments, align metadata locations across host pool, app groups, and workspaces; use separate pools per region for autonomy and staged failover.

Practical Problem Scenario

Siemens AG must deliver CAD and productivity workloads to engineers in Munich, Chicago, and Singapore while minimizing cost and ensuring high performance.

1. Map user cohorts, workloads, and regions

• Identify three cohorts: CAD-heavy (GPU needed), standard productivity, and contractors with app-only needs. Measure latency from each site with the AVD Experience Estimator.
• Why: Cohort-based pools prevent noisy-neighbor effects and allow right-sized VM families and scaling behavior per workload. Latency measurements inform regional placement.

2. Design regional host pools and app delivery

• Create three regional host pools per cohort in West Europe, East US, and Southeast Asia. Use:
  • GPU NVadsA10 v5 for CAD (pooled, Breadth-first, lower Max session limit).
  • D/E-series for productivity (pooled, Depth-first to maximize deallocations off-peak).
  • RemoteApp-only pools for contractors publishing specific apps.
• Register RemoteApp and Desktop app groups to regional workspaces matching each pool’s resource location.
• Why: Segregating pools by workload and region optimizes performance and cost while maintaining clean app entitlements.

3. Implement identity and DNS

• For EU and US, domain-join to on-prem AD DS synced to Entra ID. Configure each VNet’s custom DNS to two regional DCs for resilience. In Singapore, deploy Azure AD DS and set the VNet DNS to the managed domain IPs to avoid WAN dependency.
• Why: Local domain controllers and correct VNet DNS ensure reliable Kerberos resolution and fast logons; Azure AD DS reduces operational overhead where on-prem AD is not present.

4. Optimize user state and storage

• Use Azure NetApp Files for CAD and high-concurrency productivity cohorts; use Azure Files Premium for contractors. Place storage in the same region as the host pools and enable FSLogix profile containers with Cloud Cache for CAD users who roam between two nearby offices.
• Why: ANF delivers the lowest latency and highest IOPS for heavy workloads; Azure Files Premium lowers cost for lighter users. Co-location prevents cross-region SMB latency.

5. Capacity, autoscale, and Start VM on Connect

• Establish density targets from pilot testing (e.g., CAD 1–2 sessions/vCPU, productivity 4–6 sessions/vCPU). Configure autoscale plans with workday ramp-up and off-hours drain and deallocation. Enable Start VM on Connect with a system-assigned identity on each host pool and grant Desktop Virtualization Power On Off Contributor on the session host resource groups.
• Why: Autoscale and Start VM on Connect minimize compute spend while preserving user experience; identity and role assignment permit the service to power VMs reliably.

6. Staged rollout and validation

• Flag a small validation host pool per region to receive agent updates early. Patch cadence: validate → pilot → production. Use drain mode during patching and enforce Max session limits suitable for each workload and algorithm.
• Why: Controlled rings avoid service-wide regressions; drain mode maintains sessions during host maintenance.

7. Network and QoS tuning

• Ensure branch routers prioritize UDP/TCP 443 to AVD endpoints with sufficient bandwidth allocations. Remove any VPN hairpin for remote users so home users connect directly to AVD.
• Why: AVD media flows rely on 443; under-provisioned QoS causes slow responses and connection drops.

By aligning pool types, app groups, identity, storage, scaling, and regional placement to Siemens’ cohorts and geographies, the design achieves predictable performance, operational safety through validation rings, and cost efficiency through intelligent power management and density controls.

All domains · Identity →

Practice these questions → · Timed practice on ExamRoll.io →

Browse Microsoft →