Your VSA, audited
Wegweiser no longer pairs VSA devices by name: a person links each one, with the evidence in front of them. A new audit reads what your VSA knows about the estate once, from the notification backlog and what it sends into Autotask to the agents that went quiet, and ends every chapter on what to change. Also: Wegweiser alerts in your Skald hall, and each machine's agent version in the device list.
Your RMM knows a great deal about your estate that nobody has time to read: thousands of notifications, which of them land in your PSA, which agents have stopped reporting, which records belong to machines that were reinstalled a year ago. Wegweiser now reads it, and it starts by getting one thing right that it used to get wrong.
Links you confirm, not names we match
Until today, Wegweiser wrote its health score into VSA 10 by pairing devices by name. On our own instance that paired HERA, a Windows 11 install that stopped reporting in July, with Hera, the same box now running Linux Mint. The score landed on the right hardware by luck. Nothing in a name can tell that apart from two machines that happen to share one.
So a VSA device now gets Wegweiser's fields only when somebody has linked it. Integrations > Kaseya VSA 10 > Link devices reads VSA's device list once and suggests which record is which machine, with the evidence laid out:
- a network adapter's address on both sides, the strongest there is, because it survives a reinstall and a rename
- the serial number, unless it is a placeholder such as "System Serial Number", which a self-built board reports and proves nothing
- the operating system, the name and the model
Each suggestion carries a verdict: same machine, same hardware, reinstalled (HERA's case), name only, or conflict. Only same-machine pairs can be linked in one go. The others are linked one at a time, by somebody who has read why. Every link records who made it and when, and the daily run puts a link back in review when VSA stops listing the record, the operating system changes, or VSA's agent goes silent while ours keeps reporting. Nothing is written to a link in review until somebody looks at it.
Nothing carries over from the old matching. Until you link, nothing is written and Wegweiser's fields come off every VSA device. A linked machine shows In VSA on its device page, with VSA's own link to the record.
Agent 0.3.109 reports every adapter's address and the machine's SMBIOS serials and UUID, which is what the suggestions stand on. Like every release it runs on our own fleet first and reaches your machines a day after it has run there cleanly.
An audit of what your VSA knows
Stack > VSA audit reads your VSA once and keeps what it found. The wizard offers it the moment a connection works, before you have installed a single Wegweiser agent, so it also works as the first look at a client you are taking over.
It has seven chapters, and each ends on one recommended action:
- Notifications. The backlog by priority and age, grouped into families by their wording, so the same free-space rule firing on a hundred machines is one line. Policy errors that name no machine are counted as such; on Kaseya's demo instance they were more than half of all notifications.
- Where it goes. What each organisation sends into Autotask or ConnectWise, and what that comes to in tickets a day at last month's rate.
- Why it fires. The monitoring profile and threshold behind the largest families, read from the rule VSA names in each notification.
- Coverage. Machines only one system knows, VSA agents that went quiet while ours still report, second records left behind by a re-enrolment, and records nobody has seen for a year. Where VSA's agent went quiet, the audit says whether Wegweiser still sees that agent running on the machine, which is the difference between an agent that cannot reach its server and one that is gone.
- Posture. Antivirus, firewall, UAC and ransomware detection as VSA sees them, and waiting updates of CVSS 7 or above, with the CVEs CISA lists as actively exploited.
- The RMM itself. Licences and when they run out, and who used the RMM from where this month, with remote control sessions and ad-hoc scripts.
- Automation. The workflows that failed.
Its headline sits in the Stack's RMM chapter, and a PDF of it sits beside the audit.
It reads, and it counts
The audit only reads. Nothing in VSA is changed, and no button on the page could change anything: every recommendation is something to do in VSA or in your PSA yourself. The one thing Wegweiser ever writes into VSA is still its own three custom fields, on the devices you linked.
Every call Wegweiser makes appears in your VSA's own audit log, so the audit is kept small: bulk reads, and single ones only for the dozen noisiest machines. That is about eighty calls for five hundred machines and forty thousand notifications. The audit's own chapter on the audit log counts its lines apart from everybody else's.
If you say yes, your own AI provider reads the audit's findings and writes what to look at first. It reads the counts and families, and the machines and people they name, never your notifications one by one. It is metered like any analysis and costs nothing on a local provider or your own key. The same answer decides whether the chat may use what VSA says. You can change it on the audit page at any time.
Also new
Wegweiser alerts in your Skald hall. If you run Skald, connect it under Integrations with a publish key and tick the alerts you want: a machine going down, a tripped honeytoken, a critical finding. Each arrives with a link back to the device. The key can only publish, and Wegweiser refuses one that can do more. On the way, notification settings now offer all nine events Wegweiser sends, where they used to offer four.
Agent versions in the device list. Every machine shows the agent version it runs: green on the latest release, amber behind it, red when it is too old to update itself and needs reinstalling. The masthead names the latest release and how many machines are not on it yet.