Summary - Could Not Add a NetPath Node
The problem I was having concerned the creation of new NetPath Probes. I would go through the wizard to create a new probe, test the credentials, see the probe appear under the service, and a while later disappear. When you looked at the Agent Installed Plugins there was no NETPATH listed. It was as if it never happened.
I worked with SolarWinds technical support to capture all kinds of logs on the primary polling engine, the nodes in question, and even several packet capture files. We tried uninstalling agents and reapplying them, no luck. Installing Winpcap, the latest version of NPCAP, and still nothing worked. We tried it on a new server, no luck. I did the latest Orion release updates. Still no change. Then I tried a different newer machine and it worked and on another similar machine it failed. Now I was flummoxed.
Bottom Line: When adding a new NetPath probe there is something wrong with the search creating the cross reference between the PROBEs table [SWQL Orion.NetPath.Probes] and the AGENTs table [SWQL Orion.AgentManagement.Agent].
***Postscript: After submitting these findings I was directed to this Knowledge Base article. NetPath shows No Data Found even Agent is connected and running. This is not exactly what is happening in my instance. While the probe was visible I would get the "no data found error" the probe would completely disappear some time later in my case.
The Details
I think I uncovered the problem [I can't see the code so technically I only found the resulting symptom of a coding issue]. I continued troubleshooting after one of our SolarWInds' Support calls. I do not know why it occurs, but this is what I uncovered.
When the new probe is created it is put into the NetPath_Probes table. In that table the cross reference is made to the AgentID. Here you see AST-DC-2 is referred to as 268. Well, this seemed odd to me [yes, I have a fairly small number of agents I monitor]. I went and checked the Agent table.
NetPath_Probes table query and results
The query from the AgentManagement.Agents table shows the AgentID is 3, not 268
AgentManagement.Agents table query and results
I updated the NetPath_Probes table so the AgentID match that in AgentManagement.Agents. Then restarted the Agent on the AST-DC-2. Checking the PLUGINS directory on that server showed that the NetPath plugin files were now installed. Prior to this they were not there. I went into the NetPath services in Orion, removed the broken Probe from the Service, and added two new services using the AST-DC-2 probe. As you can see they are now both working.
AST-DC-2 probes show the service paths are being monitored.
I was able to repeat the process on one of the other servers we were having trouble with – MNP-PS1.
Looking in the Agent table with SWQL this time to get the correct reference for the Agent ID.
Showing the updated entry through SWQL query. I used the Database Manager to edit the table entry to correct this record.
Then I restarted the agent services on the probe and the path is now being monitored.
WRONG AGENTID [NOTICE IT INCREMENTED FROM THE AST-DC-2 PROBE NUMBER.]
Looking in the Agent table with SWQL this time to get the correct reference:
Showing the updated entry, made using Database manager, through SWQL query.
After restarting services, etc. The paths appear to be working now.
Makes me wonder if there is something wrong with the Probe creation process. Digging further I find when the agent NAME is an IP address, and trying to add the probe using the name, it doesn’t match an AGENTID. Tested this with the LVG-FS1 server. If the host name of the probe is used that matches the agent’s name then it works ok. See WPB-DC-2.
Next, I tried to add the Probe using the IP address instead of the HOST name to see if at least the PROBE table would pick up the correct AgentID. I did this on SLC-FS1, after a query of the AgentManangement.Agents table. Sure enough the NETPath_Probes table was updated appropriately.
NetPath_Probes table query and results showing LVG-FS1 and WPB-DC-2.
Query from the AgentManagement.Agents table where Agent Name is not like an IP address.
Query from the AgentManagement.Agents table where Agent Name is like an IP address.
NETPath_Probes table query show that the AGENTID matches that from of the AgentManagement.Agents table entry.
I can see that the NETPATH plugins were added to SLC-FS1 just fine. However, as I have noted previously, they do not appear to even get installed on LVG-FS1 as it has the wrong AgentID in the NetPath_Probes table. Notice that the LVG-FS1 probe persists in the table even though it no longer appears in the NetPath page.
LVG-FS1 probe is not longer showing up.
So I am guessing at this point there is something wrong with the search creating the cross reference between the PROBEs table [SWQL Orion.NetPath.Probes] and the AGENTs table [SWQL Orion.AgentManagement.Agent].
***Postscript: SolarWinds' support informed me of the following:
Thomas,
I heard back from the development team, confirming that this is a known issue and providing a workaround that is essentially the SQL update you already identified. See resolution 2 of NetPath shows No Data Found even Agent is connected and running.
I don't have any information on if the developers have planned any changes to the platform to prevent this from happening in the future.
