Documentation

Vantage is self-hosted monitoring and management for Citrix estates: Citrix session-performance monitoring and failed-launch troubleshooting from VDA agent telemetry and from NetScaler HDX Insight (AppFlow) and syslog analytics, Windows Server diagnostics, and management consoles for NetScaler, XenServer and Hyper-V, on one Windows server inside your network.

In practice: NetScaler / ADC pairs, XenServer pools, Hyper-V hosts and Windows servers on one dashboard, plus uptime targets, syslog and the analytics the gateways and VDAs can give you, collected on a schedule, shown live, and run entirely on your own server. For a Citrix estate the three views that matter most are Session performance (the VDA side), HDX Insight data (the gateway side) and Troubleshooting a failed launch (the two joined).

NetScalers and XenServer pools are read without agents: Vantage connects out from one Windows server over SSH, NITRO REST and XenAPI, stores what it reads locally, and renders it. Windows servers report through a small PowerShell agent that Vantage deploys from the dashboard and that runs as a least-privilege service account.

Reading is the default. Where you license a management module — NetScaler Configuration, the XenServer Console, the Hyper-V Console, Windows Update — the same pages carry the controls, every change is confirmed in words, and every change is logged with who made it and what the system answered. See Licensing for the module list.

The product tabs

Across the top are the products: XenServer Pools, NetScalers, Uptime, Data analytics and Windows Infrastructure. A tab you have not licensed shows a 🔒 badge. Click one to switch the whole workspace to that product; the left sidebar then shows that product's views.

The sidebar

XenServer, NetScaler and Windows share one shape: a labelled menu of the product's views (Overview, Certificates, Notifications, Analyze, Console, Updates, Security — whichever the product has), and under it, beneath its own heading, a tree of your pools, appliances or servers grouped by category, with a search box. Collapse menu folds the menu up into one row of icons, their names on hover, and the tree takes the room; the choice is kept in your browser for every product. In a short window the menu is that row of icons anyway. Data analytics and Uptime are plain lists of views.

Header tools

The header shows how fresh the data on screen is, a Tasks pill for anything running in the background (reports, deploys, XenServer operations) with Cancel, Refresh, Help (this documentation), Settings (admins), and your name, role and Sign out.

These are two different operations, because what they cost is not the same.

Refresh redraws the screen from data Vantage has already collected. It is instant, and it never opens a connection to an appliance — so it cannot make what you are looking at any newer than the last poll. Next to it is the thing that answers "am I looking at current data": the age of the data on screen. On the NetScaler side that is a range, because a fleet is polled on a rolling schedule.

Polling is the scheduled collection. Operators can force one (Poll now, Rescan, Collect now, depending on the product), and the XenServer console additionally follows the pool's own event stream, so a VM that changes state shows within seconds.

The browser's Back steps through views. Each view you open is a history entry, so Back returns to the previous view (and, inside the fleet console's tab, the console's own Back button does the same).

HA pairs count as one. Vantage reads the full picture from the primary of a pair and probes the standby, so the pair is as fresh as its freshest half. An appliance that did not answer its last poll is named, with the reason, rather than shown with stale numbers.

Three roles, from least to most privileged:

Roles map to Active Directory groups — see Mapping AD groups to roles. Admin-only controls are hidden from other roles on the page and refused on the server.

The landing view for XenServer: a list of pools, problems first, with Cards as the other view (the choice is remembered). Four tiles above it count the pools that need attention, the hosts reachable, the hosts with a current reading, and the findings by severity.

Reading a pool's row

• Health is what the latest report observed, with its reasons on hover; the same rule draws the row, the sidebar and the pool page. A report older than twice the collection interval makes the health Unknown, with what it last said beside it: old evidence is not a clean bill.
• Collection is how complete the evidence is: the hosts with a current reading against every host the report or the console knows, the missing ones named. Missing coverage never makes a pool Warning; it is its own column.
• Host memory used is the physical hosts' memory summed (used over total bytes), read by the console's scan, with the busiest host beside it. Without a management API credential it says so rather than showing a figure.
• Dom0 memory, the load and the system disks are the control domain's: the health check runs in Dom0, so its figures are labelled as Dom0's and never stand for the host. The pool's Dom0 figure is the hosts under pressure (almost no memory free, or swapping).
• Fullest VM storage names the fullest repository, each counted once, shared and local told apart; DVD drives and ISO libraries are never judged as full.
• Physical CPU busy time is XenServer's performance data (RRD), which Vantage does not read yet: it is not shown rather than estimated from a load average.

Click a row to expand it: the pool's problems in a strip, and its hosts side by side (the coordinator tagged, an unreachable host said as such, a host missing from the health report named). With one pool on the page it opens by itself; the rows you open are remembered. Click the pool's name to open its page. Trends draws per-host CPU, memory, disk and load over time from the readings kept at every collection.

The page is the pool, in tabs: Overview (hosts online, VMs running, storage used over the writable repositories, host capacity, the pool's configuration and its findings), Hosts, VMs, Storage, Networks, Activity (alerts, kept as history rather than current health) and Settings. The verdict and its reasons sit above them, and each reason's "show" opens the tab and the row it names. The head says how fresh the inventory and the health report each are; Rescan, New VM, Collect now and an Actions menu are the toolbar.

The page refreshes in place: a rescan changes only what differs, so an open fold, a scroll position or a half-typed box survives it.

Updates shows the pool's update readiness and, with the console licensed, applies updates host by host (see XenServer Console).

Under Manage pools you enroll and remove pools and set their category.

Enrolling a pool

1. Add the pool's coordinator address and a label.
2. The dashboard offers to install its public key into the coordinator's authorized_keys. You enter the root password once; it is used only to install the key and is then discarded — never written anywhere. From then on the health check runs over that key.
3. For the console, add a XenAPI credential. It is stored encrypted with a key that never leaves the server, and the coordinator's certificate is pinned by its SHA-256 the first time it is used. A changed certificate is refused until an administrator accepts it by hand; a credential never reaches a certificate Vantage has not seen.

Collecting on demand

Operators and admins see Collect now and Rescan pools. Normal collection runs on the configured interval; the console's inventory is also rescanned whenever the pool's event stream reports a change, and every few minutes as a safety net.

Licensed as XenServer Console. XenCenter's pages and menus, in the browser. The sidebar tree lists every pool's hosts, VMs, templates, storage repositories and networks, kept live; right-click anything for its actions, or open its page.

Virtual machines

Start, shut down, reboot, suspend, resume, migrate, snapshot, revert, copy, convert to template, delete — each a confirmation in words and then a task whose outcome is the pool's own answer. VM properties is one dialog for name, description, folder, tags, vCPUs, memory, home server, HA priority, boot order, and the disk and NIC tables with their actions. Changes are judged against the live record and only the fields that differ are written; shape changes (vCPUs, memory) are refused on a running VM before anything is written.

The console screen

The Console tab is the VM's screen over VNC, relayed by the Vantage server through the pool's pinned session. The toolbar has Connect, Ctrl+Alt+Del, Full screen, an Options menu (fit, resize the guest, mouse capture, USB tablet), Send text (types text into the guest as keystrokes), Fixes (named command recipes typed line by line — the built-in Windows network reset, DNS flush, WinRM enable and others, plus your own from Settings), Detach to a window of its own, and, for admins, Take over when someone else is on the same screen. The status line says which pointer mode the guest reports and whether the mouse is captured.

Beside the VNC screen, RDP in the browser opens the guest's own desktop over Remote Desktop to its first IPv4 address (the same browser RDP console the Hyper-V page uses), and SSH opens a terminal to a host or a guest with an address, for administrators. Through the cloud console the VNC screen, RDP and SSH are carried as streams, so they work there as they do on site.

Wizards and pool operations

New VM from a template (disks, network, ISO or install URL, start after create), New storage (NFS, iSCSI, SMB, ISO libraries; attach an existing repository), Add VLAN network, network and virtual-interface properties, host restart toolstack, SSH enable / disable, licence assignment, and Install updates: the pool syncs, readiness is checked, then each host is evacuated, updated, rebooted or its toolstack restarted as the update asks, and re-enabled, coordinator first, every step on the task log, Cancel between steps.

The tree

The tree finds and selects: a view selector (Infrastructure, or one kind of object across the pools), the power state as the icon (green running, grey powered off, amber suspended), health as a separate badge from the pool's verdict, favourites at the top, and the keyboard (arrows, Home / End, Enter). Health that could not be read draws no badge and the footer says so.

VM settings

A VM's settings open with its state beside its name, in tabs: General, Compute & placement, Storage and Networking. The foot counts the unsaved changes and Apply changes stays off until there is one; it saves General and Compute & placement. vCPUs and memory are changed only with the VM shut down — a running VM shows them with the reason, and nothing is kept for later. Disk and network actions are made when you confirm each one: a disk's actions are one menu with Delete disk… set apart (administrators), and its confirmation names the disk and says its data is permanently deleted. Tags are chips; the MAC and IP carry a copy button.

With more than a handful of appliances the list is the navigation. The labelled menu opens the Overview (every appliance as a card or a row), Appliance management (enrolment, collection, access, categories, pausing, bulk actions, and the event channels), Certificates (every SSL certificate on every appliance, expiry first; the red count is what has expired or expires within 30 days), Notifications, Analyze (analyses across several pairs) and Security posture (the gateways' half). The tree under it groups appliances by category; HA pairs are one entry. Type in the search box to narrow it by name or address.

Above the appliance list is a row of cards for the whole fleet: appliances reporting, and the up / down / partial split for VIPs, service groups, services, content switches, gateways and GSLB. Every non-zero figure opens the objects it counted, across every appliance, with the box each one lives on; Copy list puts it on the clipboard for a change ticket. The counts and the lists are built by the same code on the server, deliberately, so a card never says "6 down" over a list of five.

The Detail table sorts by any column — address, name, state, version, last poll, the object counts — inside each category group. Each row carries its unread critical events. Build report opens the reports dialog for the fleet.

All appliances together (aggregate)

Every virtual server, content switch, gateway, service group and service across the fleet in one list. A row opens exactly what the appliance's own list shows for it — Drill-down, History (30d), Path and Config, read from that row's appliance — and a right-click (or its ⋯) offers the same menu: Properties to edit it, Enable, Disable, Bind / unbind, Capture & analyze and Save config, decided by what that appliance allows. What the list knows beyond the appliance's tree — a content switch's targets followed down, a gateway's bindings resolved across appliances — stays under the tree.

The appliance page

An appliance's page is one view. Its head names the appliance and its address, and under them each node of an HA pair on a line of its own: the node's address, its role (and its configuration sync when that is not healthy), when its software started and how long its operating system has been up. Beside them are Build report (opened on the appliance, it offers first the appliance’s documentation: the topology diagram and every tile’s list, as HTML, PDF or Word — for an imported ns.conf, which is never polled, that is the report), Poll now and ⋮ More, which holds the appliance's doors (Open GUI, SSH, Syslog, NITRO access) and the configuration's actions (Enable / disable, Bind / unbind, Save config, Changes log, Re-read the save state). The configuration bar, the health strip, the topology, the tiles and the right-hand column (Needs attention and Recent activity; All activity opens the whole list down the column, in place) follow.

Everything on the appliance is also in the sidebar tree: each appliance unfolds, as a XenServer pool does, into its sections — Application delivery (virtual servers, content switching, gateways, authentication), Backend services (service groups, services, members, monitors), Policies & actions (folded until you open it), Network (interfaces, VLANs, routes, ARP, IP addresses, traffic paths), Security (certificates) and Appliance (resources, events, global settings) — each kind with an icon, its Total and a Down column ("8 down", or a dash; a disabled object is not down; a certificate says expired or expiring). A section folds up to one line naming what it holds. Find an object or section at the top of the branch narrows the sections and names the objects that match. What is not configured is listed under Not configured (N) at the foot.

The top of the page is kept small so the topology has the room: the head is one line, the health strip one short row (High availability, the virtual servers, the certificates and a Resources card with CPU, memory, the fullest disk and the interfaces from this node's last poll — a figure the poll did not carry reads "unavailable", never 0), and the topology is as tall as its diagram, never so tall that the first row of tiles leaves the screen (a bigger diagram opens at its top and scrolls inside the frame at full size). Every page you open starts at the top. Its head folds to a single row (the title, Overview / Traffic flow and a one-line summary of what is drawn); the diagram stays, and the fold button brings the zoom and the buttons back. An appliance opened afresh starts folded.

Reading the topology

A traffic object's whole box is its state: green up, orange disabled (an administrator switched it off; never drawn as down), red down, amber partly up, grey not known. The badge keeps the kind's colour, and network and policy objects keep their kind's colour. A legend at the top left names the colours and only the kinds drawn; it stays put while you pan and folds to one line. Enable and Disable on a menu are one or the other: the one that does not fit the object's state is greyed with the reason. A change made from here is read back from the appliance and the appliance polled at once, so the box turns colour without waiting for the schedule.

Right-click either appliance box (the pair is one unit) for HA configuration — both nodes as the last poll reports them and, over NITRO, every HA field as the appliance returns it (read-only) — and, for administrators with NetScaler Configuration, Force failover, which names who hands the Primary role to whom and is refused in words on a standalone appliance, a split pair or a node that is not plainly Primary and Secondary.

Tabs

The tab row sits directly above the topology, with the Overview (the page itself) first. An item picked anywhere — the sidebar, a tile, a finding — opens in the tab on screen, full width; from the Overview it opens in the tab you used last, or in a first tab when there is none. So clicking from item to item does not pile up tabs. + opens an empty tab: it lists what is on the appliance, and the next item you pick fills it. An item already open in another tab shows that tab. A tab's × closes it and shows the one to its left; Close all closes every tab but the Overview. Your tabs are your own and they persist: they are kept on the server under your sign-in, so they come back after a reload and in another browser, and opening another appliance shows that appliance's items in the same tabs (a kind it does not have says so in its tab). The top of the page stays put on every tab.

Right-click an object in the topology for the same menu its row has; a service group member takes Enable member and Disable member there and in a service group's drill-down (named on the appliance by the server it is bound under). Properties from the topology opens the editor in the right-hand column beside the graph, with a close (×) in its head and Cancel and Apply at its foot, both kept in view however long the editor is; in theater the information box itself becomes the editor. The topology card switches between Overview (the topology) and Traffic flow: which servers this appliance reaches and over which path (a PBR, a route or a connected subnet), with a GSLB tab of its own, drawn from the last poll and the running configuration stored with it (the same document a support bundle's analysis draws; nothing is contacted, and an imported configuration draws from its configuration alone). Expand and Theater work on either; Open in a new tab and Download give the flow full size or as a file, and the Overview has the same two: a copy of the topology exactly as drawn (the members shown, your layout), one interactive document you can pan, zoom and search, where a click on an object shows its details and what it binds; your choice is kept in your browser. Switching the appliance's tabs, or a module's tab, starts at the top of the page. Hide tiles folds the tile grid away for you (kept in your browser) and says how many are hidden and how many have something down.

Poll now polls this appliance only: its HA pair, the primary collected and the peer probed. It waits for the poll to finish, then reads the page again in place. The tabs, the list open, the zoom, the graph's position and the object picked all stay, and the outcome is said beside the button: how long the poll took, or why it failed in the poll's own words. Refresh reads the page again the same way without polling.

Opening an appliance gives you the pair's health and HA state, a live topology diagram, and category tiles for virtual servers, content switches, gateways, authentication (AAA) servers, service groups, services, GSLB, certificates, network (interfaces, VLANs, routes), high availability and resources — each with up / down / partial counts you can expand. Tiles can be arranged and the arrangement is remembered.

Two clocks per node

The head's HA line prints, for both nodes, when the software started and how long the operating system has been up. A software start well after the boot is a restart of the software alone (a warm restart, an upgrade in place, a crash the watchdog recovered) and is marked as such. Resource history — CPU, memory, disks, interfaces — is kept per node at every poll and probe, so both halves of a pair have history.

Right-click a row

Every object row has a menu: Properties opens the object as the appliance reports it (read-only for operators; editable with NetScaler Configuration).

The appliance's own GUI and SSH

⋮ More holds Open GUI and SSH in the browser. SSH in the browser is a terminal in a window of the page, the Vantage server being the SSH client: the appliance's stored sign-in is tried first and, when it is refused, the window asks you (the password goes for that sign-in only and is kept nowhere). The host key is pinned on first use and a changed one is refused before any credential is sent. Administrators only: a shell is the whole appliance. Through the management console, Open GUI opens the appliance's own GUI as a tab of the licensing app on an address made for that console session and appliance alone (see the cloud management console).

NITRO access

Each appliance can be read over NITRO REST as well as SSH. Test & enable on the appliance's page (or Enable NITRO on selected in the Appliances table) probes the API, records the certificate's SHA-256, and from then on refuses a changed certificate. Monitoring uses a read-only account; configuration uses a separate one.

The Analyze tile on an appliance's page, and the Analyze view on the rail for several pairs at once, answer questions as a verdict with a confidence, the evidence, what happened afterwards, and what would settle it. Every verdict says plainly that it is an estimate from the records held here, not a fact the appliance stated.

Capture & analyze

Where a restart or a failover is not the question but a connection is, Trace analysis in the Analyze panel (and Capture & analyze… on a virtual server, gateway, service or member's menu, and on the topology) takes a packet trace on the appliance itself: started over NITRO with the configuration account, scoped to the object you picked, stopped by Vantage's own clock, read back file by file, deleted from the appliance, and analysed. The verdict is about that target, with the client side and the server side told apart, and keeps three lists apart: what the packets show, possible causes (never stated as established), and what the capture could not see. A trace already running on the appliance is never touched; SSL session keys are not collected; the capture is kept here for an hour for download, then removed, and the job says so. Administrators, with NetScaler Configuration licensed.

Licensed as NetScaler Configuration. Writes go over NITRO, the appliance's own object model — the calls its GUI makes — so a firmware update moves the object model, not text parsers.

The configuration account

A separate read-write account, set under Appliance management, must differ from the monitoring account, is never returned by any read, and is used only for explicit admin actions, never for collection. Nothing can be written without NITRO enabled and the appliance's certificate pinned.

What you can do

• From a tile row's menu: Enable, Disable, Bind / unbind a service or service group, Save config, and Properties — an editor drawn from the object as NITRO returns it, in the GUI's sections (Basic settings, Method, Persistence, Protection, Profiles, Push, Authentication, Traffic settings, SSL), with every binding list the GUI's page has: certificates and SSL, services, policies of every family, authentication, gateway settings (STA, intranet applications, bookmarks, portal theme, EULA), monitors, members. Bind, unbind, edit a binding's priority, open a bound policy and its action.
• Enable and Disable are one or the other: the one that does not fit the object's state is greyed out, with the reason on hover (the last reading, or a change made from here that the reading has not caught up with yet), and does nothing. A disabled object is orange — its dot and bar in the topology, DISABLED in the lists — never the red of DOWN. After a change from here the appliance is polled at once (a service is also read back over NITRO), so the page follows within seconds.
• In the topology every traffic object's box is its state — green up, orange disabled, red down, amber partly up, grey not known — and its kind is the badge (VIP, CS, GW gateway, AAA authentication server, SG service group, SVC service, SVR a group member). A legend pinned at the graph's top-left says so, naming only the kinds drawn; it folds to one line and stays folded.
• Right-click the appliance (either node of a pair) for HA configuration — every HA node setting as the appliance reports it now over NITRO (operators, where NITRO is on), beside the last poll's show ha node — and, for administrators with the configuration module, Force failover: asked first, naming who hands the Primary role to whom and warning when configuration sync is not healthy; offered only when the last reading shows one Primary and one Secondary (never on a standalone appliance or a split pair). The appliance may still refuse it, in its own words; the pair is polled at once so the roles follow.
• Policies, actions and profiles are editors of their own.
• Apply sends only the fields that differ from a fresh read. A field the reference does not allow is refused in words.
• Certificate upload, gateway sign-in blocking (Identity threat), AppFlow export setup (HDX Insight) and Migrate config live on the same licence.

Every change is a row in the configuration log (who, what, the appliance's words) and an audit line. The Configuration bar on the appliance's page says whether the config is saved.

Migrate configuration

Migrate… on Appliance management replays one appliance's configuration, or an imported ns.conf, onto a new appliance line by line; the new appliance's management address, hostname, HA and licensing are never touched, and nothing runs before you review the plan. The certificate and key files the SSL lines name come from the old appliance, or — for an imported config, which has no appliance behind it — from a folder: one on your computer, or one the Vantage server reads (a share). Only the files the plan names are read, matched by name in any case, and a missing one is named before anything is applied. Lines carrying a value the old appliance encrypted with its own key (-kek, e.g. an SNMPv3 user) are a group of their own, off by default: the new appliance cannot decrypt them, so create those with the secret typed in. When a line is refused, Exclude it and continue with the rest applies the lines after it.

Appliance management

One list: a row per appliance, an HA pair as one row, with its connection (address and how it signs in), collection (polled, event-driven or paused, and the cadence), access (SSH, NITRO and the configuration account), the last successful poll and the actions; Version and Category are columns to add. Search and filters narrow it (state, category, access). Add appliance is a split button (one appliance, or import a config); Configuration tools holds Migrate and the NetScaler service account; Categories manages them. Editing opens in a side panel beside the list with Cancel, Test connection and Save changes always in view; Authorize SSH key shows only for key sign-in. Tick rows and a bar offers what fits them: poll, enable NITRO, Pause or Resume collection (a pair pauses as one unit, and a paused appliance keeps its history and says it is paused), categories and remove. The XenServer pool list is unchanged.

Event channels

The Event channels tab of Appliance management (operators and above) shows what the appliances actually send, the evidence for detecting a state change in seconds rather than at the next poll. It has two sub-tabs. Syslog counts what the store already holds per sending address, as a table with View events per row, by event name: the state lines (DEVICEDOWN / DEVICEUP), the commands run (CMD_EXECUTED: every command, reads included, so a poll's own show commands are counted there too; not only configuration changes), the lines no name was parsed from, and any enrolled appliance that sent nothing; a name opens its newest lines, whole; the state and command names are always shown, and +N more opens the rest. SNMP traps is a diagnostic capture only (nothing is alerted from it), off until an administrator starts it: it listens on UDP 162 (or the port given), counts each trap per source by its version and identity, and keeps the file for download. The v1/v2c community string is masked before anything is written, and an SNMPv3 trap sent with privacy is said to be encrypted, never decoded. The census and the capture change nothing and contact no appliance.

Crashes and sign-in commands, as they arrive. The support bundle's rules for a crashing daemon are also read on the syslog as it arrives: the watchdog (pitboss) reaching a daemon's restart limit or declaring a system failure, a daemon such as the authentication daemon nsaaad exiting three times within five minutes, and a sign-in line whose user name carries shell commands (a download saved and run). Each becomes one notification on the appliance as soon as its lines settle, the crash critical; the section lists them with their lines, says nothing arrived apart from arrived-but-no-finding, and counts lines from an address no enrolled appliance has without notifying anything. Whether an appliance forwards pitboss's lines (they are written to /var/log/messages, not ns.log) depends on its syslog action; the counts here say. Every poll also lists the crash-dump folders (/var/core, /var/crash) on both nodes, so a new dump raises a notification even when no line arrived.

Fast path. A DEVICEDOWN or DEVICEUP line naming a service (the shape copied from a real appliance) is a hint: it is never taken as the state and never raises an alert, since a syslog datagram can be lost or forged. It makes Vantage ask the appliance at once: that one service over NITRO where NITRO is on, otherwise a poll of that appliance (at most once a minute; a burst of lines waits a few seconds so one read covers them). The answer is what is stored and alerted on, so a service going down shows in seconds instead of at the next scheduled poll, and a line the answer contradicts moves nothing. The section lists every hint with the address it came from, what the line said, what confirmed it and how long that took; the same line arriving twice is counted as a duplicate, costs no second read and is shown as one line under the row it duplicates, with the reason said: an appliance with more than one packet engine logs each event once per engine (normal, each line naming its engine), otherwise one event received twice or logged twice; and counts the lines it did not act on: another shape of line (a service group member's or a virtual server's has not been captured yet), an address no enrolled appliance has, a service the poll does not record (among them the appliance's own devices named without cfg_, such as a service named internal, which are never matched to a configured service). Refreshing the picture. A confirmed change of state, or a command line that changed the configuration (add, rm, set, bind, enable and the like with Status Success; the poll's own show and stat lines never), makes Vantage poll that appliance again, so its lists, tiles, the virtual servers' and groups' own states and the topology follow within about a minute, an object added or removed included; a burst of commands waits until a few seconds pass without another, and the same once-a-minute limit applies. The section lists each of those polls with why it was asked (the command's first words and who ran it, never an option's value) and what came of it. What the fast path learned is drawn at once, before that poll: a state confirmed over NITRO since the last reading becomes the service's state in the lists and the topology, marked confirmed with the time, and a syslog line still being confirmed is shown beside the state it does not replace ("syslog says DOWN · confirming", a dashed ring on the topology node), and it goes the moment a reading confirms it, whether or not the state moved; a line sent before a reading already taken (the read-back after an Enable or Disable) is answered by that reading and not shown at all; the virtual servers and groups bound to it are the appliance's own reading and follow at the re-poll. A state line is read within a fraction of a second of arriving and confirmed about a second later. An open appliance page takes a newer reading by itself, checking every three seconds: when an object was added or removed or its state moved it is redrawn in place (the tabs, the list, the zoom and the object picked all kept) and the line beside Poll now says what changed; otherwise only the reading's time moves. Never while a dialog, a menu, the editor or a field being typed in is open: it waits for them. A service bound to no virtual server is drawn in the topology too, hung off the appliance. It is on by default where the NetScaler and syslog modules are licensed; an administrator can switch it off there.

Refused sign-ins

When an appliance refuses the service account's sign-in (a wrong or expired password, a locked account, a key the appliance no longer accepts), Vantage counts it; a timeout or an unreachable appliance is never counted, since nothing was refused. Each refusal is a warning on the appliance's Activity ("Sign-in refused on X (1 of 2)"). After two refusals in a row, automatic polling of that node is held, so a directory account is not locked out by every poll trying again, and a critical notification says so; the appliance list's Collection column reads "Held: sign-in refused" with the next try and Try now. A held node is tried again once an hour; while it is still refused it stays held, and the first sign-in that works ends the hold and says polling resumed. The other node of an HA pair is polled as usual. Poll now, Poll selected, Try now and saving the appliance's credentials sign in at once, held or not. Settings > Collection sets the number of refusals (1 to 10), how often a held node is tried (15 minutes to a day) and can switch the hold off.

Event-driven polling

An appliance whose syslog arrives here, with its service state changes in it, is watched from the syslog instead of by the five-minute poll: a light states poll (the virtual servers', services', service groups' and gateways' states, the HA roles and the resources, laid over the last full reading) reconciles it every 15 minutes, and the full poll (bindings, certificates, the network, the running config) runs every hour. A states poll that finds an object added or removed runs the full poll at once. An appliance counts as heard when a syslog line from it arrived in the last 30 minutes AND a DEVICEDOWN or DEVICEUP line from it has ever reached the store; otherwise it is polled every 5 minutes as before, and says why. One that goes quiet is written as a notification ("No syslog heard from …", and again when it is heard) and goes back to the five-minute poll until it is: silence is never shown as health. The appliance page says under its reading how it is polled, and a states reading says the bindings, certificates and network are from the full poll and when that was; the network panel's time is the full poll's. Event channels lists every appliance with how it is polled, why, when its syslog was last heard, its last poll and the next. Settings > Collection sets the cadences (states 1 to 30 minutes: it bounds how long a lost line can hide a change; full 5 minutes to a day; not heard after 5 to 240 minutes) and can switch it off; a per-appliance poll interval sets both its states poll and its five-minute fallback.

The Certificates view lists every certificate bound on every appliance with its expiry, expired first, then within 30, 60 and 90 days. The rail badge counts what has expired or expires within 30 days. The same appears per appliance on its Certificates tile, where a new certificate can be uploaded with the Configuration licence.

Automate certificate renewal… on this view opens a new certificate workflow in Automation, aimed at the appliance or category the view is narrowed to.

Operations reports

Build a report across one or more appliances for a date window: executive summary, incidents, uptime, resources and trends, certificates, HA and GSLB, interfaces, syslog activity, inventory, and Enabled virtual servers & backends — every enabled load-balancing and content-switching virtual server from the last poll, with the service groups (each member's address and state), services and content-switch targets behind it; the disabled ones are named and left out, and a virtual server with nothing bound says so. Each member and service also shows its source (SNIP): the address the appliance uses to reach it, worked out from its SNIPs, routes, modes and PBRs the way the Traffic paths view does, with how it was chosen and, where the appliance's own connection table shows a different source, that address beside it. With USIP on it reads the client's address; a poll with no IP table says the source is not known; where net profiles are configured the report says a bound one overrides it. A report runs as a background job — the dialog counts the seconds and the Tasks pill offers the download even if you closed the dialog — so a month across a busy fleet finishes instead of timing out. Export as HTML or PDF; footers carry your branding. The HTML report is interactive, as the Windows report is: a long table opens on its top 10 with Show all, every column sorts on a click (an incident's severity by weight, critical first), a long table has its own search over every row, each section folds on its heading and a line of contents under the head links to them. In the virtual servers & backends table a virtual server and its backends move, fold and match together, so a search for a member's address shows the whole virtual server. The syslog section holds every configuration change and event name in the HTML; the PDF prints the first 25 of each and says how many more the HTML holds. A copy without its script (an e-mail body) shows every row. Gateway sign-in attacks (with NetScaler Identity Threat licensed) puts the gateways' failed sign-ins in the report on the Security page's own attack map — the same places, colours and line to your servers' place — over the longest of 48, 24 or 6 hours the period covers, with a row per address (where it is, the failures, the accounts it tried, which appliances, and whether it is blocked and enforced); a store that could not be read, no gateway sign-in line held at all, and lines held with no failing address are each said apart. The PDF lists the top 25 addresses and points at the HTML for the map.

Documentation export

Generate a standalone document for an appliance — topology diagram plus full text and tables — as HTML or PDF, from a live collection or an imported ns.conf. An optional AI pass adds prose summaries and findings.

Config compare and migration

Compare the running configuration between two appliances to spot drift, side by side. Migrate config copies an old appliance's configuration onto a new one, every command verbatim from the source's running config in its own order, with the identity commands (NSIP, hostname, HA node table, RPC passwords, licensing) blocked and named, and the whole plan shown before anything runs.

Each Windows server runs a small PowerShell agent as a Windows service. It runs as a shared, least-privilege service account — deliberately not an administrator, so that a password stored for monitoring is not a password worth stealing — and reports to Vantage over HTTPS on the collection interval, each report signed with a per-server secret.

The secret is shown once, at enrolment or redeploy, and never returned by any read. Rotating it keeps a grace window on the previous one so a server mid-update keeps reporting. A server whose report is late is marked not reporting; nothing on its page pretends to be current.

Two cadences. OS health, Windows Update and the event-log rules run every cycle; the applications sweep, Citrix, RD Gateway, Hyper-V and security posture collectors run on the slow cadence (Settings → Collection → Agent slow collectors every, 5 minutes by default) and carry their last result in between, so no fold goes empty. Event-log rules are one query per log; the Security log is read incrementally; the service runs at below-normal priority.

What the agent collects: OS health and reboot state, services, disks, event log alerts by rule, certificates, IIS sites and bindings, RDS, Citrix roles (StoreFront, Cloud Connector, Delivery Controller, VDA, licence server — detected, or set per server), Hyper-V guests, running applications with CPU and IO, failed sign-ins, the RD Gateway role's health (the /rpc redirect, the RPC proxy's answers, services, listeners, the certificate) where the gateway service exists, and for VDAs the per-session performance. It also reports the security posture: which endpoint protection products are installed and whether their services are running, Defender's own status (real-time protection, running mode, how old the definitions are, the last scans, tamper protection) where it can be read, the firewall profiles, and any threat detection that was not cleaned. Some collectors need a right the account does not have by default (the Security log, Hyper-V); the deploy grants exactly those, and the page says when a collector is blind and why.

Add server asks for the server's name and your own credentials. Vantage connects over WinRM as you, enables remoting on the target if it is off, creates the service account's rights, installs the agent, starts it, and waits for the first report. Your password is typed per action, held in memory for the deploy, handed to the child process over stdin, and never stored; the audit line records your user name and "credential not stored".

If remote management is not on, the deploy turns it on rather than printing instructions: it runs Enable-PSRemoting inside its own session first, and where WinRM itself is refusing it tries WMI, then an SMB session to the target's admin share (writing the enable script and asking the target's own scheduler to run it as SYSTEM), then the service control manager over that same session. No password is ever put on a command line: each rung rides the session's credential. When all four are shut the job says what each way in answered, and the target's own log of the attempt is printed.

Each deploy is a job with a live log on the Agents view or the server's page; a refusal (WinRM not listening, a rejected credential, a target that cannot be reached) is said in Windows' own words with the fix.

Update agents redeploys the shipped agent build to every server whose agent is older, four servers at a time; each server's lines are written into the job as one block when it ends, and the job waits for each new service's first report (the check that used to be a validation cycle run as the administrator). From agent ag_b045 the agents also update themselves: when an update of this dashboard ships a newer agent, the dashboard tells each agent at once (from ag_b046 every agent keeps one connection open to the dashboard while it waits between reports, and the dashboard answers on it the moment there is a new version; nothing listens on your servers), offering the new files signed with that server's own secret; the agent downloads them, checks their size and SHA-256, and replaces itself and restarts. It waits while anything is being installed on its server (Windows Installer, Windows updates, DISM, a deploy, or an update install Vantage has scheduled within the next 15 minutes), and the Agents view's Auto-update column says it is waiting and why. A new agent that does not reach a report within three starts, or fails three cycles in a row, puts the old files back. The update scan script and nssm.exe still come with Update agents, and agents older than ag_b045 need one Update agents first. You can turn this off in Settings > Collection (Agents update themselves). Every update package carries DTR Networks' agent launcher (DTRVantageAgent.exe), signed by DTR Networks when the package is published (a package whose launcher could not be signed leaves it out); the deploy runs the agent in it, so Task Manager lists it as Vantage Agent instead of Windows PowerShell. It only does so when Windows reports the launcher's signature as valid; otherwise the agent stays in powershell.exe, and the deploy log says which it is and why. Automatic updates replace the agent's scripts only, so moving a server that runs in powershell.exe into the launcher takes one deploy: the Agent fold's Runs in line says which program each agent runs in (agent ag_b047 and later), and the Windows Infrastructure page names the servers still in powershell.exe, with a button that deploys to exactly those. Every step of a deploy says how long it took, files already on the server unchanged are not sent again, and the agent restarts itself if it grows past 512 MB. The Agents view shows each server's build against the one shipped, which are older, and which are blind to a log.

Agentless: Inventory reads a server over WinRM without the agent (hardware, OS, roles, software, IIS configuration), on demand as you by delegation or on a schedule as the server's own identity.

Four questions, answered apart

A server can be healthy and unpatched, or connected with half its collectors refused. So every Windows server answers four questions separately: OS health (the machine: volumes, memory, event-log alerts, the Citrix and RD Gateway services; Unknown when it is not reporting, since its last reading is not now), maintenance (a reboot pending, updates pending, and Patch status unknown when the update scan failed or never ran — never "Up to date"), security (the posture and sign-in collectors) and coverage (what could be read: Current, Partial when a source was refused or cannot be seen, Stale, Awaiting first report). The one verdict pill stays for the badges and reports; the columns say what it is made of.

Editing several servers at once

Tick servers and choose Edit: every field starts on Leave as it is with what the selection holds now beside it ("on for 4 of 15"). Collectors are switched on or off, never set as a list, so nothing a server had and the form did not name is switched off. Only what differs is written, a server the change would leave with no collector is refused on its own while the others go, and the result names every server with what changed or why not. Notes stay per server.

Licensed as Hyper-V Console. A guest's page and a host's page are live reads from the host, as you by delegation (or through the cloud console, as the Windows account you give once for the tab): state, generation, processors, memory and its dynamic range, checkpoints, adapters, disks, DVD drives, firmware, integration services; the host's folders, switches, adapters, live migration and NUMA settings. A guest's page is laid out as a XenServer VM's: one VM actions menu in the head and the tabs General, Console and Checkpoints. A running guest opens on its Console tab.

The page draws at once: every guest's last good read is held on the Vantage server for half an hour (for that account only) and shown while it is read again, and opening one guest reads the host's other guests in the background, together, through one session kept open to the host for ten idle minutes (your password is still never stored; the session is closed when idle).

Actions (power, checkpoints, rename, settings, adapters, disks, switches, new VM, remove VM, host settings) are admin, confirmed in words, and write only what differs from the live object. Right-click a host or guest in the sidebar tree for the same menu.

The guest's screen

Hyper-V exposes a guest's screen only as RDP on the host's port 2179 (VMConnect). The Console tab draws it in the browser: the browser itself speaks RDP (a WebAssembly client) and the Vantage server only opens the connection to the host and carries the bytes, so the screen is native RDP, not a stream of pictures. The target is Vantage's own record of the guest, never an address the browser names. Your password goes to the host inside RDP's own sign-in, encrypted by the browser for the host: Vantage carries it and cannot read it. The toolbar is the XenServer console's: Connect, Disconnect, Ctrl+Alt+Del, the Windows key, Full screen, Send text, Fixes, Options (an Enhanced session where the host's policy and the guest allow it; Basic by default), and the .rdp file for your own client. The account and password are asked once and used for the tab; a session that connected and then dropped reconnects once on its own. The picture fits the place evenly, never stretched.

The same browser console opens a Windows server's desktop (Remote Desktop on the server's bar) and a XenServer VM's guest (RDP in the browser on its console toolbar). It is the one Hyper-V console: the Myrtille gateway earlier builds offered beside it is gone (b604), and an installed one is left alone.

Licensed as Windows Update; reading the pending list needs only Windows Infrastructure. A scheduled task the deploy registers (as SYSTEM, since the Windows Update Agent refuses a search to the agent's least-privilege account) scans each server on your cadence (Settings → Windows Update) and the agent reports the result: pending updates with KB, severity, category and size, the source (WSUS, Windows Update for Business, Microsoft Update), reboot state, and the install history. A server whose scan task is missing or broken says so, and Register the scan task… on the bar registers it on the servers chosen, one at a time with progress, the outcome per server in Windows' own words. When Task Scheduler itself holds tasks back (a pending reboot, for example) the row says the task is queued rather than running.

Three lists: Servers (one row each; the Pending and Last run cells say apart nothing pending, not scanned yet, agent too old, stale, not reporting, scan failed and an install that failed, in its own words), Updates (every update pending across the servers, one row each with the servers waiting for it, grouped by severity with critical first, by category or by server, searchable; an update that failed before on a server says so) and History (every KB the servers' history names, with each server's attempts newest first and what a failure code usually means). A server whose updates are not known is named with why, never left out.

Tick servers, or updates (an update ticked is ticked on every server waiting for it), and Install now or Schedule (a start time, a stagger between servers, an optional reboot after each). The dialogs list what the chosen servers are waiting for and offer every pending update, security and critical only, critical only, or the ones you tick. Installs are started as you by delegation, one server at a time, and run on each server as a SYSTEM scheduled task, the way the scan does: the Windows Update Agent refuses to install from a remote session, even for an administrator. Vantage writes the install script into a folder only SYSTEM and Administrators may write (C:\ProgramData\DTR Vantage\wuinstall), registers the one-off task “Vantage update install”, starts it, waits up to 25 minutes for its result and removes the task. The outcome is written per server with each update’s own result and code, and a reboot is never done by the install. Your account must be an administrator of the server to register the task. An install still running after 25 minutes is said as still running, and one Windows holds at Queued names Task Scheduler (a pending reboot is the first thing to clear); the next scan shows what was installed. A run where every update failed counts as a failed run, and one still going is drawn as still running with its words, never as ok. Through the cloud console, name the administrator account Vantage places the task as (the updates still install as SYSTEM). Both dialogs open expanded.

Licensed as Device lockdown (presumes nothing on its own). Windows machines enrolled over the internet and kept on a signed lockdown policy, so a user cannot install software you have not approved. It is a separate component from the monitoring agent: that agent stays a least-privilege service account, while the lockdown component runs as SYSTEM — a scheduled task “Vantage Device”, at start-up and every 15 minutes — only on machines you enrol. A non-administrator cannot stop it. On most sites every user is a local administrator, so by default the Windows Installer and application-control blocks reach administrators too — that is what stops them installing without taking their administrator rights away. Removing those rights (the Local administrators setting) is the stronger step, since the blocks are machine settings a knowledgeable administrator could switch off.

Enrolling a machine

Make a site key on the Devices view (it names a site; it enrols any number of machines, or a set number, and lasts until you revoke it or for a set time). Download its installer: it carries the key, this installation's ID and the portal address, so Install.cmd needs nothing typed — run it as an administrator, or deploy it with Group Policy or your RMM tool (it runs as SYSTEM there). The machine makes its own key in the machine key store (never exported; there is no password for a device), enrols through the portal's manage address — the same route the remote console uses, so nothing is opened inbound — and signs every check-in with that key. Between its full check-ins the machine holds a long-poll open to the dashboard, so a policy change, an approved install or a new script reaches it within seconds rather than at the 15-minute tick; the 15-minute cadence stays as the backstop, and an older portal simply falls back to it. Treat the installer like a password; revoke the key and it stops enrolling, while machines already enrolled stay. The remote console must be switched on under Settings → License, Updates & Manage for any of it to reach the dashboard.

The policy

Each setting is off, report only (read and judged, nothing changed — start here) or enforce (Defender also has audit): Local administrators (only the accounts you name stay, the built-in Administrator always kept; enforcing with nobody named is refused so a machine is never locked out), Windows Installer (users cannot run unapproved .msi, and the setting that lets a user's install run elevated is off), Programs on USB drives (nothing runs from a removable drive), Microsoft Defender hardening (the attack surface reduction rules, potentially unwanted apps blocked, SmartScreen set to block), and Application control — an allow-list with two engines. Software Restriction Policies (the default; off or enforce, no report mode): only programs in Windows and Program Files, the all-users Start menu (so admin shortcuts such as Server Manager keep working), the agent's own folder, and any extra folders you name, run; administrators too by default (turn off Block administrators to skip them), and it works on Windows Pro and up. The agent always whitelists its own folder, so an enforced allow-list can never lock the agent out of Constrained Language Mode, and if a policy from an older build ever did, the agent relaxes it on its own with no reboot. SRP is a machine setting a knowledgeable administrator could switch off. App Control for Business (WDAC) is the stronger engine: a signed policy the machine enforces from the kernel, so a local administrator cannot remove it without the signed policy itself — it locks administrators down without taking them out of the Administrators group. WDAC has a report-only (audit) mode (start there: it logs what would be blocked and blocks nothing), and an enforce mode. In audit mode each machine reports what the policy would block; the Devices view's What audit mode is blocking panel aggregates it across the fleet into publishers and files, and an administrator Approves the software you trust — an approved publisher (which covers its later versions) or file (by its exact hash) becomes an allow rule baked into the policy, so a machine can move to enforce without breaking it. A user cannot approve anything; only an administrator does, from the dashboard. WDAC loads unsigned by default (no certificate needed; it loads on every supported Windows, and the lockdown still removes standard users' local-admin rights so they cannot remove it); a signed policy is tamper-resistant but a self-signed certificate will not load at boot on a Secure Boot machine unless it is enrolled in UEFI or a boot-trusted PKI. The policy's signed .cip is built on the Windows dashboard with your own code-signing certificate and never leaves as readable bytes; until that certificate is in place the Devices view says so and offers nothing. Setting it up: under the WDAC engine there is a signing-certificate panel (administrators) that lists the code-signing certificates in the dashboard's LocalMachine\My store — pick one, or paste its thumbprint — and a Test signing button that builds and signs a throwaway policy and tells you plainly if anything is missing (the certificate, its private key, or the Code Integrity cmdlets). The policy is signed with signtool, which is bundled with the dashboard, so there is nothing to install on any dashboard. If a build failed before the certificate was in place, Rebuild policy builds it again without changing the policy, and the dashboard rebuilds a failed policy on its own when the service restarts (so applying an update that fixes signing heals it). You do not need a certificate authority: the panel's Create a self-signed certificate button makes a code-signing certificate in the dashboard's store in one click and selects it, because WDAC trusts whatever certificate the policy is built with and embeds that same certificate in the policy as the only one allowed to replace it — public trust and a CA are irrelevant. (You may instead pick a certificate issued by your own CA from a Code Signing template; it still need not be publicly trusted.) Each dashboard uses its own certificate; a private key is never shared between dashboards or sent anywhere. The private key stays on the dashboard; grant the Vantage service account read access to it. On Windows 11 and Server 2022+ it applies with no reboot; on Server 2019 (and 1809) it is written as the single legacy policy and needs one reboot to take effect. The allow-list is signer-based on every supported Windows: programs are allowed by their publisher or exact file hash (approved from audit), never by folder path (WDAC file-path rules are a 1903+ feature that Server 2019 refuses to build). The policy is signed here with a key that never leaves the server; the machine checks that signature before it applies the policy and before it applies its last good copy while offline, so it stays locked down with no connection. Every setting reports back, machine by machine: compliant, changed to comply, not compliant (report mode), not applicable (for example Defender in passive mode beside another antivirus — never read as "no protection"), could not be read, or paused.

On the machine

An enrolled machine shows a Vantage icon in the notification area (the tray) so the user can see protection is running, and a Vantage entry in the Start menu. Either opens a small status window that reads what the dashboard set — which protections are on, whether installs are allowed right now, and the user's own requests and where they stand. It only reads; it changes nothing.

Self-service installs

Under the policy you turn self-service on or off and choose whether a reason is required on every request, so each install is documented. With application control enforcing the user does not have to do anything first: when Windows blocks a program, they are prompted to ask for it, the request pre-filled with what they just tried to run. They can also open a request themselves from the tray icon or the status window.

Installing something legitimate

Two ways, and both leave Defender's rules and the administrators list in place. An administrator can Allow installs on one machine for a few hours (a signed grant naming that machine): it lifts the installer and USB blocks for the window and puts them back on its own.

Or the user asks — prompted automatically when a program is blocked, or from the tray icon or the status window. They type what they need and why, and read you the Request ID it shows. The request appears on the Devices view's Install requests card, and an operator or an administrator Approves it (or Denies it, in which case the user gets nothing and nothing changes on the machine). If the machine is online it lifts the blocks on its own within seconds (it holds a long-poll open between check-ins). If it cannot reach the dashboard, approval shows a short code to read to the user — or use Unlock by phone and type the Request ID to get the same code — and the machine checks that code offline, with nothing to contact and no clock to sync, then opens the install window for as long as the policy's window says. The code is an HMAC of a secret only that machine and the dashboard hold, is never written to a log, and is good only for that one request; a request older than a day cannot be approved.

The Devices view lists every machine with a column per setting (the gap on hover; a row opens its history), the install requests waiting, the policy editor, and the site keys. Not built yet: signing in to Windows through Vantage. (A report-only allow-list is the WDAC engine's audit mode.)

Licensed as Syslog. Vantage runs a syslog receiver on the standard port (the installer opens the firewall rule). The Messages view lists what arrives with severity and source, searchable, each message shown whole (as text: a message that carries markup is shown, never drawn); retention is set under Settings → Data retention. From a NetScaler's page an admin can push the syslog configuration to the appliance in one step.

Filters, which combine: a search, the sending appliance, the event, the user and the severity, and on a second row Time (the last 15 minutes, hour, 6 hours, day, week or 30 days, or a Custom From / To in this server's clock), Module (the line's event module, from the newest lines), an IP address anywhere in the line (the address parsed out of it, the sender, or the text), text a line must not contain, and configuration changes only. Reset clears them all. A search over the whole log with no time set says it may be slow.

A notification's from the syslog link opens this view on the exact message it was raised from: that appliance's lines around its time, the message highlighted. Search the whole log instead widens it.

The same store feeds the identity threat rules, the restart analysis and the syslog section of reports.

One page for one question: what is protecting each thing, and what is being thrown at it. It is reached from three rails and shows the half that rail owns — the NetScaler rail the gateways, the Windows rail the servers, Data analytics both. The sign-in protection is licensed as two modules (NetScaler Identity Threat and Windows Identity Threat); the servers' endpoint protection comes with Windows Infrastructure.

Endpoint protection (Windows servers)

Whether anything is actually protecting a server is a different question from whether something is installed. The agent reports what the box says about itself: the endpoint products it recognises by service name and whether each is running, Defender's own status (real-time protection, running mode, definition age, the last scans, tamper protection), the firewall profiles, and any threat found and not cleaned.

The page opens on the issues: one row per rule, with the servers it lands on under it, why it matters, where the setting lives when the fix is not a command, and the command once when every affected server takes the same one. The Servers chip beside it is the same data as one row per server, with the sign-in figures in the same table. The rules the page applies, which are the agent's:

• A server that could not be asked is never drawn as protected. The refusal is quoted in Windows' own words, and the verdict line carries the coverage beside it — “read on 11 of 12 server(s) — 1 not read, which is not a pass”.
• There is no percentage score, deliberately. A figure over an estate with a server unread counts a machine nobody asked as a pass, and the weights that would make one mean something are not grounded in a real estate yet. The verdict is a word: Critical, Needs attention, Meets the baseline, Not enough read.
• Windows stands its own services down on purpose. Defender and the Defender for Endpoint sensor idle beside a running third-party product is not a fault; the page says which is doing the job. A product a person installed, stopped while something else protects, is still a finding.
• Only a threat found and not cleaned is critical — an observation, not a setting. A firewall profile off is a warning that says a deliberate reason is possible; definition age is judged only while Defender is what protects the box.
• An age Defender has never had is said as never, not as a number and not as silence: a server that has never run a full scan reports the largest number a 32-bit count can hold.

Where the agent's own account is refused, an operator can read the same facts over WinRM as themselves from the server's fold; it stores the facts, not a verdict, says whose eyes they were, and writes nothing. If nothing has been reported at all, the page says which of four things it is: the collector ran and failed (with its words), the agent is older than the build that reads the posture, the agent is not reporting, or the slow cadence has not come round yet.

Gateways

Where the attacks come from: the gateways' card carries the same attack map as the Windows Security page — the same places, colours, country labels and line to your servers' place — over the last 6, 24 or 48 hours of the gateway sign-in lines held here (pick the range above the map). Each address is coloured by what the gateways did with it: signed in after failing, met the rule but not held, held and dropped on every appliance (blocked and enforced), held but not written everywhere (report only, or refused on an appliance: blocked, not enforced), or watching. Your servers' place is one setting for both maps, set from either. Where the gateways authenticate with SAML, the appliance never sees the password (the identity provider checks it), so there are no failed sign-ins to map — Vantage reads the running configuration, says so on the card and in the first question, and the marks instead show the addresses the appliances dropped by the block list (a “dropped by the block list” colour in the legend), which is the real inbound-attack signal on a SAML estate.

Every minute Vantage scores the failed gateway sign-ins in the appliances' syslog per source address: failures, accounts tried, the appliance's reason, the browser, and the gateway they were aimed at. The rule (failures, different accounts, the window, the quiet hours before an address is unblocked) is set under Settings → Sign-in protection, or with Change on this page, and every appliance and, for the Windows half, every agent follows the one rule; by default ten failures or three accounts in an hour is an attack, on the gateways also ten requests blocked by the appliance's Application Firewall from one address in that hour (an nFactor gateway's injected sign-ins -- a username that is a shell command -- leave no client address on any sign-in line, only on the firewall's APPFW_SCHEMA_VALUE_INCORRECT blocks of the same requests, which is where the guard reads it since b814; an ordinary client trips that check now and then, so it is a threshold, never one block), on the gateways also a SAML sign-in answer carried in the address — a SAMLResponse holding a <Response> on the URL, which the SAML sign-in profile forbids, so no identity provider sends one (one by default, 0 switches it off; a LogoutResponse by redirect is ordinary single logout and never counts), and on the Windows servers also one account tried from five addresses in that hour (every one of them is blocked; 0 switches that part off); private ranges, your allow list and the appliances' own addresses are never blocked. The rule judges each window on its own: on the Security page an address over a 24-hour range is said to have met the rule only when one window held enough — the figure beside the total is the most in one window. An Application Firewall finding names the paths it blocked, busiest first; the query (a SAML message, a token) is never printed. In report only mode the page shows what would be blocked. With enforcement switched on (per appliance, needs NetScaler Configuration) each appliance holds exactly the block list in an ipv4 data set behind one responder DROP policy whose binding follows a per-appliance scope — global (every virtual server), the gateways, or chosen virtual servers — set on Security › Settings; the data set and the rule are the same either way, only the binding moves, and the list lives on the appliance, so a Vantage restart does not lift it; a large list is synced in batches over several passes, and the CLI it writes is shown as written. A quiet address is unblocked after 24 hours; a block by hand never ages. Where the sources are comes from a local geolocation database (Settings → Geolocation).

The block list on the appliance, and what it drops. The gateway block list is activated by NetScaler enforcement rules of the block list kind (Security › Settings), and it never includes the shared reputation feed. The two halves of the list are turned on by separate rules: a Manual rule pushes the addresses an administrator added by hand, and an Automatic rule pushes the sign-in-attack addresses Vantage learned on its own — so self-learned blocking can be switched on, off and targeted apart from the hand-added list. Each Automatic rule also chooses what it blocks for, from four detections, every one ticked on a new rule and each explained in the editor: repeated failed sign-ins (one address getting the password wrong again and again), password spraying (one address trying many different accounts), Application Firewall blocks (requests the appliance's own firewall blocked: scanners, injection probes, forged sign-in forms, and an attacker whose address is on no sign-in line) and forged SAML sign-ins (a SAML response sent in the address, which no identity provider does). Vantage records which of these it learned each address for, and an appliance blocks an address only when an Automatic rule covering that appliance blocks for one of its reasons, so several Automatic rules can each take a different kind of attack on different NetScalers. The thresholds stay one setting for every rule (Settings › Sign-in protection). An address learned before this was recorded is blocked by every Automatic rule until it ages out; the self-learned list shows each address's reasons. (A rule from before this split, with no set chosen, is Manual-only, so self-learned blocking pauses until an Automatic rule is added.) Inside a block-list rule, Block and Remove are staged: the list marks each change not saved (with undo) and nothing is sent until Save rule, which stores the rule and the list together and applies both in one background pass. That pass shows on the Enforcement rules card in words — the rule it is applying, which step it is on (writing the block lists, then the reputation methods), the appliance being written and how far it has got — and in the Tasks list at the top of the page, with Open to come back to the rules. The hand-added addresses are held on each appliance the Manual rule reaches as an ipv4 data set behind its own responder DROP policy bound globally. The self-learned addresses are not written to the appliance at all (since b815): where the Automatic rule reaches, the appliance's own HTTP callout asks Vantage about each client address (/api/netscaler/callout/auto/<address>, with a token and the appliance's name) and drops the ones Vantage answers BLOCK, so a newly learned address is blocked without a change on the box. The callout fails open: if Vantage cannot be reached the request is let through, where the old data set kept blocking. The policy carries its own UNDEF action (NOOP), so this holds whatever the appliance's global set responder param -undefAction says. The appliance can keep each answer for a while (Keep each answer for on the Automatic rule, 60 seconds by default, 0 asks every time), which needs Integrated Caching on the appliance's licence: where the licence lacks it the appliance asks on every request and the page says so; where Vantage is the one switching Integrated Caching on, it binds a global no-cache policy first, while the feature is still off, so nothing but this callout is ever cached (if the appliance refuses that policy the feature is left off), and takes both off with the rule. Where the appliance cannot say whether Integrated Caching is already on, Vantage leaves it alone and the answer is not cached (switching it on blind could start caching the site's own traffic). A new block reaches an appliance within that time, and so does an unblock. An appliance that held the earlier self-learned data set has its policy pointed at the callout and the data set removed on the first pass. Where the callouts reach Vantage (since b817): Vantage answers them on a port of its own, TCP 8095 by default, a small listener that serves the callout addresses and their health check and nothing else — not the sign-in page on 80 or 443 — and removes any cookie or sign-in header before the dashboard sees an ask. The service opens the Windows Firewall rule DTR-Vantage Callout (TCP 8095) on the Domain and Private profiles (for any address on those networks, not only the appliances; a rule Windows refuses is tried again, and the panel says so). The port speaks plain HTTP, so the token the callouts carry crosses the network between the appliances and Vantage as clear text: keep that path on your own network. An installation whose callouts were set to HTTPS on the web server keeps them there until an administrator switches the listener on. At most 64 connections are served at once and each is closed after a minute, so nothing on the network can hold the listener. On each appliance the callouts go through VANTAGE_CALLOUT_VS, a virtual server with no address of its own whose service points at that port and whose HTTP monitor asks the health check every few seconds from the appliance's own address. When the monitor cannot reach the port the virtual server goes DOWN and every callout lets the request through at once instead of waiting out a timeout, and the Callouts column says in red that the appliance cannot reach Vantage's callout port and what to open. Each block rule leaves the callout's own request out (it carries the token), since a callout sent through a virtual server on the appliance is judged by the appliance's global policies again. Nothing is written for port 80. A callout an earlier pass wrote with the address-and-port form keeps working where it is until the appliance's own monitor reaches the new port; only then is it moved onto the virtual server, and until then the Callouts column says it is kept and why. Vantage's own VANTAGE_CALLOUT_VS and its service are left out of the poll, so they never show as one of your virtual servers or raise an UP/DOWN notification. A callout service disabled on the appliance is said as disabled (enable it again), not as a blocked port. The port and the address the appliances use are set in the rule's Vantage callout options: a new port is opened before it is saved (one another program holds is refused in words, and the callouts keep the old one); the web server's ports, the dashboard's own and the download proxy's are refused, and the download proxy cannot be moved onto the callout port. Answering on the web server's port instead is an advanced choice for an installation that cannot open a port of its own. The Manual rule's panel adds and removes the hand-added addresses; the Automatic rule's panel shows the self-learned ones read-only with per-row Unblock. Each Manual rule keeps its own hand-added addresses: an address added inside a rule is pushed only to the appliances that rule covers, and another Manual rule keeps its own list (an address may be on several). Removed in one rule, it stays blocked where another rule holds it; removed from the last, it is unblocked. Each address may carry a note saying what it is (typed with it, or changed with the row's note link), shown in the lists and exported with them. An address blocked on the Block list tab, outside a rule, goes to every Manual rule; one no rule holds any more (its rule deleted) stays listed and is dropped by no appliance until it is added to a rule or removed. On the upgrade to b822 every existing hand-added address is held by every Manual rule, so nothing stops being blocked. A Save is pushed only to the appliances it reaches — those a changed rule covers, before or after the change — and the progress counts only them; the hourly check still looks at every appliance. On Security > Integrations, the reputation databases card lists the self-learned list as a database hosted on this Vantage server and names where the appliances ask it: the callout's TCP port and address, or that the callout listener is not running (with why) or switched off. Its count (and View all) opens every address on the list, newest first, with where it is, why it was blocked, the requests that counted, when it was learned and last seen, and whether the allow list lets it through — searchable, the first 200 shown with Show all, and exported as .txt or .csv; the hand-added list opens the same way. Unblocking stays in the Automatic rule. Each rule row has a View button for a quick read-only look at what is applied on each appliance. A box that ran an earlier single combined set is migrated off it on the first pass. Turning a rule off, rolling it back or deleting it removes its own list's objects (the Manual rule's data set and policy, the Automatic rule's callout, policy and cache policy) and the bindings, and leaves the other list's — no Vantage objects are left behind. The Protection table shows, per appliance, how many addresses are on each list (self-learned / hand-added) and, from the appliance's own responder-policy hit counter, how many requests each list actually dropped (self-learned, hand-added, and the Webroot IP-reputation policy). That counter is a total: it does not carry the client address or which virtual server was hit. Its Callouts column says whether each callout on that appliance is being answered: answered (Vantage counted asks from it in the last 15 minutes), answered from its cache (the appliance used the callout and none went unanswered, no ask reached Vantage in 15 minutes, and the last one is within the time its cache keeps an answer — callouts answered while nothing reaches Vantage for longer than that read FAILING: something else answers at the callout's address, such as a web server redirecting HTTP to HTTPS where the callouts are set to the web server's port, and nothing is blocked), no traffic, first reading, FAILING in red (the appliance counted callouts that got no answer, with its own reason, or Vantage refused the token — those requests were let through; a refused ask names the address it came from, since the appliance's name in the request is not a credential), not on the appliance, or not known. It is judged from the asks Vantage counted from that appliance and the appliance's own counters of answered and unanswered callouts; it never says answered from silence. An address the allow list covers is tagged on the allow list: the guard never blocks it, so it is watched whatever it does, and it never counts as meeting the rule. When the range holds more Application Firewall lines than are read, or lines naming a block that are not in the shape Vantage reads, question 1 says so instead of counting them as nothing. Save on the sign-in rule keeps every setting the form does not carry (drop logging included — from b782 to b814 a Save switched it off).

NetScaler policies (Security › Rules, administrators with NetScaler Configuration): each enforcement engine — the Manual block list, the Automatic block list, Webroot IP reputation and the shared reputation callout — writes one responder policy, and parts of it can be changed: the action (DROP or RESET), the priority and the global bind point (REQ_OVERRIDE runs before a virtual server’s own policies, REQ_DEFAULT after), an extra condition ANDed onto the engine’s own expression (it can only narrow what is dropped: one whose brackets or quotes would let it widen the rule is refused), and for the two callouts what happens while Vantage cannot answer (NOOP lets the request through, as built; RESET or DROP fail closed and the editor says what that costs). Two engines at one priority and bind point are refused. Object names, the data set and the callout stay Vantage’s, so the counters and the teardown still find them, and free-form commands are deliberately not offered. Each row shows the commands it writes; only what differs from the built-in values is stored, and Built-in puts an engine back. The next pass writes a change to the appliances that carry the engine; a changed priority or bind point is unbound and bound again, so for that moment the policy is not bound.

Named policies (b830, same place): make several policies for one engine and let each rule choose one in its editor (Policy). A named policy carries the same parts — action, priority, bind point and, for a callout, what to do while Vantage cannot answer — and says what to block: requests from a listed address that match its conditions. A condition is a URL path (starts with, is, contains, ends with), the query string, the HTTP method, the host name, a request header (by name: is present, contains, is), the user agent or the virtual server’s port; each can be negated, and they are joined all or any. A value may not hold a quote or a backslash, so it cannot end the quoted string it is written into. The conditions are ANDed onto the engine’s own rule, so a policy only narrows which listed addresses’ requests are dropped; a named Webroot policy may also name its own threat categories, and the advanced expression of the built-in policy is there for what the builder cannot say. On each appliance a policy that a rule uses is its own responder policy, named after the engine’s built-in one with _P<n> (for example VANTAGE_BL_MANUAL_POL_P3), bound where the rules choosing it reach, at its own priority; the built-in object is bound only where a rule using the built-in policy reaches; a named object no rule uses there is unbound and removed (what it is bound to is read from the appliance, so this holds after a restart). Which addresses are listed stays the engine’s — one data set, one callout — so two rules on one appliance with different policies narrow the same list differently. Every policy, named or built-in, needs its own priority at its bind point; a policy a rule uses cannot be removed, nor its engine changed. The rule’s command preview shows its chosen policy’s object, expression and binding.

Reputation databases and the IP lookup. Security › Integrations lists Vantage's own two lists first — the self-learned and the hand-added — with how many addresses each holds, how it is enforced and the newest, then the external reputation databases — shown unless Settings > IP reputation databases is switched off (with it off nothing external is pulled or folded into the shared block list). A second switch there, Firewall integrations, is off by default: the firewall section at the foot of Security › Integrations (Sync now and the push cap, UniFi, Other firewalls) is hidden, nothing is sent to a UniFi controller, and none of the external databases' addresses reach the NetScaler data set or the Windows agents; the databases still sync and answer lookups, and Vantage's own lists are enforced by their rules as before (an installation that was already pushing a Block-mode list or had UniFi set up keeps it on after the update). Sync now, how many addresses reputation.db holds and the Push to firewalls cap are in the firewall section at the foot of the page, with UniFi and Other firewalls, shown only with Firewall integrations switched on in Settings. The lookup there can ask all databases or one of them: that database's answer comes first (listed or not, in its own terms; an address the allow list covers is said to be let through), then where the address is and every other list it is on.

What each rule holds and dropped. On the NetScaler Security page the Overview opens with the four answers as one compact strip (the whole answer on hover; Show the full answers for the cards), tiles for the rules (rules on, addresses held, requests dropped, addresses dropped, attack sources), and then one card per enforcement rule: its method, what it covers, how many addresses it holds (a Manual rule its own hand-added addresses, the self-learned rule the learned ones, the reputation callout the shared list; Webroot's database is not counted here), what it dropped in the range and when it last did, and whether it is applied on each appliance it covers (a refusal in the appliance's words). Opening a card lists what that rule dropped: each source address with its note, where it is, how many requests, the VIP it targeted and the appliance that dropped it, then the addresses it holds that dropped nothing in the range. A drop is credited to the rule whose list dropped it on that appliance, at the virtual server the rule names, and for a hand-added address to the Manual rule that holds it. The Attack source investigation shows the VIP hit and the rule that dropped each source. Drops are per address only while drop logging is on; with it off each rule shows the appliance's own counter, without addresses.

Which VIP a blocked address hit (drop logging). To see the client address and the VIP behind a drop, Vantage can bind a log action to each DROP policy (the self-learned and hand-added block lists, Webroot and the reputation callout) so every dropped request writes one syslog line (the source list, the client address, and the address it hit). It is off by default — on a gateway under attack that is a line per dropped packet, a high syslog volume — and turned on by an administrator from the Dropped requests card (it needs NetScaler Configuration to write to an appliance; a refused bind never stops the DROP). With it on, the Dropped requests card on the Security page lists each blocked address, where it is (geolocation), the VIP it hit (resolved to the virtual server's name from the last poll), the list that dropped it, and how many times. Each per-list count in the Protection table's Dropped (policy hits) column is a link: it opens the card narrowed to that appliance (and its HA peer) and that list, with Show every drop to go back; the appliance's own counter is only a number, so drops counted before logging was on cannot be broken down. The card is kept across Vantage restarts and updates (ns_drops.json, written with the syslog position it was counted up to, so nothing is lost or counted twice), says since when it counts, and forgets an address and VIP not hit for 30 days. Those dropped addresses also appear in Attack sources (disposition “Dropped by the block list”, with the VIP in the Evidence column and the detail panel) and as Dropped events in the Event explorer, so the source IPs behind the policy-hit counters can be read there as well as in the card. The hit counters on the Protection table are bare totals; this per-address, per-VIP detail comes only from the drop log, so until it is on (and the log action has bound on a pass) a note above Attack sources says the appliances have dropped N requests but which addresses and VIPs is not yet known. The count is live and resets on a Vantage restart, like the appliance's own counter.

Servers

The agent reads failed sign-ins from the Security log (after the last record seen, never a record twice) and, where RD Web Access is installed, the IIS logs, scores them the same way over the window and blocks attacker addresses on the host's firewall. A 4625 the RD Web form logs without an address (w3wp.exe, IpAddress "-") is joined to the nearest failed login.aspx POST within 5 seconds, which carries the address and the account; on an RD Gateway host the gateway's own connection events serve as address hints; a failure nothing explains is counted "without a source address" and the fold says why it cannot be blocked. A successful sign-in counts as an incident only from an address that had been failing or is blocked; every other external sign-in is a person, listed quietly. A success is named from the nearest 4624 logged by w3wp.exe, and the Windows report's "Sign-ins that got through" table lists them with account, address, location and why. The Windows servers table shows each server's failures, blocks, where they came from and whether the dashboard's rule has been applied by that agent; a row opens the server's Identity threat fold.

Internet-facing web servers

Wherever IIS runs, the agent (ag_b038 or later) reads the server's IIS configuration and each site's web.config, the new lines of each site's IIS log since the last report, the web roots, and the Security log's process starts. Every finding is one of three kinds, never mixed: The card opens folded each time the page is entered, its head saying how many servers it covers, how many need attention and any evidence of compromise; a click opens it, and each server's row opens on its own.

• Evidence of compromise: found on the server. A script in a web root with a web shell's shape (it evaluates what a request sends, loads code from base64, or starts a process with it), and the web worker (w3wp.exe) starting a command shell or reconnaissance tool. Evidence for a person to confirm before anything is removed.
• Suspicious activity: requests in the IIS logs shaped like an attack (path traversal, encoding tricks, SQL, command, script and LDAP/XML injection, web-shell and known exploit paths, hunts for backups, source and keys, unusual methods, scanners by their own user agent, 8.3 short-name enumeration), counted per hour, address and site; and an IIS module Microsoft did not sign. A category seen from outside is raised; one answered 2xx where that matters is critical, because the request may have got what it came for. Seen only from inside, it stays in the table and is not raised.
• Configuration exposure: directory browsing, WebDAV authoring, detailed errors to remote visitors, ASP.NET debug, customErrors Off, remote tracing, ViewState MAC off, a machine key in the file, double escaping allowed, Windows sign-in without Extended Protection, Basic sign-in over plain HTTP, TLS 1.0/1.1 switched on, 8.3 names on every volume, keys and backups left in a web root.

What could not be read comes first, in Windows' words, with the rules it stops: the IIS configuration is administrators-only on most servers, so a refusal there is likely and is never shown as a clean result. The window is 24 hours, 7 days or 30 days; each kind's chip narrows every server to it. The same body is the server page's Web threats fold. A server whose agent is older than ag_b038 has not been asked and is named, never counted as "no web server".

Security (Windows servers): the investigation and the endpoint posture on one page

The Windows rail's Security page is one page for the Windows servers (b629; before it, Security posture and Identity threat were two). It shows what is protecting each server and who is attacking its sign-ins. Tabs: Overview, Servers (the endpoint protection table), Attack sources, Targeted accounts, Blocklist, Web threats (the internet-facing web servers) and Event explorer. A fourth question, is every server protected, comes from the endpoint posture, with the posture's issues as finding cards beside the sign-in ones and two tiles (servers protected, threats left). Without the Windows Identity Threat module the page is the endpoint half alone and says so. Where the attacks come from is a world map on the Overview. Each place an attack came from is a mark, sized by failures and coloured by what was done about it, with a line to your servers. Beside the map, the usernames tried at each place; a mark opens that place's addresses with the accounts each one tried. Places come from geolocation, every source the page lists, the ones remembered from earlier in the range too; a source with no known place is counted, never placed, and the count says how many are internal addresses (which have no place) apart from public ones the database does not know. Your servers are placed from this dashboard's own public address: it asks a what-is-my-address service (api.ipify.org, then ifconfig.me, then icanhazip.com) once, looks the answer up in the geolocation database already on the server, and says the address, its reverse name and the city, as the database's answer rather than proof. That is an outbound call, made only when the Security page is read with no place set by hand, kept six hours; the services see this server's address and nothing else. An administrator can switch it off on the map, or place the servers by hand by clicking the map, which always wins. The map names the countries at the world view, each with how many attacking addresses it holds, and the cities once you zoom in; where names would overlap, the busiest is named and the rest left out (Aa hides them). The map expands over the page (Esc puts it back) and zooms with its buttons, the mouse wheel or a double-click; drag to move it. Its first screen answers the three sign-in questions: are we under attack right now (failed sign-ins in the collectors' current window; “not known” when no feed is current), are our protections stopping it (the addresses that met the rule in the current window and are blocked by a firewall rule that holds them and is enforcing), and is there evidence an account was compromised (a sign-in that succeeded from an address that had been failing; “not looked for” where no server has RD Web Access).

• Timeline: failed and successful sign-ins, new source addresses and block events over the last 6, 12 or 24 hours (a point an hour), 7 days (a point every 6 hours) or 30 days (a point a day), picked above the graph and remembered. Vantage keeps every hour the collectors report for 35 days, so the longer ranges are read from the dashboard, not the agents; an hour no agent reported is drawn as a gap and said in the legend (not kept is not the same as quiet), and before the history begins the graph says so. The totals over the range are under the graph. A click on an hour narrows the sources and accounts to it, within the range those tables cover (the page's own 6, 24 or 48 hours).
• Findings are grouped where the evidence supports it: password spraying (addresses each trying several accounts with few attempts per account, one campaign when they tried the same accounts), sustained attempts against one account, one account tried from many addresses, a block list nothing enforces, a correlation delay, a log not read.
• Attack sources and Targeted accounts are searchable, sortable and paginated; a row opens a side panel with the place and network (from geolocation), first and last seen, the accounts tried or the addresses that tried it, the findings, the block history and the evidence — and, for the gateways, the exact LOGIN / LOGIN_FAILED lines the appliance sent for that address, newest first, so you can read what was found in the syslog without leaving the page (an address blocked only by hand has none, which the panel says apart from a line it could not read). Failure counts are the most one window held, never windows added together.
• Blocking rule: Settings, at the top of the page on every tab, says the rule set for every server (failed sign-ins, different accounts, one account from several addresses, the window, how long a block lasts) and, per server, whether its agent has applied it yet. The rule is judged per window: an address under it in every window but back hour after hour is listed as a repeat offender, one that met it once and is on no block list now (the block aged out, an allow list, report only) as met the rule, not held now. Administrators change it there with Change; the Protection table still says per server whether it is applied. It is the same rule as Settings > General > Sign-in protection.
• Blocklist keeps what is on each server's list apart from what is enforced: an entry is enforced only while the server's firewall rule holds it and is enforcing. Unblock (administrators) asks for a reason, is audited, and rides to the agent at its next report (agent ag_b052 or later); the failures before it no longer count, and the address is blocked again for new ones.
• One block list for every firewall: Vantage keeps one list and every firewall holds it. An address is on it while a Windows server’s own rule or the NetScaler gateway guard blocks it, while its reputation is 40 or more, or while an administrator blocked it by hand; a trusted address never is, and an internal address never is. Every server running Identity threat holds the whole list in its firewall rule from its next report (identity collector it_b018 or later), and the gateways hold it where enforcement is on, so an address that attacks one server is blocked on all of them. Trusting an address takes it off the list everywhere and every server lets it go. The Blocklist tab shows the list (why each address is on it, where it came from, its reputation and how many servers hold it), the addresses watched (reputation 15 to 40) and the trusted ones; Export gives one address a line for another firewall. The switch is on the Security settings page. Reputation is remembered for 90 days: what each server and the gateways saw at their busiest window (never windows added up), the accounts tried, the hours it came back, whether a rule blocked it and whether a sign-in from it got through; it halves every 14 days the address is not seen. The weights are a first reading and every reason is shown.
• The long lists open on their top 10: Attack sources, Targeted accounts, the blocklist and the Vantage block list show their first 10 (the worst first) with Show all; a search, an hour or a finding narrows over every row. Attack sources and the block list can be grouped By country, the busiest first; a country opens its addresses.
• Settings and integrations: the Security page has three tabs at the top: Overview (this page), Settings and Integrations, each a page of its own (also offered by right-clicking Security in the Windows rail); under the tabs one line says the blocking rule, the shared list and the firewall's state. Security settings holds the Windows servers' blocking rule and the shared block list, and points at what is set elsewhere (the NetScaler gateways' rule, geolocation). Security integrations has a card per firewall Vantage keeps the list on; UniFi's lists every rule on the gateway, read only, list by list from the top (the first rule that matches wins), the block list's own rule marked, one made by Vantage said, and an enabled Accept placed before the drop rule flagged. Port forwards are not listed there.
• The UniFi firewall holds the same list: on the Security integrations page, the UniFi card's Set up takes the controller's address (the page UniFi Network opens on), an API key (UniFi Network: Settings > Integrations > Create New API Key) and the site, and Vantage then keeps one IP list on the controller, DTRV_BLOCKED by default, in step with the shared list: written when the list changes (checked every minute) and read back, so the line says what the controller actually holds. Once, by hand, make the rule that uses it: in UniFi Network, Settings > Security > Firewall rules (Internet In / WAN In), a rule with the action Drop whose source is that IP group. The older firewall's rules (a USG, a USG Pro) are read after every sync, and the line says whether one drops the list (rule in place, an Accept rule comes first, covers the gateway only, switched off, does not drop it, or no rule yet). An administrator can click Create the rule: Vantage makes that one rule (Internet In, Drop, source the list, placed first; optionally the same under Internet Local), audited, and never changes or removes any other rule. The API key is stored encrypted and never shown again; the controller's certificate is recorded on first use and a changed one is refused until an administrator forgets it. Vantage writes only the list it created, never one of the same name somebody else made, and a block list that could not be read never empties the controller's list. IPv4 addresses only, at most 1,000; an empty list holds 192.0.2.1 alone, a documentation address no traffic comes from, since UniFi refuses an empty list. Coming next: Cisco Meraki and other firewalls, each as its own card on the Integrations page holding the same one list.
• Event explorer: blocks, unblocks, lockouts and sign-ins the collectors reported. The raw Security and IIS events stay on each server.
• Not collected, and said so: whether a tried username exists, a source's reputation, and the traffic the firewall actually denied.

The blocking rule (how many failed sign-ins, or how many different accounts, block an address, or how many addresses trying one account block them all) is shown and changed in Settings at the top of this page, and also under Settings › General › Sign-in protection; both change the one rule.

Licensed as NetScaler Data Analytics. NetScaler Gateway exports AppFlow (IPFIX) records about sign-ins, launches and ICA sessions; Vantage listens for them (UDP 4739 by default, on by default) and decodes what arrives.

Configure a NetScaler (admin, needs NetScaler Configuration) sets an appliance up to export to Vantage: the collector, action and policy, bound on each gateway you tick at both Request and ICA Request, every step's outcome in the appliance's words.

The Decoded records card shows gateway sign-ins, ICA launches, sessions and ICA sessions — the last with round trip (last, average, worst), bandwidth each way, reconnects and the connection's state, and a chart per session minute by minute. Every row names the appliance that exported it (the exporter's address resolved to the enrolled pair) and the gateway, from the record or from the last poll ("from the poll"). Type a user's name to narrow every table to them on the server, past any row cap; every table opens newest first and any column header sorts. The exporters table says which appliance sent what (a busy node exports from several ports at once, one per packet engine, and templates are held per port), and the raw capture can be downloaded or decoded again.

Unreadable records. A record whose text fields hold control characters or non-UTF-8 bytes, whose time is before 2015 or whose round trip is over ten minutes is counted as unreadable per exporter and template, its first bytes shown under What the appliance sends, and never written as data; the writer purges any such rows an older build stored. The record layout NetScaler uses (every fixed-length field first, then the variable ones, whatever the template's order) was established from a busy customer pair's capture beside the lab's; the docs say so because the earlier walk read multi-record sets wrong.

Retention. The decoded HDX records (sign-ins, launches, sessions, ICA sessions and their minute-by-minute metrics) follow the syslog retention setting under Settings → Syslog (days; 0 keeps forever), pruned hourly on the host; a session is judged by when it was last seen. The raw capture file kept for Download and Decode starts over past a size you set (64 MB by default; 0 lets it grow to a 256 MB stop), since the records are decoded as they arrive. Nothing is relayed anywhere.

Licensed as NetScaler Data Analytics with Windows Infrastructure. Once a server's Citrix role is set to VDA, its agent reads every signed-in session's CPU, memory and disk (two raw process-counter samples a second apart, grouped by session), the ICA round trip and bandwidth from the VDA's own ICA Session counters (matched to the session by the instance name the VDA gives it, session (user)), and the logon duration from the RDS event log (events 21 to 22). The view shows tiles, the sessions across every VDA, and per-user charts over 1 hour to 7 days: sessions, round trip against the 150 ms line, CPU, memory, bandwidth in and out. The gateway's side of each session (sign-in, launch, HDX metrics) sits beside it from HDX Insight, and the Gateway connections section joins the appliances' LOGIN / ICASTART / ICAEND syslog lines by ICA UUID with the destination VDA named.

Who is signed in

The agent runs as a non-administrator, and on a workstation OS quser may list nobody for it. The session list is then built from the Terminal Services API, the console session, the process list (a session with a desktop shell) and the ICA counter instance's own name; each row says which source named it ("named from the counters"). A sample stored without a user is named from the nearest sample of the same session that had one, and the chart says how many readings were filled that way.

Two layers of notes

Everyone gets one plain line per server: the report's age first (red, with "the agent is not reporting; everything below is from that report", when it is late); "No ICA connection was up at that report, so the round trip and bandwidth were not read"; "The session list could not be read on X"; "The session's user could not be named on X"; or the agent build the view needs. Administrators get the diagnostics behind a Details link: the counter set's answer, what quser, the API and WMI each said, the counter instances seen. A counter set that is present with no instance is what a VDA answers while no ICA connection is up; it is said as such, not as a missing set.

Logon duration, broken down

Each logon on a VDA is analysed once, by the agent, on the cycle after its shell started (LocalSessionManager 21 then 22; a reconnect is not a logon): the profile load (User Profile Service 1 to 2), Citrix Profile Management, Group Policy (4001 to 8001) with every client-side extension's time and outcome, the logon scripts, the Winlogon subscribers (FSLogix, WEM, and the rest), printers added, and the pre-shell phase from the Security log's process-creation events where auditing allows, each with the gap since the previous phase; plus Citrix's EUEM record for the Workspace app and VDA startup panels. The Logon duration section on this view draws the picked logon beside the user's average and everyone's over the window, Director's way, then the phase table, the extensions and the logons list; the server's page has a Logon duration fold. Every read is bounded and at most a few logons are analysed per cycle, so a busy VDA's agent is not slowed; a log the agent could not read, an old agent and a queue are said apart from "no logon".

Retention: one row per session per report for 7 days; the logon analyses 30 days. See Troubleshooting a failed launch for reading this view with HDX Insight.

A Citrix launch is a chain: the gateway sign-in, the store, the ICA launch, the gateway's connection to the VDA, the logon on the VDA, the session. Vantage holds a record for each stage it can see; the stage after the last record you find is the suspected point of failure, not a proven one: a record can also be missing because the feed did not arrive (AppFlow not bound on that gateway, an agent not reporting, a window that ends too early), which is why the Launch analysis names the side it could not read before it names a stage.

Reading both sides. The VDA's counters and the gateway's metrics both give a round trip. Both low and the user still waiting: the session's own CPU or disk. The gateway's climbing while the VDA's reads normal or is not read: the path or the connection (reconnects counted, the close code on the row). A VDA session with no gateway connection for that user: they came in another way.

One attempt at a time

A window can hold a failed launch and a good one, so the verdict is about one attempt. The page 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 fall within ninety seconds of each other and named on the row; either alone is still an attempt and is said to be one. Pick one and everything narrows to it, and the rows the pick left out are counted rather than dropped quietly.

Four questions are answered apart: the outcome (completed, failed, 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 stages were observed for this attempt and why the rest were not) and the explanation. A launch that completed with no Windows logon analysed reads unknown and says the speed was not measured: a successful launch and an unexplained delay can coexist.

Launch analysis

Under Data analytics → Launch analysis the chain is read for you. The name box lists who is signed in now — an open ICA session on a gateway, a session on a VDA, or both, each row tagged with the side — and takes any name for an earlier or failed launch; pick the window and press Analyze. The verdict names the stage and the side (the gateway sign-in with the appliance's reason or a blocked address, the store when a sign-in has no launch after it, the VDA when a launch reaches no session, a slow Windows logon with its longest phase, a slow round trip), with the evidence, what would settle it, the six stages as pills, a timeline across the three sides and each side's records behind a fold. Nothing is contacted: it reads the gateways' syslog and HDX records, the StoreFront servers' collector state and the VDAs' sessions and logons already held on the server, and says which side could not be read.

What it needs: AppFlow from every gateway bound at Request and ICA Request (Configure a NetScaler does both), syslog from the appliances to the receiver, the agent on each VDA with the Citrix role VDA.

One model of the three layers Vantage already reads, with provenance on every link. It is a module of its own (Estate map), presumes none of the others, and reads whatever else you have licensed — naming the layers it could not.

What goes in: each appliance's last poll (virtual servers and what they bind, service groups and their members, services, the ARP table), each XenServer pool's last scan (hosts, VMs with their resident host, network interfaces and addresses), the enrolled Windows servers' own addresses, and the Hyper-V collectors' guests. They are joined at the member's address: the address an appliance sends traffic to is the pivot. Nothing is polled and nothing is contacted, so an answer is only as fresh as the last poll, scan and report — which is why every source is listed with when it was read, or the words of the refusal that stopped it.

Ask the map. Pick a thing and ask what would be affected if it went away, or what it rests on. Every affected thing comes back with the number of hops, how sure that path is and what observed each step:

• stated — the product itself said so: a binding on the appliance, XenAPI's resident host, the Hyper-V guest list.
• corroborated — a second observation agrees: the address is a MAC in the appliance's ARP table and that MAC is an interface of that VM.
• joined — matched by address alone. inferred — matched by name, and always said.

An answer's confidence is the weakest hop along its path. Two honesty rules carry the page: a member address nothing here explains stays on it and is counted (“this virtual server has members Vantage cannot place” is itself the finding), and “nothing depends on this” is never said while a source could not be read — the unread sources come first in the answer, in a callout that says so.

Which manufacturer an address belongs to

Every lookup is a dictionary read on your own server. No MAC address is sent to a lookup service: a device identifier is inventory, and a service receiving one also receives your address and the time. The IEEE registry is a public file the operator downloads from Settings → MAC vendor lookup (a plain GET; nothing of your estate goes with it) or uploads by hand; nothing is bundled, because the terms of that file are IEEE's. The longest assignment wins, since a small block inside a large one has a different owner, and four kinds of “no vendor” are said apart: no registry loaded, an address no manufacturer can have assigned (locally administered), a registry loaded with no match, and something that is not an address. Where no registry can cover an address, the hypervisor that made it up is named instead, from the source that reported the machine.

Reachability checks for any target — a URL, host, port or mail server — independent of the other modules. Add a target with its address and check type; the monitor polls on the configured schedule, records up / down transitions and latency, and reports uptime over any window.

Checks: ICMP, TCP, HTTP(S), UDP and SMTP. A UDP check sends a real question where the port has one (a DNS query on 53, an NTP request on 123) and reads the answer; silence is down. An SMTP check holds the mail server's own conversation: the greeting must be 220, EHLO must be answered, and with STARTTLS (the default on 587) or TLS from the start (465) the handshake must complete; what went wrong is said in words (no greeting, STARTTLS not offered, a handshake failure, something that is not SMTP on the port). Uptime data feeds the NetScaler reports when both modules are licensed.

Internal and External

The Uptime sidebar has two views of the one list. Internal is your team's; External is what your company sees from outside. Tick targets and press Move to external (or Move to internal) in the selection bar to move them across; an operator may.

Checked from the internet

An external target is checked by the portal from the internet, not by your server: the publish carries each external target's check settings out and brings the portal's results back, and every row on the External view says who checked it and from which public address ("checked from the internet · from 203.0.113.10"; the Internal view says "checked from this server"). The card's "Checks from outside" line says the state plainly: off, waiting for the first result, the portal not answering, the portal older than the feature, or running with its address. A result that stops arriving is a grey dot with the minutes, never the last colour; the history says which source each stretch came from.

The company's status page

On the External view an administrator switches on Publish to the company portal and sets the cadence (30 s to an hour). The external targets, with their state, latency and 24-hour figure, are then sent to uptime.dtrvantage.com, and the portal serves them at a status link made for this installation: Get the status link asks for it, Copy and Open share it. Nobody signs up; the licence is the credential, and only a licence carrying the Uptime module can publish (the portal refuses otherwise, in words). The link is replaced on a schedule you set on the same card (Rotate the link every 24 h by default; 0 = never); a link replaced on schedule keeps working for an hour and says so, while Rotate link by hand kills the old one at once. Publishing is off by default; it is a timed contact with the portal made only after an administrator switches it on (the fleet console's report and remote console are the other two, each behind its own key).

The Automation tab holds every workflow of every kind in one list (search, and Type and Covers chips), their Run history and the Reports they built. The whole tab is licensed as Automation, and each kind also needs the product it works on: certificate deployment, ACME, certificate cleanup, SSH commands and the appliance analysis need NetScaler; Reporting needs a module a report reads. NetScaler Configuration is not needed for any workflow (the workflows sign in with the appliance’s own SSH access, not the configuration account). Administrators only; every run is audited and kept.

The kinds

• Certificate deployment — renewed files from a share the service account reads. Four steps: where the certificates are, where they go (every appliance, a category, chosen appliances or chosen virtual servers, gateways and AAA servers), when it runs (manual only or a schedule), and a review of what will change. Every binding on the appliance is read before anything is sent; a certificate shared by a virtual server outside your selection waits for you to acknowledge it. It lands as a new certKey named with the date and time with every binding moved onto it, in place, or replacing the old one; the result is read back and a rollback plan is kept.
• Renew and deploy (ACME) — the certificate obtained from your CA; the key is generated on the appliance and the EAB credential is never stored.
• SSH commands — a job as in the Citrix Console: commands typed or started from a saved template, on the appliances you choose. Write $name$ where a value differs per appliance and the Values step asks for it (a default, and a value per appliance); the commands are checked as they will be typed, so a value cannot slip a pipe or a restart past the rules, and an appliance left without a value is not run and is named. A line with a pipe is refused (the appliance's shell splits it), and a command that restarts an appliance needs its own permission. A custom rollback is typed on an appliance whose run failed after something was accepted — never when the first command was refused, never on a preview — and the run still reads failed. Every run is a report of each appliance's commands and the appliance's own words, kept here and e-mailed or written to a folder every run or only when an appliance failed. Save as draft keeps a job that is not finished; a draft does not run, by hand or on its schedule. The review is a Job Preview: what is typed on each appliance.
• Certificate cleanup — removes certKeys that expired past the grace and are bound to nothing, and the files no certKey names, keeping the newest for a rollback; a list it could not read stops it.
• Appliance analysis — the support bundle analysis (crashes and restarts, resources, signs of compromise, the integrity rules among them) run on the appliances Vantage is connected to, with no support bundle: each node of each chosen pair is read live over its SSH session — the logs of the window you choose, a listing of the folders the rules look at, a setuid search, the configuration files and the resource readings — and nothing is written to it. A node that cannot be read is named with its reason and the rest are still analysed. The whole analysis is kept under Utilities > Support bundle analysis, its report with the run; it can be e-mailed or written to a folder every time, or only when something needs review. Licensed with NetScaler monitoring, since it only reads.
• Reporting — any of the dashboard's reports (NetScaler, Windows infrastructure, Uptime, certificate runs) built on a schedule through the report's own route, kept here, e-mailed through Settings > Mail, and written to a folder. Each delivery is its own step with its own words.

Each row's last run is counted in its own unit: certKeys for a deployment, commands for SSH, steps for cleanup, ACME and reports, nodes read for an appliance analysis. A preview comes before anything is sent; the result says Succeeded, Partially completed, Failed or No changes, and a preview is never drawn as an install.

Tools over material you already have; administrators only, since a certificate file can hold a private key.

Run commands on NetScalers

The SSH commands job run once, now: commands typed or from a template, the appliances chosen, the values for any $name$, an optional custom rollback, a preview that signs in and sends nothing, then Run now after a confirmation. Nothing is saved: the run is kept in Automation › Run history as “Commands run from Utilities” with its report. Save as a workflow… takes the same commands, targets and values to Automation to name and schedule. It opens with NetScaler Configuration or with Automation (and NetScaler); monitoring alone never runs a command.

Certificate converter

Three steps: choose the file (an upload or a path this server reads) — a PFX / P12, a PEM bundle (the certificate, its chain and a key in any order, openssl’s Bag Attributes lines and all), a .p7b or a single .crt / .cer — with its password (a PFX’s, or the passphrase of an encrypted key in the PEM); review what is in it — the certificate, whether a private key is present, the chain as a ladder, and anything that fits nowhere listed rather than dropped; export the certificate, key and chain in PEM or DER, the key encrypted with a passphrase or said plainly to be unencrypted, named the way a Certificate deployment workflow reads them (with the date and time if you want). To take only the chain out of a .pem, open it and tick CA chain alone. In a file of several certificates the one it is about is the one the key belongs to, else the one that is not a CA, else (a chain on its own) the lowest rung — never the file’s order — and the review says which; a key that belongs to none of them is not used, and a block it does not read (a certificate request) is named. Delivered as a ZIP or written to a folder, never over an existing file without asking. Neither password is stored and the file is not kept.

Trace analysis

A pcap or pcapng (up to 25 MB), or a capture taken on a NetScaler (see Capture & analyze). The answer is where the connection failed first — DNS, TCP or TLS — with the packets that show it, the addresses named from what Vantage knows about your estate, and what Vantage recorded in the same minutes (NetScaler events, syslog, Uptime checks, Windows alerts, each saying when it had nothing or could not be read). Connections, DNS and a timeline are tabs with one search. The capture is not kept; the report is held for an hour. NetScaler's own nstrace format is not read yet: take the trace as pcap.

NetScaler integrity check

Reads every node of the appliances you choose over SSH, both nodes of a pair, and judges what signs of tampering look like on a NetScaler: a setuid /bin/sh, setuid files where none belong or that only some nodes of the same build have, the web server set to run PHP inside a <FilesMatch> block (the stock php_flag engine off guard, and the firmware’s own site-level line, are shown as evidence and are not findings), and /bin/sh or httpd.conf changed while the node was running. A node that could not be read says so and is never counted as clean. It also looks for what the Google Threat Intelligence Group's advisory of 29 September 2026 (CVE-2026-88772, fixed in 14.1-73.37 and 13.1-64.23) found on exploited appliances: a .sig or script file in the gateway's plug-in or media folders (nsgclient.sig by name), files there holding a web shell's words, an httpd.conf alias that serves an icon's address from such a file or a handler that runs .sig, .deb, .html, .rpm or .tgz as PHP (all three copies, /flash/nsconfig/httpd.conf included), the SLAPSHOT tunneler's /tmp/.uxdport and /tmp/.uxdlock and its Python process, and a build below the fix. Two or more of those together is said as that campaign. The stock files and lines those places hold (the plug-in packages, Thumbs.db, the stock aliases onto the plug-in folders, NetScaler Console's own Python) are not findings. It also makes four checks Cloud Software Group’s own NetScaler IOC scanner makes: a guard the firmware ships switched on and switched off by commenting it out (# Require all denied, # php_flag engine off), a process of the web server’s account that is not the web server (a shell or an interpreter is critical), crash dumps deleted (rm /var/core/*, or rm typed in /var/core; a warning, since it is also how a full /var is freed), and memory written into ns.log past a buffer (a SAML or WS-Fed value carrying bytes it cannot hold: the mark a memory-overread exploit leaves, quoted with those bytes replaced). The last two are read from the logs, so a support bundle or an Appliance analysis finds them. Citrix’s own addresses and file hashes are not included; run its script as well. The same check is a NetScaler report section, so a scheduled Reporting workflow runs it.

Support bundle analysis

For an appliance Vantage is connected to, no bundle is needed: Analyse live appliances… sets up an Appliance analysis workflow (Automation), which reads each node over SSH and runs this same analysis on demand or on a schedule. For one it cannot reach, upload the bundles show techsupport writes (whole, or in the parts they were split into for transfer), one appliance per slot — both nodes of a pair together — and the analysis answers three questions with the log lines that show each: why it crashed or restarted (the packet engine exiting, the watchdog, a reboot, an HA takeover; a failure that follows the traffic from one node to the other is said to point at the traffic, not at a host; a cause is named only where a line states it), what was using the resources (memory, CPU, disks and swap at collection, and the logs searched for memory or a disk running out), and whether anything points at a compromise (the integrity check’s rules, scripts and executables where none belong, crontab and boot scripts, shell commands, SSH sign-ins and commands by source, the web application firewall at the endpoints known exploits used, unusual listeners). Beside the cards, the records behind them: Addresses lists every address that did more than browse, worst first, with its reverse DNS name, the tools it claimed to be (its user agent: Nmap, ZGrab, Nuclei, a Python or Ruby script, an out-of-date browser string beside other signs) and what its requests looked for (the file that gives the firmware build away, the CitrixBleed 2, Citrix Bleed, CVE-2023-3519 and CVE-2019-19781 endpoints, method probing, a crawler or a directory brute-forcer), with what it did (requests answered or refused, firewall blocks, failed SSH, management or gateway sign-ins, commands, a scanner’s shape), where it is, and its own lines; an address blocked a few times by the firewall is an ordinary client, not a probe, and the appliances’ own addresses are named as themselves. Commands lists every command run through the CLI, NITRO or the GUI with who ran it, from where and what the appliance answered, reads and monitoring tools’ sign-ins grouped with their counts. Shell commands lists every command typed at a terminal with its time and the SSH sign-in that opened the session, opens with what the sessions on each node were (NetScaler Console backing up the appliance, reading the configuration, checking for a firmware image or running its telemetry; the bundle’s own collection, tied to its collection time; someone looking for crash dumps; sessions that only opened and closed) and says what each command likely does. They are recognised by the script, folder and tool names in the commands, so they are said as likely, not as fact; a command no rule knows is marked not recognised, and those sessions are the ones to read. A flagged command keeps its flag whatever session it sits in, and Needs attention on the Shell sessions tab leaves out the sessions a tool ran on its own; and Sign-ins the gateway’s sign-ins and failures by user and address. A user agent is what the program sent, which any program can set; a request’s purpose comes from Citrix’s advisories, and the log shows the request and its answer, not whether an exploit worked. A fourth card says what each log covers: a bundle that ended early is read up to where it ends and names the files it lost; a zip of the missing var/log files added to the same appliance fills them in. Administrators only, since a bundle carries the configuration and shell history. The bundles are deleted when the analysis ends; the analysis is kept (the newest ten) with a report to hand to Citrix support or incident response, and no password is quoted. The same advisory's signs are read from the bundle too: the alias and handler lines, the .sig in the listing, a static file answered with a "404" that changes size (a missing file's 404 is one small page; a web shell's output is not), the two addresses the advisory names, a failed DTLS 1.0 handshake with an internal error followed by a packet engine crash, and the tunneler's commands in the shell history; a sign dated inside a crash is named on the crash card. A bundle lists files but does not carry their contents or /tmp's hidden files, so those two checks are said as not possible from a bundle; the live Appliance analysis makes them.

The Analysis summary first. The result opens with one row per question — Security, Restarts, Resources, Evidence coverage — each with its conclusion (never stronger than its evidence: “59 findings need review; compromise not confirmed”, “no pressure identified at collection; this does not establish conditions at the crash”), its next step and a button that opens its tab already filtered, and up to three next steps in order, each linked to the findings it settles. The evidence is not in the summary: the four cards that explain how each conclusion was reached are folded under it. The tabs and their filters stay at the top while the records scroll; the filters are the tab’s own. Every finding has an ID (SEC-001, RES-001; restarts RST-001; gaps in the evidence COV-001). Findings of one rule are one expandable row: Observed (each instance, its ID opening its lines), Interpretation, Next check, and its confidence. Severity is the analysis’s own, confidence how directly the evidence shows it, and review status your own mark (Mark reviewed, kept in this browser per analysis), three things kept apart; Unreviewed only leaves out what you have marked. The flat list is one click away. Export CSV on Addresses, Commands and Shell commands gives every row the analysis kept, not only the rows drawn.

The report is an assessment first and a technical appendix after. Its first page carries no path and no quoted line: Vantage, the appliances, their management addresses and firmware, when each bundle was collected and when it was analysed, the report ID and the analyzer version, the scope; the assessment as Area, Conclusion and Limitation; three next steps linked to findings. Then the findings, numbered and grouped, each with Finding, Severity and confidence, Observed evidence, Assessment, Limitations, Recommended next step and Evidence references (the lines, behind a fold on screen, printed open); the event timeline; resource observations; the collection scope and evidence gaps, each log said as expected or optional with why an optional one may be absent. Every time is GMT, the appliances’ own log clock; a quoted line keeps its own stamp. The download is the concise report; with the full appendix adds every address, command, sign-in and terminal command and the source lines by ID, and a listing cut short says it is a partial listing of how many, with the CSV that holds the rest. Printed, sections are numbered, table headers repeat and pages are numbered.

Several bundles of the same appliance (one from before an incident, one from after) are read as a timeline: what changed between them — the firmware, a reboot, the files written, grouped by the minute, permissions changed without a write, setuid files added or gone — with the log lines around each burst of writes and what explains it (the firmware install, the reboot, or nothing here). A finding both bundles carry is listed once, on the newer. The timeline takes down what it explains, keeping what the finding said before: a bulk write at the reboot during a firmware change is the install; /bin/sh setuid in both bundles across a reboot comes with the firmware image, since the root filesystem is rebuilt at every boot. A script written on its own stays critical. The same script written at the same moment on both nodes of an HA pair (the same path and size, within two minutes) is not written on its own: it reads as a warning, since that is how a firmware install, an HA file synchronisation or a change made to the pair looks, and the file is still worth hashing. Changes you made, in the analysis options, is where a firmware update or a maintenance window is declared, one per line (2026-09-20 18:00 to 20:00 firmware update, in the appliances’ GMT clock): a file written inside one is put down to it on your word, the old verdict kept beside it; a sign-in, a command or a request is never explained by a window (trust the address or the account for those). Every critical or warning finding says when it happened and what came next: its time and what a person did on that appliance in the following hours (terminal commands, configuration changes, refused commands), or, where the evidence carries no time, why not and how close it can be bounded (a setuid bit on the root filesystem was either in the image or set after the last boot, and the next reboot tells them apart).

Analysis options change what the analysis decides; they are kept with the analysis and reused by Analyze again. Trusted addresses and accounts (your jump hosts, NetScaler Console, a monitoring tool): their sign-ins and commands are said as trusted and do not raise the verdict, but what a request got (a script answered 2xx) and what is on the disk are never taken down by trust. A focus window judges only what happened between two times, in the appliances’ own clock, and counts what it left out. The conditions: how many failed SSH, management or gateway sign-ins or firewall blocks make an address probing, what makes a scanner’s shape, how many scripts in one minute are a bulk write, and how many hours “what came next” looks. Reverse DNS and geolocation can be switched off. A value that is not valid is refused with the reason. Options… on a result analyzes the same bundles again with other options. Uploaded bundles are never kept, so Analyze again on an earlier analysis asks for the same files: the file window opens, and once the files chosen match the ones the analysis had (by name, in any order) it runs; a file it never had is named and left out, and what is still missing is named on its appliance. The filters over a result — appliance, level, from and to, hide explained and trusted — narrow every tab without analyzing again.

Firmware. Each appliance says what it runs, when that firmware was installed — from the install’s own state files in /var/nsinstall — and the build before it, read from the first software start whose saved configuration came from another build (NetScaler logs both at every start). Where the bundle holds neither, it says so rather than guessing. A script in a web-served folder written within the hour after the install began is the install’s own and is said as such.

Traffic flow. Each appliance’s bundle also shows which servers it reaches and over which path: the Traffic flow tab draws every virtual server, what it binds, each back-end server (service group members, services, the authentication servers, STAs, DNS name servers and syslog servers the configuration names), the path each takes — a PBR, a route, the default route or a connected subnet — the next hop, and the egress (the SNIP, its VLAN and the interface). The path is worked out the way the appliance decides: the source address first, then the PBRs by priority (source, destination, port and protocol; a DENY hands the packet back to the routing table), then the longest route of the running table the bundle carries. Whether a server answered is said apart from its path, and only from what the appliance’s monitors said: a service’s state, a service group’s state (the bundle does not list each member’s), nothing for an authentication or syslog server. No path means no route covers the server or the PBR’s next hop is on no subnet the appliance is on. Click any box to follow its traffic — everything upstream and downstream of it lights up, the rest dims, and the panel beside it says the facts and which servers go through it; the search, the verdict chips and the table of every server narrow it. Download (interactive HTML) saves the same document as one file that works where it is saved, nothing fetched; Open in a new tab shows it full size. GSLB is drawn as what it is, a DNS answer: a GSLB virtual server is a front end with its domains and the ADNS service that answers them; it answers with one of its GSLB services’ addresses, and the client connects there itself. A local service at one of the appliance’s own virtual servers leads into that virtual server’s flow (a dashed line); a remote one is the other site’s address, with this appliance’s own route to it (what its monitors take). Whether DNS may answer with a service is its effective state, which can read DOWN while the service’s own state reads UP — when the metric exchange with its site is down, which is named as the likely reason. A remote site is drawn as the metric-exchange partner, with its own path and the exchange’s state. The GSLB tab beside Traffic flow draws GSLB as a diagram of its own, read left to right: the domains, the GSLB virtual servers that answer for them, their services and sites, where DNS sends the client, and this appliance’s path to a server elsewhere or a site. A service on one of this appliance’s own virtual servers ends there, with Follow its traffic in Traffic flow one click away, and a GSLB box in the traffic flow opens in the GSLB diagram the same way. The tab is not offered on an appliance without GSLB.

SAML against the appliance’s memory. A bundle also says whether SAML is being used to overflow or over-read the appliance’s memory, as far as its logs can show it: SAML requests (/cgi/saml…) in the five minutes before the packet engine exited on the same node, named with the addresses that sent them (critical); a SAML or WS-Fed line in ns.log carrying bytes no text holds, beyond the two shapes Citrix’s scanner names (a warning, quoted with those bytes replaced); a SAML request answered with 8 KB or more, since an over-read sends memory back in the answer and an assertion consumer normally answers a redirect; and one address sending twenty or more SAML POSTs inside ten minutes. The request’s body, where an oversized PrefixList or a second SAMLResponse travels, is in no log the bundle carries, so these are the shapes such an attack leaves, said as such, not proof. Where the saved configuration gives SAML a front end and the access logs hold no SAML request at all, that is said too — and that it is not the same as none sent, since whether the appliance writes its SAML endpoint into those logs is not known from a capture. The same reading of ns.conf lists the front ends with SAML SP configuration that lack Citrix’s PrefixList responder policy at AAA_REQUEST, as exposure beside the build — never as a sign of compromise on its own.

A daemon’s crash dumps. The packet engine is not the only thing that crashes: a dump in /var/core named <program>-<pid>.gz (for example nsaaad-2886.gz, the authentication daemon that handles sign-in) is a crash whether or not a log line says so. The analysis groups each program’s dumps that are no more than five minutes apart; three or more is a crash loop — the daemon dying, being restarted and dying again — which reads critical, a lone dump a warning, and the Restarts card never says “no crash” while such dumps exist. SAML requests in the minutes up to an authentication daemon crash are named beside it. The dump is what shows where the program died; copy it off the appliance (scp -p) for Citrix support.

When the watchdog gives up. The watchdog (pitboss) restarts a daemon that dies, up to a limit; past it, it declares a system failure and reboots the appliance. The analysis reads that sequence from the logs — the daemon dying on a signal, each exit and its status, “has had its maximum number of restarts”, “Pitboss declaring system failure”, “All monitored processes have exited, rebooting” — as one incident that names the daemon, how many times it exited, the restart limit and the reboot, and says the status in words (0x8a: signal 10, SIGBUS, with a core dump — a reading, since the line does not say which form it prints). Two appliances failing the same way within seconds are said as one cause they both received. These rules match the words of the lines as reported from 14.1-73.37 appliances, not a whole captured line.

Shell commands in a sign-in. A sign-in line (AAA, SSL VPN, SAML) carrying a downloader followed by its address — wget, curl, fetch, also spelled with ${IFS} for spaces — or a shell separator followed by a shell, chmod or a path is an attempt to run commands through the authentication path. The finding names the payload host and the path the commands save to, read from the line (no address is built in), and where else in the bundle that host appears; it is critical when a daemon or the packet engine fails on that node within ten minutes after it. A command somebody typed (CMD_EXECUTED) is never counted. The lines show the attempt, not that a command ran. The saved file is looked for: on disk and present it is critical; on the memory filesystem (anything outside /var, /flash and /nsconfig) it is rebuilt at every boot, so its absence says nothing and the analysis says so.

Each product has a Notifications view collecting the noteworthy events from its sources — for XenServer the pool's messages and task outcomes; for NetScaler state changes, HA role changes and failed polls; for Windows the agents' alerts and the fleet's reboot-pending, not-reporting and attack lists. Marking an event read persists, so a re-collection does not resurface what you have already triaged. Per-appliance muting is under Settings.

The setup wizard

Download DTRVantageSetup.exe from the licensing portal and run it on the Windows server: one program, signed by DTR Networks, carrying the installer inside it. (A DTRVantageSetup.zip holds the same program beside DTRVantage-Setup.ps1; unzip it completely first. Everything the install needs is carried inside it: Python 3.12, every package wheel, NSSM, and IIS's URL Rewrite and ARR, each checked against its SHA-256 before use, so a server with no internet connection installs as well. A deps folder of your own beside the program is looked at first.) It asks for administrator rights, then walks through the install folder, the parts to install (the IIS web front end, Python 3.12, the Windows Firewall rules, the geolocation database), how people reach the dashboard (HTTPS with a self-signed certificate or your own .pfx, the ports, Windows single sign-on), the syslog port and an optional proxy or offline folder. The review page lists every choice before anything is installed; the install page shows each step as it runs and keeps a log in your temporary folder. The wizard runs the installer below with your choices; a certificate password or MaxMind licence key is handed to it on standard input, never on a command line.

The installer script

The installer itself is a single PowerShell file, DTRVantage-Setup.ps1, beside the wizard. Run it from an elevated prompt on a Windows Server for a scripted install. It installs Python silently if absent (the installer carries the product as Python 3.12 bytecode, not source, so it uses Python 3.12 and installs it beside any other version), places the app under C:\Program Files\DTR Vantage, registers the DTR-Vantage Windows service, opens the firewall rules (the dashboard port, the syslog and AppFlow receivers; the NetScaler callouts' port, TCP 8095, is opened by the dashboard when it starts), and can set up IIS in front of the dashboard with HTTPS. It uses the prerequisites the download carries (dtrvantage-deps.zip beside the script, unpacked and checked against its manifest, then removed) and downloads only what is missing; a -DepsDir folder of your own is looked at first.

Full-auto install

.\DTRVantage-Setup.ps1 -InstallIIS -EnableHTTPS -NonInteractive

Useful switches: -PfxPath for your own certificate, -RedirectHTTPToHTTPS, -WindowsAuth for IIS single sign-on instead of the LDAP form, -MaxMindAccountId / -MaxMindLicenseKey or -GeoIPFile for a geolocation database of your own. An interactive run asks each of these.

Geolocation works from the first start: the installer carries DB-IP's free IP to City Lite database (IP Geolocation by DB-IP, CC BY 4.0) and lays it down as geoip.mmdb when no MaxMind account or file is given, and never over a geoip.mmdb already in place. A MaxMind account takes its place whenever one is set up.

After it finishes, browse to the dashboard, sign in with the setup account, connect Active Directory, install your licence, and enroll your first pool, appliance or server.

Updating

Under Settings → License and updates, Check for updates presents the dashboard's own key to the update service and says whether a newer build is published for it. Download fetches the package into the install folder's updates directory with its SHA-256 checked against the portal's answer. Install now hands it to a system task that runs the updater apart from the service — stop, back up, swap the files, restart, roll back on failure — and the outcome is written on the same page once the dashboard is up again (about a minute offline). A report that never came back can be cleared from the page. Every update package also carries DTRVantageServer.exe, which DTR Networks signs when the package is published. The dashboard runs the same Python inside it, so Task Manager lists the service as Vantage Server instead of Python. It switches only when Windows reports the program's signature as valid and a test run starts Python with the dashboard's packages, and the change takes effect at the next restart of the service. Otherwise the dashboard stays in python.exe, and the Updates block says why. Vantage's own parts (the web server, the syslog receiver, the captures, the schedulers) run inside that one process, so Task Manager cannot list them separately.

By hand, as before: copy the package to the server and run Update-DTRVantage.cmd; it swaps the files, restarts the service, and keeps your configuration, enrolled systems, database, licence and branding. Then hard-refresh the browser. Agent-side changes additionally need Update agents on the Windows servers.

• A Windows Server VM (2019 or later) that can reach the systems you will monitor: XenServer coordinators over SSH and HTTPS (XenAPI), NetScalers over SSH and HTTPS (NITRO), Windows servers over WinRM for deployment and HTTPS inbound from their agents.
• Inbound to the dashboard: the web port, UDP 514 for syslog and UDP 4739 for AppFlow where you use them, and TCP 8095 from the NetScalers' subnet IPs where an enforcement rule uses a Vantage callout (the dashboard opens that rule itself).
• For AD sign-in: reachability to a domain controller over LDAPS (port 636).
• Sizing: a small estate is comfortable on 2 vCPU and 8 GB; a busy syslog and AppFlow feed wants disk and retention set accordingly.

Place the VM alongside the infrastructure it watches, not inside a pool it monitors, so a pool problem never takes the dashboard with it.

Save names exactly what changed, old value to new, or says that nothing did.

Mail is the dashboard's own mail server for scheduled reports: host, port, STARTTLS or TLS, user and a password or API key (Resend: smtp.resend.com, 587, user resend, the API key as the password). The password is encrypted and never shown again. The certificate is verified by default; under Certificate you can instead trust one specific certificate (Vantage reads it on Save and pins it by its SHA-256, so it is accepted even where the chain cannot be built on this machine, and sending stops if it later changes), or turn the check off for a relay you control. Send a test message says what the server answered, in plain words (a misspelled server, a port/security mismatch, or an untrusted certificate each named).

The product name, subtitle, footer text, support email, classification label, and colour palette are all configurable. Report exports pick up your product name automatically, so customer-facing documents carry your identity, not ours.

Under Settings → Authentication, operators sign in with their domain accounts — no separate user store.

Settings you provide

• Domain (e.g. company.local)
• LDAPS URL (e.g. ldaps://dc01.company.local:636 or an IP)
• Search base (e.g. DC=company,DC=local)
• The AD groups that map to each role

Use the Test login button before saving. Only disable the local setup account after a domain login has succeeded.

Map one AD group to each role — viewer, operator, admin. A user gets the highest role whose group they belong to.

Group membership is resolved even in hardened domains: the dashboard reads the user's memberOf where available, and falls back to a transitive group query when a domain's ACLs hide that attribute.

A session is an idle timeout, not a stopwatch. Every request pushes the clock back out, and an open dashboard window checks in on its own, so a window you are using — or one left up on a wall display — does not sign itself out. A window that comes back from being hidden renews before it does anything else; if the session cannot be revived, a bar across the top says so instead of every panel quietly rendering empty.

Once signed in, the browser can come back the next morning without retyping the password: a random token, stored on the server only as a hash, separate from the session, revocable from the sign-in settings.

Your licence is a signed file naming the modules it enables and any limits (appliances, pools, hosts, servers). The dashboard verifies it offline with an embedded public key — there is no phone-home. A locked tab or button says which module it needs.

A key is bound to the installation it was issued for: Settings → License, Updates & Manage shows the Installation ID (DTRV-XXXX-XXXX-XXXX-XXXX-XXXX, a hash of the machine identifier and host name) with Copy, and a key naming another installation is refused in words. Activate online asks the licensing portal for a short code; you sign in on the portal, approve this installation there, and the key lands here bound to it — no portal password passes through the dashboard. Once a key is bound to this installation, a renewal or upgrade issued on the portal is pulled with one button, Check for a new license, with no code (the first key is what teaches the portal this installation's ID). And if the installation reports to the cloud management console, a newly-issued licence is pushed to it automatically and installed on its next report — no visit needed. Without internet, quote the Installation ID and a key file is issued for it. The portal's three names (licensing, updates, uptime) are built in.

Trial. Anyone can ask for a 14-day trial on the licensing portal (/trial): a name, a work e-mail they confirm, the organisation and what they would monitor. DTR Networks approves each request; the trial key then waits on the customer's own portal page with the installer and the three steps (install, Activate online, enter the code). It carries every module for up to 2 NetScaler HA pairs, 1 XenServer pool, 10 Windows servers and 2 Hyper-V hosts, the 14 days start at the activation, and an installation takes one trial only. The header says Trial · N days left on every page. When it ends the dashboard runs in limited mode; settings and collected data stay, and a purchased key brings everything back.

A trial account is private: DTR Networks never sees or opens its dashboard. The portal issues it no cloud management key and refuses its fleet report, its remote console and its Uptime-from-outside publish; what DTR sees is what an approval and a sale need (the person, the organisation, the key and the Installation ID it is bound to). After a purchase only the customer's own portal user can lift the privacy.

The trial request is made under trial terms the person accepts on the form (among them: no reverse engineering, no working around the licence key); the account records the version. A trial key gets no update packages, which carry source: a trial runs the build it was installed with, and the newest installer is on the portal page.

Through a partner. A partner buys units per module into a pool at its tier's price (Registered, Silver and Gold, at 20, 30 and 40 percent off list) and issues keys to its clients from the portal, each installation on its own record; an NFR key for the partner's lab (2 pairs, 1 pool, 10 servers, 2 Hyper-V hosts, one year) draws on no pool. The shape of pricing is on the pricing page.

Updates for a partner's clients. Each installation updates itself from its own Settings page (Check for updates, then Install now), or by hand from the update zip; the portal stages a build on the dev channel and to early-access accounts before releasing it to everyone. An installation that reports to the cloud management console is also updated from there: releasing a build to everyone pushes it to every reporting dashboard (at a time you choose), and the installation's Fleet page shows when it was applied.

Online services can be switched off from the portal. DTR Networks (or the partner that manages an account) can suspend an installation's or an account's online services — updates from the portal, online licensing, the cloud management console, and Uptime checked from outside — with a reason the dashboard shows. The dashboard itself is never locked: it keeps running on its offline licence.

Under Settings → License, paste or upload the licence file you were issued and apply it. The status panel shows which modules are enabled by name, the limits and any expiry. New tabs and controls appear immediately, no restart.

Optional, off by default, for estates managed by a partner or run at several sites: the management console at manage.dtrvantage.com (the licensing portal's Fleet page) shows every installation that reports to it, opens each dashboard in a tab, mails scheduled reports and pushes released builds. Nothing here is on unless an administrator pastes in a cloud management key the portal issued for this installation (on the account's page there; one live key per installation, with the scopes report and remote chosen by the issuer and a term of one to five years) and switches the opt-ins on under Settings → License, Updates & Manage → Vantage cloud. The dashboard verifies the key offline, like the licence, and Forget removes it.

Updates pushed. When a build is released to everyone on the portal it is approved for every reporting installation (at once or at a time chosen); the dashboard downloads it with the SHA-256 checked and applies it through the same system task as Install now, and the installation's page on the portal shows Pushed and Applied in this dashboard's own time zone. An installation without the report opt-in updates from its own Settings page as before.

Scheduled reports. From the installation's page on the portal, a NetScaler, Windows or Uptime report is scheduled by mail (PDF or HTML, the targets and sections chosen the way the dashboard's Build report dialog offers them, Send now for a first one); the portal builds it through the remote console as a viewer. A remote console session lasts 8 hours at most and ends when nobody has been at the page for the console's idle limit; opening the dashboard again from another window or browser ends your older session there, and the tab left on it says so instead of quietly opening another. The Sessions list shows only the sessions open now.

Under Settings → TLS Certificate, upload a certificate and key for the HTTPS endpoint. After validation the dashboard applies it and IIS rebinds the HTTPS port — your browser may briefly drop and reconnect.

• Your password is never stored. Anything Vantage does as you — an agent deploy, a Hyper-V change, a Windows Update install, Remote Desktop — takes your password for that action, holds it in memory, hands it to the child process over stdin, and forgets it. The audit line says "credential not stored".
• Certificates are pinned before a credential is sent. XenServer coordinators and NetScaler NITRO endpoints are recorded by SHA-256 on first use; a changed certificate is refused until an administrator accepts it. Nothing here has a "skip TLS verification" switch.
• The Windows agent is not an administrator. It runs as a shared least-privilege account and is granted exactly the rights its collectors need.
• Two NetScaler accounts. Monitoring is read-only; configuration is a separate read-write account that exists only where NetScaler Configuration is licensed and is used only for explicit actions.
• Secrets never come back out. The agent secret is shown once; stored keys (appliance passwords, the XenAPI credential, the MaxMind licence key) are encrypted with a machine-local key and never returned by any read.
• Remote screens and shells are the server's targets, not the browser's. RDP, SSH and the VNC console open to an object Vantage has on record, through a one-time ticket bound to you; the browser never names an address to dial. In the browser RDP console your password travels inside RDP's own sign-in, encrypted by the browser for the server, so Vantage carries it and cannot read it. SSH pins each host key on first use and refuses a changed one before any credential is sent; a shell is for administrators.
• Every change is an audit line naming who, what, and the system's own answer.
• Nothing leaves on a timer unless you opt in, and each opt-in needs a key. The Uptime page, the fleet report and the remote console are off by default; the last two count only with a cloud management key the portal issued for this installation. A remote console session carries no dashboard password, is capped to the role you set, and times out idle.
• No device identifier is sent to a lookup service. The estate map names a manufacturer from the IEEE registry held on this server; the registry is fetched from its public address, and nothing of your estate goes with the request.

Reporting a vulnerability. Write to dtrvantage@dtrnetworks.com (also published at /.well-known/security.txt on dtrvantage.com). A confirmed finding is fixed in the next build and you are told which build carries it. The fix reaches installations the way every build does: the dev channel, early-access accounts, then everyone; each installation applies it from its own Settings page.

• Reads by default. Monitoring never changes anything. Management is licensed apart, confirmed in words, and written only where it differs.
• No agents where none are needed. XenServer and NetScaler are read from one server reaching out; Windows has one small agent, deployed and updated from the dashboard.
• Honest about freshness and about failure. Data carries its age; "nothing to show" and "could not read" are always said apart, with the reason.
• Verdicts with reasons. Every health colour comes with why, and the analyses say how confident they are and what would settle it.
• Written against real output. Parsers and decoders are built from captures taken on production appliances, not from documentation samples.
• Offline. After install it needs no internet.

Why is a number stale?

Collection runs on an interval. Check the age in the header; an operator can force a fresh poll. The XenServer console also follows the pool's own events.

I updated the agents. When does the page show it?

At once. An agent says which build it runs the moment it starts, before its first collection, and an open page is told the fleet changed instead of waiting for its timer. The identity collector's build on the banner is the one that last ran; a server that has the new collector installed and has not finished a run with it is named as updated, with nothing to deploy, or with the collector's own error if it fails.

A tab or button is missing or shows a lock.

That module is not licensed. The lock names it; an admin adds it under Settings → License.

A panel says "could not read".

It says why beside it: a refused credential, a certificate that changed, a collector without the right it needs, an agent that is not reporting. Fix that and the next collection fills it.

Can Vantage change my NetScaler or my VMs?

Only with the management module licensed and only when an administrator or operator asks for a specific change, which is confirmed first and logged afterwards. Without those modules it reads.

I can sign in but can't see anything.

Your AD account is not mapped to a role, or the group names do not match. An admin maps groups under Settings → Authentication.

How long is HDX Insight data kept?

As long as the syslog retention setting says (Settings → Syslog; 0 keeps forever), pruned hourly on your host. The raw capture file rolls at a size you set.

Does it integrate with our PSA?

Not today. What leaves Vantage is the PDF reports, a CSV of certificates and the company's Uptime page. PSA integration is on the roadmap with alerting.

We run thirty client installations. How do we update them all?

Installations that report to the fleet console take a released build automatically (Release to everyone on the portal approves it for each; the dashboard downloads, verifies and applies it, and the portal shows when). The others update from their own Settings page or from the update zip. See The fleet console.

A user says their Citrix launch failed. Where do I start?

Search the user on HDX Insight data and read the chain: sign-in, launch, the connection to the VDA, then the VDA's session on Session performance. The stage after the last record is the suspected point of failure, subject to the feeds having arrived; the Launch analysis says which side it could not read. See Troubleshooting a failed launch; Vantage does not read the Delivery Controller, so a failure inside brokering shows as a sign-in with no launch.

A user says the logon took minutes. Which part?

Session performance → Logon duration: pick the logon and read the phases beside the user's average. Group Policy names the extension that took the time; the profile load, the logon scripts and the printers have rows of their own; the Workspace app panel says whether the wait was before the VDA at all. A phase the agent could not read is named with the reason (the Security log for the pre-shell phase needs process-creation auditing).

The External Uptime view is green while the service is down for the world.

Check the "Checks from outside" line on the External view: external targets are checked by the portal from the internet only while publishing is on and the portal is answering; a row that shows a result from this server instead says so.

Is there a security score out of 100?

No, deliberately. A percentage over an estate where two servers could not be read counts a machine nobody asked as a pass, and the weights that would make a score mean anything are not grounded in a real estate yet. The verdict is a word — Critical, Needs attention, Meets the baseline, Not enough read — with the coverage beside it, and the page opens on the issues rather than on fifteen rows. See Security posture.

Does the estate map contact anything?

No. It is built from the last poll, scan and report already held on this server, and every source is listed with when it was read or the words of the refusal that stopped it. The manufacturer behind a MAC comes from the IEEE registry held here too; no address leaves. See Estate map.

A server says "Patch status unknown". Does that mean it has no updates?

No. It means the Windows Update scan failed there or has not been read, so whether updates are pending is not known. The row and the Collection fold say why (usually the scan task is missing, fixed by Register the scan task on the Windows Update view). Vantage never shows "Up to date" for a server it could not ask.

The Collection fold says the Security event log cannot be read.

It is listed there with the cause and the fix, and it does not count as a coverage gap. The agent says which cause it is: the service account is not in Event Log Readers yet (or the agent has not been restarted since), the log's own access list leaves Event Log Readers out, or a Group Policy (Event Log Service → Security → Configure log access) sets that list. Fix collector rights on the server's Agent fold repairs the first two and restarts the agent; for the policy it names the setting, since a change on the server would be put back.

How much memory does the agent use, and on what?

The server page's Agent memory fold draws the agent's memory after every report over the last week and says whether it is steady (a fixed cost) or climbing (a leak) since the agent last started. Below that, a table shows what each step has added since the agent started: every collector, the sleep between cycles, sending the report and the heap collection. For each it gives the private bytes, the native part (memory that is not the managed heap, which is where a leak in Windows' own components shows), the handles and the cycles. A slow leak adds too little in any one cycle to see there, so the climbing step in this table is the one to look at. The fold also shows the last cycle and what the process holds: the managed heap, the .NET assemblies and native DLLs loaded, the PowerShell modules, handles and threads. Native DLLs are mapped from their files and are mostly not part of the private bytes. Above its ceiling (1 GB by default) the agent restarts itself, and the restart keeps the totals.