MartinK

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 possible upgrade problem might be described in more detail in standard EP trace.log - as you are using MySQL, there were few reports of ailed upgrades with this database type in case there was not enough memory, but it is hard to confirm this -> I would recommend to monitor resources.

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.

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.

From provided logs it seem that EP service is not able to finalize upgrade of data, because it has not enough resources or there is some HW or operating system issues. Could you please monitor system resources of both EP service and also DB server and possibly check they are not hitting limits? Most probable cause will be insufficient memory, either for EP service or DB server itself, as few failures do indicate that database shutdown was also reason for failures.

Actually recent release 8.0.19.0 updates only EP server and console, so there is no need to update management agents in case they were already on version 8.0.

From provided logs and screenshots, most suspicious is upper-left graph that indicates there are "pending" logs, i.e. data from client that was not processed in time. This might have two reasons: There is some performance degradation on DB layer, i.e. database server itself is overloaded, or underlying hardware or disk storage There is significant increase of traffic/data sent from clients. This seems to be confirmed also by growing database size - are you in middle of deployment and just much more clients has been deployed recently? Or there has been configuration changes that might have forced clients to send more data? For example by enabling reporting of all installed applications, or by requesting diagnostic logs... Also when you open status.html and hoover over number in section "Received logs statistics" it will show more granular data, which might help us to pin-point which type of data might be causing issues, if provided to us.

Security mechanisms for policies works the same as with computers for example, i.e. there is the same hierarchy-based security model. In case AdminA has full administrative access to group All, this admin will be able to see and manage all objects, regardless of where they are placed or whom they were created. In case AdminB has access to only group "Subgrup", only objects that are placed in this group, and it's subgroup should be visible. But note that user can have multiple permission sets, which are combined, so it is crucial to verify that permission set that grants this user access to policies is limited to specific static group. Once correctly set, AdminB should not see all policies created by AdminA. In case it still wont work, please provide us some screenshots of permissions configuration of those users, and possibly some basic example of object and its placement in hierarchy, so that we can check whether expected configuration is even feasible.

Could you please check state of ESET Management Agent installed on the virtual appliance? Any chance you already tried to reboot whole appliance? Also was there any service interruption or operating system changes performed on a date that management agent connected for the last time? Previously we have seen that operating system updates or even changes of timezone/time o machine could result in this state.

I would recommend to open support ticket, where required logs will be requested. Otherwise it might be difficult to find problem: it might be performance related, for example report might be too large, or system resource might be insufficient, as report generating operation is CPU-intensive.

Is there any chance you imported configuration policy for ESET Management Agent from your original on-premise ESET PROTECT to cloud instance? That might be source of this issue, especially in case this imported policy had contained your certificates.

Any chance this has recovered in the meantime? Version check status re-calculation might take some time (should be no more than 1 hour in case ESET repository servers are available).

Is there any other limitation, for example operating system version, that prevent you from installing newer SQL Server database version? There are various DB upgrade and migration scenarios described in documentation: https://help.eset.com /protect_install/80/en-US/?db_migration.html and it is definitely recommended to upgrade from SQL Server 2008, which is long (very long) out of support. Also note that all-in-one installer for ESET PROTECT 8.0 does support upgrade not only of product itself, but also upgrade of database server, in case minimal requirements for SQLServer 2019 is met by your operating system.

In case client are not longer connection to ESMC (console), it effectively means that those clients are no longer managed (why they are not connection? Management agent has been uninstalled?), and thus is is not possible to send command remotely. If this is the case, only possibility is to uninstall ESET product manually or using other remote management tools if available. In case ESET product is password protected, it might happen that uninstallation from safe-mode will be required.

Would it be possible to enable full trace logging on ESET Management Agent installed on the same machine as your ESMC server, re-execute upgrade task on this "client" and attache those logs. From provided details it seems that AGENT fails to find updates for your ESMC, which might be caused by some dependency (version of operating system, version of database) or possible even by network issues or miss-configuration. There is also possibility configuration on our side is not correct, but we had not received similar report since ESET PROTECT 8.0 release...

We do currently track improvement for reporting version - which is currently not available especially on Linux. On Windows, there is at least possibility to check version as shown in executable file details. If I recall correctly, creating update mirror does not uses any retry mechanisms, but downloading of repository packages should use some basic retry mechanisms and also "continuation" type of download, which should be able to continue failed download and re-use already downloaded data. Regardless of that, MirrorTool was designed in a way that it should download only incremental changes, so it might be called repeatedly. Or problem is that even repeated calls which are supposed to not download much data are failing? Also note there is possibility to use HTTP proxy in between MirrorTool and internet as an additional caching layer, which might helps in case of network instability and often failures.

Unfortunatelly there is currently no way how to find out status of AGENT in such a way. Only possibility for now is to check status.html log, but it is intended primarily for diagnostic of issues, and it's content might change version to version. Would it be possible to provide more details of why would you do that and would would be outputs required for your scenario? Is it just to automate health-check of management agent using some other remote management tools?

Also export and import of static groups (see documentation) might be helpful, but it depends on migration type that was used, as mentioned in previous comments.

Would it be possible to provide more details of what logic is used behind dynamic group, i.e. based on what parameter should be move operation performed? Asking just to find out whether there is correlation with similar requests.

Not exactly sure I understand it correctly: question is whether it is possible to use dynamic groups for specific AGENT version? If so, this should be possible, based on data with list of all installed software, where filter for "ESET Management Agent" can be used.

Checked that and it was present in changelog of original 7.2 release: but it might have been superseded by change-log for hotfix release of 7.2, which might cause confusion.

Not sure I understood it correctly, but from provided steps I think that crucial part missing is that in order to actually stop managing of devices, uninstallation of ESET Management Agent is required. This can be done manually or via "Stop managing" client task (more details in documentation). Once task is executed, device will stop connecting, and that is a moment when it can be removed as mentioned previously. Also note that result of "Stop managing" task won't be finished, so there is no need to wait for that, but I would recommend to verify at least last connection time to be sure, otherwise device might re-appear once it connects again.

Could you possibly verify there is no problem with internet connectivity? Errors from download of repository packages indicates some network related issue, maybe even DNS related . Is it possible to download manually file from repository.eset.com mentioned in error? Unfortunately I cannot currently verify error generated during creation of update mirror, but there is a high probability it is also network-related -> might be clearly visible from network capture, for example using tools like wireshark.

Could you please try it from incognito tab of your browser or different browser than used normally? Most probable issue is some inconsistency in cookies for hostname of console, which might result in this state and solution might be to just clean cookies for used hostname.

Actually it has probably changed as set of detection types that are resolved automatically has been extended. If I recall correctly, recent addition is "firewall" type of detections, but it might be also dependent on version of ESET security products used in environment. Regarding mechanisms itself, it is based on data as received from ESET security products, where crucial for automatic resolution is that detection is marked as handled/resolved/cleaned, i.e. that it is a detection that does not require any further actions as it was resolved either by blocking or removing malicious content.

Not sure how deep in inspection of traffic would you like to go, but it will be necessary in case filtering based on IP address is not enough. As AGENT->ESMC communication uses standard TLS protocol, where both endpoint are authenticated using certificate (i.e. it is mutually authenticated TLS connection), first filtering layer might just check this and prevent TLS connections (or even non-TLS connections) that are not using trusted certificate. More advanced way would be to use some kind of proxy, that would do TLS introspection and analyze also content of traffic, which is actually HTTP2 protocol. This would enable you to filter on this layer, but configuration would be much more complicated, as it requires understanding of TLS/PKI certificates. In case you would like to just limit connections to ESMC directly, commonly used solution is to use HTTP proxy in DMZ part of the network, that will be forwarding communication from outside networks. This won't prevent possible attackers to open connections to ESMC, but there will be at least one more layer to detect or prevent possible DoS attacks.