MartinK

Also note that there is a set of quarantine management tasks available in the PROTECT console (see: https://help.eset.com/protect_admin/11.0/en-US/client_tasks_quarantine_management.html) which enables console user to remotely perform specific actions. But I am not sure it covers required scenarios as it is not clear to me what is the usecase - but as already mentioned, objects are quarantined automatically, and it is not possible to just request to quarantine specific file.

I do not think there is alternative, but it should be possible to use timezones for this purpose. All devices should report timezone properly, but there might be a different naming uses in between platforms, which might cause issue you mentioned. To check what timezones are reported by devices, you can create simple custom report, where you can see that CET timezone is reported differently by Windows and Linux devices. As an alternative, also timezone difference in minutes might be used - this one would be independent on timezone naming.

For better understanding: number of consumed licenses is represents number of all products using this license, regardless of whether this device is managed by the console as of now. So this kind of inconsistency migh happen in case: Device was removed from the console without being deactivated prior. Solution: In case device no longer exists: wait ~30 days or manually deactivate device from EBA/EMA portals where full list of devices, with basic identifiers can be found so that you can identify those devices easily In case device still exists, but it is no longer expected to be managed: deactivate using EBA/EMA2 portals Device was cloned - it might happen that when device is cloned or created from master image, license might be considered as used. In this case follow steps as if device no longer exists So in short, I would recommend to check EBA/EMA portals for start, and check which devices are actually licensed + whether they are still actively using license. Might be some forgotten devices, or just some devices no longer managed and present in the console...

Just a note, that this will effectively disable protection on those devices. So it is not suitable for just hiding numbers of devices, that do continue t be managed in PROTECT on-prem, using the same shared license. Indeed this is the case - both consoles are sharing the same license, so both of the consoles shows total usage of the license. In other words it is not considering when and how were the seats activated, nor where are those devices actually managed (might be even devices not managed ad all, but still running and being protected by ESET products).

Not sure what was the results, but generally actions in the context menu are available only in case users has: permisions to perform actions = in this case permission to access inspect console user has access to inspect license there is a inspect connector deployed and operational = i.e. it makes sense to investigate in the inspect [not sure of last one] at least one "alarm" (inspect detection) from this device is available in the console If none of his is the case, previous recommendation to open support ticket should help.

As per kb8515 ESET PROTECT 11.0+ should be capable of running on OpenSSL3+ based linux distributions, but there are certain limitations in certificates is is actually using, especially in case older operating systems are being managed in the network. As you mentioned, there is a problem with MySQL ODBC driver, which is probably still using using older openssl or other dependencies are missing (might be verified for example using ldd command line utility). If this is the case, I would recommend to "consult" with documentation of MySQL ODBC driver or linux distribution, depending of the source of the used ODBC driver. It is possible later version of ODBC driver will be required to be used, or dependency will have to be resolved otherwise.

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.

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.

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.

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?

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.

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.

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.

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.

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).

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?

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?

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.

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.

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?

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.

Unfortunately it is currently not possible to report public IP address of connecting devices.

Could you please clarify what do you mean by "blank". In case progress bar is just empty, it might indicate that trigger ()task execution command) was not delivered to any device yet. This might be just temporary in case device is active, or it might take longer time in case device is not actively communicating with the console.

As of now, there are no separate changelogs for ESET Management Agent - it is considered as an support components, and new features and resolved issues are communicated as part of ESET PROTECT or ESET PROTECT Cloud changelogs. Plan for the future is that ESET Management Agent with support for new features is released prior to console update, so that transition and usability of new features is more transparent and not delayed...

Could you please clarify why predefined/default notification of type "New computer connected for the first time" is not suitable for your use case? It should trigger notification when new device is enrolled into console. Unfortunately reporting won't be possible as we are not storing date of first connection, i.e. it would be problem to filter devices based on theirs enrollment date directly, even there might be some not-so-reliable workarounds (like checking date when ESET Management Agent was installed as reported in the console).