Azure Virtual Desktop regional host pools are now generally available in East US 2 and Central US ONLY.

Regional host pools use backing infrastructure designed to reduce cross-region dependencies and their impact on users connecting to session hosts. Microsoft manages the AVD web service, broker, gateway, resource directory, AND NOW metadata databases. Your session hosts and the services they depend on are still your responsibility.

A regional host pool uses a metadata database associated with its own region. An “existing” geographical host pool uses metadata storage for regions within a geography. From a functionality perspective, there is no difference. Your end users will not have a different desktop experience.

The Azure portal is a straightforward place to start. Check that the target region fits your deployment requirements before creating anything.

1. 1. Sign in to the Azure portal. Open Azure Virtual Desktop, select Host pools, then select Create.
2. 2. On Basics, select your subscription and resource group. Enter a host pool name.
3. 3. Set Location to East US 2 or Central US.
4. 4. Set Deployment scope to Regional. Do not leave this setting to chance: Geographical remains the default when you do not specify a scope.
5. 5. Choose your host pool type, such as pooled or personal, and complete the remaining host pool settings.
6. 6. Configure your session hosts, networking and workspace. Make sure the workspace uses the matching regional scope.
7. 7. Select Review + create. Check the settings, allow validation to complete, then select Create.

Big Chris’s Note: A regional host pool’s application groups automatically use regional scope. Those groups cannot associate with a geographical workspace, and geographical application groups cannot associate with a regional workspace. Scope also applies to App Attach packages. Check the scope of the resources you intend to connect, not just the host pool. Deployment scope is fixed when an object is created. You can’t “configure” an existing geographical host pool into a regional one by changing a toggle later. In existing environments, assess which resources need to be recreated and how users, applications and workspace associations will move. Treat that as a planned change, not a quick settings update.

Regional scope gives you more control over placement of AVD service metadata such as host pool, application group and workspace names, and user principal names. The service uses metadata replicas across availability zones and, if applicable, replication to a paired region. User documents, application settings and other customer-managed data follow your data backup configurations.

Big Chris’s recommendation: Keep planning and testing recovery for session hosts, profile storage (storage account, NetApp files), identity, network connectivity and applications. Regional host pools do not automatically move your VMs or profiles to another region. Decide what users need to recover, identify the dependencies and test the recovery steps before you need them.

This is a useful step forward for AVD resiliency. Choose Regional deliberately, keep the related resources aligned and continue doing the recovery work around the service. Now is a good time to use Regional host pools!