Close AVD tickets faster in 2026 with PowerShell, KQL, and portal steps for session host registration, RDP Shortpath, Entra ID join, FSLogix, App Attach, and autoscale plans.
Azure Virtual Desktop (AVD) troubleshooting in 2026 comes down to isolating the failure to one of five layers: session host registration, the RDP transport (Reverse Connect or Shortpath), identity (Entra ID join or hybrid Entra join), the FSLogix profile, and App Attach package delivery. Honestly, nine out of ten tickets I've closed this year are one of those five, and the diagnostic path is the same every time: check the health of the host pool object, then walk down the stack. This guide gives you the PowerShell, log queries, and portal steps to close AVD tickets fast without guessing.
Start every AVD ticket by checking session host status in the host pool blade. Unavailable or NoHeartbeat almost always means the RDInfra agent lost its outbound TLS 443 connection to the broker.
RDP Shortpath for public networks uses UDP 3478 (STUN) and a dynamic UDP port range. If it silently downgrades to Reverse Connect (TCP 443), the endpoint or perimeter firewall is blocking those ports.
Entra ID-joined AVD hosts need the targetisaadjoined:i:1 RDP property on the host pool and Kerberos support enabled on the FSLogix profile storage account to mount Azure Files.
App Attach (the unified successor to MSIX App Attach) is generally available in 2026 and supports both MSIX and non-MSIX apps, but the storage account and image reference must sit in the same region as the session host.
Autoscale plans deallocating hosts mid-session usually trace to a mismatched work-hours schedule or a missing "Ramp-down force logoff" grace period. Check the Autoscale operational logs, not the session host itself.
The Get-AzWvdHostPool, Get-AzWvdSessionHost, and Log Analytics WVDConnections table are your three most useful diagnostic surfaces. Memorise them.
Why is my AVD session host showing "Unavailable"?
An Unavailable or NoHeartbeat status in the AVD host pool blade means the RDAgent service on the VM hasn't checked in with the AVD broker within the last five minutes. This is the single most common opening symptom of a broken host pool, and the fault is almost never the broker. It's the outbound path from the VM to *.wvd.microsoft.com, the RDAgent or RDAgentBootLoader service being stopped, or a broken URL rewrite in a proxy.
Start on the VM itself. Open an elevated PowerShell prompt and run the following. Every command is commented so tier-1 staff can copy the whole block:
# Confirm both AVD services are running - if either is Stopped, that's your ticket
Get-Service RDAgentBootLoader, RDAgent
# Trigger the AVD service health test that Microsoft runs during onboarding
Test-NetConnection rdweb.wvd.microsoft.com -Port 443
Test-NetConnection rdbroker.wvd.microsoft.com -Port 443
# Read the RDAgent log for the last hour - this is where broker rejection appears
Get-WinEvent -LogName "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" `
-MaxEvents 200 | Where-Object TimeCreated -gt (Get-Date).AddHours(-1)
So, the three failure modes I keep seeing in tickets:
RDAgentBootLoader is Stopped because Windows Update reset the service after a reboot. Set it back to Automatic and start it.
The Test-NetConnection returns False because a corporate proxy rewrites the SNI. Either bypass *.wvd.microsoft.com and *.prod.warm.ingest.monitor.core.windows.net, or use the AVD required-URL check tool built into the RDAgent installer.
The registration token expired because someone rebuilt the host from an image older than 90 days. Regenerate the token from Get-AzWvdRegistrationInfo / New-AzWvdRegistrationInfo and re-run the boot-loader MSI.
There is no fourth mode worth checking before those three, so don't get sucked into looking at NSGs first. I did that once on a Sunday call and burned an hour before realising the service was just stopped.
If you inherited a host pool that has been failing for weeks and nobody knows why, dump the whole session host state to a table so you can see patterns:
If AgentVersion is behind the current build (check the AVD What's New page), the host will keep failing health probes until the boot loader self-updates or you manually reinstall it. This is very common on hosts that spent months deallocated as part of a personal desktop pool.
End-user connection errors are the second-biggest bucket. The AVD client hides most of the useful diagnostics behind a small "Copy details" button in the error dialog, so always ask the user to paste that into the ticket instead of just the number. Here are the four codes that make up about 80% of the tickets on my team:
0x3000047 ("The user is not authorized to connect to this resource"). The user isn't in the Application Group assignment. Even if the user is a Global Admin, AVD ignores directory-level roles for session assignment. Add them explicitly with New-AzRoleAssignment -ObjectId $userId -RoleDefinitionName "Desktop Virtualization User" -ResourceName "dag-prod-01" -ResourceGroupName "rg-avd-prod" -ResourceType "Microsoft.DesktopVirtualization/applicationGroups".
0x204 / "We couldn't connect to the gateway". Outbound 443 to *.wvd.microsoft.com is blocked on the endpoint side. Most often it's a split-tunnel VPN client that captures all traffic. Ask the user to disconnect the VPN and retry; if it works, add AVD gateway URLs to the VPN's split-exclude list.
0x3000018 ("Your session ended because of an error on the remote PC"). The FSLogix container failed to attach and the shell exited. See our FSLogix profile container troubleshooting guide for the storage account permission checklist. Nine times out of ten it's a missing NTFS ACL on the profile share.
0x108 ("Remote resource not found"). The workspace URL cached in the client is stale after a host pool was rebuilt. In the AVD client, right-click the workspace > Unsubscribe, then re-subscribe. Do not tell users to reinstall the client; it doesn't clear the workspace cache.
For patterns across many users, run this Log Analytics KQL query against your AVD diagnostic settings workspace. It ranks the top error codes over the last 24 hours by unique user count, which lets you tell a real outage from one noisy person:
// Top AVD connection error codes over the last 24 hours
WVDErrors
| where TimeGenerated > ago(24h)
| where ServiceError == "false"
| summarize UniqueUsers = dcount(UserName), TotalErrors = count() by CodeSymbolic, Message
| sort by UniqueUsers desc
| take 20
If ConnectionFailedNoHealthySessionHostAvailable tops the list, you have a capacity or drain-mode problem, not an error the user can do anything about. That ticket should route to the AVD platform team, not sit in tier 1.
RDP Shortpath: enabling UDP transport and verifying it's actually used
RDP Shortpath is the UDP-based transport that AVD uses instead of the default Reverse Connect (TCP 443 through the AVD gateway). For managed networks (ExpressRoute, S2S VPN) it uses direct UDP; for public networks it uses ICE/STUN via 3478/udp to turn.wvd.microsoft.com. In 2026, RDP Shortpath for public networks is on by default for new host pools, but you still have to prove it's working. If it silently downgrades to Reverse Connect, users see the classic "AVD feels laggy over hotel Wi-Fi" pattern.
Enable Shortpath on managed networks with a group policy or Intune configuration profile setting the RDP UDP client transport, and open UDP 3478 outbound plus the dynamic UDP range (49152-65535 on the host by default) on any firewalls between the AVD client and the host. Microsoft's official RDP Shortpath documentation has the exact port matrix. Then verify from the session:
# Run inside the AVD session - reports the current transport type
# UDP means Shortpath is active; TCP means it fell back to Reverse Connect
$rdp = Get-Process mstsc -ErrorAction SilentlyContinue
if (-not $rdp) {
Write-Warning "This command must run inside an active AVD session, not on the local endpoint"
return
}
# Read the transport reported by the session itself
Get-ItemProperty "HKCU:\Software\Microsoft\Terminal Server Client\Servers\*" |
Select-Object PSChildName, UsernameHint, KindText
The quickest visual check is inside the AVD client: click the wireless-fan icon on the connection bar > Session Information. If Transport Protocol reads UDP, Shortpath is in use; if it reads TCP, you're on Reverse Connect and network diagnostics should look at UDP 3478 egress. For a deeper connectivity path check, our network diagnostics toolkit guide covers the STUN and traceroute-under-UDP techniques that reveal exactly where the drop happens.
Entra ID-joined and hybrid AVD hosts: registration and Kerberos for Azure Files
Pure Entra ID-joined session hosts have been supported since 2022, but the setup still catches people out in 2026 because Azure Files SMB with Kerberos requires a different auth path than AD DS-joined hosts. Two properties on the host pool are load-bearing:
# View the current RDP properties on the host pool
Get-AzWvdHostPool -Name "hp-prod-entra-01" -ResourceGroupName "rg-avd-prod" |
Select-Object -ExpandProperty CustomRdpProperty
# Set the two properties that Entra-joined hosts need
# targetisaadjoined tells the client to auth against Entra ID directly
# enablerdsaadauth enables the newer Entra ID auth path for Windows 11/Server 2022+
$props = "targetisaadjoined:i:1;enablerdsaadauth:i:1;audiocapturemode:i:1;redirectclipboard:i:1"
Update-AzWvdHostPool -Name "hp-prod-entra-01" -ResourceGroupName "rg-avd-prod" `
-CustomRdpProperty $props
For FSLogix profiles on Azure Files with Kerberos, the storage account needs Azure AD Kerberos enabled (not on-prem AD DS auth), the users need the RBAC role Storage File Data SMB Share Contributor on the file share, and (critically) the target AD object for Kerberos must exist in the tenant. The most common ticket I've picked up is "profile fails to load on Entra-joined AVD host," and the root cause is one of these three items missing. See the Azure Files identity authentication documentation for the exact sequence.
If you're mixing hybrid Entra join with cloud Kerberos trust for the wider tenant, our Windows Hello for Business troubleshooting guide covers the cloud Kerberos trust dependencies that also matter for AVD single sign-on. The same PRT that fails Hello sign-in will fail AVD SSO with error 0x4. For the underlying protocol behaviour, the MS-KILE Kerberos protocol specification is the authoritative source when you have to explain to a security team why a ticket lifetime setting is doing what it's doing.
App Attach troubleshooting: package registration and version conflicts
App Attach reached general availability in 2024 as the unified successor to MSIX App Attach, and in 2026 it supports both MSIX and non-MSIX Win32 packages published to an Azure Storage account. Applications are attached at user sign-in and detached at sign-out, which means package delivery failures show up as "the app icon is missing" rather than a hard error. Users open a ticket saying "my Photoshop is gone" rather than reporting a specific code.
Aspect
MSIX App Attach (legacy)
App Attach (2026)
Package format
MSIX only
MSIX, appx, and Win32 (via CIMFS/VHDX)
Attach point
Host pool
Workspace, application group, or per user
Storage requirement
SMB share with NTFS ACLs
Azure Files or SMB, with RBAC on the share
Region binding
None enforced
Package region should match session host region
Package versioning
Manual overlap handling
Active/inactive versions per package
Update mechanism
Publish new package, update host pool
Set new version Active, old goes Inactive
The failure I see most: the package publisher signs a new App Attach package with a different certificate than the previous version. The MSIX manifest requires the same publisher for an in-place update, so the second version registers as a new package and the shortcut ends up pointing at the old Inactive version. Confirm with:
# List all published App Attach packages in a host pool and their state
Get-AzWvdAppAttachPackage -HostPoolName "hp-prod-01" -ResourceGroupName "rg-avd-prod" |
Select-Object Name, ImageIsActive, ImageLastUpdated, ImagePackageFamilyName |
Sort-Object ImageLastUpdated -Descending
# Inside the session: check which packages are actually registered to the user
Get-AppxPackage -AllUsers | Where-Object PackageFamilyName -like "*YourAppFamily*"
If Get-AppxPackage returns the old family name after you set the new version active, the certificate mismatch is confirmed. Either re-sign with the original cert or publish under a new package identity and give users the new shortcut manually. There's no supported way to force MSIX to treat a different-signer package as an in-place update. I hit this exact bug shipping a repackaged Adobe app last spring, and the "fix" ended up being a new Start Menu tile plus a comms email, not a technical workaround.
Autoscale plans: why hosts deallocate mid-session and how to fix it
Autoscale plans on pooled host pools drive most of the "my session died at 5:03pm every Friday" tickets. The plan runs on a per-schedule cadence and ramps down aggressively unless you configure a force-logoff grace period. The three settings that trip people up:
Ramp-down capacity threshold too low. If you set 30% capacity but you have three hosts, the plan drains and shuts down two of them even at 25% load, leaving one host serving everyone.
"Force users to log off" enabled with a short grace period. Ten minutes sounds reasonable until a user is mid-render or presenting in Teams; set it to 60 minutes minimum for knowledge workers.
Timezone mismatch between plan and users. The plan's timezone must be the users' actual timezone, not the resource group's location. This is the single most common cause of "hosts scale down at lunch" tickets.
To diagnose, check the Autoscale operational log in Log Analytics. The plan writes structured events every time it runs:
// Autoscale plan activity for a host pool over the last 7 days
AzureDiagnostics
| where ResourceType == "HOSTPOOLS/SCALINGPLANS"
| where Category == "AutoscaleEvaluationPooled"
| where TimeGenerated > ago(7d)
| project TimeGenerated, hostPoolName_s, action_s, activeSessionHostsCount_d,
minimumHostsFinal_d, capacityThreshold_d, message_s
| sort by TimeGenerated desc
The message_s field tells you exactly why the plan made the decision it did, so read it before changing thresholds. AVD autoscale is deterministic given the inputs; if you don't like the output, one of the inputs is wrong. For adjacent DaaS troubleshooting patterns, our Windows 365 Cloud PC troubleshooting guide covers the equivalent connection and provisioning issues on the fully managed Cloud PC service.
AVD Insights, Log Analytics queries, and diagnostic settings
AVD Insights is the built-in workbook Microsoft ships in the AVD portal blade, but it only works if you have diagnostic settings configured to send the seven AVD categories to a Log Analytics workspace. If Insights shows "No data available" for a host pool, it's not broken. The diagnostic setting is missing or misconfigured. Enable the required categories with:
Once data is flowing, the four tables you'll actually use day-to-day are WVDConnections, WVDErrors, WVDCheckpoints, and WVDAgentHealthStatus. Everything else in AVD Insights is a workbook wrapper around joins between those tables. My favourite ad-hoc query for a "the app is slow" ticket:
// Round-trip time and connection duration for a single user
WVDConnections
| where UserName == "[email protected]"
| where TimeGenerated > ago(24h)
| join kind=leftouter (
WVDCheckpoints
| project CorrelationId, Name, TimeGenerated
) on CorrelationId
| project TimeGenerated, State, ConnectionType, ClientOS, ClientVersion,
SessionHostName, TransportType, StartTime, EndTime
| sort by TimeGenerated desc
If TransportType is TCP and ClientOS is macOS or iOS, the user needs the latest Windows App client. The old Microsoft Remote Desktop app was retired in 2025 for macOS/iOS and doesn't negotiate Shortpath properly against 2026 host pool builds. Have them install the Windows App from the Mac App Store or TestFlight and the transport issue disappears.
Frequently Asked Questions
How do I check if my AVD session host is registered?
Run Get-AzWvdSessionHost -HostPoolName <pool> -ResourceGroupName <rg> and look at the Status column. Available means the host is registered and heartbeating. Unavailable, NoHeartbeat, or NeedsAssistance mean the RDAgent lost its connection to the broker, so check outbound 443 to *.wvd.microsoft.com and confirm the RDAgentBootLoader service is running.
What is RDP Shortpath and do I need it?
RDP Shortpath is a UDP-based transport that AVD uses in place of the default TCP Reverse Connect over the AVD gateway. Yes, you want it. UDP handles jitter and latency dramatically better, so users on Wi-Fi or cellular get a noticeably smoother session. It's enabled by default on new 2026 host pools but requires UDP 3478 outbound plus a dynamic UDP port range to actually negotiate.
How do I fix AVD error code 0x3000047?
Error 0x3000047 means "the user is not authorized to connect to this resource." AVD doesn't honour Global Admin or Owner roles for session assignment, so you have to assign the user the Desktop Virtualization User role explicitly on the application group. Add them via Application groups > Assignments in the portal or with New-AzRoleAssignment.
Can I use Entra ID-joined session hosts with FSLogix and Azure Files?
Yes, this is fully supported in 2026. You need three things: enable Azure AD Kerberos auth on the storage account, grant users the Storage File Data SMB Share Contributor RBAC role on the share, and set targetisaadjoined:i:1 and enablerdsaadauth:i:1 on the host pool's custom RDP properties. If any of the three is missing, the profile silently fails to attach and the user sees a temporary profile.
Why do my AVD hosts deallocate while users are still working?
Almost always the autoscale plan's ramp-down phase is running with an aggressive capacity threshold or a short force-logoff grace period, and the plan's timezone doesn't match the users' actual timezone. Check the AutoscaleEvaluationPooled events in Log Analytics: the plan logs exactly why it made each decision. Bump the grace period to 60 minutes and pin the plan timezone to your users' region.
What's the difference between AVD and Windows 365?
AVD is a platform where you build, size, and manage the session hosts yourself: you pick VM SKUs, patch them, and pay Azure compute costs. Windows 365 is a fully managed Cloud PC service where Microsoft owns the infrastructure and you pay a per-user monthly price. Use AVD when you want pooled multi-session and custom images; use Windows 365 when you want persistent per-user Cloud PCs with minimum admin overhead.
Troubleshoot Intune Remote Help licensing, RBAC scopes, EPM elevation, and session errors. Real KQL, PowerShell, and network fixes from a helpdesk lead.
Fix Windows Server 2025 hotpatch failures the way I do in production: Azure Arc enrollment checks, baseline drift diagnostics, WSUS/WUfB conflicts, and clean rollback steps with PowerShell and CBS.log queries.
The four buckets that cover 90% of Teams Rooms tickets in 2026: resource-account sign-in, console pairing, PMP signal alerts, and auto-update ring stalls. A helpdesk manager's runbook with copy-paste PowerShell.
