Jump to content

MartinK

ESET Staff
  • Posts

    2,503
  • Joined

  • Last visited

  • Days Won

    71

MartinK last won the day on December 13 2022

MartinK had the most liked content!

9 Followers

About MartinK

  • Rank
    Newbie
    Newbie

Profile Information

  • Gender
    Male
  • Location
    Slovakia

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Can it be confirmed (via audit log) those report templates were actually removed? If so, they should be re-created upon next PROTECT upgrades (in a few weeks) or it can be forced manually - but that would work only in case they were actually removed, not in case of other issues. Also note that this might be caused by missing permissions to access report templates - but that is case only in case it was not tested using administrative account which should have access to all objects in the console.
  2. I would recommend to contact support in this case. In your case, you are performing upgrade with modification of configuration and thus I would expect password to be required so that crucial configuration is actually protected. But regardless of that, seems that this change is not properly documented, as there is possibility to enter password as part of the command line (or as part of install_config.ini property file used by installer), which would resolve this issue.
  3. Be aware that such commands are executed in security context of LOCAL_SYSTEM (i.e. service accounts used to run ESET Management Agent) and thus it might have specific limitations tied to to. For example, such service account might have limited access to the network - especially if domain authentication is used. If this is not the issue, I would recommend to run command also with msiexec logging enabled for further analysis.
  4. Could you please more details of your concerns regarding current interval? As of now, indeed interval is not configurable, but since older versions, communication protocol was optimized in a way that there should not be a big connection overhead, especially not in case persistent connection are working properly (depends on network configuration). There are also transparent push notifications used in cloud PROTECT which improves responsibility of the clients for changes. In case there are come limits, would it be possible to provide us to us, i.e. what would you consider as reasonable traffic use for example in one hour?
  5. Indeed AGENT stores it's own version and other similar details here. Another alternative might be to search for version in the "MSI" database in registries, but it has no fixed location, so it would be less reliable = but on other side, it will correspond to data as shown in Windows itself and also in the console.
  6. This part of the configuration file: innodb_log_file_size= 100M innodb_log_files_in_group=2innodb_log_files_in_group =2 does not look correct and that is probably reason why second setting is probably ignored.
  7. In case you are using GPO deployment method, i.e. distribution AGENT installer with configuration in install_config.ini file, simplest would be to modify install_config.ini by adding PASSWORD=... as visible in referenced KB6745. I guess you already modified this configuration file with new IP address or hostname. Also note that if AGENTs are configured to connect IP address or new hostname, certificate of ESEET PROTECT Server service has to be adapted for this if it was not previously (especially in case certificate is not using wildcard host which is not default). Otherwise AGENTs will be rejecting connection as they will consider it as an unsecure. IF this is the case, you will have to follow one of the migration scenarios - most probably this one: https://help.eset.com/protect_install/80/en-US/?migrated_database_same_ip.html. In the most optimistic scenario, creation and application of new ESET PROTECT Server certificate with proper configuration should resolve this - especially in case the same certificate authority will be used to create new certificate.
  8. Thanks for letting us known. Would it be possible to check system logs (even viewer) for any clue that would provide more details of why was service removed? We have seen similar reports related to Windows7 -> Windows10 migrations, but not sure we found out where the problem is - especially because we are using fairly standard mechanisms for service registration, and my only idea is that service was removed due to some incompatibility detected by Windows itself.
  9. Before you get response from ESET support, I would recommend to troubleshoot network connectivity, especially between ESET PROTECT Server and ESET repository servers (http://repository.eset.com). Creation of all-in-one installers heavily depends on download of multiple larger files from ESET repository. Also note that firewalls and HTTP proxies in between should be verified in case it won't be clear where the problem might be. As ESET PROTECT Appliance is in use, I would recommend to check there is enough free resources (disk space and RAM) during procedure - creation of all-in-one installers might be resource consuming (even few hundred MBs of RAM might be required).
  10. Could you please clarify relation between RMM plugins and ESET PROTECT 10.0? Asking as purpose of those plugins is not bypass need of ESET PROTECT in a first place, and mentioned executable was never part of ESET PROTECT packages - or do you mean ESET Endpoint Security 10.0 for Windows is not manageable by DEM plugins after upgrade?
  11. Any chance you found out what was going on? From logs I can confirm, that original problem was caused by problem with database - for some reason, it ended up in an inconsistent state in terms of our data. This is something that can be possibly resolved with help of ESET support, but might not be as fast - depending on impact. So reverting database to previous backup was recommended step. But it is crucial to resolve source of the problem as it will most probably occurs again, especially in case there is problem with underlying storage or disk size limitations. Regarding MySQL configuration, there are few parameters that has to be set properly to use MySQL server for ESET PROTECT - were they set prior to deployment of PROTECT over new database?
  12. End of support of ESET PROTECT has not such impact on products, i.e. security product will be getting updates until it is in support, or there are no technical limitations (beware of old/unsupported operating systems). Once ESET PROTECT reaches it's end of life, you might loose ability to create installers (= deploy AGENTs via console) and possibly manage newer versions of security products, but without security and protection implications.
  13. Would it be possible to check uptime/system boot time on the affected device using system tools, i.e. for example using command from this article: https://www.windowscentral.com/how-check-your-computer-uptime-windows-10 We would like to know whether system reports also unchanged uptime or there might be an issue in ESET Management Agent reporting wrong value, as it currently relies on system provided date.
  14. There is no customization possible as of now. This mechanisms relies on system-provided API/tools that are used to detect missing updated. Therefore I am little confused by behavior on systems that cannot be upgraded due to policy - could you clarify those systems are not offering upgrade to the users?
  15. In case of ESET PROTECT (on-premise) there is a difference in a way how upgrades of ESET Management Agent do work: ESET Management Agent is not updated to latest version, but rather to "latest compatible" version. This means, that if ESET PROTECT has version 9.1, ESET Management Agents will be updated automatically only to version 9.1 and not version 10.0 (until ESET decides that there is no compatibility issue). In case of on-premise ESET PROTECT, mentioned ~1 month countdown starts in a moment when ESET Management Agent detects that ESET PROTECT has been upgraded, and thus latest compatible version has changed. So in case AGENT is not connecting to console for a long time, it won't be able to detect this change and thus it won't upgrade. It would upgrade only to hotfix or service release of AGENT, which does not happen very often. In case of cloud console: ~1 month countdown starts in a moment when specific AGENT detects new version in the ESET repository. This means, that in case AGENT is offline (no access to ESET repository) for some time, it's own countdown will start later. Also note that we have slightly changed algorithms for the future updates. Scheduling will be more "randomized" in a way that initial ~2 weeks delay was significantly shortened = instead of waiting for first updates for ~2 weeks, it should start sooner and thus progress should be visible from the first days.
×
×
  • Create New...