Jump to content


ESET Staff
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by MartinK

  1. Could you possibly provide some logs or output summary so that we can check which phase actually fails? My understanding is that generated live installer (BAT) is used, which actually downloads MSI installers from ESET repository servers, and once done, it verifies it's checksum using tool, that is part of installer script, which might theoretically also fail in case of very strict protection rules, but we have not encountered that yet.
  2. Not exactly sure I understood question correctly, but in case you would like to install AGENT using standalone MSI installer and INI configuration file used/generated for GPO deployment in console, it is expected to be used in silent mode. Such installation can be started from command line for example as: msiexec /qn /i Agent_x64.msi where configuration INI file has to be placed in the same directory as is MSI installer. In case standard GPO/SSCM or other third-party tools are used for deployment, you have to consult installation mode with manual of those tools, but silent install
  3. Please double check also HTTP Proxy configuration if it is used, as it might also result in download errors. Provided error string indicated that client failed to connect to HTTP proxy, and then failed to connect directly to ESET servers, so probably it is crucial to have HTTP proxy working in case direct access to internet is not possible.
  4. Install date is most probably not reported as it was not required, and this specific reports is one of the largest so it makes no sense to report data. But regardless of that, I do not think that just this date would resolve original request. More suitable would be to remotely collect also audit logs as generated by ESET security product locally. It might be partially remediated by collecting so called "event logs" (which is possible even now in management consoles) but that would probably not provide all details.
  5. Could you please provide more details of your environment? Are you using appliance provided by ESET, or is it your custom linux environment? Also please provide more details of how you ended in a state when console has different version than server - have you actually executed in-product upgrade?
  6. As mentioned, ESET PROTECT Appliance is based on CentOS7 that should be supported for some time. Regarding future versions, it is currently not decided. I would personally expect more stable variant than CentOS Stream to be used, but there are not so many long-term support distributions.
  7. Could you please provide more details of why would you want to restart AGENT's service? Asking as it is protected by product and mostly there is no need to restart it.
  8. Just to let you know, problem was indeed triggered by localized Windows operating system, i.e. operating systems where certain status messages provided by system itself contained non-ASCII characters. Unfortunately problematic helper tool UpdaterService.exe is part of already installed version 7.2.1266.0 and therefore proper solution was not possible and upgrade from this specific version to any new version will report this kind of failure even when upgrade will be successfully. Also it has been confirmed that upgrade from version 8.0 is not affected, so there should be no such problem wi
  9. Any chance firewall is used that might block access of AGENT to ESET repository servers and thus failing, depending on where AGENT is downloading package from? Various data-centers and public CND providers are used to server installers, so missing access to one of them could result in seemingly random failures.
  10. Could you please check whether there are any custom blocking rules for HIPS used on problematic machines where upgrade fails with mentioned error? We have recently discovered issue where invalid HIPS rules might result in a state when self-defense is preventing upgrade of AGENT. If I recall correctly, issue is triggered by providing path to executable in quoted format. If this is the issue, correcting HIPS rules should resolve the issue remotely - also there should be an update of HIPS module rolled out soon that targets this issue.
  11. Actually it could have been ENU, but this device seems to have been deployed from Japan version of ESMC (maybe just installer created in such ESMC was used), or possibly just migrated from such environment. But regardless of that, this AGENT won't upgrade automatically when task is executed from non-Japan ESMC, so I would recommend to upgrade it manually, i.e. using any installer type create in ESET PROTECT. In case there are many of such devices, we might think of some more automated workaround (for example using run command task...). Also I will probably report this, as even if it won
  12. In short, problem is, that this version of AGENT (7.0.579.0) was to be used only with ESMC that was distributed on Japan market and thus it has a specific versioning and compatibility settings. In case it is used with non-Japan ESET PROTECT, it won't upgrade automatically and only possibility is to upgrade it manually -> and once it will be upgraded to globally available version (= compatible with your ESET PROTECT), it will have no issue in upgrading next time. Could you please confirm machine was previously managed by Japan ESMC installation?
  13. In that case I would recommend to create so called "Delete Not Connecting Computers" server task, that will automate removal of devices that are not connecting for some time. Please check documentation of this task for more details, it enables administrator to set various removal parameters.
  14. Thanks for letting us know. Just to let you know, you probably have quite old "appliance", and even when ESET product itself is upgraded and it will work properly, I would recommend to use "migration" style of upgrade when you will decide to upgrade to next ESET version. It is fairly easy process (documentation link), especially in case there are no custom modification made to operating system / appliance itself. During migration, whole ESET ESMC database is transferred to newly deployed appliance, which might contain various fixes that are not part of standard ESMC upgrade procedure - as
  15. Could you please provide more details of what firewall type was used, and possibly also what detection/blocking module had to be modified? As hostname/IP addresses of repository servers has not changed, I suspect there is some kind of whitelisting of executables or more advanced techniques used by enterprise firewalls.
  16. Could you please provide more details of what is not working as expected that you would like to make database cleanup? There is currently nothing like user purge -> all possible cleanups are made automatically. But maybe if you provide more details, at least some workaround might be found ...
  17. I would just double check that ESET products can successfully update before enabling globally, to be sure you won't have issues with this, as it is most crucial for security to have access to latest updates and possibly also communication with eset services.
  18. In case Windows is used, I would recommend to download latest all-in-one installer for ESET PROTECT 8.0 and upgrade using it. It will upgrade all components, including third-party as is database or apache tomcat. Regarding non-responsive console, in case Apache Tomcat is actually running, most common issue is that it cannot locate Java executable - maybe it was updated prior to forced restart of system caused by power failure?
  19. Could you please clarify what is actually missing? It is not clear from provided screenshot - you are not able to add any new data field to report template?
  20. Could you please clarify that you have upgrade appliance to latest version using "migration" mechanisms? Asking to be sure you are using latest version of both appliance and Apache packages as available there. Regarding issue with slashes, if I recall correctly, we have encountered it also with Windows variant, where it has been mitigated by adding directive: MergeSlashes OFF into Apache configuration file, which is in appliance located in: /etc/httpd/conf.d/proxy.conf Could you possibly try to modify configuration, restart proxy service (systemctl restart httpd) and verify?
  21. Unfortunately I am not sure it is error described in provided links, as in case of our service, connection fails sooner than actually URL can be accessed. I would recommend to open standard support ticket with ESET, where more details will have to be provided, as are details and versions of VMWare environment, and possibly also network captures (wireshark) to verify what is going on and whether it might be wrong URL used by our service, or some other issue, for example with certificates or TLS algorithms.
  22. Could you possible check trace.log in full verbosity for more details? Otherwise error indicates that there is an issue during TLS handshake with VMWare, which might be caused either by incompatibility between protocols, or certificate validation fails - for example there might be missing CA certificate in console required for validation. Also it is required that certificate properly signs hostname where PROTECT server is connecting, i.e. used hostname has to be present in certificate's common name or subject alternative name fields...
  23. I have asked around and no such issues was reported recently, so my only suspicion is that there is some problem with caching - any chance some caching proxy is used in your company that might result in a state where old files are served to clients? Or any specific chrome plugin is used in company? As a workaround, possibly cleanup of cookies for ESET PROTECT instance, or maybe even cleanup of cached files for this domain might help. Otherwise I would recommend to open support ticket as it might require further analysis - for example capturing so called HAR logs in browser might be required
  24. Could you please provide more details of what is actually not working - is it actually authentication? Or not even login screen is loaded? Also is it possible to verify behavior with different browser or possibly from different device?
  25. It will be most probably in standard logs directory of AGENT, most probably here: c:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\ where name will contain "upgrade". It's content should be standard msiexec log output.
  • Create New...