MartinK

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 mig

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 a

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 y

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 chan

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.