Now in public preview: Azure Virtual Desktop regional host pools

At Microsoft, we understand customers need a desktop service that is reliable and resilient. That’s why we’ve made service resilience a core architectural design principle within the Azure Virtual Desktop connectivity platform — so your employees stay connected and productive. To deliver enhanced resiliency, we are announcing regional host pools, a new host pool deployment type that is now in public preview.

What are regional host pools?

Today, Azure Virtual Desktop uses a geographical model for all host pools, where the metadata is stored in a geographical database within each of the Azure geographies around the globe. For resiliency purposes, these geographical databases store multiple replicas within the same region as well as in a separate, paired region. This enables local and cross-region recovery. However, having only one database within a geography serving multiple regions introduces 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.

To reduce the impact of these types of issues and remove the cross-region dependency, we are deploying new Azure Virtual Desktop databases and infrastructure into every Azure region that Azure Virtual Desktop supports. This means any issue will only impact host pools in the same region. These service enhancements will ultimately result in approximately 40 regional databases across Azure. This also significantly improves your ability to meet any data sovereignty requirements your organization may have, as the metadata associated with your host pools is stored within the Azure region you select. In the event of a local database issue, we still store multiple local replicas across availability zones within the region as well as replicate the metadata to a secondary region where there is an Azure paired region for cross-region failover. This paired region is typically within the same country or at least the same Azure geography.

There are no functional differences between existing geographical host pools and the new regional host pools, aside from one additional field to complete within the deployment process. 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.

What are the benefits of regional host pools?

The main benefit of the new regional host pools is the increased resiliency inherent in the underlying database and infrastructure architecture. They will also give you more control to define your data sovereignty requirements by aligning your host pool metadata with each of the Azure regions supported. When this service becomes generally available, we strongly recommend that you create all new host pools as regional host pools to take full advantage of these benefits and consider transitioning your existing geographical host pools over to regional.

Where can you use regional host pools?

Two infrastructures will co-exist until after we have completed deploying all of the new regional infrastructure in all regions that Azure Virtual Desktop supports.

Future changes:

1. A date will be announced when creating new geographical host pools will no longer be allowed.
2. A later date will be announced for retiring geographical infrastructure entirely.

During this transition you can still create geographical host pools, but they won’t offer the improved resiliency of regional host pools. We recommend creating all new host pools as regional host pools to take advantage of improved resiliency and data sovereignty. Begin planning your transition from geographical host pools early — Microsoft will provide tools to help move metadata, or you can manually deploy new regional host pools with the same configuration and transition users. Watch for upcoming communications on timelines to ensure a smooth migration

During the public preview, we are supporting two new “regional” regions, East US 2 and Central US. Additional regions will be added individually once these two regions enter general availability. This rollout will enable you to deploy new regional host pools in an ever-increasing number of Azure regions over time.

Getting started

There are no functional differences between existing geographical host pools and regional host pools. However, you will need to choose from one additional field during creation — the Deployment scope. You can create regional host pools using both the Azure portal and PowerShell. 

Create a regional host pool in the Azure portal (available 8/31/2026 onwards) 

1. In the Azure portal, open Azure Virtual Desktop → Host pools, then select Create.  
2. Under Basics, choose your resource group and enter a host pool name.  
3. Select your Azure region (East US2 or Central US) for the host pool location field, then set the Deployment scope to Regional. This will store the host pool metadata regionally.  
4. Complete host pool type (Pooled or Personal), networking, and session host settings as usual.  
5. Select Review + Create to deploy.  

Note: In case you select a different Azure region for your host pool location field, you will not see the Deployment scope field; it will automatically default to a geographical host pool.

In case you select East US2 or Central US for your host pool location field and set the Deployment scope to Geographical, your created host pool will be a geographical host pool as per the previous experience. 

Create a regional host pool with PowerShell  

When creating the host pool, set the DeploymentScope parameter to Regional so the metadata is written to the regional database. Example:  

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

Note: In regions where regional host pools are not yet supported, regional-deployment scope calls return a "Not Supported" response.  

Regional host pools use regional workspaces, app groups, and App Attach packages  

The Deployment scope is also relevant for new Workspaces, Application Groups, and App Attach packages. Regional and geographical objects cannot be mixed: a regional host pool can only be a member of a regional workspace and can only contain regional application groups. A regional host pool cannot join a geographical workspace, and vice versa.  

You can use the new Deployment scope column in the host pool view to see the type — regional or geographical — of each of your host pools.  

Public preview limitations

During public preview the following features are not supported:

• Errors and checkpoints will not be reported into Log Analytics for regional session hosts.

Now supported in public preview 

• Session host update 
• Dynamic autoscaling 
• Private Link 
• App attach packages and  
• Automated host pool creation 

App attach packages carry a deployment scope and follow the same association rule as workspaces and application groups: a regional host pool uses regional App attach packages, and regional and geographical objects cannot be mixed 

Migration

We are working on a future service that will enable the migration between existing geographical objects to new regional objects.

Global availability

New “regional” infrastructure is slowly being enabled globally, and individual or small numbers of regions will become available periodically over time. 

Click here for further detailed instructions: Regional Host Pools

Stay up to date! Bookmark the Azure Virtual Desktop Tech Community.