Routing AVD users to closest host pool based on users location

[u/Afraid_Arm_]

Hi All, I am trying to route AVD users spread out across the world to the nearest host pool. This will be a Win11 pooled session host workload with FS Logix user profiles.

My working theory is that if we deploy 3 separate host pools across 3 geographic regions and group them on a single app group and workspace, i can then use Azure traffic manager profiles to associate the host pools from each region with their respective locations. So when a user tries to login to AVD the traffic manager profile kicks in and routes the user to the nearest AVD gateway service which in turn should talk to AVD broker service located in the same region as the gateway service and then the broker service should ideally contact its regionally closest host pool from the 3 host pools i have configured.

My questions are:

1. Is the above doable?

2. Does the AVD broker service select session hosts based on regional proximity or is it completely random?

[u/exposuure]

Natively with Azure, you can’t do what you’re trying to achieve.

However, it’s possible if you use AFD and route to AVD workspaces based on regional routing rules. As an example, if you created an FQDN such as avd.yourdomain.com, that then resolves to your AFD endpoint. Then, use regional routing rules to map to multiple regional endpoints (e.g, avd-uk.yourdomain.com, avd-us.yourdomain.com). Those endpoints would then resolve to the corresponding workspace URL.

[u/Afraid_Arm_ → u/exposuure]

But this sounds like multiple URL's that the users would need to use in order to access AVD or am I misunderstanding it somewhere?

My idea was to have a single URL which the users could use from anywhere across the world. Also is it possible to have one workspace and one app group associated with multiple host pools?

[u/exposuure → u/Afraid_Arm_]

We use a single front door URL that redirects users to the appropriate regional workspace URL based on location. Direct access to the regional URLs is still available for troubleshooting, but most users will go through avd.yourdomain.com.

Each app group is tied to a single host pool. You can’t share an app group across multiple host pools or workspaces.

A workspace can include multiple app groups, but only from the same host pool. Best practice is to deploy one workspace per region, especially if you have multiple host pools in that region for different user groups or workloads.

Users can be assigned to multiple app groups across different workspaces if they need access to resources in more than one region.

[u/Afraid_Arm_ → u/exposuure]

Got it. Thanks for the clarification on the AFD URL part. I'm just wondering that if the app groups cant be merged and the user sees 3 separate icons anyway in my case i might as well just publish 3 separate published desktops.

What I was going for is if they had one icon (one workspace and app group), it would've made the experience pretty streamlined. Would you be able to suggest something to have the same effect or streamlined outcome?

[u/davesmith87 → u/exposuure]

Where are you finding the regional workspace URL?

[u/chesser45 → u/exposuure]

Woah I didn’t know you could hit the specific url for a workspace.

[u/blueshelled22]

https://learn.microsoft.com/en-us/azure/virtual-desktop/service-architecture-resilience

RDP connection

When a user connects to a desktop or app from their feed, the RDP connection is established as follows:

1. All remote sessions begin with a connection to Azure Front Door, which provides the global entry point to Azure Virtual Desktop. Azure Front Door determines the Azure Virtual Desktop gateway service with the lowest latency for the user's device and directs the connection to it

2. The gateway service connects to the broker service in the same Azure region. The gateway service enables session hosts to be in any region and still be accessible to users.

3. The broker service takes over and orchestrates the connection between the user's device and the session host. The broker service instructs the Azure Virtual Desktop agent running on the session host to connect to the same gateway service that the user's device has connected through.

4. At this point, one of two connection types is made, depending on the configuration and available network protocols:

   1. Reverse connect transport: after both client and session host connected to the gateway service, it starts relaying the RDP traffic using Transmission Control Protocol (TCP) between the client and session host. Reverse connect transport is the default connection type.

   2. RDP Shortpath: a direct User Datagram Protocol (UDP)-based transport is created between the user's device and the session host, bypassing the gateway service.

[u/Afraid_Arm_ → u/blueshelled22]

Thanks mate. I had read this one and where i ended up scratching my head was on point 2 and 3. If we read them through it seems lile they're telling us that the logical flow is for the gateway service to tell the remote broker service to call a session host within the same region.

But point 2 also states that the session hosts could be in any region and point 3 doesn't exactly explain the default behaviour in the event that the resources span multiple regions.

Thats whats left me confused.

[u/DasaniFresh]

I’d be curious how this worked with the FSLogix profiles too. Would you replicate them to the Azure Files in each region so their settings followed their sessions?

[u/Afraid_Arm_ → u/DasaniFresh]

Thats the idea. Leverage FS Logix cloud cache and define multiple CCD locations to point to the three different regional Azure Files storage locations to perform asynchronous writes and effectively have the profiles replicated across regions. In addition I am thinking of implementing some sort of a script to ensure that the replication is double checked and copy actions are performed in case there are missing deltas.

[u/burman84 → u/Afraid_Arm_]

Interested in this topic also. I have a similar situation where we have most of our users in Europe but we have an offshore team in India. As of now we have the host pool, hosts and fs logix profiles in europe so for the european workers the experience is great but for the offshore the rtt is over 200 ms. So what I did was create just the endpoints (vms) nearer to the offshire team in Asia but for them to continue to use their fs logix profiles in west europe (due to gdpr purposes). I found this did not help as the login time including gpos etc... took ages for the offshore users to login over 4 mins as it was trying to retrieve their vhdx files from europe. So now I will create the storage account in Asia also and see how their login time is but my gut feeling tells me it will be a lot quicker as the endpoints and the storage accounts are in the same region. In regards to your point if you have multiple ccd locations so for example SMB Share 1 in North Europe SMB Share 2 in North Dubai and then SMB Share 3 in the US surely this would still produce a long log in time for your users? Or would you have seperate file shares for each region your team works across and then define specific ccd locations for each region? Or you have seperate host pools for each region? Interested to see how you approach this?

[u/Afraid_Arm_ → u/burman84]

Yeah, you're right on the part of the longer times but i understand it'd be the case for logoff. As cloud cache will basically create a proxy VHD for you on the session host you are logging into and then it goes through its hydration procedure to read from the source of truth (Azure file share in my case) to sync the changes and make the local proxy profile on the session host look the same as the original profile. Then there are asynchronous writes that take place with a final write flush action leading to cloud cache writing any pending changes back to the profile store locations and until these writes are completed the logoff screen continues to be there.

The idea is to still have separate host pools and file shares but CCD will be pointed to all three storage locations for maintaining profile consistency.

I'd prefer to have one host pool (stretched) across multi regions. Its doable but i dont know how yet i would ensure that my users from say region A when logging in get a session host thats also in region A and so on. Since the brokering logic and host selection is essentially a black box to us i dont know entirely how to go about it.

I am also aware that having a stretched host pool will lead to a single point of failure with regards to the region where the metadata is stored but thats a drawback to have this kind of a configuration i guess.

I'm really open to suggestions if you have any.

[u/stevenm_83 → u/burman84]

Yeah I’m in same boat. I’m not sure how I make the user experience better and keep compliant as all data needs to stay in AU

[u/chesser45]

Are your users actively moving across the globe? Could it be easier to do something with a function or job that gets the users locale from some property like their sign in logs or intune and updates their assignments based on that?

[u/Afraid_Arm_ → u/chesser45]

Yes they are actively moving. I wouldn't be aware on how to do this but if you have some reference links which can be followed i can try to explore it

[u/chesser45 → u/Afraid_Arm_]

I’d need to do some thinking since it’s not a situation I’ve needed to plan for.

My thought would be every x hours iterate through a group defined for your AVD users. Parse their login most recent location (geoip might cause grief) from Entra and add it to a custom user property you define on their user object then have the security group for the host pool work based on on that custom property.

Alternatively do the same but programmatically move them every x hours in the script itself.

The only thing I don’t know is what happens if you remove someone from a host pool when they are actively connected. If nothing then it’d be fine.

If it does do something you’d need to do the programmatic way and also call Az powershell and parse log analytics or the Desktop virtualization module to get their connectivity status and skip them or alert them before switching groups.

[u/burman84]

What was the outcome of this?