ESET Staff
  • Content count

  • Joined

  • Last visited

  • Days Won


MartinK last won the day on April 3

MartinK had the most liked content!

1 Follower

About MartinK

  • Rank

Profile Information

  • Gender
  1. My personal recommendation is to enable status logs ( that will log each cahce hit or miss. This will enable you to check whether any requests are handled by cache and whether they are actually served from cache. It is also possible to use various apache modules for monitoring status and load. For example module mod_status (blog) may help you to monitor at least server activity, number of connections and transferred bytes.
  2. Have you tried to install AGENT manually or any other supported method, i.e. bundle installer? Both method you tried are based on the same bat file, therefore isue with installation script will result in failure of both of them. I would also recommend to try manuall installation of AGENT, with enabled full msiexec logging for furhter analysis in case it will fail.
  3. You have not mentioned sizing (number of managed computers), but in case you manage more than ~10000 computers, it is recommended to use SQL Server as a database server. In case you manage less computers, there should be no performance difference between Windows/Linux platforms. I guess Windows is simplier to manage for most of users, but that is affected by administrator's prefference. Regarding ERA, installation is more straightforward on Windows platform (all in one installer, interactive with GUI) and it is simplier to configure all ERA features, especially those intergrating ERA with AD/LDAP, including login into domain. Installation on Linux may be more complicated, but you will most probably get system with much lower memory footprint, especially in case of "headless" installations.
  4. Could you be more specific of deployment scenario that was not working because of specific vendor name? We had not seen any such report and compa in vendor name is used for a long time as it is par ot official company name.
  5. Dynamic group condition is evaluated over list of all network addrees available on client. In your case, based on screesnhot, there are two values that are compared with dynamic group condition, namely and fe80::/64. You can see that second one will be matching your condition regardless of IPv4 network that this computer is currently connected. It is possible to improve this behaviour by adding second condition defining Network IP addresses . Address type == IPv4, but it won't work properly in case computer that is not in company network has multiple IPv4 networks. I would recommend to redesign dynamic group template to: Unfortunatelly I had no time to test it, but I would give it a try. You can also tweak conditions in case IPv6 is used also. Technically this template is negation os "computer is in company network".
  6. Please check in what state is PROXY itself. IS it connecting to ERA? See status.html log of PROXY (not AGENT on the same machine) whether it is connecting. Seems AGENT connecting to PROXY are timeouting, i.e. they do successfully connect, but they are not handled in time - this could be caused by broken or extremely slow database. Is there enough resources for PROXY and it's database. Is PROXY'ss databse on local machine or remote - if remove, is network connection between them sufficiently fast in terms of response times?
  7. Could you please re-run installation with sudo bash -x so that all commands performed during installation are visible? Errors does not make sens, for example file /tmp/postflight.plist should have been created even before installation itself. Agent is also not starting because of missing files...
  8. PROXY logs should be located in C:\ProgramData\ESET\RemoteAdministrator\Proxy\EraProxyApplicationData\Logs\. I would recommend to check status.html first as it will highlight last connection error.
  9. Please check trace.log and status.html log of this PROXY installation. There will be most probably problem with configuration or certificates. Does not seems as issue with network as "managing" AGENT is connectint successfully to SERVER.
  10. New module version 1461.18 should be available for a few days. Could you check whether you have received this update and whether it helped?
  11. This error was present in ERA (6.4), and was triggered by bug in "proxy fallback" mechanism. If this is the case, it means that download through HTTP proxy failed, and another attempt by-passing HTTP proxy failed with mentioned error. Are you using HTTP proxy? Could you check whether it is running properly?
  12. Thanks for reporting. There seems to be a problem with "paging" -> could you try to disable it temporarily whether it helps? Paging controls are available in bottom-right corner by default.
  13. Just guessing but is SELinux enabled on this machine? If I recall correctly, SELinux-enabled systems are not supported by this product. I would recommend to check audit logs or test functionality with SELinux switched into permissive mode in case it was enabled previously (in enforcing mode). Another possibility is that sshd is running under user account, that is for some reason not able to access mentioned shared memory. Is SSHD running with root privileges?
  14. I think that this was caused by repository content update (= seems latest EEA/EES for MAc OS X has been added as MichalJ promised). Matadata file that was temporarily unavailable in repository and caused your failures contains metadata for updated products. I would recommend to re-run task on failed client computers.
  15. We have seen this behavoir in case of Windows XP and I do not recall final solution. What I think is that you need to enable "Anonymous access to network shares", see for example this article. Be aware that this configuration may not be secure.