MartinK

Please check AGENT's trace log (C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\trace.log) for errors - especially those just after service startup. It seems AGENT is not able to fetch system information. We have seen similar issues when WMI provider was not running properly.

Could you please restart the AGENT service on the target machine? Are there any errors in AGENT's trace.log? There is a chance fetching installed applications fails for some reason and therefore old state is reported. If possible search windows registry (regedit) on client machine for string "6.3.2012.0" to be sure there are no remnants of previous version. Are there multiple machines with this problem or only this one?

Exported configuration can be seen (and requested) in client's details view, in subsection "Configuration". There will be also possibility to convert exported configuration to policy - which I guess is exactly what you want.

There should be no need to manipulate your certificate store. Mentioned KB recommends to install specific windows hotfix that enables applications running on Windows 2003 to verify SSL/TLS certificates signed by SHA2 based algorithms. Certificate should be the same as is used for ELA portal -> you may check whether it is considered as valid when opened in internet explorer on your server.

Actually it may be the problem. Please follow steps for troubleshooting error code 4099 in ESET KB2434. Not sure you have this problem (we would need SERVER's trace log to clarify) but there is specific problem with Windows 2003 as this older and no longer supported system is not able to verify new SSL/TLS certificates used by ESET licensing. Imported licenses are mostly for management, but without imported license, SERVER won't be able to update it's modules introducing new functionality, especially improvements in localization and security products configuration. You don't have to explicitly activate Remote Administrator Server, but you should synchronize/import your license.

Computer name in ERA is not dynamically changing - it is based on reverse DNS resolution of IP address from which AGENT connected for the first time (especially in case computers are created in Lost&Found group). In case computers are changing name in time, you may use "Computer renaming" task to rename computer based on hostname they are reporting - this task is most probably configured to be executed automatically only over Lost&Found group.

What database type/version are you using? Installation using unsupported MariaDB results in similar state where specific database operations are silently failing rendering ERA hardly usable.

Just checked again your configuration and there are two statements configuring value of max_allowed_packet in section [mysqld]. The second one (max_allowed_packet=4M) will override value of first and that will be reason why ERA database checks are failing. Also be aware that ERA supports MySQL since version 5.5 and does not support MariaDB at all. More information about database check failures may be available in installer log: /var/log/eset/RemoteAdministrator/EraServerInstaller.log

I am not sure as it not clearly visible from your screenshot, but AD synchronization task expects absolute (full) distinguished names for excludes. This means all excludes should contain also DN you specified in "Distinguied Name" field. In case you won't be able to make it work, please provide full DN name of specific server and other parameters -> you may of course replace sensitive information with something else, but please replace it with the same word in all distinguished names so that we can compare them.

Hello, parameter innodb_log_files_in_group is of numerical type and expects number between 1 and 100 according to documentation. I would suggest to try innodb_log_files_in_group = 2 and restart server. Have you seen it using 2M somewhere in ESET documentation or KBs?

Right. There is also alternative: when creating live installer or remote deployment task it is possibility to specify "server hostname", which is where newly installed AGENTs will be connecting to -> you may specify PROXY's hostname so that AGENTs are connecting to PROXY directly from beginning. Otherwise they would have to connect to SERVER for redirection configuration policy as in mentioned KB - which may not be possible for all scenarios.

Is there any specific reason you are using 32bit Java JRE as tomcat/system seems to be 64bit? We cannot be sure from provided logs, but it seems there is problem with running Java and it may be problem with 32<->64 mismatch. I would also check PATH environment variable for user account that is used by service to be sure Java is accessible.

Not sure I understand you correctly, but ERAv6 architecture is different. There should be only one ERA server in infrastructure which is collecting all logs. ERA Proxy is only used to redirect communication between clients and this main SERVER - mostly due to network traffic or visibility limitations. All clients are managed from main SERVER. In case for some reason you are not able to access Webconsole interface from specific part of network, it is also possible to deploy multiple tomcat instances (i.e. on the same machine as is PROXY) and configure Webconsole to communicate with remote ERA Server. Is this what you require?

You were right, we are not installing "redirection" of root when installing on Windows using all-in-one installer -> it is available only when ERA appliance is used. Simplest (and solution used on appliance) is to create redirection file <tomcat installation path>/webapps/ROOT/index.html with this content: <!DOCTYPE HTML> <html lang="en-US"> <head> <meta charset="UTF-8" /> <meta http-equiv="refresh" content="0;url=era/" /> <script type="text/javascript"> window.location.href = "era/" </script> <title>Page Redirection</title> </head> <body> If you are not redirected automatically, follow the <a href='era/'>link to ERA</a> </body> </html> and your browser should redirect you automatically.

Could you please specify what deployment scenario/platform/version are you using? Redirection of "root" requires trivial tomcat configuration changes or creating redirection file -> and If I recall correctly, it should be created during setup.

Please follow KB406 to generate full installation log -> it may contain reason why this is happening.

Managed computer will be re-created each time it connects to ERA server -> you have to uninstall AGENT from this machine. In case both of clients with the same name are connecting, one of them will be most probably wrongly named and it will be two different AGENT installation = two different computers. Please check computer identifier in client details view to find out which one is correctly named.

That is correct. ERA does not manipulate AD/LDAP storage in any way. You may use read-only user to access AD/LDAP to be sure nothing can corrupt your infrastructure.

Not sure what version of appliance you are using (there is no CentOS 7 based), but for latest released version 6.3.12 check file /root/firewall-ports.sh and add required iptables rules. One finished, run /root/firewall.sh or restart appliance. There is no other configuration required in ERA.

It is internal error according to KB2434. Please try it later and if it fails, contact support.

Yes, that should be right order.

Yes, uninstall "MySQL Connector/ODBC 5.3" and install older version - it should be named the same, except version will be older. Be sure you are re-installing driver for proper platform (x64), as difference is hardly visible in control panel in case you have also x86 version installed.

We have similar reports being just now investigated. It does seem SERVER is not properly working with latest MySQL ODBC driver (5.3.6) released this year. Any chance driver has been updated recently? You may check it's version in Control Panel -> Administrative Tools -> Data Sources (ODBC) in tab "Drivers". In case "MySQL ODBC 5.3 Unicode Driver" will be of version 5.3.6, revert it to version 5.3.4 (Download from MySQL archive: hxxp://downloads.mysql.com/archives/c-odbc/).

What is logic of applying polices to client? Based on some dynamic group? For scenarios like this, I would suggest to use dual profile for updating described in hxxp://support.eset.com/kb3621/-> manual is focused on HTTP Proxy configuration, but it should work also for you if you correctly specify profiles priority.

Please search SERVER's trace.log for "Errors" that may indicate problems. It may be database related - data may have been queued or even dropped in case database write operation failed. Is is possible to verify whether only last connection time is incorrect? For example version of virus database is updated? Are problematic clients connection directly to SERVER or you are using ERA Proxy?