Troubleshooting failed Citrix launches
A launch is a chain of stages across the gateway, the store, the VDA and the session. Vantage holds a record for most of them and says at which stage the evidence stops.
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 |
Launch analysis: a verdict per attempt
Since b435 the chain is read for you. On the Launch analysis page under Data analytics, pick who is on now (the list is who is signed in at that moment: an open ICA session on a gateway, a session on a VDA, or both, each tagged) or type any name for an earlier or failed launch, choose the window, and Analyze gathers the six stages from the records held on your server: the gateways' syslog (LOGIN, LOGIN_FAILED with the appliance's reason, ICASTART / ICAEND), the HDX Insight records, the StoreFront servers' collector state and findings, and the VDA's sessions, samples and analysed logons. The verdict names the stage and the side, with the evidence and what would settle it; each side's records are behind a fold. Nothing is contacted: the analysis reads what has already arrived.
One attempt at a time. A day's window can hold a failed launch and a good one, and a single verdict over both is unreadable: whichever rule matched first spoke for all of them. The page now finds each launch in the window and lists them newest first — an HDX launch record and the gateway's ICA connection for the same launch are the two sides of one attempt, joined when they are within ninety seconds of each other and named on the row, while either alone is still an attempt and is said to be one. Pick one and everything narrows to it; the rows the window held and the pick left out are counted, never dropped silently.
Four questions, answered apart. The outcome (completed, failed, or unconfirmed), the timing (how long it took, measured — or “unavailable” with the reason, never a zero and never a silence that reads as fast), the coverage (which of the six stages were observed for this attempt and why the rest were not) and the explanation. That split is a correctness fix, not a layout: the older verdict ended “nothing in the records held here explains a delay” whether or not a Windows logon had ever been analysed — a green tick standing for evidence nobody read. A launch that completed with no logon analysed now reads unknown and says the speed was not measured, because a successful launch and an unexplained delay can coexist.
- the gateway's syslog: 1 failed sign-in (External authentication server denied access) before the one that worked
- HDX Insight: the launch of Win11 VDI through gw1, store /Citrix/Store; the ICA connection to VDA01 over EDT
- the VDA's logon analysis: the logon took 1 min 35 s, of which Group Policy was 1 min 10 s (profile load 5.6 s, printers 0.7 s, pre-shell 2.4 s)
- the phase named, on the VDA: Group Policy's extensions and scripts
The verdict above comes from the live demo, which runs on synthetic data; the rules are product knowledge about how a Citrix launch works, and the page says so as an estimate.
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 b547, 2026-09-30. Where a statement is product knowledge rather than a tested capture, it says so.