Microsoft AZ-140: Session Host Operations, Scaling and Optimization — 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

Session host operations in Azure Virtual Desktop (AVD) center on three core disciplines: right-sizing and performance engineering, intelligent scale and power management, and reliable day-2 operations. The goal is to deliver consistent user experience during peak demand while minimizing spend during off-hours, all without compromising maintainability or recoverability. This section explains how to design and operate AVD autoscale with scaling plans, schedule and capacity configuration, operational states such as drain mode, and health and registration troubleshooting. It then ties sizing guidance (including GPU-enabled workloads) and automation together with cost optimization levers such as reservations, savings plans, and Azure Hybrid Benefit.

Autoscale Design: Scaling Plans, Schedules, and Host-Pool Targeting

• Scaling plans and targeting

  • A scaling plan defines when and how a pooled host pool starts, drains, stops, and deallocates session hosts. One scaling plan can target multiple host pools, even across regions.
  • Each targeted host pool executes the scaling plan independently in its own time zone context. Use the scaling plan’s time-zone setting per schedule to align with local business hours.
  • Exclusion tag: define a tag key/value pair so autoscale ignores specific VMs (e.g., operational canaries or maintenance pilots).
  • Load balancing mode matters: breadth-first spreads sessions across hosts (improves instantaneous performance, slows scale-in); depth-first stacks sessions on fewer hosts (maximizes consolidation and cost savings). For cost-focused autoscale, use depth-first with appropriate capacity thresholds.

• Schedules: ramp-up, peak, ramp-down, off-peak

  • Ramp-up: starts and warms the minimum fleet ahead of demand, then scales out when capacity thresholds are crossed.
  • Peak: keeps more capacity online to minimize latency and queuing; scale-out continues if thresholds are exceeded.
  • Ramp-down: places selected hosts into drain mode, consolidates sessions, and after a grace period powers down idle hosts.
  • Off-peak: maintains a small baseline for after-hours access; remaining idle hosts are deallocated to minimize spend.

• Capacity thresholds, minimum host availability, and autoscale behavior

  • Capacity threshold (%) is measured against total session capacity of online hosts. When average utilization exceeds the threshold, autoscale starts additional VMs. Utilization is driven by max sessions per host and current session counts. Tune per workload; start with 60–70% for depth-first, 70–80% for breadth-first.
  • Minimum host availability can be defined as a number or percentage of hosts to keep running in each schedule phase. Always maintain at least one “spare” to absorb sudden bursts.
  • Scale-in safety: autoscale uses drain mode and “no-active-session” checks to avoid dropping users. Only idle hosts are stopped/deallocated.

• Power management and cost-aware deallocation

  • Stop (deallocate) releases compute charges; OS and data disks continue to incur storage charges. Autoscale deallocates idle hosts during ramp-down and off-peak.
  • Start VM on connect can complement off-peak posture by booting deallocated VMs when a user attempts to connect. Ensure the host pool’s managed identity or service principal has VM Start permissions on the session host resource group.
  • Avoid in-guest shutdown without deallocation; it leaves the VM allocated and billable.

Operational State, Maintenance, and Health: Drain Mode, Notifications, and Registration

• Drain mode and maintenance windows

  • Drain mode (AllowNewSession=false) prevents new logons while allowing existing sessions to complete. Use it to patch, update agents, replace images, or for scale-in.
  • Maintenance approach: set host(s) to drain mode, wait for idle, gracefully logoff lingering sessions after notification, then apply updates and reboot. Validate health/heartbeat and re-enable new sessions.

• User-notification strategy

  • Scaling plan notifications: configure logoff message and grace period during ramp-down. Use clear, time-bound language.
  • Supplemental notifications: use Azure Automation (Send-AzVMRunCommand, toast notifications via PowerShell) or Endpoint Manager to display in-session messages ahead of maintenance.

• Session-host status, heartbeat, and agent health

  • Typical statuses: Available, Unavailable (NoHeartbeat), NeedsAssistance, Unhealthy, Shutdown, NotJoinedToDomain, Upgrading.
  • Heartbeat/agent prerequisites: outbound 443 to AVD service endpoints (use AzureVirtualDesktop service tag), stable DNS resolution, time synchronization, and successful domain join if applicable.
  • Agent services: Remote Desktop Agent Loader and Remote Desktop Agent must be running. The AVD agent and side-by-side stack auto-update if outbound access is permitted.

• Registration and troubleshooting

  • To join existing VMs to a host pool, create a registration token (valid for a limited time) and install/register the AVD agent with that token.
  • Common fault isolation steps:
    • Check host shows as Registered and Available in the host pool; if not, re-register with a fresh token.
    • Inspect Event Viewer: Microsoft-RDInfra-RDAgent, Microsoft-RDInfra-RDAgentBootLoader, and RDS/TerminalServices logs for connectivity or authentication errors.
    • Validate DNS: domain resolution and service endpoint resolution must succeed; if using Azure AD DS, ensure VNet DNS points to the managed domain controllers.
    • Confirm Windows Firewall or network security rules permit outbound 443 and that no TLS interception breaks service trust.

• Helpful automation examples

# Put a session host in drain mode (no new sessions)
Update-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-finance `
  -Name host1.contoso.com -AllowNewSession:$false

# Gracefully logoff idle users after notice (example)
Invoke-AzVMRunCommand -ResourceGroupName rg-avd -Name host1 `
  -CommandId RunPowerShellScript -ScriptPath .\Notify-And-Logoff.ps1

Sizing, Utilization, and GPU-Enabled Workloads

• VM size selection and workload-driven sizing

  • Start from workload characterization: office/productivity, knowledge worker with Microsoft 365 Apps and Teams optimization, developer/engineering, or graphics/3D.
  • CPU: keep sustained CPU under 70–75% with short spikes under 85%. Monitor Processor(_Total)% Processor Time and System\Processor Queue Length.
  • Memory: target <80% committed with Memory\Available MBytes above 500 MB per host; watch for paging. FSLogix cache may increase working set—size accordingly.
  • Storage: user experience depends on FSLogix profile IOPS and latency. Premium SSD v2, Ultra Disk for temp/cache-intensive scenarios, and Azure Files Premium or Azure NetApp Files for high IOPS profiles. For very large estates or the lowest-latency profiles, Azure NetApp Files provides the best consistency.
  • Initial baselines (multi-session):
    • Light productivity: 4–8 vCPU, 16–32 GB RAM; breadth-first for responsiveness.
    • Medium knowledge worker: 8–16 vCPU, 32–64 GB RAM; depth-first for cost-efficiency.
    • Heavy dev/compilation/data: 16–32 vCPU, 64–128 GB RAM; consider dedicated pools.

• GPU-enabled session hosts

  • For CAD/GIS/3D/video editing and complex visualizations, use NVads A10 v5 for granular vGPU profiles and strong price/perf; consider NV v4/v5 families where appropriate.
  • Deploy the NVIDIA GPU Driver Extension for Windows on N-series VMs. Validate hardware encoding: enable AVC/H.264 and configure “Use hardware encoding for Remote Desktop” via policy when beneficial.
  • Monitor GPU with Performance Counters (GPU engine utilization, GPU memory) and Azure Monitor metrics. Ensure sufficient CPU headroom; graphics-heavy apps are still sensitive to CPU starvation.

• Telemetry and iterative tuning

  • Enable Azure Monitor for AVD insights and Log Analytics. Track CPU, memory, FSLogix profile latency, logon duration, disconnects, and brokering times.
  • Adjust host pool MaxSessionLimit and load balancing mode based on observed contention, then retune autoscale thresholds to match.

Cost Optimization: Power, Autoscale, Reservations, Savings Plans, and AHB

• Align scaling with business hours

  • Use depth-first plus conservative capacity thresholds to consolidate sessions and accelerate scale-in. Combine with off-peak deallocation and Start VM on connect for late/rare access.
  • Set a small but non-zero minimum host count to avoid cold-start storms.

• Reservations and savings plans

  • Reservations: 1-year or 3-year VM reservations lock specific SKUs in specific regions for the largest discounts; ideal for baseline capacity that runs most of the time (e.g., daytime peak fleet).
  • Compute Savings Plans: offer flexible discounts across VM families and regions; useful when mixing sizes or for dynamic estates where exact SKU predictability is lower.
  • Storage reservations: Azure Files reserved capacity can reduce FSLogix storage costs at scale.

• Azure Hybrid Benefit (AHB) and licensing

  • Apply AHB to Windows Server and eligible Windows client workloads to reduce compute OS licensing charges. Ensure license eligibility and compliance.
  • For Microsoft 365 deployments, confirm licensing covers Windows Enterprise multi-session and Microsoft 365 Apps where applicable.

• Operational scripts and runbooks

  • Use Azure Automation or GitHub Actions for:
    • Fleet drain/enable sequences before and after maintenance.
    • Pre-scale warm-up scripts on Mondays or after public holidays.
    • Health remediation (restart agent services, re-register host if heartbeat lost).
  • Tag-driven orchestration makes selective operations simple (e.g., tag Environment=Pilot to exclude from scale-in).

# Start or stop idle hosts by tag (supplemental to native autoscale)
$hosts = Get-AzWvdSessionHost -ResourceGroupName rg-avd -HostPoolName hp-ops
foreach ($h in $hosts) {
  if ($h.Session -eq 0 -and $h.Tags["KeepOnline"] -ne "true") {
    Stop-AzVM -ResourceGroupName rg-avd -Name ($h.Name.Split("/")[1]) -Force -StayProvisioned:$false
  }
}

Practical Problem Scenario

IKEA faces weekday spikes from 3D planners, product engineers, and call-center staff using remote apps. Evenings and weekends are low demand. GPU-backed sessions must remain responsive while minimizing overall compute cost.

1. Segment host pools by workload

   • Create three pooled host pools: GPU-CAD (NVads A10 v5), KnowledgeWorker (D/E-series), and ContactCenter (D-series).
   • Why: Aligns VM size and density with distinct performance profiles; enables independent autoscale and maintenance windows.

2. Attach a single scaling plan with schedules per business hours

   • Define ramp-up at 07:00, peak 09:00–17:00, ramp-down 17:00–19:00, off-peak otherwise; set time zone to the region of each pool.
   • Why: Guarantees capacity is ready before users arrive, consolidates and powers down gracefully after hours, and honors regional times.

3. Tune capacity thresholds and minimum host availability per pool

   • GPU-CAD: breadth-first, capacity threshold 70%, minimum hosts 30% online; KnowledgeWorker: depth-first, threshold 65%, minimum 10%; ContactCenter: depth-first, threshold 70%, minimum 15%.
   • Why: GPU workloads prefer broader spread for responsiveness; office workloads gain from consolidation to cut cost; call center requires steady reserve for shift changes.

4. Enable Start VM on connect for KnowledgeWorker and ContactCenter

   • Grant host pool managed identity VM Start permissions; keep off-peak minimum low.
   • Why: Reduces idle runtime charges while preserving just-in-time access for unexpected after-hours logons.

5. Implement maintenance and notification workflow

   • Before Patch Tuesday: place 20% of each pool in drain mode via tag; notify users 30 minutes prior; after idle, patch, reboot, validate agent/heartbeat, then rotate to next batch.
   • Why: Rolling drain avoids mass logoffs, preserves service continuity, and reduces helpdesk spikes.

6. Monitor and iterate with Azure Monitor for AVD

   • Track CPU, memory, GPU utilization, logon duration, FSLogix latency; adjust MaxSessionLimit and autoscale thresholds monthly.
   • Why: Data-driven tuning maintains SLA and controls spend as usage patterns evolve.

7. Apply cost levers

   • Reserve 3-year capacity for baseline weekday peak in KnowledgeWorker and ContactCenter; use a Compute Savings Plan for variable GPU demand; apply Azure Hybrid Benefit where eligible.
   • Why: Reservations lock in biggest savings for predictable base load; savings plans flex with less predictable GPU peaks; AHB lowers OS licensing costs.

8. Harden registration and health

   • Maintain a standing runbook to re-register any host that shows NoHeartbeat, and validate DNS/time. Keep exclusion tags for diagnostic hosts.
   • Why: Swift, automated remediation limits user impact and preserves capacity during unexpected agent issues.

With this design, IKEA meets daytime performance objectives—including GPU responsiveness—while aggressively deallocating off-hours capacity and automating maintenance, resulting in a stable user experience and measurable cost reduction.

← FSLogix · All domains · Applications and End-User Experience →

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

Browse Microsoft →