MartinK

Daemon is automatically restarting in case it is stopped - even in case stop is requested by user. Seems it is crashing during initialization of AGENT's database, but hard to tell why - maybe we corrupted it by previous attempts.... There is a chance we will see more with enabled full trace logging of AGENT by creating dummy file: sudo touch "/Library/Application Support/com.eset.remoteadministrator.agent/Logs/traceAll" Please provide trace.log output after AGENT is restarted.

I meant to open specific client's detail view (click on client name -> details) and check whether there are any values available. In case it is clean installation, how did you handled certificates .. you have restored them from previous installation? Otherwise old AGENT should not be able to connect to new SERVER - especially in case certificates were generated automatically during installation. You mentioned that not connecting clients are present in Webconsole as not managed -> how did they get there? You used AD/LDAP synchronization? Or they were automatically created in Lost&Found group some time after SERVER installation?

Are you sure there was no other ERAAgent process running when you started this one? Multiple running instances may be reason of previous and also this strange errorc causing premature stop or crash. There may be also more relevant information in trace.log.

Adding entry to /etc/hosts may be used as temporary workaround. You may also repair AGENT installation so that it will be connecting to IP address instead of hostname, but only in case your SERVER's certificate "host" field is ready for this, otherwise AGENT will reject connection during TLS handshake.

Seems it is not able to resolve your SERVER's hostname to IP address. Could you try to ping/nslookup this hostname manualy and verify results?

Please try to follow this article: https://blogs.technet.microsoft.com/sbs/2008/05/08/installing-a-self-signed-certificate-as-a-trusted-root-ca-in-windows-vista/ There is also mentioned possible workaround for your issue:

Try to check whether there is any information collected from client in it's client view - maybe only main view stopped refreshing its content. I would check SERVER's trace log (C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs\trace.log) for "Error:" entries - they may indicate some problem with database causing data loss. When you were reinstalling SERVER, what were your steps? It is clean installation? Or you used some backup?

Latest log indicates that AGENT is running and most probably connecting to your SERVER -> there does not seems to be any principal problem and we have to find out why AGENT was not running as daemon. Stop manually started AGENT if you have not done that already. After that, check what is status of AGENT daemon: sudo launchctl list | grep eset You may also try to manually start AGENT's daemon using: sudo launchctl start com.eset.remoteadministrator.agent and check it's status after time either using previous list command or by checking whether ERAAgent process is running (pgrep ERAAgent). In case AGENT won't be running, check it's trace logs and status.html located in /Library/Application Support/com.eset.remoteadministrator.agent/Logs/.

I would try to restart SERVER's service to be sure it is not related to one known issue with ERA 6.3 (mostly affecting MySQL database installations). In case it won't help, please check whether there are no duplicates in Webconsole, i.e. whether problematic client is not connecting as different entry in Webconsole. Also status.html on client should contain IP address of SERVER where this client is connecting - does it match you new SERVER's IP address?

Permissions seems to be set properly. Please try to run AGENT manually, but this time from directory where it is installed: sudo cd "/Applications/ESET Remote Administrator Agent.app/Contents/MacOS/" sudo ./ERAAgent Are there any system configuration differences in comparison with other Mac computers? Especially security configuration, and maybe also applications that may interfere - for example some kind of security applications? To be honest, we have not seen nor received reports with such an error to this time.

My guess is that they have problems connecting to new SERVER because of network or certificates change. Please check status.html on client machine, described in related ERA documentation article. It should give us reason why is AGENT not connecting to new SERVER.

Please provide system specification, especially version of OSX. We are also interested in list of installed files using: sudo ls -la "/Applications/ESET Remote Administrator Agent.app/Contents/MacOS/" There should be file Protobuf.dylib in this directory side-by-side with ERAAgent executable, but it seems to be either missing, or there are some permissions issues. In case mentioned Protobuf.dylib will be present, please run also next commands in case required otool command line tool will be available on this machine: sudo otool -L "/Applications/ESET Remote Administrator Agent.app/Contents/MacOS/Kernel.dylib" sudo otool -L "/Applications/ESET Remote Administrator Agent.app/Contents/MacOS/Protobuf.dylib"

I am almost out of ideas .. please check also AGENT's trace.log for Errors, especially for new/different than you already posted. Unfortunately previous error indicates some kind of network configuration problem and I am now almost sure that AGENT connection are not received by PROXY. In order to verify this, Wireshark capture on PROXY machine may be useful (filtered for specific AGENT). I have seen similar errors in case port forwarding managed by Virtualbox/VMWare vere involved. Second alternative is that AGENT is actually connecting...how are you checking in Webconsole whether AGENT is connecting or not? Please check also whether managing AGENT of this PROXY is connecting successfully (AGENT installed on the same machine as PROXY).

Seems you are missing Thawte root CA certificate that should be available in system. Have you updated this system recently or updates are disabled since older ERA release? You mean update the ERA server appliance? It is on version 6.3.148.0 No, that was question for bbahes as his system was not able to validate ESET certificate. In your case, I would suggest to reboot machine (if not already tried) as there seems to be connection problems and it may help. It seems that outgoing SSL/TLS connections are not working properly -> firewall in appliance is not filtering outgoing traffic, therefore I think there is some kind of configuration problem, or maybe firewall/security product somewhere between appliance and outside internet.

Actually those DNS resolving problems are known issue of ERA 6.3 - it should not fails in such way even if DNS server is not available. In case you encounter such problem again, you can use fixed libraries available in this post" https://forum.eset.com/topic/8061-workstations-showing-up-as-unmanaged-in-era-63-and-task-timing-issue/?p=43028-> especially Network.so for this problems. Unfortunately form PROXY log we can only see, that it is attempting to connect to SERVER every 5 minutes and it fails because of this DNS resolving issues on SERVER. There does not seems to be any record of incoming connections therefore I think there is some kind of network problem. Have you check (using netstat) whether ERAProxy process is actually listening on correct port? HAve you tried to restart PROXY or whole machine to be sure?

Seems you are missing Thawte root CA certificate that should be available in system. Have you updated this system recently or updates are disabled since older ERA release?

I've tried it. [root@era /]# openssl s_client -connect edf.eset.com:443 socket: Connection timed out connect:errno=110 That is definitely not correct -> it should have output as provided by bbahes. Please re-run command with some different HTTPS-enabled site, for example www.google.com:443 to check whether SSL works correctly.

This ESET machine is not replying to ping request, therefore this output - but IP seems t obe resolved correctly. In order to verify connection, you may also try this command: openssl s_client -connect edf.eset.com:443 It will download remote peer SSL certificate and validate it. Validation should be OK as ve are using system certificate in ERA.

Those IP addresses (at least first two) belongs to hostname ts.eset.com mentioned in referenced KB article.

Yes, it is communication/network error. SERVER is either not able to resolve hostname edf.eset.com to IP addresses or connection cannot be established. Any chance you have company firewall that could possibly block communication on standard HTTPS (443) port?

For start I would try to ping edf.eset.com to check whether network access is available. Also SERVER's trace log /var/log/eset/RemoteAdministrator/Server/trace.log may contain more detailed information why license synchronization fails (search for errors).

Could you try to activate it directly (not using ERA)? It may give more failure details, especially error code. Once failure details are known, you may check KB2434 for most common activation failures and possible solutions.

Is IP of ERA Proxy correct = 192.168.20.10? Are there any related entries in PROXY trace logs? There is a chance that connection attempt has not even reached PROXY server - it may have been blocked by firewall (on AGENT, PROXY or somewhere between).

Can you explain this answer a little more please? In short: your system is most probably not able to verify SSL certificate of ESET servers. Most probable reason for this is either missing latest root CA certificates (as mentioned in previous post) or inability to verify newer type of certificates. Second issue may be targeted by Microsoft hotfix: https://support.microsoft.com/en-us/kb/938397.

It is problem with WMI provider on this system. Please check whether system is matching prerequisites of this windows KB: https://support.microsoft.com/en-us/kb/2465990