Java / Azure Virtual Desktop Interview questions

Azure Virtual Desktop (AVD) is Microsoft's cloud desktop and app virtualization service that runs on Azure. Users connect from almost any device and get either a full Windows desktop or individual published apps (RemoteApp) streamed from virtual machines in your own subscription.

Microsoft runs the control plane (web access, gateway, connection broker, diagnostics). You own the session hosts, images, networking, identity integration and profile storage, so you control cost, region and security posture.

It is the only service that offers Windows 11 Enterprise multi-session, which lets many users share one client-OS VM. That is what makes pooled desktops affordable. You pay for the Azure compute, storage and networking you consume, while user access rights come from eligible Microsoft 365 or Windows licenses.

AVD splits into a Microsoft-managed control plane and customer-managed resources. The control plane contains Web Access, the Gateway, the Connection Broker, Diagnostics and extensibility components. You never patch or size these.

On your side sit the host pools and session hosts, application groups, workspaces, the virtual network, identity (Microsoft Entra ID plus optional AD DS), the profile storage for FSLogix, and the images used to build hosts.

flowchart LR
  U["User client"] --> W["Web Access feed"]
  U --> G[Gateway]
  G --> B["Connection Broker"]
  B --> H["Host pool"]
  H --> S1["Session host 1"]
  H --> S2["Session host 2"]
  S1 --> F[(FSLogix profile share)]
  S2 --> F

Everything left of the host pool is Microsoft's responsibility; everything from the host pool onward is yours.

A host pool is a collection of Azure VMs, called session hosts, that are registered to AVD as one unit and share the same configuration and image source. Users are never pointed at a VM directly; they land on whichever host the pool selects.

The pool is where you set the type (pooled or personal), the load-balancing algorithm, the max session limit, custom RDP properties and whether it is a validation environment.

New VMs join a pool using a registration token. The token is time-limited (up to 27 days), so a stale token is a common reason a freshly built host never shows up.

There are two types: pooled and personal. The difference is whether users share hosts or each user owns one.

Autoscale works for both, but behaves differently: pooled pools scale on session load, personal pools react to schedules, Start VM on Connect and disconnect/sign-out actions.

An application group controls what users can launch from a host pool. It is the object you assign users to, and it comes in two kinds: a Desktop group that publishes the full Windows desktop, and a RemoteApp group that publishes individual applications.

A host pool can have only one desktop application group but several RemoteApp groups, which is handy when different departments need different app sets from the same hosts.

Access is granted by giving a user or Entra group the Desktop Virtualization User role on the application group. The group must also be added to a workspace, otherwise nobody sees it in their feed.

A workspace is the logical grouping of application groups that determines what appears in a user's feed inside the AVD client. Without registering an application group to a workspace, its desktops and apps are invisible to users.

A workspace can hold application groups from several host pools, and each application group can be registered to only one workspace. Teams often create one workspace per department or per environment (for example Prod and Test) so users see a tidy list.

The workspace also carries the friendly name and description users see, and it is the resource you attach a private endpoint to when using Private Link for feed discovery.

A session host is the VM that actually runs the user's Windows session. It belongs to one host pool, has the AVD Agent and the SxS network stack installed, and is joined to Microsoft Entra ID, AD DS, or both depending on your identity design.

Session hosts normally run in Azure, but they can also run as VMs on Azure Local. The OS can be Windows 11/10 Enterprise (single or multi-session) or a supported Windows Server release.

In the portal each host reports a status such as Available, Unavailable, Shutdown or Upgrading, driven by agent heartbeat and health checks. A host that is not Available will not receive new sessions.

Windows 11 Enterprise multi-session is a Windows client edition that allows several users to hold concurrent interactive sessions on one VM. It exists specifically for AVD, so you get the Windows 11 desktop experience at a density normally associated with Windows Server RDS.

It is supported only for AVD, on Azure or Azure Local. Because access rights come from your per-user Windows or Microsoft 365 license, you do not buy RDS CALs for it.

The older Windows 10 multi-session image still exists, but Windows 10 reached end of support on October 14, 2025, so new pools should start from Windows 11. Microsoft 365 Apps work well on multi-session when installed in shared computer activation mode.

You need two things: an eligible user license for access rights and an Azure subscription to pay for the infrastructure.

For client-OS session hosts, eligible per-user licenses include Microsoft 365 E3/E5/A3/A5, F3, Business Premium, Windows Enterprise E3/E5 and Windows VDA E3/E5. Many customers already own one of these and pay nothing extra for AVD access.

For Windows Server session hosts you also need RDS CALs with Software Assurance, or RDS user subscription licenses. Access for external users who are not covered by your tenant licenses is billed per user per month for apps.

Microsoft's recommended client is the Windows App, a single app for Windows, macOS, iOS/iPadOS and other platforms that can also reach Windows 365 and Microsoft Dev Box. Older Remote Desktop clients are being phased out in its favour.

• Windows App for Windows, macOS, iOS/iPadOS, Android and ChromeOS (availability varies by platform)
• Web client, which runs in a modern browser with nothing to install
• Remote Desktop clients for Windows, macOS, iOS and Android (legacy)
• Thin clients from partners that embed an AVD-compatible client

Feature support differs by client. Teams media optimization and some redirections, for example, need the Windows App or the Windows desktop client, not the browser.

FSLogix is a set of profile and app-management tools that makes pooled, non-persistent desktops feel personal. Its main component, Profile Container, stores the whole user profile in a VHD(X) on network storage and mounts it at sign-in.

Because the profile is attached rather than copied, sign-in is fast and the user sees the same files, settings and Outlook cache on whichever host they land on.

• Profile Container - the full profile in a VHD(X)
• Office Container (ODFC) - only Outlook/OneDrive-related data in its own disk
• Cloud Cache - local cache plus multiple remote storage providers
• App Masking - hides apps or files per user or group on a shared image

FSLogix is included with the same licenses that entitle you to AVD.

The AVD Agent (Remote Desktop Services Infrastructure Agent) is the software that links a session host to the AVD service. It registers the VM using the host pool token, sends heartbeats and reports health so the broker knows whether the host can take sessions.

Three pieces matter in practice: the RDAgent itself, the RDAgentBootLoader service that starts it, and the SxS Network Stack, which handles the RDP traffic on the host.

Agents update themselves and are rolled out progressively, with validation host pools getting new builds first. If a host shows Unavailable, checking that the boot loader and agent services are running is step one.

Session hosts can be Microsoft Entra joined, Microsoft Entra hybrid joined, AD DS joined, or joined to Microsoft Entra Domain Services. Users, however, must always exist in Microsoft Entra ID, synced from AD DS if you have one.

The choice also decides how you authenticate to Azure Files for FSLogix and whether single sign-on needs extra setup.

A scaling plan is the autoscale configuration for a host pool. It starts and stops (deallocates) session hosts on a schedule and in response to user demand, so you only pay for compute when people need it.

Pooled schedules have four phases: ramp-up, peak, ramp-down and off-peak. Each phase sets its own load-balancing algorithm, minimum percentage of hosts and capacity threshold. Personal pools use schedules plus actions on disconnect or sign-out, such as hibernate or deallocate.

The AVD service needs permission to power VMs, granted with the Desktop Virtualization Power On Off Contributor role on the subscription. Plans for hosts built with session host configuration can also create and delete VMs.

RDP Shortpath is a transport feature that gives the client a direct UDP path to the session host instead of relaying everything through the AVD gateway. The result is lower latency, less jitter and a smoother experience for video, voice and graphics.

It comes in two flavours:

• Managed networks - client and host reach each other over private routes (ExpressRoute or VPN). The host listens on UDP 3390 by default.
• Public networks - uses STUN to find a direct path through NAT and TURN as a relay fallback, typically over UDP 3478.

If UDP is blocked, the connection simply falls back to TCP through the gateway on port 443, so nothing breaks.

Start VM on Connect powers on a deallocated session host the moment a user tries to connect, so you can keep idle VMs switched off without locking people out.

You enable it on the host pool, then grant the AVD service principal the Desktop Virtualization Power On Contributor role on the subscription or resource group that holds the VMs. The first connection takes longer because the VM has to boot, and the client shows a short wait message.

It works for both pooled and personal pools. In a pooled pool with a scaling plan, the plan manages capacity, and Start VM on Connect acts as a safety net if no host is running.

Session hosts can run Windows 11 Enterprise (single or multi-session), Windows 10 Enterprise (single or multi-session), and Windows Server 2025, 2022, 2019 and 2016.

Windows Server 2012 R2 and older are not supported as session hosts. Always check the current support matrix before standardizing, because supported builds change with each Windows release.

App attach delivers applications to session hosts as a disk image that is mounted when the user signs in, instead of installing the app into the OS image. The app appears installed to the user, but it lives outside the image.

Packages are typically MSIX, and App-V packages are now supported too. They are stored as VHDX or CimFS images on a file share such as Azure Files, registered as an app attach package in Azure and assigned to a host pool. The same image can be shared by many hosts.

The big win is that app updates and image updates become independent: you swap a package instead of rebuilding the golden image.

Azure Compute Gallery stores and distributes the versioned images you use to build session hosts, so every VM in a pool starts from exactly the same, tested build.

A gallery contains image definitions (the logical image, such as Win11-Multisession-M365) and each definition contains image versions (the actual snapshots). You can replicate versions to other regions, keep several replicas for faster large deployments, and share them across subscriptions or tenants with RBAC.

Older managed images still work but lack versioning and replication, which is why the gallery is the recommended source for AVD and for custom image templates.

Session hosts need outbound only access, mainly TCP 443 to the AVD service. No inbound ports have to be opened. The easiest rule is to allow the WindowsVirtualDesktop service tag, plus the dependencies below.

Add Azure Monitor, Windows Update and storage endpoints if you use those. Check the current required-URL list before locking down a firewall, since Microsoft updates it.

A validation host pool is a host pool with Validation environment set to Yes. It receives AVD service updates, including new agent and stack builds, before production pools do.

Use it as an early-warning system: keep a small pool with the same image, GPOs and key apps as production, put a few pilot users on it, and watch for regressions. If something breaks, you find out before the rollout reaches everyone.

A validation pool only helps if it is representative. A pool with a bare OS and no apps will not catch the problems your real users would hit.

Choose personal when a user needs a persistent, one-to-one desktop: local admin rights, tools installed over time, or an app whose licensing or security model assumes a dedicated machine.

• Developers and power users who install their own tooling
• Apps that do not behave in multi-session, such as those tied to a single interactive user or needing a driver
• Strict isolation requirements where no other user may share the OS
• Dedicated GPU workloads where one user should own the whole VM

The trade-off is cost: you pay for one VM per user, so use autoscale with hibernate or deallocate on disconnect and Start VM on Connect to avoid paying for idle desks. If most users run the same few apps and need no customization, pooled with FSLogix is almost always cheaper.

Both are load-balancing algorithms for pooled host pools. Breadth-first spreads new sessions across the hosts with the fewest sessions; depth-first fills one host up to its max session limit before moving to the next.

In a scaling plan you can choose the algorithm per phase, and the schedule's value overrides the host pool setting while the plan is active. A common pattern is breadth-first in ramp-up and peak, then depth-first in ramp-down and off-peak.

A connection goes through authentication, feed discovery, brokering and then the RDP session itself. The key detail is that the session host has already opened an outbound connection, so the client never reaches the VM directly.

1. The user opens the client and signs in with Microsoft Entra ID (MFA and Conditional Access apply here).
2. The client calls Web Access to retrieve the feed of workspaces, desktops and apps the user is assigned to.
3. The user picks a resource. The client connects through the Gateway to the Connection Broker.
4. The broker chooses a session host: for pooled pools by the load-balancing algorithm, for personal pools the user's assigned VM. It may trigger Start VM on Connect.
5. The host's agent has an outbound reverse connect tunnel, so the gateway links the client to it. If UDP is available, RDP Shortpath takes over the transport.
6. The user signs in to the host (SSO if configured), FSLogix attaches the profile, and the desktop appears.

sequenceDiagram
  participant C as Client
  participant E as Entra ID
  participant W as Web Access
  participant G as Gateway
  participant B as Broker
  participant H as Session host
  C->>E: Sign in
  C->>W: Get feed
  W-->>C: Desktops and apps
  C->>G: Connect to resource
  G->>B: Request session host
  B-->>G: Selected host
  H-->>G: Existing outbound tunnel
  G-->>C: RDP session established

AVD is a flexible, consumption-based platform where you design and run the infrastructure. Windows 365 gives each user a dedicated Cloud PC at a fixed monthly price, managed mostly through Intune.

Both use RDP and the Windows App, so users see the same experience. Pick AVD for large, variable or specialized fleets and cost optimization; pick Windows 365 when simplicity and predictable billing matter more than control.

At sign-in, the FSLogix service and its filter driver find the user's VHD(X) on the configured share, create it if it does not exist, mount it, and redirect the profile path to the mounted disk. Windows then treats it as a normal local profile, even though the data lives on network storage.

1. The user signs in; the FSLogix service checks whether Profile Container is enabled.
2. It locates (or creates) the user's VHD(X) in a folder named from the user's SID and name.
3. It mounts the disk and uses the filter driver to present it as C:\Users\username.
4. During the session all profile reads and writes go to the VHD(X).
5. At sign-out the disk is detached and the lock released.

Minimal configuration on a session host:

reg add HKLM\SOFTWARE\FSLogix\Profiles /v Enabled /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\FSLogix\Profiles /v VHDLocations /t REG_MULTI_SZ /d \\stprofiles.file.core.windows.net\profiles /f

Only one session can normally hold the read-write lock on a profile disk, so concurrent sign-ins need specific settings or a different design.

Profile Container mounts a VHD(X) straight from one network location. Cloud Cache adds a local cache and writes to several remote providers at once, which gives you storage-level redundancy at the profile layer.

Most deployments should start with Profile Container on resilient storage. Move to Cloud Cache only when you need profiles available from two regions or storage accounts without a manual failover.

For most deployments Azure Files Premium (SMB) is the better starting point: it is simple, cheap to operate and fast enough for typical profile workloads. Azure NetApp Files (ANF) wins when you have very large user counts or strict latency and IOPS needs.

Whichever you pick, keep the share in the same region as the session hosts and size it for IOPS, not just capacity.

RDP Multipath keeps several network paths open between the client and the session host, watches their quality, and switches to the most reliable one when the active path degrades. Users see fewer freezes and disconnects when networks change or fail.

The newer redundant TCP support adds standby TCP paths alongside UDP, which extends the benefit to environments where firewalls or proxies block UDP and sessions fall back to TCP reverse connect over port 443.

It differs from RDP Shortpath: Shortpath is about getting a direct, low-latency UDP route, while Multipath is about having alternate routes ready. It works automatically when prerequisites are met, and admins can review connection reliability in AVD Insights.

In ramp-down, autoscale shrinks capacity gradually: it puts surplus hosts into drain mode, waits for their sessions to end, and then deallocates them, while keeping at least the configured minimum percentage of hosts running.

The schedule's capacity threshold decides how much spare capacity to keep, and the load-balancing algorithm is usually switched to depth-first so sessions pack onto fewer hosts.

If you enable force sign-out, users on hosts selected for shutdown get a notification message and a delay in minutes, then are signed out so the host can power down. Without it, a host with one lingering disconnected session stays on and keeps costing money, so pair it with disconnected-session time limits.

With Microsoft Entra single sign-on, the token the user got when signing in to the client is reused to authenticate to the session host, so there is no second password prompt. The host uses Microsoft Entra authentication for RDP instead of NTLM or Kerberos from a domain.

1. Enable it on the host pool by setting the RDP property enablerdsaadauth:i:1.
2. Grant users the Virtual Machine User Login role (or Administrator Login) on the session host VMs.
3. Manage the one-time consent prompt for the remote connection, ideally with a trusted device group, so users are not asked on every connection.
4. Include both the Azure Virtual Desktop and Windows Cloud Login apps in Conditional Access policies.

Passwordless methods such as Windows Hello for Business and FIDO2 keys then work end to end.

Create a Conditional Access policy in Microsoft Entra ID that targets the Azure Virtual Desktop cloud app, assign it to your AVD users or groups, and set the grant control to Require multifactor authentication.

If you use Entra single sign-on, also target Windows Cloud Login, otherwise the connection to the session host itself is not covered by the policy. You can add conditions such as compliant device, trusted location or sign-in risk.

Use sign-in frequency to control how often users must re-authenticate when reconnecting. Setting it to a short period gives stronger security but more prompts, so match it to your risk appetite.

Exclude break-glass accounts, and test with a pilot group before enforcing.

Private Link lets clients and session hosts reach the AVD service through private endpoints in your virtual network, so traffic uses private IP addresses instead of public service endpoints. It is the right choice when policy forbids public exposure.

There are three endpoint types: connection on the host pool (RDP traffic), feed on the workspace (resource discovery) and global (initial feed discovery). You also need private DNS zones such as privatelink.wvd.microsoft.com so names resolve to the private IPs.

Once private endpoints work, you can disable public network access on host pools and workspaces. UDP over Private Link is now generally available, so you keep good media performance too.

Use Teams media optimization, which moves audio and video processing from the session host to the user's local device. Without it, calls are encoded on the host and streamed over RDP, which burns CPU and sounds poor.

1. Use New Teams with the SlimCore-based optimization, installed on the session host and on a supported client.
2. Connect with the Windows App or a supported Windows client; macOS support through the Windows App is in preview.
3. Allow the required media traffic (UDP preferred) from the client to Microsoft 365 media endpoints.
4. Confirm it works: in Teams open Settings, About, Version and look for an AVD media optimized banner.

Also size hosts with enough vCPU headroom for the non-media parts of Teams, and keep the client device's CPU and drivers healthy because the local device does the real-time work.

Start with a GPU-enabled VM size from the NV family, such as NVadsA10 v5, which offers partial GPUs so several users can share a card. Then install the correct GPU driver and turn on the Windows policies that make RDP use it.

1. Deploy hosts on an NV-series size and install the NVIDIA GRID driver (the VM extension can do this).
2. Enable the policy Use hardware graphics adapters for all Remote Desktop Services sessions so apps render on the GPU.
3. Enable GPU-accelerated frame encoding (Configure H.264/AVC hardware encoding) to reduce CPU load and latency.
4. Prioritize H.264/AVC 444 mode for sharp text in CAD or design apps, and test HEVC where the client supports it.

Check actual GPU use with Task Manager or nvidia-smi inside a session. If the GPU sits idle, the policies are not applied or the driver is wrong.

For pooled pools, do not patch hosts in place. Build a new image version, deploy fresh hosts from it, drain the old ones and delete them. Users move over naturally as they sign in again.

1. Update the golden VM, run Sysprep and publish a new version to Azure Compute Gallery.
2. Deploy new session hosts from that version into the same host pool (or update the session host configuration and roll it out in batches).
3. Set the old hosts to drain mode so no new sessions land on them.
4. Wait for users to sign out, or force sign-out after hours.
5. Delete the old hosts and their disks.

Keeping apps in app attach packages and profiles in FSLogix means the image holds little besides the OS, which makes rebuilds quick and low risk. Personal hosts are different: patch them in place with Intune or Configuration Manager.

Build a reference VM, install and tune everything, generalize it with Sysprep, capture it as an image version in Azure Compute Gallery, and deploy session hosts from that version. For repeatable builds, automate it with Azure VM Image Builder through AVD custom image templates.

1. Create a VM from a Windows 11 multi-session marketplace image (the Microsoft 365 Apps variant if you need Office).
2. Install apps, apply optimizations and policies, and install updates. Leave the AVD agent to the deployment process.
3. Run sysprep.exe with the generalize, OOBE and shutdown options (command below).
4. Capture the VM into a gallery image definition as a new version, and replicate it to the regions you deploy in.
5. Create or update the host pool using that version.

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown

Templates make this a pipeline you can rerun every month instead of a manual ritual.

Unavailable means the service stopped receiving healthy heartbeats from the agent. Work from the outside in: is the VM running, are the agent services up, can it reach the service, and is its identity intact.

1. Open the host in the portal and read the health check results (domain joined, domain reachable, SxS listener, monitoring agent) to see which one failed.
2. Confirm the VM is running and you can sign in to it.
3. Check that the agent services are running.
4. Verify outbound TCP 443 to the AVD service and that DNS resolves correctly.
5. For domain-joined hosts, test the secure channel to the domain.
6. If the agent is broken or the token expired, generate a new registration token and reinstall the agent.

Get-Service RDAgentBootLoader, RDAgent, TermService
Test-ComputerSecureChannel -Verbose

Agent logs in the Application event log and under C:\Program Files\Microsoft RDInfra usually name the exact failure.

Find out which phase is slow before changing anything. AVD Insights breaks logon time into connection, profile load, group policy and shell start, which points you straight at the culprit.

• Profile load - oversized VHD(X) (Outlook cache, OneDrive), a share in another region, or a storage tier that is out of IOPS.
• Group policy and scripts - long logon scripts or many GPOs processed synchronously.
• Antivirus - scanning the mounted VHD(X) because FSLogix exclusions are missing.
• Cold start - the VM is booting through Start VM on Connect.
• First sign-in on multi-session - Appx package registration for a new profile.

Typical fixes: put the share in the same region on premium storage, add Defender exclusions for the VHD(X) files and FSLogix processes, move Outlook data to an Office Container, trim logon scripts, and size the share for IOPS. Re-measure after each change so you know what actually helped.

AVD Insights is an Azure Monitor workbook that shows connection health, host performance, user experience and capacity in one place. It reads data from a Log Analytics workspace, so the setup is mostly about getting data into that workspace.

1. Create or pick a Log Analytics workspace.
2. Add diagnostic settings on the host pool, workspace and application groups, sending the AVD log categories (checkpoints, connections, errors, management, agent health) to it.
3. Install the Azure Monitor Agent on session hosts with a data collection rule for performance counters and event logs.
4. Open Insights in the portal, pick the host pool and review the tabs; configure alerts on the signals that matter.

The older Microsoft Monitoring Agent is retired, so new setups should use the Azure Monitor Agent only. Insights also reports connection reliability, which helps judge the impact of RDP Shortpath and Multipath.

Treat each layer separately, because the control plane is Microsoft's responsibility while hosts, profiles, identity and networking are yours.

Assign users to both application groups, keep the DR pool at minimal size with autoscale, and rehearse failover regularly. An untested plan is just a hope.

Start from the user workload type, apply Microsoft's density guidance, then validate with a load test. The guidance is a starting point, not a promise.

Example: 120 medium users at 4 per vCPU needs about 30 vCPUs, so roughly eight 4-vCPU hosts before adding headroom for failures and peak. Prefer a few mid-sized hosts over many tiny ones to cut per-VM overhead, but not so few that one host failure hurts many users.

Use the AVD experience estimator and a tool like Login VSI to test, then tune with AVD Insights data from real use.

Most of the bill is session host compute, so the biggest savings come from running fewer VM-hours and paying less per hour for the ones that must stay on.

Do not forget storage: right-size the profile share and cap profile growth, since provisioned Premium file shares are billed whether used or not.

The session stays alive on the same session host. Apps keep running and memory stays allocated, and the user can reconnect to that exact session later. Signing out ends the session, closes processes and detaches the FSLogix profile disk.

This matters for cost and capacity. A pooled host with even one disconnected session cannot be deallocated by autoscale unless forced sign-out is on, and disconnected sessions still count against the host's session limit.

Control it with session time limits set through RDP properties, Intune or GPO: for example end a disconnected session after 1 to 4 hours, and log off idle sessions after a longer period. For personal pools, a scaling plan can hibernate or deallocate the VM a set time after disconnect.

Combine redirection controls, screen protections and network egress limits. No single setting is enough, because a user who can copy, print, capture the screen or upload to the internet can leak data.

• Disable redirections through host pool RDP properties: clipboard, drives, printers, USB.
• Turn on screen capture protection so local screenshots and recordings show a blank window.
• Enable watermarking, which overlays a QR code with the connection ID so leaked screenshots can be traced.
• Restrict outbound traffic with NSGs or Azure Firewall and block personal cloud storage.
• Require compliant devices and MFA through Conditional Access.

redirectclipboard:i:0;drivestoredirect:s:;redirectprinters:i:0;usbdevicestoredirect:s:

Test with a pilot group first because disabling clipboard or printing breaks legitimate workflows.

A host in drain mode keeps serving its existing sessions but refuses new ones. The broker skips it when placing users, which is why it is the standard step before patching, replacing or shutting down a host.

Under the hood the host's Allow new sessions flag is set to off. Users already signed in are not interrupted, and disconnected users can still reconnect to their existing session. Once the last session ends, you can safely deallocate or delete the VM.

Autoscale uses the same mechanism during ramp-down, and you reverse it by turning new sessions back on.

Choose it when desktops or apps must run on-premises or at the edge: low latency to local equipment, data residency rules, or apps that cannot move to the public cloud, while you still want AVD's management and the Windows App experience.

Session host VMs run on Azure Local hardware in your own site. The control plane (broker, gateway, web access) and host pool objects stay in Azure and are managed with the same portal, RBAC and tooling, so admins use one model for cloud and on-prem.

Trade-offs: you own the hardware and capacity planning, and feature parity with cloud-based session hosts is not always complete, so check the current limitations before committing. If latency and residency are not issues, cloud session hosts are simpler.

Use app attach when apps change more often than the OS, when different user groups need different app sets, or when you want one lean image for many pools. Bake apps into the image when they are tiny, rarely change, or cannot be packaged.

In practice, many teams bake in core tools like Microsoft 365 Apps and use app attach for line-of-business and departmental apps.

An empty feed almost always means an assignment or registration gap, not a broken session host. Check the chain: user, application group, workspace, then the client.

1. Confirm the user, or a group they belong to, has the Desktop Virtualization User role on the application group.
2. Confirm the application group is attached to a host pool and registered to a workspace.
3. Check the user signed in with the expected account; a personal and a work account give different feeds.
4. Refresh or re-subscribe the feed in the client, and wait a few minutes for role changes to propagate.
5. Look at the Entra sign-in logs for a Conditional Access block or an MFA failure.

Remember that role assignments on the host pool or VM do not publish anything. Only the application group assignment decides what appears in the feed.

Because the session host starts the connection. The AVD agent opens an outbound HTTPS (TCP 443) tunnel to the service, and the gateway later rides that existing tunnel to carry the user's RDP session. Nothing on the internet needs to reach the VM, so no inbound rule is required.

flowchart LR
  H["Session host agent"] -- outbound TCP 443 --> G["AVD Gateway"]
  C["User client"] -- authenticated connection --> G
  G -. uses existing tunnel .-> H

The practical benefits are a smaller attack surface, no public IPs on session hosts and no need to expose TCP 3389. You should still block inbound 3389 from the internet in your NSGs.

With RDP Shortpath for managed networks the host does listen on UDP 3390, but only for traffic on your private network, not from the internet.