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
15
three outcomes, twelve repairs; 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
In production
at customers
a multi-site NetScaler estate of 12+ pairs among them; no write-up published yet
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. Vantage runs in customers' environments today, among them a multi-site NetScaler estate of more than a dozen HA pairs on 14.1 and hosting estates with RD Gateway and RD Web Access; that is where the product meets a scale the lab does not have, and where many of the repairs below came from. Screenshots are the product's real renders on the demo estate unless captioned otherwise.
Outcomes: diagnosed on the page, fixed, verified on the page
Three incidents where a shipped build placed the problem, the operator took one step, and the same page showed the result. The twelve walkthroughs under them are the repairs those incidents and others drove into the product.
| The problem | Users saw occasional sign-in failures on the gateway while one address sprayed accounts through it. |
| What the page said | The Identity threat page: 278 failed sign-ins from one address against 52 accounts in the hour, aimed at one gateway virtual server, with the appliance's own failure reason on each; in report-only mode the page said what would be blocked. |
| The step taken | Enforcement switched on for that appliance from the same page. |
| Verified by | The page's Configuration changes made: the appliance's own answers to the pattern set, the responder policy (DROP), the binding on the gateway and the address added as a member, each row with the appliance's words; the Blocked addresses fold listing the address with its block time. |
| Where the data came from | DTR's lab gateway (NetScaler 14.1), September 2026 |
| The problem | Sign-ins, launches and sessions decoded on the HDX Insight page, but no round trip or bandwidth per session. |
| What the page said | What the appliance sends: the metric templates announced by the appliance with no data records, and the note naming the policy's bind point as the thing to check. |
| The step taken | Configure a NetScaler run again, which binds the AppFlow policy at ICA Request as well as Request (and says which gateway refused). |
| Verified by | The next launch produced the session's start record, a metric record a minute (round trip against the 150 ms line, bytes each way) and the close record on the ICA sessions table. |
| Where the data came from | DTR's lab gateway and a Windows 11 VDI, September 2026 |
| The problem | Session performance listed no session for the VDA while an ICA launch to it was open. |
| What the page said | The page's line under the tiles: the session list could not be read on that host (quser's own words as the agent's service account), the process list showed one session, and the counter instances it saw were listed. |
| The step taken | Update agents from the dashboard (the agent names the session from the VDA's own counter instance when no other source does). |
| Verified by | The session appeared on the next report, named from the counters, with a 67 ms round trip and bandwidth both ways; the page tags where the name came from. |
| Where the data came from | DTR's lab, a Windows 11 VDI behind the gateway, September 2026 |
Repairs: what the collectors and decoders learned
| 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 first Security posture page on a real estate showed all six servers critical, each reading "Microsoft Defender Antivirus, CrowdStrike Falcon — Microsoft Defender for Endpoint (sensor) stopped". CrowdStrike was running on every one of them and the firewall was on. |
| Data collected | Each server's endpoint services with their state and start mode, Defender's own status (real-time protection, running mode, definition age, tamper protection), the firewall profiles, the threats found in the last thirty days. |
| The finding, with its evidence | The rule scored any installed-and-stopped product critical, and the Defender for Endpoint sensor ships with Windows and stays stopped until the machine is onboarded — so six protected servers were red for the state Windows had put them in, and a page of red says nothing. |
| Corrective action | The question the page answers is now whether something is actively protecting the server: Windows' own services are idle by design while a third-party product is running and are drawn quietly; Defender's own upkeep (definitions, scans, tamper) is judged only while Defender is what protects the box; only a threat found and not cleaned is critical. A separate estate then produced a server whose Defender reported a scan age of 4,294,967,295 — the largest number a 32-bit count can hold, which is how Defender writes an age it has never had. That threw the whole collector, so a protected server read as unread; it is now said as never, which is a finding of its own. |
| Where the data came from | A customer's estate, September 2026, anonymised |
Click to zoom
| 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
| The problem | The first run of the syslog fast path: a test service on a web server behind the appliance, with IIS stopped and started. Every DEVICEDOWN and DEVICEUP arrived twice in the same second, and the page called the first copy superseded, as though a state had been lost. |
| Data collected | The DEVICEDOWN / DEVICEUP lines as the appliance sent them, verbatim, with their sequence numbers; each hint and what became of it; the appliance's own answer over NITRO. |
| The finding, with its evidence | The two copies carried different sequence numbers and different packet engines (0-PPE-0 and 0-PPE-1) from one address: each packet engine logs the event itself, which is normal on an appliance with more than one engine and not a fault. Every DOWN and UP was confirmed by the appliance in its own words, within about two seconds of the line. |
| Corrective action | A second line for the same service saying the same state is folded into the first as a duplicate, with how it came (another engine, received twice, another address); only the opposite state is superseded. The page shows one row per event. |
| Where the data came from | DTR's lab pair, NetScaler 14.1, September 2026 |
Click to zoom
| The problem | A service enabled from the topology's right-click went green, then orange (disabled) for a few seconds, then green again. |
| Data collected | When each reading was taken against when it was stored: the Enable's own read-back over NITRO, and the poll the Disable a minute earlier had started. |
| The finding, with its evidence | That poll read the service while it was still disabled, finished after the Enable had been read back, and was stamped with the time it finished, so it counted as the newer reading and was drawn over the Enable until the next poll landed. |
| Corrective action | A poll's states now carry the time it began reading, and a confirmation is stamped when it asks; a reading taken before a change is older than the change, in the store and in the drawing. The read-back also waits for the appliance to settle rather than recording a passing state. |
| Where the data came from | DTR's lab pair, NetScaler 14.1, September 2026 |
Click to zoom
| The problem | Support bundle analysis of both nodes flagged a Perl script in a web folder, written on a day nothing else was written, as the shape a planted web shell takes; the customer had applied an update that day. |
| Data collected | Both nodes' bundles (the file listings with their times, the logs), and the customer's own system backups from after the date. |
| The finding, with its evidence | The same script, the same size, written in the same minute on both nodes, and byte-identical in the backups to the firmware's EULA-theme upgrade script, which the earlier bundles listed with the build's own date. Rewritten by something that ran on both nodes, not planted. The analysis had judged each node alone and had no way to be told of the update. |
| Corrective action | A script the HA peer holds identically, written within two minutes, is a warning naming both nodes and both times (never cleared, since a synchronised folder would carry a shell too); and Changes you made lets the operator give the window of a change, which puts a file written inside it down to that change, said as resting on their word. |
| Where the data came from | A customer's HA pair, NetScaler 14.1, September 2026, anonymised; the screenshot is a synthetic bundle |
Click to zoom
Independent validation
Vantage runs in production at customers, but no customer has published a write-up of it and no independent test has been published, 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 b547, 2026-09-30. Where a statement is product knowledge rather than a tested capture, it says so.