MartinK

When you open client details, you see more information? Are clients connection - according to last connection time in Webconsole? Does restarting SERVER service makes any difference? Could you please check AGENT logs on one of client computers? Especially status.html should provide quick hint what could possibly be wrong.

Could you please check creation date of msi installer you used to upgrade - exact date could be checked in digital signature section? We had problem that were fixed almost immediately but there is a chance your installer is not correct. Could you try to download current installer from ESET webpage and compare it with installer you used? Repairing SERVER to the latest and fixed version should fixed this issues.

Logs and other program data files are located in: /Library/Application Support/com.eset.remoteadministrator.agent/Logs/ as described in help

I'd be grateful if you could described required firewall rules here for future reference.

I have made some simple tests and this kind of construction seems to be working, at least in ERA 6.3. Is there a chance computer has not connected since you modified this template? Would it be possible to enable debug trace.log verbosity for client that should be matching second group and post it here?: create file C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\traceAll to temporarily enable full verbosity of trace log without configuration change restart AGENT service search trace.log for regex you used - there should be line containing regex, data that it was compared with and result. delete traceAll file Also I would like to inform you, that we have added support for "not regex" condition type, which solves this problem much more elegantly. It has only one limit -> both SERVER and AGENT must be version 6.3 or newer.

This is flow of dynamic groups content computation: dynamic group template is created or modified by user new or modified dynamic group is sent to AGENT (i.e. client must connect to get latest template version) client computes and sends to SERVER whether it matches this new dynamic group template based on locally available data. (there is high probability results will be sent to SERVER in the same connection, but not guaranteed) SERVER computes content of dynamic group and two conditions must be met in order to be group member: computer must be member of static group under which is dynamic groups is placed computer must be matching latest dynamic group template used in dynamic group - data already sent to SERVER are relevant. I would recommend to check whether clients that should be matching group are actually connecting. Also, check whether they are reporting OS as "Windows XP" and not as "Windows Xp" as example - you should see this in main clients view and probably also in clients detail view.

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component. What is error code / message of failing signature update available in clients's GUI? Every client is behind a central proxy server that controls their internet access, then there's a central firewall that blocks everything apart from HTTP/HTTPS, Clients can't download files from the internet, unless they have a specific internal IP address. This is in the Apache HTTP proxy error.log: [Tue Mar 01 11:22:06.678432 2016] [cache_disk:error] [pid 3368:tid 900] [client X] AH00703: Cannot cache files to disk without a CacheRoot specified. The error message on the client is: "Could not connect to server.", but that only happens when the ESET firewall on the server is enabled. If I disable it in Endpoint Security the updates work. To the first issue - please verify that CacheRoot is correctly set in httpd.conf - it should point to existing directory where cached files will be stored - now it looks like caching does not work's for you and Apache HTTP Proxy operates more like gateway. What were you installation steps in case mentioned value is not correctly set? Second issue seems to be definitely related to firewall. Is there any chance to find in firewall logs details about reason why this communication was blocked? Maybe there is bad port selected in rule, or rule is not properly applied for clients.

This is not exactly my domain, but what rules have you added to enable communication? Have you enabled both incoming connections client->proxy on port 3128 and also outgoing connections proxy->ESET? ESET uses IP/hostname based balancers and maybe endpoints started using different hostname that is not covered by firewall? There may be also related information in error log of Apache HTTP Proxy located in "Logs" sub-directory on installation - especially in case updates are sabotaged by this component. What is error code / message of failing signature update available in clients's GUI?

Easiest would be to check file C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html on client for replication errors. As you mentioned, it will be most probably network-related but there are multiple possibilities like: blocked port hostname cannot be resolved or is resolved to invalid address SSL/TLS certificate is not correctly validated for some reason AGENT may be configured for connection to different hostname/IP than expected - this may happen especially in case you used live installer or remote deployment. In case status.html won't contain useful information, you may search C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\trace.log for errors.

Hello Martin, first of all thanks for your fast response. We use the Apache HTTP Proxy for updates, the port is open since it used to work until Saturday/Sunday. I configured it using this article. ERA product are not manipulating firewall configuration in any way, so my guess is that Apache HTTP proxy was actually not running properly and therefore clients were not able to connect. There was a bug in Apache HTTP proxy itself in previous versions that caused proxy to stop working after some time - could you please verify version of your proxy? It can be find in CHANGES.txt file located in installation directory. Also there is "Logs" directory which may contain error log with more information. In case your Apache HTTP proxy is not of version 2.4.18 you may proceed with upgrade: more information can be found here: hxxp://help.eset.com/era_install/63/en-US/components_upgrade.htmbut do not forget to backup your currently installed proxy in case something goes wrong.

Unfortunately there is currently no list of supported application because it is version dependent. Referenced list is most probably for newer version of AVRemover (version in bundled in AGENT 6.3 installer is no longer newest) but in case 3rd-party product is not supported in the latest release, it is almost 100% that it was not supported in previous versions. In case 3rd-party product is not supported, AVRemover ends with "No applications found" and that is why task is considered as success. You may try to download latest ESET AVRemover from mentioned KB article and test whether it is able to detect and uninstall 3rd-party products you are using, but you won't be able to use ERA even in case it will work.

In case you are using Apache HTTP Proxy with configuration distributed with ERA, have you opened port 3128 for incoming connections. How are you clients configured, using HTTP proxy for updates? In case you are using HTTP server as mirror, you may create updates profile without proxy so that updates are downloaded directly from HTTP server.

Please try to run it manually using command /opt/apache/bin/apachectl start and check whether it works as expected - maybe there went something wrong during startup.

Could you please specify configuration you used (what products were selected). In what phase on installation occurred this - before actual installation of products? Is there any chance you used non-latin characters during installation wizard (for example asian characters)?

I am now even more confused than before ... are there any clients that are successfully connecting to SERVER? Is there any kind of security software installed on SERVER's machine (firewall, antivirus, load balancer) that could possibly interfere with network communication? Does restarting SERVER's service (or whole machine) makes any difference? Could you verify that is is ERAv6 listening on port 2222 and not other process?

All mentioned errors are performance-related as you noted. Could you please provide some configuration details? Free memory? Number of connecting computers? Have you had some "infection" in environment that could cause huge number of security event's to be received? As a workaround you may try to reserve more RAM for this machine or use more strict filter for this kind of reports. If I recall correctly, there is default filter for last 7 days - can you try to change it so that less data will be processed? Also we would appreciate if you could provide as more diagnostic information - if you enable full trace.log verbosity of SERVER (debug level in configuration) and access "Threats view", you may see something like this: 2016-02-29 08:51:49 Information: CDatabaseModule [Thread 7f2de67fc700]: Reports SQL: SELECT C.computer_uuid,C.computer_name,C.computer_comment,C.muted,NAIPV4.ip_address,NAIPV6.ip_address,FT.product,FT.description,FT.cause,FT.action,FT.severity,FT.occurred,FT.csn,FT.action_details,FT.restart_required,FT.scanner,FT.object_type,FT.object,FT.process_name,FT.circumstances,FT._user,FT.number_of_occurrences,FT.source_address,FT.source_port,FT.target_address,FT.target_port,FT.protocol,FT.inbound_communication,FTM.muted FROM tbl_computers_ids AS CID JOIN tbl_computers AS C ON C.computer_id=CID.id LEFT OUTER JOIN vw_frontend_threats AS FT ON FT.sourceuuid_id=C.computer_id LEFT OUTER JOIN vw_network_ipv4addresses_aggr AS NAIPV4 ON NAIPV4.source_uuid=C.computer_uuid LEFT OUTER JOIN vw_network_ipv6addresses_aggr AS NAIPV6 ON NAIPV6.source_uuid=C.computer_uuid LEFT OUTER JOIN vw_log_newest_threatsmute_event AS FTM ON FTM.sourceuuid=FT.sourceuuid AND FTM.logid_product=FT.product AND FTM.sequence_no=FT.sequence_no WHERE (FT.product <> 0) AND (FT.severity IN (3,4,5,6)) AND (((FTM.muted = 0)) OR (FTM.muted IS NULL)) AND (C.removed = 0) 2016-02-29 08:51:49 Information: CDatabaseModule [Thread 7f2de67fc700]: Reports time: total: 6ms (cpu) total: 22ms from mem: 0ms to db: 0ms from db: 0ms guard: 0ms sql exec: 2ms 2016-02-29 08:51:49 Information: CDatabaseModule [Thread 7f2de67fc700]: Reports rows: read: 0 to db: 3 from db: 0 2016-02-29 08:51:49 Information: CDatabaseModule [Thread 7f2de67fc700]: Reports: protobuf size: 0.00 MB in SERVER's trace.log, which will tell us how many data it is actually loading from database.

Could you please check trace.log on you SERVER and search for network related errors. Especially DNS resolving or hostname resolution could be reason for this issue.

Yes, you should enable multi-threading. It is not only due to performance, but also for certain functionality that requires it - for example canceling SQL queries that are no longer required.

These error means that there is "something" connecting to SERVER (most probably port 2222), but it is not ERAv6 AGENT. For example it could be ERAv5 connections which is expected in case you have migrated from v5 to v6. In case you are sure those are ERAv6 AGENTs connections, there is most probably something interfering communication in the way it is no longer recognized by ERA - in this case capturing network traffic on port 2222 using Wireshark or similar tools may help in analysis of this problem. One last hint - your AGENT installed on the same machine as SERVER is connecting to 192.168.55.12 instead of default "localhost" -> you could try to change it (by repair) back to "localhost" or "127.0.0.1" and check whether it helped. This change could possibly bypass firewall if present.

Yes, only SERVER has to be stopped during command execution. It should fix the issue until some "rare" circumstances occur.

There are no related errors in trace log. I suspect that DNS resolving either does not work correctly (1. case) or resolves SERVER's hostname to wrong IP address (2. case). I would try nslookup or ping of selectasvr.RSELECTA.LOCAL on client machine. Alternatively you could try to manually repair AGENT installation and change hostname selectasvr.RSELECTA.LOCAL to IP address of your SERVER so that there will be no DNS resolving preceding connection attempt.

Thanks for your patience and help. Now we are almost sure what is the problem - it is quite rare and only workaround is to force re-computation of task states by this database command (please make sure SERVER is not running!): mysql --host=localhost --user=root --password era_db --execute 'UPDATE tbl_etl_event_csn SET last_csn = 0 WHERE plan_name = "sp_clientTasks"; DELETE FROM tbl_client_task_aggr;' After SERVER is started, it should synchronize data, which may take some time (should be no more than minute).

First issue on client PC seems to be problem with DNS name resolving. Could you please verify that client can resolve hostname of your SERVER? Next command will try to resolve hostname using system resources: nslookup selectasvr.RSELECTA.LOCAL in case it fails, problem must be somewhere in network infrastructure - especially in case hostname was supposed to work. For second issue there are multiple possibilities: Is SERVER running? Can you log into Webconsole? Does restarting SERVER service makes any difference? Are there any network or SSL/TLS related errors in SERVER's trace.log? Are you using firewall that could possibly cause this?

This scenario is currently not supported - direct connection from ERA Server to client machine is required. In case there is no way how to connect, you will have to consider other means of AGENT installation, for example "Live installers". No, Rogue Detection Sensor is able to detect only machines in LAN it is connected to. In case you have not machine which is connected to all LANs, you will have to install multiple Sensors. Installing it side-by-side PROXY may be ideal solution in case first condition is met. There can be multiple Sensors in your environment - detected machines will be propagated to ERA through "managing" AGENT installed on the same machine as Sensor.

Proper value depends on number of clients you are managing, amount of collected data and overall performance of MySQL database. In case value 600 is not enough, you may increase it (maybe to 3600). Also have you checked whether multi-threading is enabled for your MySQL driver (/etc/odbcinst.ini)?