Microsoft AZ-140: Resilience, Recovery and Migration — 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) resilience, recovery, and migration planning focuses on maintaining user productivity through regional failures, protecting data (profiles, images, applications), orchestrating dependency failover, and delivering a predictable transition from legacy Remote Desktop Services (RDS). Effective designs separate the stateless AVD control plane from stateful data planes, use repeatable automation for rebuilds, define clear recovery objectives for each component, and validate real-world performance with discovery and capacity modeling.

Regional Architecture, User Access, and Failover

• Control and data planes: AVD’s broker, web access, diagnostics, and management services are globally resilient. Session hosts, host pools, images, and storage are region-specific and must be designed for failover.
• Regional failure strategy:
  • Create a secondary-region host pool per user cohort with the same VM size family and image lineage. Replicate images to the secondary region using Azure Compute Gallery.
  • Publish identical application groups (RemoteApp and/or Desktop) in both regions and assign users to both, setting the primary pool as the default and the secondary as the DR target.
  • Keep DR hosts in a cold or warm standby posture. For pooled hosts, scale-in to zero or power off, then rely on scaling plans and Start VM on Connect to minimize steady-state cost.
• User access during failures:
  • The AVD service routes connection requests to healthy session hosts. When you place the primary host pool in drain mode or it is unavailable, new connections are brokered to the secondary pool if users have assignments there.
  • Educate users that open sessions in the failed region will disconnect; reconnection attaches to the available region.
• Image and MSIX app attach parity:
  • Use Azure Image Builder and Azure Compute Gallery (SIG) with regional replication for images.
  • Store MSIX app attach packages in resilient storage locations that are reachable in both regions and replicate content to the secondary region (e.g., ANF cross-region replication or storage account replication).
• Network and identity dependencies:
  • Ensure DNS and identity (Active Directory or Azure AD DS) are reachable from both regions. For Azure AD DS, configure VNet DNS settings to the managed domain IPs in each regioned VNet that requires domain join and name resolution.
  • Validate RDP Shortpath behavior across regions; fallback to reverse connect if UDP is impeded.

Example to replicate an image version to two regions:

az sig image-version create \
  --resource-group rg-avd-images \
  --gallery-name sig-avd \
  --gallery-image-definition win11-ms \
  --gallery-image-version 1.0.3 \
  --target-regions eastus=1 westus=1

Recovery Objectives and Data Protection Roles

Define distinct RTO/RPO per component:

• Host pools and session hosts:
  • Pooled: Treat session hosts as ephemeral. RTO is minutes (automated redeploy), RPO is N/A (no host state). Do not rely on VM backups for recovery; redeploy from image and autoscale.
  • Personal: If user state resides on the OS disk, protect with Azure Backup or Azure Site Recovery (ASR). Prefer offloading user state to FSLogix profiles to simplify DR.
• Images:
  • RPO near-zero for image availability using Compute Gallery replication; RTO minutes to deploy new hosts. Keep golden image pipelines versioned and reproducible.
• Profiles and Office caches (FSLogix):
  • RPO: minutes to hours depending on replication and backup schedules; RTO: minutes to mount in secondary region if Cloud Cache configured, otherwise time to restore volume/share and re-point sessions.
• Applications:
  • For in-image applications, align with image RTO/RPO. For MSIX app attach, align with package storage replication and re-registration time.

Azure Backup and ASR:

• Azure Backup:
  • Back up Azure Files shares that host FSLogix profile and ODFC containers. Use frequent snapshots to meet RPO targets; restore individual VHD/VHDX or a full share. Communicate that snapshots are crash-consistent while users are logged on; for precision restores, perform out-of-band copy/rename of a user’s container and instruct user to re-logon.
  • Back up personal desktops’ OS disks when needed. Pooled hosts generally do not require VM backups.
• Azure Site Recovery:
  • Use ASR for stateful infra components that are critical to AVD (e.g., management servers, license servers if applicable, LOB servers) and for personal host pools when preserving VM state is required.
  • Avoid ASR for pooled AVD hosts; redeploy from image/scaling plans is faster and cheaper.

Profile Storage Resilience, Cloud Cache, Backup, and Restore

• Storage options for FSLogix:
  • Azure NetApp Files (ANF): Highest IOPS/lowest latency at scale; supports cross-region replication for DR. Ideal for very large estates or high concurrency and profile IO demands.
  • Azure Files Premium: SSD-backed PaaS file shares with ZRS for intra-region resilience; excellent balance of performance and administration. For cross-region DR, combine with Cloud Cache and share-level backup/restore or design dual-region shares.
  • Storage Spaces Direct (S2D) on IaaS: Use only when PaaS is not viable. Requires a minimum of three VMs without Cloud Witness for quorum. Operational overhead is higher than PaaS alternatives.
• Cloud Cache:
  • Configure multiple providers (e.g., two Azure Files or ANF endpoints in different zones/regions). During a regional outage, FSLogix continues against surviving providers with eventual consistency for cached writes.
  • Sample configuration:

# PowerShell on session host
New-Item -Path HKLM:\SOFTWARE\FSLogix\Profiles -Force | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name Enabled -Type DWord -Value 1 | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name CCDLocations -Type String `
  -Value "type=smb,connectionString=\\files-pri.file.core.windows.net\profiles;type=smb,connectionString=\\files-dr.file.core.windows.net\profiles" | Out-Null
New-ItemProperty HKLM:\SOFTWARE\FSLogix\Profiles -Name DeleteLocalProfileWhenVHDShouldApply -Type DWord -Value 1 | Out-Null

• Backup and restore patterns:
  • Implement hourly or every-few-hours Azure Backup snapshots for profile shares. For a corrupt user profile, isolate the current VHDX, restore the previous snapshot to an alternate location, and copy or reattach the user’s container.
  • For ANF, use snapshots and cross-region replication; restore volume-level or single file via snapshot directory.
• Testing:
  • Include mount/attach validation, corruption simulations, and user-level rollback in DR drills.

Traffic, DNS, and Dependency Failover

• Application dependencies:
  • Many AVD apps depend on HTTP/S APIs, web front ends, or databases. Architect these with global load balancing and regional deployments so that failover of dependencies does not strand users in otherwise-healthy sessions.
• Azure Front Door and Traffic Manager:
  • Use Azure Front Door for global HTTP/S layer-7 load balancing, WAF, and path-based routing of app dependencies used by AVD users. Pair with zone-redundant backends in each region.
  • Use Azure Traffic Manager for DNS-based load balancing for non-HTTP endpoints that are public-facing and support health probes.
• Private DNS and name resolution:
  • Centralize conditional forwarders using Azure DNS Private Resolver to route queries between on-premises, Azure VNets, and managed domains. Publish low-TTL records for endpoints that may need rapid failover.
  • For storage endpoints that cannot natively fail over seamlessly, consider dual-named endpoints abstracted behind internal DNS to switch between primary and DR shares during an incident.
• Network QoS and access:
  • Prioritize real-time AVD traffic (UDP/TCP) across WANs; adjust QoS on branch routers to ensure AVD traffic classes have sufficient bandwidth to reduce connection errors and latency.
  • Validate Shortpath reachability and firewall pinholes; ensure egress bandwidth planning matches concurrency and workload mix.

Migration from RDS, Discovery, Density, and Capacity

• RDS assessment:
  • Inventory Connection Brokers, RD Gateways, RD Web, RD Session Hosts, RD Licensing, and file servers/profile stores. Document GPOs, FSLogix configuration, and application delivery methods.
  • Map roles to AVD constructs: host pools, workspaces, app groups, profile storage, and AVD-managed brokering; remove the need for RD Gateway and Broker in Azure.
• Azure Migrate and discovery:
  • Use Azure Migrate appliance to discover existing RDS VMs, performance baselines, and dependencies. Identify app-to-server relationships for AVD session host placement and data gravity.
• User-density analysis:
  • Build density models per workload (task/knowledge/power users). Derive sessions-per-VM using CPU ready, memory pressure, and profile IO baselines. Validate with pilot benchmarks on candidate VM SKUs (e.g., Dv5/Esv5/Dasv5, GPU-enabled for graphics).
  • Use the Azure Virtual Desktop Experience Estimator to select regions with the lowest user-to-host latency.
• Capacity modeling:
  • Convert density into host counts per pool with N+1 buffer and maintenance overhead. Define scale-out thresholds and minimum/maximum hosts in scaling plans. Consider capacity reservations for predictable cost and guaranteed cores in busy regions.
  • Ensure subscription and regional quotas (vCPU, cores per family, IPs, NICs, disks) are raised in advance; submit quota increase requests early.

Cutover, Coexistence, Quotas, and Runbooks

• Cutover planning:
  • Run parallel coexistence: keep RDS operational while AVD onboards pilots. Publish the same apps in both systems, but steer users by cohort.
  • Pilot cohorts: start with IT and early adopters, expand to representative departments, then broad rollout. Use feedback to tune images, FSLogix settings, and scaling.
  • Rollback: maintain RDS access paths until acceptance criteria are met. Keep user profiles backward-compatible or provide a profile reset path per cohort.
• Operational readiness:
  • Registration keys: when onboarding existing VMs to host pools, generate a registration key and join via the AVD agent; automate via Azure Image Builder and post-provisioning scripts.
  • Workspace and app group hygiene: publish least-privilege app groups; separate Desktop and RemoteApp; keep DR app groups assigned but visually de-emphasized if needed.
• Runbooks and automation:
  • Build Business Continuity and Disaster Recovery (BCDR) runbooks that cover:
    • Declaring incident and placing primary pools in drain mode.
    • Scaling DR pools and verifying image parity.
    • Switching profile storage via Cloud Cache or DNS re-point.
    • Validating critical app dependencies through Front Door/Traffic Manager.
    • Communicating to users and service desk.
    • Rolling back when the primary region is restored.
  • Implement runbooks using Azure Automation or Functions with role-based access controls and change approvals.
• Cost and reservations:
  • Use Savings Plans and Capacity Reservations for steady baseline workloads; keep burst capacity on pay-as-you-go with autoscaling. Schedule non-production pools to shut down out of hours.

Practical Problem Scenario

Adobe must ensure creative and support teams can work continuously during a regional outage while migrating from an on-premises RDS farm to Azure Virtual Desktop, with hundreds of terabytes of roaming profiles and demanding graphics workloads.

1. Discover and baseline

• Use Azure Migrate to inventory RDS hosts, profile shares, and LOB dependencies, and to capture CPU/memory/IO patterns for graphics and support cohorts.
• Why: Empirical baselines drive accurate user-density targets and VM SKU selection, minimizing overprovisioning.

2. Design regional architecture

• Create primary host pools in West US 2 with GPU-enabled NVadsA v5 for creatives and Dv5 for support; deploy secondary pools in Central US.
• Replicate images via Azure Compute Gallery; store MSIX packages in ANF with cross-region replication.
• Why: Ensures compute and app parity across regions with predictable performance.

3. Harden identity and DNS

• Configure VNet DNS to Azure AD DS IPs where session hosts will domain-join; deploy Azure DNS Private Resolver to forward queries between on-premises and Azure.
• Why: Reliable name resolution across regions enables logon and app access during failover.

4. Implement resilient profiles

• Use Azure NetApp Files for FSLogix with snapshots and cross-region replication; enable FSLogix Cloud Cache pointing to primary and DR ANF volumes.
• Why: ANF delivers the IOPS/latency creatives require; Cloud Cache and CRR provide continuity if a region fails.

5. Orchestrate dependency failover

• Front LOB web APIs with Azure Front Door and configure regionally deployed backends; use Traffic Manager for any non-HTTP public endpoints.
• Why: Keeps application endpoints reachable from either AVD region without reconfiguration.

6. Establish recovery objectives and protection

• Set RTO minutes for pooled hosts (rebuild), hours for personal desktops (if any, protected by Azure Backup/ASR), and 15-minute RPO for profiles via ANF snapshots; back up support cohort’s Azure Files shares if used.
• Why: Component-specific objectives align cost with business impact.

7. Pilot and coexist

• Onboard 100 support users and 50 creatives to AVD; keep RDS published in parallel. Validate density, profile stability, and app performance. Iterate scaling policies and FSLogix settings.
• Why: Controlled pilots de-risk image, storage, and autoscaling choices.

8. Cutover and DR drill

• Generate AVD registration keys to expand pools; assign DR app groups to all users. Execute a DR drill: drain primary, scale DR, validate Cloud Cache continuity, and fail app dependencies through Front Door.
• Why: Proves end-to-end failover, including profiles and dependencies, before full migration.

9. Quotas, reservations, and automation

• Pre-increase regional vCPU and GPU quotas; purchase Capacity Reservations for baseline GPU and CPU; implement Azure Automation runbooks for drain, scale, storage switch, and comms.
• Why: Guarantees capacity during incidents and removes manual steps from stressful events.

10. Full migration and rollback plan

• Migrate remaining cohorts in waves over two weeks; maintain RDS access as a rollback path with clear decision gates per wave.
• Why: Gradual cutover reduces risk and preserves an immediate fallback if unexpected issues arise.

← Monitoring · All domains

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

Browse Microsoft →