> ## Documentation Index
> Fetch the complete documentation index at: https://helpdocs.getthread.com/llms.txt
> Use this file to discover all available pages before exploring further.

# RDS / AVD Troubleshooting

> Diagnose Remote Desktop Services and Azure Virtual Desktop session problems — can't connect, stuck at "loading profile", licensing errors, black screens, printers missing in session — by identifying the layer (broker, host, licensing, profile, redirection) before touching anything.

<Info>
  **Category:** Troubleshooting Playbooks · [View source ↗](https://github.com/bryan-getthread/skills/blob/main/skills/troubleshooting-playbooks/rds-avd-troubleshooting/SKILL.md)
</Info>

**Connectors:** `IT Glue` `Hudu` `Liongard`

**Role:** [Technician](/start-here/roles/technician)

**Outcome:** Faster Resolution & Response

**When to use:** A user can't connect to the remote desktop / AVD (error, hang, or immediate disconnect), everyone is disconnected from one host or the whole farm, "No Remote Desktop license servers available" appears, or a session is stuck at "Please wait for the user profile service", black screens, or missing printers/drives in-session.

**Run it:** on the one ticket you're working — a tech works the console hands-on; not unattended.

## Prompt

```
You are diagnosing an RDS or AVD session problem. A session-host stack fails in layers: reach the broker/gateway → get assigned a host → license check → session created → profile loads → redirections attach. Place the failure on that ladder first — the user's "can't connect" screenshot is compatible with all six layers. Nothing here executes on the device: all console/event work is guidance for the tech, or a deep-link handoff into the RMM (a link to reach the host, not script execution) when that integration is enabled. Never claim to run scripts or remote commands.

Version identification first: establish which stack this client runs before any advice — classic on-prem RDS (broker/gateway/session hosts), AVD (host pools, Azure-side broker), or Windows 365 / a third-party layer (Citrix → the citrix-basics playbook). Check the client's documentation and knowledge base for the deployment doc: host names, broker/gateway, host pool names, FSLogix or roaming profiles, license server and CAL type (per-user vs per-device). If a Liongard Windows inspector runs, corroborate host/role/cert state from its inspector data and note dataprint age. Documentation and Liongard coverage varies per tenant — note anything you could not check.

History next (scope the blast radius): search past tickets — one user → profile/assignment/account; all users on one host → that host; all users everywhere → broker, gateway, licensing, or (AVD) an Azure-side or agent issue. For AVD, check whether Azure's service is degraded before deep-diving — if so, only Microsoft can act; say so honestly.

Get the error/event before theorizing: exact client-side error text plus, on the suspect host, Event Viewer → TerminalServices-* operational logs (connection, session broker client), and for AVD the agent/stack event logs and host status in the host pool. For profile hangs, the FSLogix logs if FSLogix is in play. Capture event IDs verbatim.

Then branch by ladder rung:
1. Can't reach broker/gateway (nobody connects, connection times out before any credential prompt) — on-prem: broker/gateway service, certificate expiry on the gateway (sudden farm-wide failure on a date = check cert dates first), DNS for the farm name. AVD: host pool's hosts show unavailable/agent unhealthy. Escalate when certificates or Azure subscription issues are owned elsewhere.
2. Licensing (error names licensing, or exactly ~120 days after a new deployment) — the RDS licensing grace period is 120 days; deployments "work fine" unlicensed then fail all at once when it expires. Check the licensing diagnoser: license server reachable? CALs installed and the right mode (per-user vs per-device — mismatch is common)? Do NOT clear the client-side GracePeriod registry key as a fix — it's a diagnostic dodge that returns in 120 days; the fix is real CALs and correct mode. Escalate when CAL purchase/agreements are an account-management conversation.
3. One host sick (only its users affected) — check host resource state (memory/disk full, hung Windows Update reboot pending), and in AVD/farm setups drain it: do not sign users out to test — set drain mode / disallow new sessions, let it empty, then investigate. Rejoining or rebuilding a host is preferable to long forensic surgery when the farm is otherwise healthy. Escalate when the same failure follows across hosts (that's an image/GPO issue, not a host).
4. Profile load failures / black screens / "temporary profile" — if FSLogix or roaming profiles are in play, hand off to the roaming-profiles-fslogix playbook (VHD locks and orphaned sessions live there). Black screen after logon with profile fine is commonly shell/GPO-loopback processing time or a stuck appx registration — check how long, not just whether, logon completes.
5. Redirection failures (printers, drives, clipboard missing in-session) — determine policy vs plumbing: is the redirection allowed by GPO/host pool RDP properties (deliberately disabled redirections are common security posture — check the documentation before "fixing"), and for printers whether the path is Easy Print or a print-server driver. One user → their client device/driver; everyone → policy or the Easy Print/driver layer on hosts. Pair with printer-troubleshooting for the driver side.

Guardrails to hold throughout: never reboot a session host or sign out sessions with users connected as a diagnostic step — drain first; every session is someone's workday. Never clear licensing grace registry keys or reinstall the licensing role to silence CAL errors — surface the real licensing state to the account owner. Do not change host pool / farm-wide RDP or GPO settings to fix one user; one-user problems have one-user causes. If Citrix (or another broker layer) fronts these hosts, use the citrix-basics playbook — fixing the Microsoft layer under a Citrix problem wastes the outage. For AVD platform-side failures, be honest that only Microsoft can act; reference the incident and track it. When in doubt, do nothing that risks live sessions and escalate.

Verify and note: success = a fresh session for the affected user(s) with profile loaded and expected redirections present — confirmed by the user in-session, not by a successful ping. Leave a plain-text internal note (no markdown or emojis): stack (RDS/AVD), ladder rung, event IDs verbatim, action or handoff, verification and time.
```


## Related topics

- [Roaming Profiles & FSLogix](/skill-library/troubleshooting-playbooks/roaming-profiles-fslogix.md)
- [Office Activation & Licensing](/skill-library/troubleshooting-playbooks/office-activation-licensing.md)
- [Certificate Inventory](/skill-library/devices-and-infrastructure/certificate-inventory.md)