Jump to content

MartinK

ESET Staff
  • Content Count

    2,281
  • Joined

  • Last visited

  • Days Won

    66

Everything posted by MartinK

  1. If my understanding is correct, you created installer where you included policy for EFDE? If so, it is actually expected behavior, as installer will just configure installed product to use settings from embedded policy, but to enforce settings, policy has to be applied also in console in a standard way. If so, solution would be to visit policies screen and assign required policy to groups or devices. In other words, policy as included in installers are intended primarily for initial configuration used until management agent is able to fetch policies and other properties from ESET PROTECT.
  2. Could you please check EP's trace.log for possible network-related issues? It seems that communication with ESET repository servers might be failing and thus EP is not able to decide whether installed version is latest or not. Also what platform, DB type are you using? What was previous ESMC version used before upgrade?
  3. Most probable reason for this behavior is that EP is receiving much more data, that it is able to handle (write to database) - could you possible check performance dashboard for "pending logs"? Also were there any changes in configuration of your environment that could possibly result in much more data generated? For example changes in various detection methods and especially reporting, or maybe changes in EEI rules (filtered websites, firewall, webcontrol)? Any change there is some degradation on DB layer which might be no longer able to handle data processed by EP? Also is it possible to c
  4. As already mentioned, you have to assign it at least to device where RDSensor is actually installed, but nothing would happen if you assign it to group All - devices where no RDSensor is installed will ignore it, and in case you will deploy new sensor on different device in your network, it will share the same configuration.
  5. I can think of only two possibilities: maybe Apache Tomcat is performing re-deployment of era.war - what method you have actually used for installation of it? Is era.was still present in webapps directory? or maybe there is a components upgrade task scheduled on this client, which also attempts to upgrade console? But this process should retain original configuration file, so it is less probable this is the problem. Otherwise web-application itself does not require write access to deployed files (in webapps) and is not modifying them, so it will be most probably something from
  6. Also if possible, please provide us details of your use-case, so that we can possibly focus more on this scenario. We are mostly interested why are you collecting such data, what is the expected output and what would you do with reports generated in console (i.e. postprocessing) - especially in what granularity you are analyzing them, whether you are just checking some statistics or you are interested in per-request granularity, etc....
  7. Actually it is mentioned also in referenced KB that you should be testing download either directly on specific installer, or at least on metadata file: http://repository.eset.com/v1/info.meta http://repositorynocdn.eset.com/v1/info.meta or even this ones are failing? Metadata file for each product is downloaded separately, so it is possible that only certain requests do fail and thus only specific products are missing.
  8. I would recommend to check size of database table tblf_webcontrolagregated_event to confirm that issue with report filters is caused by amount of data collected, and not some other issue. If so, solution might be increasing performance parameters of your DB server (if possible) or removal of data, but is not recommended in case there are not more significant impacts. Also what are the performance characteristics of your DB server? And what type of DB server (MySQL or MS SQL Server) is actually used?
  9. Just to be sure, but by "only check in when they are turned on" you mean that do connect only once, after they are started, and another connection attempt is made after reboot? If so, I would double-check configuration of interval, especially in case "cron" based configuration was used. Also as mentioned, troubleshooting of such device connectivity will be required, as issue might be also related to network configuration, which might prevent subsequent connections, especially in case there are other security/VPN products used or strict firewall configuration is applied.
  10. In case it wont helps, I would check EP's trace.log for errors indicating failure with repository synchronization. That might be the first step to confirm it is indeed some network related issue - synchronization is performed every hour, so there should be quite a lot of errors in case it is the case. It network-related problem is indicated by trace.log, one might use tools like wireshark to capture network traffic (communication with ESET repository servers performs quite a lot of standard HTTP downloads), but in case problem happens outside of monitored device (i.e. on proxy, firewall or
  11. Unfortunately I am not aware of how Intune works and what are its capabilities, but even when you used all-in-one installer for deployment, it is just wrapper over standard/standalone MSI installers, so I would expect uninstall will work as with other such packages. Even uninstallation from console works in a way it uses msiexec calls to uninstall product - there is no custom logic behind that. Standalone installers can be downloaded manually, but maybe even better solution, at least for management agent would be to use installer stored on client device on path: C:\ProgramData\ESET\Remot
  12. Could you provide more details of how database was actually migrated? According to logs, there indeed seems to be some problem with DB schema, but that should not happen in case of standard backup/restore mechanisms, so something must have gone wrong. Regarding mitigation, I have suspicion that there will be much more of similar issues, and as we have no clue how it happened, it is hard to provide any hints. I would definitely recommend to open support ticket with your ESET representatives for futher analysis - my best guess is that analysis of your current DB schema, and it's comparison w
  13. Please also check whether your Java version is actually distributed. Seems that there might be similar issues with latest Java versions, as mentioned in another topic:
  14. In the meantime, I would recommend to check configuration of firewall, http proxies or other similar tools, that might possibly block HTTP requests. As an example, repository requests might be redirected to public CDN server which might be blocked, by your infrastructure, and it would explain why it work randomly.
  15. Alternative might be to use conversion of exported configuration to policy, but it would require some client's configuration to be actually requested by console (and still present there) from time when settings were applied.
  16. There seems to be some issue with TLS communication, most probably related to certificates - but it is not clear from provided logs. Any chance there are some client that are not able to connect? As an hint, IP addresses from logs can be used. Could you possibly check logs/ status.html logs on such clients? My guess would be that clients are rejecting EP's certificate and thus interrupting connection attempts...
  17. I would recommend to open support ticket so that more details can be asked/provided. In this case it seems there is some kind of database corruption in EP database, resulting in state when client(s) are not able to fetch updates of "management objects". This does not happen very often and there is no generic mechanisms how to resolve, thus further analysis will be required.
  18. Component upgrade task upgrades only ESMC/EP components, as is ESET Management Agent, ESMC Server and ESMC WebConsole, but it does not upgrade other, especially third-party components as is Apache Tomcat, Apache HTTP Proxy or MS SQL Server. Thus benefit of performing manual upgrade using all-ine-one installer for Windows, or performing upgrade ot EP/ESMC Appliance using "migration" to new version, is that also third-party and and possibly other support tools are upgraded. Also note that manual upgrade is less prone to failures caused by environment issues, as are those network related, but
  19. Could you please check or post how task configuration actually looks like? It is crucial that version 8.0.1258.0 is mentioned in configuration, i.e. the most recent version of EP.
  20. In that case task was probably executed, and it failed. If so, please try to open history of execution of such task on specific devices, and possibly check it for indication of failure. Most common issues in this case are network related problems (HTTP proxy) but also outdated/no-longer-available package version in task configuration. Also please double check correct product was selected for upgrade, and especially whether selected product is actually supported on operating system version you are using.
  21. Could you please double check that it is actually Apache Tomcat that is listening on port you are using? Are there possibly other HTTP/HTTPS servers that might be using the same port? In case you confirm that there is actually running Apache Tomcat and it is listening on expected port, could you please try different browser? Or possibly temporarily disable any security-related products that might be interfering with connection. In case you will find out that there is something wrong with Apache Tomcat itself, I would recommend to double check thathJava is properly configured - we have see
  22. If I recall correctly, there are some issues with newer connectors on Linux - so it is possible that those version do actually work on Windows platforms. Problem with linux variants is way how ODBC connectors are built, which conflicts with EP application itself.
  23. From provided logs it is not possible to find out what went wrong, but it seems that upgrade might have been interrupted and thus database schema is currently incomplete. I would recommend to perform EP server repair using installer, that can be found here: /opt/eset/RemoteAdministrator/Agent/setup/installer_backup.sh which might help to restore database, but be aware that after that, another attempt to upgrade will be performed during next service startup, where it might take some time (depending on DB size) and during this time, console won't be accessible. Also note, that possib
  24. Could you please check this issue was resolved? After re-download of installer, new version of installer should be used (it will show 4.0.14.0 in file details), which seems to be targeting also this problem.
  25. I will have to double check, but issue should be resolved and installer should be rolled-out next week. Once done, all new installers should be working correctly in your scenario.
×
×
  • Create New...