Documented walkthroughs
The live demo shows the pages; these show the work. Each walkthrough names the problem, what was collected, the finding with its evidence, the corrective action, and whether the data came from production, a lab or the demo's synthetic set.
Walkthroughs
8
each with the problem, the data, the finding, the fix
Data
stated
lab, a customer's estate anonymised, or the demo's synthetic set
Live demo
synthetic
generic data built from the product's own routes; no customer data
Independent tests
invited
none published yet; we will host one
About the data. The live demo runs on a synthetic estate generated through the product's own routes: seven NetScaler pairs, a XenServer pool, a dozen Windows servers, nothing from any customer. The walkthroughs below come from DTR Networks' own lab estate (a NetScaler 14.1 pair, a XenServer pool, Windows servers and a Windows 11 VDI behind a gateway) and from customer estates with names and addresses removed; each says which. Screenshots are the product's real renders on the demo estate unless captioned otherwise.
| The problem | Both nodes of an HA pair reported a software start at 09:20 on a weekday morning, the roles swapped, and service groups were briefly down. Nobody remembered doing anything. |
| Data collected | Both nodes' clocks (stat system Up since and shell uptime), the syslog held on Vantage for the window, the appliance's own audit log, the crash-dump listing, the rotated event logs, the firmware read before and after. |
| The finding, with its evidence | Both nodes' software started within one second of each other with no reboot of either, no core dump, and no CMD_EXECUTED line naming reboot, restart or install in the audit log or the syslog. The verdict: a deliberate restart of the pair, confidence medium, with the note that the command was not typed at the CLI as far as the records reach. |
| Corrective action | None on the appliance; the estimate was accepted. The analysis learned two things from this run: every command with a pipe was refused by the appliance's shell over SSH (removed), and Vantage's own search for restart words had matched itself in the audit log (the verb rule). |
| Where the data came from | DTR's lab pair, NetScaler 14.1, September 2026; the screenshot is the demo's restart scenario |
Click to zoom
| The problem | Users reported occasional sign-in failures on the gateway; the syslog was full of LOGIN_FAILED lines. |
| Data collected | Every AAA / SSLVPN LOGIN_FAILED line from the appliance's syslog, scored per source address: failures, accounts tried, the appliance's Failure_reason, the browser, the gateway virtual server named on the line. |
| The finding, with its evidence | 278 failures from one address against 52 accounts in an hour, aimed at one gateway, with private ranges and the appliances' own addresses never scored. Report-only mode showed what would be blocked before enforcement was switched on. |
| Corrective action | Enforcement on for that appliance: a pattern set and a responder policy (DROP) bound on every gateway, the address added as a member; the appliance's CLI shown as written. The first enforcing pass stopped at "Policy name already in use" (the policy the first pass had made); the product now treats that answer as the state wanted, and logs a repeated refusal once. |
| Where the data came from | DTR's lab gateway, September 2026; the screenshot is the demo's Identity threat page |
Click to zoom
| The problem | After Configure a NetScaler, sign-ins, launches and sessions decoded, but the per-session round trip and bandwidth never appeared. |
| Data collected | The AppFlow capture file (every datagram kept, framed with its time and source), the decoder's template inventory per exporter, the appliance's show vpn vserver output the user pasted. |
| The finding, with its evidence | The metric templates (271, 272, 287) were announced by the appliance but never carried data; the policy was bound at Request only. Bound at ICA Request as well, the next launch produced a start record, a metric record a minute and a close record. The record layout itself was then found to differ from template order on a busier customer pair (fixed-length fields first, then the variable ones), which had made a few rows read as 1970 and random bytes; that is why unreadable records are now counted and shown rather than displayed. |
| Corrective action | Configure a NetScaler binds at both bind points and says which gateway refused; Decode the kept capture re-reads the file after a decoder change. |
| Where the data came from | DTR's lab gateway and a Windows 11 VDI, September 2026 |
Click to zoom
| The problem | Session performance for a Windows 11 VDA showed no session while an ICA launch to it was open and the user was working. |
| Data collected | The agent's quser output and exit code, the Terminal Services API's answer, WMI's console user, the process list per session, the VDA's ICA counter instance names; three captures from the box, elevated and not. |
| The finding, with its evidence | quser prints the signed-in user's own session but, run as the agent's non-administrator service account, listed nobody; explorer was running in session 1; the ICA counter instance was named console (dainius.fokas), which is the VDA naming each instance "session (user)". |
| Corrective action | The agent names the session from the counter instance when no other source does, tags the source on the row, and the page says which source answered instead of showing an empty table. |
| Where the data came from | DTR's lab, a Windows 11 VDI behind the gateway, September 2026 |
Click to zoom
| The problem | The Windows identity threat fold read "0 failed sign-ins from 0 addresses" while the Security log held hundreds of 4625 events in the same minutes. |
| Data collected | Three 4625 events as XML, the IIS log for the day (6,156 failed login.aspx POSTs), the gateway's own operational log (events 200, 300, 312 captured), the collector's state file. |
| The finding, with its evidence | Every 4625 was logged by w3wp.exe (the RD Web form's own password check) with IpAddress "-", so nothing could be scored by address; the collector had also scored one cycle's IIS rows against a ten-in-an-hour threshold, so no address ever reached it. |
| Corrective action | The form's rows are kept for the window and scored over it; a w3wp 4625 without an address is joined to the nearest unclaimed failed POST within 5 seconds, which carries the address and the account; the gateway's connection events serve as address hints. Blocks followed on the next report. |
| Where the data came from | A customer's RD Web Access and RD Gateway host, September 2026, anonymised |
Click to zoom
| The problem | Remote Desktop clients through the gateway failed after a correct password; the gateway's log recorded nothing. |
| Data collected | The IIS log's rpcproxy.dll rows by status, the site's and /rpc's HTTP redirect settings through WebAdministration, the services, the listeners on 443 and 3388, the certificate bound to 0.0.0.0:443. |
| The finding, with its evidence | A site-level HTTP redirect with childOnly off had been inherited into /rpc, so the RPC proxy answered 302 after the sign-in succeeded; the clients read that as a failed logon. |
| Corrective action | One Set-WebConfigurationProperty on /rpc, which the fold now prints as the fix. The RD Gateway role is watched from then on: the redirect as configured, the proxy's answers in the last hour, the services, the listeners and the certificate. |
| Where the data came from | A customer's RD Gateway, September 2026, anonymised |
| The problem | The user switched the portal VM off; every External Uptime target stayed green. |
| Data collected | The dashboard's monitor loop, the publish payload, the portal's push handler. |
| The finding, with its evidence | Every check still ran on the dashboard's own server; the portal only re-published the results, so "from outside" was a label, not a fact. |
| Corrective action | The publish now carries each external target's check settings to the portal, the portal checks them from the internet on the cadence and hands the results back, and every row says who checked it and from which public address. A stale outside result is a grey dot with the minutes, never the last colour. |
| Where the data came from | DTR's own portal VM and dashboard, September 2026 |
Click to zoom
| The problem | A UDP monitor on port 53 read 100 % up with a 5,012 ms latency while every TCP monitor beside it recorded the day's outages. |
| Data collected | The monitor's probe and reply handling. |
| The finding, with its evidence | The check sent an empty datagram and counted silence as up ("open|filtered"), with the timeout as its latency. |
| Corrective action | A real question where the port has one (a DNS query on 53, an NTP request on 123) and the answer read; silence is down and says which probe went unanswered. Held against local responders in the test suite. |
| Where the data came from | DTR's lab, an ADNS target, September 2026 |
Click to zoom
Independent validation
No independent test or customer case study of DTR Vantage has been published yet, and this page does not pretend otherwise. If you run a Citrix estate and would test the session-performance and launch-troubleshooting claims on this page against your own environment, we will provide the licence, help with the setup, and publish your write-up here unedited, including where it says the product fell short. A reviewer's or an MSP's comparison against the tools on the comparison page is welcome on the same terms.
Walkthroughs current as of build b429, 2026-09-21. Where a statement is product knowledge rather than a tested capture, it says so.