What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

PRTG Network Monitor

Intuitive to Use. Easy to manage.
More than 500,000 users rely on Paessler PRTG every day. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free Download

Top Tags


View all Tags

PING false alarms

Votes:

0

Your Vote:

Up

Down

I'm new to PRTG; monitoring was set up by a previous admin, and I inherited it. We're monitoring a dozen or so devices, all of which have a PING sensor.

Very lately, we've been getting simultaneous PING alerts for all devices. They are showing as offline for hours at a time, and then they simultaneously close. Needless to say, these servers are not offline at all, and we have no known connectivity issues.

Sensor settings are unchanged since the problem started, and I think they're defaults. Regardless, here's what they are:

Timeout: 2 Packet size: 32 bytes

Method: Send one single ping

Auto acknowledge: Show "Down" status on error

Scanning Interval: 30 seconds

When a Sensor Reports an Error: Set sensor to "down" immediately.

When sensor state is Down for at least 60 seconds perform Ticket Notification

When sensor state is Down for at least 300 seconds perform no notification and repeat every 120 minutes (<--Some "outages" last for 4-6 hours)

When condition clears after a notification was triggered perform no notification

false-alarm ping sensor

Created on Jul 28, 2015 5:00:46 PM by  JRV (0) 1



19 Replies

Votes:

0

Your Vote:

Up

Down

When the ping sensor goes down, can you still ping the servers in case from a Command Prompt on your PRTG server?

Created on Jul 29, 2015 8:47:21 AM by  PRTG Tools Family [prtgtoolsfamily.com] (13,273) 3 4



Votes:

0

Your Vote:

Up

Down

No, I can't. But I also have a lot more information now.

Some time after my original post, PRTG reported all systems down. I happened to have a Remote Desktop session open on the PRTG server when it happened. The server was reachable from other computers, but it had no outbound connectivity. Network icon had a red X overlay, PING at the command line returned "Unable to contact IP driver. General failure." for every IP I tried (all were online to other machines).

I restarted PRTG services; connectivity immediately returned, although all SNMP sensors still reported "down". (I still do not know how email notifications were being sent out without outbound connectivity, but we get them regardless.)

I restarted the PRTG server; all alerts cleared.

Correlating Windows logs with reported "outages", I found that when the connectivity issue occurs, Windows stops Remote Registry service, but the service crashes as it stops. This is always the first of a cascade of crashes that includes COM+, Windows Font Cache, Network List, Network Store Interface, and WPAD. This is definitely related as it immediately precedes every recent PING alert. If I manually start and stop Remote Registry, it does not crash.

Created on Jul 30, 2015 4:46:34 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

Hmm, it looks like there is a problem deeper in your PRTG Server machine.

btw, does your PRTG Server machine (still) meet the System Requirements for PRTG Network Monitor ?

Created on Jul 31, 2015 8:15:44 AM by  PRTG Tools Family [prtgtoolsfamily.com] (13,273) 3 4



Votes:

0

Your Vote:

Up

Down

That indeed does look like a network connection issue on your PRTG server - any recent driver updates for the NICs? If not, can you try to update them?

Created on Aug 3, 2015 8:15:09 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Thanks for your replies.

PRTG server is a Hyper-V guest; no NIC driver to update. The host and other guests are not experiencing drops; just this machine. And on this machine, just outbound.

Only 100 sensors (free version). (Still) meets System Requirements.

Worked for a year, then just started losing outbound connectivity randomly for anywhere from a few minutes up to a few hours per day. At about that time, installed a lot of MS updates that had been pending for a long time, removed Vembu BDR client, and upgraded Backup Exec agent from BE2012 to BE15. No way to know if any are related.

Created on Aug 4, 2015 8:33:24 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

You could create a new virtual machine and just migrate it to the new server to see if the problem persists. On the other hand, HyperV is not recommended for PRTG since it has some weird quirks that might cause PRTG to trip :) VMWare is the best option here, since it's the platform we run our tests on.

Created on Aug 5, 2015 8:05:38 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Neither VMware nor a physical machine is an option here. No "weird quirks" across its dozen or so guests...except the PRTG VM.

I discovered that the Hyper-V Integration Services on this guest were out of date. Updated them and haven't had a PING false alarm since. The longest quiet period since this problem began.

Outdated Integration Services are definitely a candidate for root cause. If that fixes it for good, I'll take it.

Created on Aug 11, 2015 7:42:41 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

Looked back at my notes; I actually made another network change at the same time. A previous admin was superstitious about IPv6, and disabled it on most of the servers. And, worse, he did it the wrong way (through NIC Properties instead of the Registry). That was done on this machine. I re-enabled IPv6 when I upgraded Hyper-V Integration Services. So if it's really cured, it could be either or both that cured it.

Created on Aug 11, 2015 7:50:06 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

Nope. Got a PING false alarm last night that didn't clear for several hours, so unless there's something else to try to get this VM the same connectivity that all the rest enjoy, I guess I'm looking at migrating to a new VM.

Created on Aug 13, 2015 4:59:21 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

Alright, let me know the outcome of it!

Created on Aug 14, 2015 6:35:44 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

In setting up the new PRTG server, I'd like to kill 2 birds with 1 stone by joining the new server to a new domain to which we are gradually migrating. Right now, we're not monitoring any servers on the new domain, but we need to be able to monitor both.

Currently, PRTG is using the PRTG Core Service Account (LocalSystem).

We have a 2-way domain & forest trust between the domains.

I'm assuming that I'll need to specify new domain credentials that have transitive membership in an old domain group. The question is, which group? Unfortunately, the manual is vague:

"Use explicit credentials: Define a user account that will be used by PRTG to authenticate against the Active Directory. This should be a user account with full access to all of your Active Directory groups."

I do not know what "full access to all of your Active Directory groups" means. Membership in every AD group?? That can't be right!

It seems like the account would need only membership in the Administrators group on each monitored computer.

Is that all I need?

Created on Aug 18, 2015 5:01:02 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

I appear to have stumbled on to the way to handle the credentials issue; create a Group for each domain, put the servers in the Group, and set appropriate credentials for each domain at the Group level, allowing the servers to inherit from the Group. Leave the Active Directory Integration set at Local System.

Created a test WMI probe (disk space) against a machine in the remote domain from the existing PRTG server using that technique and it worked.

Onward to the new PRTG server...

Created on Aug 18, 2015 8:21:37 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

I have followed https://kb.paessler.com/en/topic/413-how-can-i-move-migrate-my-prtg-installation-to-another-computer, faithfully, I think, with one exception: Files dating from the installation of PRTG on the new server were locked. My solution was to rename the PRTG folder to "PRTG Network Monitor.old", create a new folder, copy files & folders into that from the old server, and then copy the 4 files I was instructed NOT to copy from the old server from the .old folder, so I had a (presumably) complete and consistent file and folder set.

But when I start PRTG on the new server and open the Enterprise Console, and edit the Connection to my credentials, IP address 127.0.0.1, I get this: Not Connected (Error in content: )

What did I miss?

Created on Aug 20, 2015 9:48:52 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

Can you open the PRTG Administration Tool, and open the webserver tab - what IP is selected for the webserver? That's the one the EC has to be configured for :)

Created on Aug 21, 2015 10:45:59 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

A subtlety I had not noticed: EC defaulted to 127.0.0.1, but the NIC's IP was entered in Administrator. I changed the EC IP address to the NIC's IP address and got in to the console. I suppose I also could have used the localhost address in Administrator.

Thanks!

Created on Aug 25, 2015 7:51:50 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

So, everything working again just as it should? :)

Created on Aug 26, 2015 11:45:59 AM by  Stephan Linke [Paessler Support]



Votes:

0

Your Vote:

Up

Down

No false alarms yet. However, we had quiet periods on the old server where we didn't have false alarms for 10-14 days, so I'm not prepared to pronounce it cured until end of September. But I suspect, and hope, that it is.

Created on Sep 1, 2015 6:58:44 PM by  JRV (0) 1



Votes:

0

Your Vote:

Up

Down

"Looked back at my notes; I actually made another network change at the same time. A previous admin was superstitious about IPv6, and disabled it on most of the servers. And, worse, he did it the wrong way (through NIC Properties instead of the Registry). That was done on this machine. I re-enabled IPv6 when I upgraded Hyper-V Integration Services. So if it's really cured, it could be either or both that cured it."

Why is disabling IPV6 through NIC properties the wrong way?

Created on Jul 17, 2018 12:12:47 AM by  epickett (0)



Votes:

0

Your Vote:

Up

Down

Check out this thread on Reddit which shows some implications of disabling IPv6 and why it's not a good idea in general :)


Kind regards,
Stephan Linke, Tech Support Team

Created on Jul 17, 2018 10:48:45 AM by  Stephan Linke [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.