PING false alarms

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

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.

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 ?

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?

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.

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.

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.

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.

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.

Alright, let me know the outcome of it!

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?

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...

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?

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 :)

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!

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

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.

"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?

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