Has anyone else experienced something like this? The situation was I initiated a scan on an existing network that I had scanned and deployed agents on months back. Due to new users connecting, a server move, as well as wanting to make sure my discovered devices record was up to date; I ran a new scan. Shortly after running this scan, that entire VLAN/subnet went down. After troubleshooting the outage, it ended up being the Kaseya Agent Probe for that network that was causing the outage. Our core switch kept shutting down the port that that VLAN was was trunked trough, and the only way I could stop this was to have the user power down their machine. As soon as it was powered down, the port would stay active and that subnet was back up. Later I had the user power up their machine and I tried the "cancel scan" button under Discovery>Networks>By Agent. While it said that it canceled successfully, and that the probe was reset, the issue continued. That network still shows "Installing" under status in By Network, and that agent shows the same when I open By Agent. My only option to allow this user to connect to the network was to uninstall the Kaseya Agent, which cured the issue. However, now I'm afraid to re-install the agent on that machine, which means I've lost my ability to support that user - with Kaseya anyway. I'm working with Kaseya Support on this issue, which they are saying they've never seen before. I've run scans probably 50 times on various subents, and I've never had any issues until now. I'm not sure if this is an issue with the .046 patch, or not. Here's hoping they find something on their end (Kaseya), because I'm now gun shy on running network scans.
Network Discovery scans, in general, should not cause any sort of issue.
However, it is a network scanning tool and depending on the type of network hardware in the environment it could raise flags against specific hardware.
To provide you more understanding of what happens behind the scenes, Kaseya VSA Agents use a tool called nmap to scan the said network.
It will execute a command similar to the following:
nmap.exe -sn -PE -PU -PS21,22,23,53,80,135,139,443,445,548,3283,3389,8080 -PA21,22,23,53,80,135,139,443,445,548,3283,3389,8080 -oX "#NmapResults#" #targetIPRange# --exclude #excludeIPRange#
The ports being scanned are the ones listed above:
My assumption would be the hardware on that network must have some sort of IDS or Security in place that is detecting/flagging the scan or causing issues with the ports.
Re-installing the Kaseya Agent should not immediately bring back the issue, while you can cancel the scan from starting, once it starts running a certain portion of the scan it can no longer be stopped.
Additionally, there are discovery scan logs available in C:\kworking(default-working-dir)\LanWatch\temp folder.
Do you know what type of hardware this environment has in place?
Thanks for your input. We have used nmap separately from Kaseya in the past. What's odd is, I've run scans from Kaseya like this 50 times or more since deployment, and I've never seen this issue. For hardware, we use a mix of Cisco, Forti, and HP products. Our HP "core" switch was the one that was disabling the port when this issue occurred. This is not a new switch, and I've run scans on this specific VLAN in the past without any issues.
I do appreciate your input here. It makes sense that once it starts running, it can't be canceled. But, what's the point of the "cancel scan" button then?
Anyhow, I'm going to attempt to reinstall the agent with /r /w switches for a fresh install.
We had the same issue and reset it by changing the database value.