2016-11-02 12:07 AM
Currently, my customer has installed ECAT agents on hundreds PCs for initial testing before going for mass deployment. Some PCs were found ecat service is installed and running on the user's PC. However, the machine is not appear in the UI console. Any guide /steps on how do troubleshooting in this case? There is no telnet client installed on the user PC. Wasn't able to look for agent installation log in the PC also.
Thank you.
2016-11-03 11:13 AM
A web browser can also be a very simple first-step tool to test communication between the endpoint and Console Server. Try to open https://cs-server-ip/ in the endpoint web browser (append a port if agents aren't using TCP/443). It should display a certificate error if you're able to communicate with the Console Server. If it times out, there's something blocking communication, such as a firewall. You should also see an entry in the Console Server logs if this connection test is successful.
Hope that helps.
2016-11-03 11:40 AM
Correct me if i'm wrong, since the ECAT agent will connect using UDP first before it initiate the TCP connection, how can we easily validate UDP port whether opened? There is no logs from agent side can tell unless we do packet capture.
2016-11-03 11:49 AM
a packet capture on both side (eg client and server) is really the only way to confirm what is being sent, is actually being recieved.
2016-11-03 11:50 AM
That is correct, UDP will be used first. A packet capture may be the only option for determining whether UDP traffic is being received by the Console Server. The agent will fall back on TCP after 20 minutes of being unable to connect via UDP. If you at least have a TCP path, the agent should be visible in the UI after that timeout.
2016-11-03 12:37 PM
Is 20 mins configurable? now we had issue with VPN, the UDP packet went through the VPN with blank agent id(the agent ID fields is all 0), the server returned with the UDP packet(the content should be the agent cannot be found), in this case, will agent falls back to use TCP?