MartinK

Technically there may be problem in two different functionality block - either AGENT is not properly detecting ESET Endpoint Antivirus as installed ESET application or there is some data synchronization problem. We can proceed with next steps: Verifying what is actually detected by AGENT: you have to enable trace logging severity by creating file c:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\traceAll and restarting AGENT service. wait few minutes after service restart and search in trace.log for list of installed applications, i.e. search for "ESET Endpoint Antivirus" string or for keyword APPS_INSTALLED Verifying ESET Endpoint Antivirus is correctly installed please check whether "ESET Endpoint Antivirus" is visible in Control Panel -> Programs and Features -> Uninstall a program and post here version and exact name of vendor/publisher

Could you please check AGENT status log located here: c:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html. It may contain: status of last connection attempt - error in case something is wrong time of last log modification (in case it is very old, AGENT is mot probably not running correctly)

Hello, is there a chance you reverted or restored AGENT files from older backup? Can you try to restart one of those machine and check if it helped after client connects? Please check also SERVER trace.log for errors related to database.

Hello, in your main clients view you should see MDM icon next to computer you installed it on. Icon presence is based on the same data, so make sure it actually works. In case compute is not reporting installed MDM, please make sure AGENT installed on this machine is actually connecting/running (last connection time?). Maybe also AGENT trace.log could help. PS: about missing privileges: even when your account has administrator privileges you have to run repair using "Run as Administrator" in order to avoid mentioned warning. It informs you that repair wizard won't be able to show you values currently in effect, but once you select new ones, wizard will ask you for administrator permissions (UAC) and proceed.

Hello, problem in attached configuration file is that there are two statements setting this parameter, and the later one is max_allowed_packet=4M. Please make sure there is only one so that 33M value it is not overridden.

Hello, as you can see in MySQL documentation (see https://dev.mysql.com/doc/refman/5.6/en/server-system-variables.html#sysvar_max_allowed_packet),your max_allowed_packet value is default value and not 33M, so there must be something wrong with your configuration. Please make sure you put configuration of this parameter in "SERVER SECTION" of my.ini configuration file (section starting with [mysqld]).

I still think your best choice is to download ERA appliance, import in into Virtualbox/VMWare and copy-out those libraries even before configuration is required

Hello, you are using CentOS 6 if I recall correctly. In that case I would suggest to use Qt4 libraries we are providing in ERA appliances. You will find compiled libraries in /root directory (there should be two archives, one containing binaries and one vanilla source code it was compiled from). They are compiled specifically for this system and are using almost newest version of 4.8 branch - and of course they are tested ...

Hello, database MySQL 5.6 is supported, but it quiet hard to guess where problem is without installer logs (should be available in the same directories where all-in-one installer is located). I would recommend to verify that parameter max_allowed_packet is correctly set (there may be different my.ini configuration files overriding this setting) using some MySQL management tools (MySQL Workbench, HeidiSQL). Also make sure you have selected proper version of ODBC driver.

Hello, wee are currently using community MySQL 5.6 in our CentOS-based appliances and have not encountered any problem. Could you please check this: https://www.centos.org/forums/viewtopic.php?f=14&t=44526&start=20... seems it is almost the same problem.

It depends whether you back-uped certificates before reinstallation or not ... In case you have not restored certificates from backup you will be currently facing two major issues in connection of AGENTs: AGENTs will reject connection to SERVER because they will be missing CA certificate of new SERVER certificate SERVER will reject AGENTs because it will be missing CA certificate that was used to sign AGENT peer certificate. With missing certificates, there is no way around -> you have to repair AGENT installations (Remote installation, live installer - newly generated or manual repair) How to restore certificates from backup in case you have them (they can be extracted from DB backup with some effort if available): import back-up of CA certificates (public parts only) from old SERVER instance to new SERVER installation (using Webconsole) change SERVER certificate (Admin -> Server settings) to back-uped certificate [optional] wait some time until all AGENTs have connected (to be sure you can wait even days) [optional] you can change SERVER certificate to the one created during new SERVER installation and stop using old certificate Make sure you perform first two steps in this specific order, otherwise chance to restore connection will be lost.

Webconsole configuration and ERA seems to be OK. Have you searched the ERA SERVER trace log for related errors? (C:\ProgramData\ESET\RemoteAdministrator\Server\Logs\trace.log) If possible, try to login using different browser / computer to be sure it has nothing to do with cached files or cookies (incognito/private mode should be sufficient). In case connection failure is instant, I suspect it may problem in Apache Tomcat or Java itself -> any chance you updated/change your java runtime (jre)? Please try to search C:\Program Files\Apache Software Foundation\Tomcat 7.0\Logs\ for erorrs related to connection attempt -> maybe you will find out connection failure reason (it may be problem with SSL certificate validation). I would also check whether there is any connection attempt made during login (wireshark or tcpview tools)

Hello, seems server response is correct (you should receive about binary bytes). In case services are running, problem could be also: incompatible versions of Webconsole and ERA Server ... when reinstalling, installers were from one "release" package? Webconsole prefers IPv4 TCP connection and fails this way in case ERA Server is listening only on IPv6 port (i.e. check ERA Server is listening on both IPv4 and IPv6 ports using "netstat -an" command) Webconsole is connecting to different IP than localhost (this can be set in EraWebServerConfig.properties file). Please find mentioned file in webapps/era/ subdirectory and check values server_address and server_port to be valid (defaults are localhost and 2223).

How would you pull the certs from the DB and fix it? I'm familiar with Linux and mySQL; I just need to know where to look and how to tweak. I was attempting to switch a certificate over and screwed up my install on the appliance. Hello, peer certificates are stored in table tbl_certificates and PFX data in field certificate_pfx_blob. Certificate authorities are stored in table tbl_certification_authorities and useful data in fields pfx_data and der_data. First field contains both private and public part of certificate in case it has been generated using ERA.

Hello, could you please verify that "ESET Remote Administrator Server" is running (or even more check that process ERAServer is listening on port 2223) as most common reason for this "Communication error" is not running ERA Server. In case ERA Server was running, try to restart "Apache Tomcat" service that is hosting Webconsole. In case ERA Server was not running, please search trace.log for possible start-up issues.

Hello, unfortunately that is not possible. Computer name you see in console is based on reverse DNS resolving of IP that client connected from. I would recommend to use either of: Server task "Rename Computers" which will rename computer to FQDN reported by clients (the same value you see in "Client details"). Manually renaming computers, i.e. using "Rename multiple items" in clients view

Hello, I would suggest to check ERA agent trace logs located in /var/log/eset/RemoteAdministrator/Agent/trace.log or /var/log/eset/RemoteAdministrator/Agent/status.html for errors. Please check also time of last modification, so that we know agent is running.

Hello, I think it works correctly with 403 error (there is no index in that page) .. you can alternatively test complete url: hxxp://repository.eset.com/v1/info.meta that should download you metadata file. But again to core of your problem .. it fails only on one client? repeatedly? Task will be downloading a quite big file (MSI installer). Is client connection capable of downloading it directly in reasonable time (~minutes)? I would also suggest to enable DEBUG trace logging, re-run task and search trace.log of AGENT for lines with "SoftwareInstallation" -> you should be at least able to identify file that it fails to download

Hello, you can create ERA configuration policy for product "ESET Remote Administrator Mobile Device Connector" and set required values: in you case two settings: General -> Hostname General -> HTTPS Certificate Once policy is ready, assign it to computer with MDC. Alternatively you could use windows msi installer and repair installation with required parameters.

Hello, error message "Error reading HTTP response data" indicates that received HTTP data were not complete -> most probably connection was interrupted before all data could be downloaded (timeout?). I guess you are using "Remote installation" to Windows machine, but we will need to know where exactly you found this error (ERA Server trace.log?) because remote installation will download files on both ERA Server and also on client machine. In case it was download on client, please make sure hxxp://repository.eset.com/v1/ is directly available from client you are deploying, otherwise task will be failing.

Hello, those logs will be located in the same directory as Setup.exe (in logs subdirectory) once you start installation. Please make sure you have rights to write in this directory, otherwise installation will fail and there will be no logs.

Hello, when installing Apache HTTP proxy with other component in Windows (Bootstraper installer), key configuration parameters in httpd.conf look like this: CacheEnable disk hxxp:// CacheDirLevels 4 CacheDirLength 2 CacheDefaultExpire 3600 CacheMaxFileSize 200000000 CacheMaxExpire 604800 CacheQuickHandler Off ProxyRequests On ProxyVia On <Proxy *> Deny from all </Proxy> <ProxyMatch ^([h,H][t,T][t,T][p,P][s,S]?://)?([^@/]*@)?([a-zA-Z0-9-]{0,63}\.)?[a-zA-Z0-9-]{0,63}\.[e,E][s,S][e,E][t,T]\.[c,C][o,O][m,M](:[0-9]+)?(/.*)?$> Allow from all </ProxyMatch> <ProxyMatch ^([h,H][t,T][t,T][p,P][s,S]?://)?([^@/]*@)?([a-zA-Z0-9-]{0,63}\.)?[a-zA-Z0-9-]{0,63}\.[e,E][s,S][e,E][t,T]\.[e,E][u,U](:[0-9]+)?(/.*)?$> Allow from all </ProxyMatch> <ProxyMatch ^([h,H][t,T][t,T][p,P][s,S]?://)?([^@/]*@)?(ds1-uk-rules-1.mailshell.net|ds1-uk-rules-2.mailshell.net|ds1-uk-rules-3.mailshell.net|fh-uk11.mailshell.net|edf-pcs.cloudapp.net|edf-pcs2.cloudapp.net|edfpcs.trafficmanager.net)(:[0-9]+)?(/.*)?$> Allow from all </ProxyMatch> <ProxyMatch ^([h,H][t,T][t,T][p,P][s,S]?://)?([^@/]*@)?(87.106.247.14|209.157.66.250|209.157.66.253|212.227.134.125|212.227.134.126|212.227.134.128|212.227.134.130|212.227.134.131|212.227.134.132|212.227.134.133|212.227.134.158)(:[0-9]+)?(/.*)?$> Allow from all </ProxyMatch> CacheRoot "C:\ProgramData\Apache HTTP Proxy\cache" please verify you are not missing any part of those settings. From previously mentioned error logs it looks more like a network issue .. maybe wireshark/tcpdump logs from machine hosting HTTP Proxy could help. We can have a look at them in case you will be able to create them (dumps will contain private data -> do not post them here, use PM).

Hello, we have checked your problems and unfortunately you are experiencing specific instability issue we have already identified and prepared fix for next release. Issue was triggered by network connection timeouts (according to trace logs it could be your issue). In most cases no workaround is required, because AGENT service should restart itself automatically but seems that does not work in your case. Could you check in what state is agent service (when it does not work) using: sudo launchctl list com.eset.remoteadministrator.agent Also manual restarting of ERA Agent will restore its functionality: sudo launchctl restart com.eset.remoteadministrator.agent

Hello, can you please verify that you can access ESET updates servers from system hosting Apache HTTP Proxy, i.e. try to download hxxp://update.eset.com/eset_upd/ep6/update.ver directly from this machine. It should either download non-empty file or ask you for ESET credentials (no need to proceed with authorization for this test). Is there any firewall or other similar software interfering HTTP/HTTPs connections on this machine?

Hello, seems you are trying to install ERA from non-local disk (is drive "P:" mapped network drive?) but unfortunately this scenario is not supported due to installer limitations. In case it is you case, please uninstall components that were already installed and try again from local disk drive.