Best way to spin up another VDI environment in another geolocation

Question

Hey everyone! I want to make sure if there is a better way of doing something.

Context: We have an AVD Environment is WEST US consisting with a Domain Controller VM, Storage Accounts for File Shares, and Workspace with Host pools and VMs for end users.

We are now growing and require another AVD Environment in CENTRAL INDIA for remote workers but require access to the data in the Storage Accounts in WEST US.

My initial thoughts is to create another DC VM (with replication to WEST US DC) in India for authentication and test the performance according to the latency in this table.
https://learn.microsoft.com/en-us/azure/networking/azure-network-latency

I also understand there will be some additional costs because of the Ingress/Egress traffic between Geolocations. (Referencing the Inter-continental Data Transfer table)
https://azure.microsoft.com/en-us/pricing/details/bandwidth/

Is there anything else I should be aware of or is there another method of accomplishing these requirements? I am all ears and thank you in advanced!

Answer 1

Hei @dvmaster-ib

Thank you for contacting Microsoft community.

As i understand,

1. Your organization is expanding globally and it needs Azure virtual desktop hosts in 2 different Azure regions.
2. The two regions are in different countries
3. The host need to be in domain and need to be able to authenticate via AD
4. There is a storage account file share that needs ot be accessible in both regions

• Let us start with storage account,

It is possible to use the same storage account without a hit to performance by changing it to "geo redundant storge or read access geo redundant storage" (depending if you need the other region to write or just read to the account).

Extended explaination and guide can be found here

Make sure you secure the access to storage account to only be accessible from the network created for these AVD hosts. This will ensure that the content of storage account do not open up to any other vm or otherwise except the ones you deployed.

• Moving to Azure virtual network for Azure virtual desktop,

You will need a new network in the proposed second region and this network should prefereably have IP range different from the current network.

This different IP range will help you peer the new network in second region with the existing network in region 1, ensuring your traffic moves within azure saving you cost and providing privacy.

• Now that we have network, we move to Azure virtual desktop.

Azure virtual desktop is a global hosted service and you will just need to create a new host pool in the new region.

This should be accompanied by seperate application group and workspace for better access control.

From an Architecture point of view, this case is similar to "Multiregion Business Continuity and Disaster Recovery (BCDR) for Azure Virtual Desktop" with Active-Active configuration.

The details guide with explaination is here

- For domain join, you have 3 options, On premise ADDS (assuming this is not present), ADDS on an Azure VM, Azure hosted ADDS service and Azure AD.

Originally, Azure Virtual Desktop domain join needed both Azure AD and AD DS domain controllers. Traditional Windows Server AD DS domain controllers were on-premises machines, Azure VMs, or both. Azure Virtual Desktop accessed the controllers over a site-to-site virtual private network (VPN) or Azure ExpressRoute. Alternatively, Azure Active Directory Domain Services platform-as-a-service (PaaS) provided AD DS in Azure and supported trust relationships to existing on-premises AD DS. Users had to sign in to both Azure AD and AD DS.

Applications, Server Message Block (SMB) storage, and other services that Azure Virtual Desktop hosts consume might still require AD DS. But Azure Virtual Desktop itself no longer requires AD DS. Removing this requirement reduces cost and complexity.

Azure AD domain join for Azure Virtual Desktop provides a modern approach for smartcards, FIDO2, authentication protocols like Windows Hello for Business, and future capabilities. Azure AD domain join also opens up the possibility of decommissioning Active Directory, since Azure Virtual Directory host pools no longer require Active Directory.

So instead of using an Azure VM with ADDS, it may be easier with cost and management, to use Azure AD domain join for AVD sessions.

PS: Azure AD is created automatically for every Azure tenant and globally available to avoid latency.

Learn more about Azure AD here

A detailed tutorial to use Azure AD with AVD here

In case you do not want to use Azure AD, it may be useful to migrate VM based ADDS to managed ADDS, learn more here

If you still want to use the ADDS on hosted Azure VM, just make sure that the network that it is hosted on is peered with AVD networks so the traffic is private.

In case of latency you may need another VM hosting ADDS in second region.Please do mark it as "Answer" if it helps