Azure Virtual Desktop Regional Host Pools Reach GA in East US 2 and Central US

The announcement also says the same regional resiliency work is coming to Windows 365. It will arrive through a gradual rollout that Microsoft manages, and the customer experience is supposed to stay the same. Microsoft gave no dates, region list or admin steps for Windows 365, so treat that part as advance notice, not a GA announcement.

The problem: one geography, one shared database​

Until now, AVD has used a geographical model for every host pool. In the preview announcement, Microsoft explained that the metadata is stored in a geographical database within each of the Azure geographies around the globe, and that these geographical databases store multiple replicas within the same region as well as in a separate, paired region.

Replicas help, but the design still has a weak spot. Microsoft acknowledged that it created a cross-region dependency, where any issue within the region hosting the Azure Virtual Desktop metadata database or with the database itself could impact users connected or trying to connect to host pools in un-related Azure regions. Your session hosts could be healthy in one region and users still couldn't connect, because a metadata database in another region was having problems.

Travis Roberts of Ciraltos summed up the issue: a single regional dependency can have a much larger blast radius than expected, especially when control plane services are shared across regions in an Azure geography.

Section summary: Geographical host pools share one metadata database across a whole geography. If that database or the region hosting it has trouble, host pools in other regions can be affected.

What regional host pools change​

A regional host pool keeps its metadata in a dedicated AVD database and supporting infrastructure inside the Azure region you pick. Microsoft's Learn documentation says this infrastructure removes cross-region dependencies thereby reducing the impact of any Azure region or Azure Virtual Desktop database outages. The preview post put it more simply: any issue will only impact host pools in the same region. Microsoft also said the project will ultimately result in approximately 40 regional databases across Azure.

Here is how the two models compare, based on the GA announcement:

"Regional" does not mean you lose cross-region failover for the metadata. Microsoft says it still keeps multiple local replicas across availability zones and copies the metadata to a paired region where one exists. The change is about where an outage can spread from. Your recovery options for the metadata stay the same.

Microsoft says there are no functional differences between the two types of host pool. The preview post said the only differences are the type of database they are stored in, and the supporting infrastructure, the regional location of each database, and the enhanced resiliency they provide.

Section summary: Regional host pools keep the control plane metadata in one region. A failure elsewhere should no longer stop your users from connecting, and replication to a paired region is still in place.

How to create a regional host pool​

You can create regional host pools in the Azure portal or with PowerShell. There is one new setting to choose: Deployment scope.

In the Azure portal​

1. Open Azure Virtual Desktop → Host pools and select Create.
2. On Basics, choose your subscription and resource group and enter a host pool name.
3. For Location, select East US 2 or Central US.
4. Set Deployment scope to Regional.
5. Choose the host pool type (Pooled or Personal), then configure session hosts and networking as usual.
6. Select Review + Create, check that validation passes, and deploy.

Microsoft recommends putting your session host VMs in the same region as the regional metadata. That is good practice: if the VMs sit in one region and the control plane in another, you still have a dependency across two regions.

If something looks wrong:

• No Deployment scope field? You picked a region without regional infrastructure. The field disappears and the host pool defaults to geographical.
• Picked East US 2 but got a geographical pool? Deployment scope was set to Geographical. In the supported regions you still have to choose Regional yourself.

With PowerShell​

Add the DeploymentScope parameter. Microsoft's example:

New-AzWvdHostPool -ResourceGroupName "testrg" -Name "xyz" -Location "centralus" -DeploymentScope "Regional"

According to the Learn documentation, the parameter is optional. If you leave it out, the host pool is created as geographical. If you request regional scope in a region that doesn't support it yet, you get a "Not Supported" response.

During preview, Microsoft's instructions said the 5.4.5-preview version of the Az.DesktopVirtualization module will be required to create new regional host pools via PowerShell, and preview users had to register the AVDRegionalResourcesPublicPreview feature first. The GA announcement doesn't say whether those requirements still apply. Check the current module version and your subscription's feature registrations before you add this to a pipeline.

To confirm the result, look at the Deployment scope column in the host pool view. It shows whether each pool is regional or geographical.

Section summary: Pick a supported region, set Deployment scope to Regional, and keep session hosts in the same region. Then check the Deployment scope column to make sure you got the pool type you wanted.

You can't mix regional and geographical objects​

This rule is the most likely to trip up existing AVD environments. Deployment scope also applies to workspaces, application groups and App Attach packages, and the two scopes can't be combined. A regional host pool can only belong to a regional workspace and can only contain regional application groups. A geographical workspace can't take a regional host pool, and a regional workspace can't take a geographical one.

The Learn page says the same thing: a new field called deployment scope has been introduced. This parameter controls whether the Azure Virtual Desktop objects being created are geographical or regional, and only objects with the same scope can be associated with each other.

In practice, your users' existing workspace can't simply pick up a new regional host pool. You'll need a separate regional workspace and regional app groups next to your current ones. That affects feed design, assignments and naming conventions, so plan for it before the first pool goes live.

Section summary: Going regional means building regional workspaces and app groups too. You can't add a regional pool to your existing geographical setup.

Caveats before you start​

• Only two regions are supported. At GA, regional host pools work in East US 2 and Central US. If your AVD deployment runs in Europe or Asia, you'll have to wait.
• Existing host pools can't be migrated yet. Microsoft says migration from geographical to regional is coming in a phased rollout, with no date given. Its advice for now is to create new pools as regional in the supported regions.
• Some documentation is still from the preview. At the time of writing, the Learn page still had preview wording. During preview it said regional host pools will not support Session host update, Dynamic autoscaling, Private Link or App Attach. The GA announcement now mentions regional App Attach packages, but it doesn't list which preview limitations, if any, still apply. If you rely on Private Link, session host update or dynamic autoscaling, test in a non-production subscription first.
• Logging gap. The same Learn page says errors and checkpoints are not being reported to Log Analytics for regional session hosts. If your monitoring depends on those tables, find out whether that is still true before moving production users.
• Geographical pools are on the way out. Microsoft's documentation says that at a future date, creating new geographical host pools will be deprecated. No date has been announced.

Analysis: a real improvement, with limits​

This is a solid architectural fix to a weakness most AVD customers didn't know they had. A control plane failure in another region is hard to diagnose and impossible to fix from your side. Removing that dependency is worthwhile, and so is the data residency benefit for regulated industries.

It is still metadata resiliency, not disaster recovery. As Tom Hickling of 9to5Azure notes, regional host pools improve resilience but do not protect against poor architecture, configuration or setup. If East US 2 itself goes down, a regional host pool there goes down with it, by design. Planning for session host failover, FSLogix profile storage, identity and networking across regions is still your job.

Starting GA with two US regions is a modest launch for a global service. Microsoft has said it will add regions in phases and that both infrastructures will run side by side, so for most organizations outside the central US this is something to plan for, not deploy yet.

What to do now​

1. New AVD host pools in East US 2 or Central US: create them as regional, as Microsoft recommends.
2. Existing host pools: list your workspaces and app groups. Any move to regional will mean building parallel regional objects.
3. Other regions: watch the Learn regional host pools page, which Microsoft keeps updated as new regions come online.
4. Windows 365: no action is needed. Microsoft says the regional changes there will roll out on the service side with no change to the customer experience.

Bottom line​

Regional host pools for Azure Virtual Desktop are generally available in East US 2 and Central US. They keep host pool metadata in the region you choose, so an outage in another region shouldn't stop your users from connecting, and the metadata is still replicated to a paired region. You can create them in the portal or with New-AzWvdHostPool -DeploymentScope "Regional". Regional and geographical objects can't be mixed, migration for existing pools hasn't arrived yet, and similar changes are coming to Windows 365 without any action from admins.