Troubleshooting failed Citrix launches
A launch is a chain of stages across the gateway, the store, the VDA and the session. DTR Vantage holds a record for most of them and says at which stage the evidence stops.
Stages
6
sign-in · store · launch · gateway to VDA · logon · the session
Evidence
records
syslog, AppFlow, VDA counters, event logs
Says
where it stops
the last stage with evidence, and what is missing
Does not read
the broker
Delivery Controller, DaaS, Director: said plainly
Fix from
the same page
block, bind, reboot, sign off, by delegation
The direct answer. For a user who could not launch, search their name on the HDX Insight page and read the chain: a gateway sign-in record (with the appliance's failure code when it failed), an ICA launch record naming the resource, an ICA connection record naming the VDA the gateway reached, and on the Windows side the VDA's session with its logon broken into phases and its counters. The stage after the last record you find is where it broke. Vantage reads the gateway's AppFlow and syslog and the VDA's agent; it does not read the Delivery Controller or Citrix Cloud yet (that integration is on the roadmap), so a failure inside brokering (no VDA registered, no capacity, a bad assignment) shows as a sign-in with no launch after it, and Vantage says that is what it is seeing rather than guessing the cause.
The stages, and the evidence for each
| Stage | What Vantage holds | When the record is missing, it usually means |
|---|---|---|
| 1. Gateway sign-in | the AppFlow sign-in record (user, client, gateway, AAA vserver, policy, failure code) and the syslog LOGIN / LOGIN_FAILED line with the appliance's Failure_reason; the Identity threat page if the address has been blocked | the user never reached the gateway (DNS, the client, a blocked address: the Identity threat page names blocks); a failed record names the reason the appliance gave |
| 2. Store enumeration | the StoreFront server's health from its agent (services, IIS bindings, certificates, Citrix role); the sessions' store and store server on the session record | StoreFront's own logs are not read; a sign-in with no launch after it points here or at the broker |
| 3. The launch | the ICA launch record: resource, gateway, session GUID; the syslog ICASTART line | the store never returned an ICA file: brokering (the Delivery Controller / DaaS side, not read here) or the client refused it |
| 4. Gateway to VDA | the ICA connection record with the VDA's address and port (2598 or 1494), the gateway's STA bindings on its page, an Uptime monitor on the VDA's port if you add one | a launch with no connection: the STA ticket, or the gateway cannot reach the VDA on that port |
| 5. Logon on the VDA | the logon's breakdown on Session performance: profile load, group policy and each extension with its outcome, logon scripts, printers, pre-shell, from the VDA's own event logs, once per logon; the server page's live event log, GPO and sessions folds as the operator; the reboot-pending and service state | a connection with no session: the VDA-side logon (profile, policy, a service down); a slow one names its phase; the server page's verdict says what is wrong on the box |
| 6. The session itself | round trip per minute against 150 ms, bytes each way, CPU / memory / disk per session, reconnect count, the close code | a session that exists but is slow: see the diagnostics page for reading both sides |
What you need in place
- AppFlow from every gateway to the Vantage server, bound at Request and ICA Request (the Configure a NetScaler dialog does both, and says which gateway refused).
- Syslog from the appliances to the Vantage receiver (pushed from the appliance's page in one step), so LOGIN / ICASTART / ICAEND lines and the appliance's reasons are held here.
- The Vantage agent on each VDA and StoreFront server, with the Citrix role detected or set.
- Optionally an Uptime monitor on each VDA's 2598 and on StoreFront's 443, so reachability is a fact rather than a guess.
Example findings
Each of these happened on a real estate (DTR's own lab, or a customer's, anonymised) and is the reason the product reads what it reads. The corrective action is what was done.
| What the user saw | What the records showed | What was done |
|---|---|---|
| Launches succeeded, but the HDX per-session metrics never appeared | AppFlow announced the metric templates without data: the policy was bound at Request only (the appliance's own bind line confirmed it) | bound the policy at ICA Request as well; the metrics arrived on the next launch. Configure a NetScaler binds both since then |
| A Windows 11 VDI showed "no session signed in" while a user was clearly on it | quser, run as the agent's service account, listed nobody; the process list showed explorer in session 1; the ICA counter instance was named console (user) | the agent names the session from the counter instance when nothing else does; the page says which source named it |
| "The logon attempt failed" from Remote Desktop clients through an RD Gateway, nothing in the gateway's log | the IIS log showed the RPC proxy answering 302 after a successful sign-in: a site-level HTTP redirect inherited into /rpc | one Set-WebConfigurationProperty on /rpc; the RD Gateway fold now watches the redirect and the proxy's answers |
| Gateway sign-ins failing for real users during an attack | 278 failures from one address against 52 accounts in the gateway syslog | the Identity threat pass blocked the address on the appliance through a pattern set and a responder policy; the appliance's "already in use" answer on the second pass is treated as the state wanted |
| Session performance said the round trip was not read | "The specified instance is not present": the ICA Session counter set was there with no instance, which is what a VDA answers while no ICA connection is up | nothing to fix; the page now says so instead of asking for a counter list |
Corrective actions from the page
Where the management modules are licensed, the fix is one confirmed, audited action away: block or unblock an address on the gateways; bind the AppFlow or STA policy; enable a virtual server; reboot the VDA, sign a user off or end a process by delegation as yourself; open the VDA's screen (XenServer) or the guest's screen (Hyper-V) from the console. Reading is the default; every change names who did it and what the system answered.
Checked against build b429, 2026-09-21. Where a statement is product knowledge rather than a tested capture, it says so.