I have a number of systems that i have checked this on and i am uncertain if this is a bug or not.
Run a query for systems that have not had an ASCI within 30days
Click the box next to one of the systems
Click the PING option
System responds with "The device XXXX is reachable", however when i ping this device by either the IP Address, HostName or FQDN i get no response.
What is ePO using to confirm connection to this device? Are these logged in the Orion.log?
I am running ePO 4.6.6, with MA 18.104.22.16835 deployed
Failure of an IP ping response may just mean it's blocked by local firewall or similar.
The ePO ping test isn't actually the same thing, it reaches out to the agent and looks for a response (which you should also see recorded in the local agent log).
Basically this is not a bug
If you're unsure, make an agent wakeup call to one of these devices then watch for the 'last update time' to be updated in the system propertes after it replies, or you can run a report for the same if testing multiple devices.Message was edited by: rackroyd on 21/05/13 16:18:48 IST
I dont think i worded this properly
Here is the response using the Ping option in ePO
Here is the response when i use a commandling Ping for the same system, this response is the same whether I use the IP or FQDN.
Why would ePO state that the system is reachable when it clearly isnt? What is ePO using to determine the system is reachable?
Also this isnt just occuring with one particular system, and this is not a firewall issue.
Message was edited by: pboedges on 5/21/13 10:51:01 AM GMT-05:00Message was edited by: pboedges on 5/21/13 10:52:03 AM GMT-05:00
As I mentioned though, the ePO ping test is *not* the same as an IP ping.
The wakeup call test I also mentioned is still valid, and is the definitive answer that the system is/is not speaking to the ePO server.
Ok, so the ePO "Ping" is not a "Ping". So what is it and what is it doing? Why does it state that a host is there when its not? Also i cant check the logs since the system is no longer online...,
It's testing the agent is responsive. Each agent has a little secure web servlet that handles the communication to ePO using proprietary protocol (spipe) generally locked over ssl unless you choose otherwise.
If the end-client machine in question is definitely switched off then yes that is odd. Perhaps it's a duplicate of a machine elsewhere in the network ?
If you can't check the logs though further analysis is difficult. The simplest thing to do is to use an ePO server task that removes machines that are showing last update time > x, where 'x' is a value you feel comfortable with that the machine is truly unavailable.
If the machines become active again their local agent will drop them back into the system tree automatically based on your sorting rules.
Look for the default server task: "Inactive Agent Cleanup Task" which uses the Inactive Agents default query.