Two Continents, One Host Pool
Northwind has 1,100 task workers in Chicago and 180 designers in Amsterdam. All accounts are cloud-only Microsoft Entra ID and there is no on-premises Active Directory, so session hosts are Entra joined. Everything runs from one pooled host pool of 44 D4s_v5 session hosts in East US 2 with depth-first load balancing and a max session limit of 25, plus FSLogix profile containers on a standard Azure Files share in East US 2 using Microsoft Entra Kerberos. Amsterdam users report 180 ms keystroke latency and 90-second profile loads. Overnight all 44 hosts stay running below 4 percent CPU, and compute is the largest line item in the subscription. You may add one region but may not redesign identity.
1. Amsterdam users call the service unusable. What topology change do you make, and what does it force you to decide about profiles?
Read the worked answer
Separate the two populations by region. Keep the East US 2 pool for Chicago and add a second pooled host pool in West Europe, with its own application group published into the same workspace. The 180 ms figure is client-to-session-host round trip, so no broker, transport, or agent tuning fixes it; only hosting the session near the user does.
The profile decision is the hard part. FSLogix containers must sit close to the host that mounts them, and you cannot replicate one Azure Files share to another. Azure File Sync does not sync share-to-share; its cloud endpoint is Azure Files but its server endpoint is a Windows Server. That means:
- Users must be pinned to a region: Amsterdam accounts get only the West Europe app group, Chicago accounts only East US 2.
- A user who travels gets the wrong region and slow profile attach. Accept that, or accept that a single-region design trades input latency for mobility. Do not split the difference by keeping one share and adding West Europe hosts; you simply move the latency from keyboard to logon, where it hurts more.
- Stand up a premium file share in West Europe. Logon is a metadata-heavy, IOPS-bound burst, and standard share IOPS scale with provisioned size, not with concurrent users.
- Microsoft Entra Kerberos is configured per storage account, so the new share needs its own Kerberos server object and RBAC role assignments (Storage File Data SMB Share Contributor) before a single user logs on.
Also verify the designers' actual usage on the new hosts before assuming D4s_v5 is the right size; design work is bursty and 4 vCPU shared across 20-plus sessions is a different proposition than task work.
2. Depth-first with a max session limit of 25 on 4 vCPU hosts: what goes wrong, and what would you set in the new design?
Read the worked answer
Two failure modes, and they pull in opposite directions.
- The limit is treated as capacity, but it is only an admission gate. The broker will happily place session 25 onto a host whose CPU is already saturated by sessions 1-24. On 4 vCPU that is roughly 6 sessions per core, which is survivable for a text-only task worker and not survivable for anyone running Teams plus Excel recalculation. Depth-first makes it worse because it deliberately piles users onto the same host until the cap is hit.
- Set the limit too low and you reject users while hosts sit half empty. Users get 'no resources available' at 08:00 and the service desk points at a host that looks idle in metrics.
How to size it, not guess it. Pull per-user vCPU at p95 from AVD Insights for the existing pool. If a task worker needs about 0.12 vCPU at peak, usable capacity is 4 x 0.8 = 3.2 vCPU, giving roughly 26 sessions; keep a headroom margin and set the limit near 20-22. Re-measure for the designers separately.
Balancing. Keep depth-first only because you are pairing it with a scaling plan that drains and deallocates hosts; depth-first is what makes that packing possible. If the scaling plan is not there, breadth-first gives a more predictable user experience at a slightly higher idle cost. Whatever you choose, validate it, because the scaling plan's host math is derived from the max session limit, so a wrong limit makes autoscale wrong too.
3. Propose the scaling plan configuration for both pools, and explain the consequence of setting the capacity threshold at 90 percent.
Read the worked answer
Proposal (per region, local time):
- Ramp-up starting 06:30 with a minimum of 15-20 percent of hosts, capacity threshold 60 percent.
- Peak phase through the working day.
- Ramp-down from 19:00 with a low minimum percentage; force logoff enabled only after you have communicated it and configured a disconnect/idle policy, otherwise users lose unsaved work.
- Both pools attached to the same scaling plan object, and hosts taken out of drain mode correctly during ramp-up.
- If a personal pool is added later, plan on Start VM on Connect rather than ramp-based autoscaling, which is a pooled-host behaviour.
Why not 90 percent. The threshold is the trigger to add hosts, and it is measured against average host utilization computed from the max session limit, not from what the host can actually do. Two consequences:
- Users already feel contention at 70-80 percent. Setting 90 percent means you only react after the experience has degraded, so you save a little compute and pay for it in tickets.
- Scale-out is not instant. A new session host must start, register with the host pool, and become available, which takes minutes. At 90 percent you are queuing users for the duration of that boot, every morning, at exactly the time when arrival is bursty.
60 percent buys the boot time as headroom and is the standard trade-off between bill and experience. Pair it with the correctly measured max session limit, otherwise both numbers are fiction.