Category: Azure Virtual Desktop

What would you do if Azure went down in your region today?
Not a total global outage — but a partial, messy one where your VMs are healthy, storage is fine, yet users still can’t connect.

This scenario is why Microsoft has introduced Regional Host Pools for Azure Virtual Desktop, now available in public preview.

This is not about making your session hosts multi-region.
It is about removing a long-standing single point of failure in the AVD control plane.

Let’s break down what’s changed, why it matters, and how to start using it.

Azure resilience isn’t one thing — it’s layered

Microsoft Azure resilience works across multiple layers:

• Global geographies
• Regions
• Availability zones
• Datacentres

Some services (like Azure DNS or Front Door) are fully global.
Others — virtual machines and storage — are tied to a region.

AVD has always sat somewhere in between.

• The control plane (metadata, brokering, app groups, workspaces) is globally distributed
• But metadata databases were shared at a geography level

That meant a database issue in one region could affect host pools in entirely different regions.

Regional Host Pools are Microsoft’s fix for that architectural risk.

What are Regional Host Pools?

Historically, all AVD host pools used a geographical deployment model, where metadata was stored in a shared database for an entire Azure geography.

With Regional Host Pools:

• Each supported Azure region gets its own AVD metadata database
• Metadata is still:
  • Replicated across availability zones
  • Replicated to a paired region for disaster recovery
• But cross-region dependencies are removed

The result:

• Outages are isolated to a single region
• The AVD control plane becomes significantly more resilient
• You gain explicit control over where metadata lives

This is especially important for:

• Regulated industries
• Public sector
• Customers with strict data sovereignty requirements

What actually changes when you deploy one?

Functionally? Almost nothing.

Architecturally? A lot.

The only visible difference during deployment is a new field:

Deployment Scope

• Geographical (legacy)
• Regional (new)

Everything else — host pool type, validation environment, assignment type — stays the same.

⚠️ This does not:

• Make session hosts multi-region
• Replicate FSLogix profiles
• Replace Azure Site Recovery

It only hardens the AVD control plane.

Public preview details (important)

During preview:

• Supported regions:
  • East US 2
  • Central US
• Metadata is replicated between those paired regions
• More regions will be added gradually as the service approaches GA

Unsupported features (for now):

• Session host configuration & updates
• Dynamic autoscaling
• Private Link
• App Attach (still geographical only)
• Log Analytics errors & checkpoints for regional hosts

These will hopefully be fix by the time this feature goes GA.

Enabling the preview

Azure Portal

1. Go to Subscriptions
2. Select your subscription
3. Settings → Preview features
4. Register: AVD Regional Resources Public Preview

PowerShell

Register-AzProviderFeature `
  -ProviderNamespace Microsoft.DesktopVirtualization `
  -FeatureName AVDRegionalResourcesPublicPreview

If you’re deploying via PowerShell, you’ll also need:

• Az.DesktopVirtualization 5.4.5-preview
• The -DeploymentScope Regional parameter

Can you convert existing host pools?

Not yet.

Currently, you have three options:

• Wait for Microsoft’s upcoming migration tooling
• Create a new regional host pool, then:
  • Generate a new registration token
  • Reinstall the AVD agent
  • Move hosts across
• Use this in testing and labs only (the safest option during preview)

Also note:

• Regional objects cannot be linked to geographical ones
• Host pools, app groups, and workspaces must all share the same deployment scope

Why this really matters

Microsoft has been very clear:

Regional host pools are the future of Azure Virtual Desktop.

At some point:

• Creating geographical host pools will be blocked
• Geographical infrastructure will be retired
• Regional will be the default — and the expectation

This change:

• Removes a hidden single point of failure
• Improves outage isolation
• Gives customers real control over metadata placement

It’s one of the most meaningful architectural improvements AVD has had in years.

Final thoughts

If you’re running production workloads today:

• Start planning your transition
• Track feature parity as preview limitations close
• Begin using regional host pools for new environments

This isn’t a flashy feature — but it’s a foundational one.
And those are usually the changes that matter most.