Hi guys,

we noticed a strange behaviour with our Dude installation (4.0beta3) on windows server 2008r2. All went fine for many years ago, we monitore >800 services (~90% only ping) on >800 devices (mikrotik and ubiquiti). The server runs on ESXi platform. Since we move our server into a new network the trouble began:

A device go down and comes up after a certain time. All services come up except the ping probe. We have to restart the dude on server so the ping probe come up too. While the dude can't ping the device i can ping from cli on the server.

We reinstall already the dude but problem still exists.

Any ideas?

Maybe delete the network card out of windows? The server move maybe left a stub network card that is not "installed" anymore.

You used to be able to boot in safe mode and show hidden items to see crud that got left behind then remove it from there but you might have to move the server back, delete the old network card, then move the server to the new cluster all for just a guess so...

THIS IS ALL A GUESS and I have no clue what the hell.

Doubt it will work,
Lebowski

Every time I've moved/reinstalled the Dude, I've run into the following:

In order for ping probes to work, the user the Dude is running as must have Local Administrator access on the machine. If you're running the Dude with its default installed options, it tends to run in the context of the user that first opened the program. As a practical matter, this means that if you just open the program with the shortcut, it will run without escalation and will not have Local Administrator privileges. Right-clicking on the shortcut to choose "Run as administrator" should generate the UAC prompt when you open The Dude and then allow pings to work.

If you want to put it in "Run Mode: as service" mode via the Local Server button in the top/left, you need to have the Dude application opened as Administrator (UAC Escalated mode). Once you've installed it that way, the default run as service account runs as LOCAL SYSTEM, which is an elevated account and should work for ping probes. At my office, we try to avoid LOCAL SYSTEM services whenever we can to minimize potential security risks, so we set up a separate service account for the Dude's service user. In that case, we have to manually add the service user to Local Administrators, or ping probes and other elements that require escalation will not work (e.g. writing to the Program Files directory, if you installed via the default options).

---

If I misunderstood you and you just took an existing server and moved it to a different network, you might check and verify whether or not Windows has detected the new network as a Private (Home/Work), Domain, or Public type. The default Windows Firewall settings are pretty restrictive for a Public network, so if your network type changed from Private to Public, that may also explain your problems. You might also check to see if your anti-virus solution reclassified your network and is now blocking ICMP traffic.

Way better answer DLNoah, Thanks.

Hi DLNoah, hi lebowski,

first, thanks for your replies.

The Dude is running as local admin. After the restart of the programm it run as local admin again and all went fine till a device that is monitored reboot or isnt't available for certain time. The same behavior is observable when it runs as a service.

The local firewall (software on windows server 2008) is disabled, the antivirus programm also. So as i said, all went fine after restart the dude (programm). The network type didn't changed, everything is still the same. The only thing that changed is the subnet where the server is connected.

Any other ideas?

Is your ESXi guest running with an e1000 NIC, or a VMXNET para-virtualized adapter? If the latter, are the VMWare Tools installed & up to date?

-----

One oddity we've seen with pings (and traceroutes) from the Dude on our network occurs when there is a "split route" from the Dude server to the target device. Our scenario usually looks like this:
- A dynamic routing protocol is in use between the server ("A") and the node being monitored ("B")
- At least two paths that can carry traffic from A to B have the same total weight
- Windows CLI pings and traceroutes consistently complete from A to B (though the traceroutes will change paths from one check to the next, as expected)
- The Dude monitoring will intermittently fail to ping the device. If you bring up the right-click menu for the device and go to Tools > Ping or Tools > Traceroute, you cannot ping or traceroute to the device from the Server (both fail without any return).

When we've had that, it basically came and went at random. I never really restarted the Dude service in troubleshooting. Changing our OSPF weightings so there wasn't a split route "fixed" the problem. I just chalked it up as a Dude Thing(TM).

-----

If the problem ONLY happens with devices after they've been down for a little while, you may have a NAT or other firewall problem that is presenting itself after the connection "closes" due to the unit being offline. Is there a NAT device between your Dude server and the target devices to monitor? Is there any firewall that would be applying some sort of ACL to prevent "new" connections but auto-accepts "established/related" connections?

Hi DLNoah,

thanks a lot for your reply! Problem is solved!

It was our firewall. It is learning the routes through ospf from it's neighbour. When a node goes down, the firewall uses it's default route to get a response. To solve the problem, we add an static route for the affected networks and all is fine again