MartinK

As mentioned, in case management of remote locations is to be handled by one instance of ESET PROTECT, network connectivity between managed devices and ESET PROTECT is required. This can be achieved by using various methods - for example by creating VPN network across offices, or using HTTP proxies, which would work as an forwarder in this case. Communication between ESET Management Agent and ESET PROTECT is using standard TLS+HTTP2, so here might be multiple alternatives. But in case of very smaller offices, It would probably depend on how big effort it would be in comparison to "manual" management of separate ESET PROTECT servers, which might be sufficient for such a small environments.

From provided description it seems to be as an expected behavior of "Automatically pair found computers" functionality. There are more details in linked documentation -> in case of on-premise management console, functionality can be disabled in settings:

As of now, version is marked as out-of-date because it is older version than version marked as compatible with your console (for your PROTECT version compatible version is 8.0). Even it works properly in this case, there might be missing support for more recent functionalities in older version of AGENT, i.e. environment as a whole might not work as expected. In case of other ESET products, version check considers latest version supported by operating system, instead of functionalities and thus ESET Endpoint Antivirus v6.5 is not reported as outdated when deployed on Windows XP, even it might be considered as misleading, especially now when product is communicating its outdated status directly and it has EOL status.

I am afraid it won't be possible as mentioned module is not present in a distributed packages - as we distribute only minimal set of modules that is required for HTTP caching. Also I am currently not sure how to disable those methods in such configuration, nor I am aware of any possible consequences or impact of current configuration, so I would also recommend to open support ticket so that it is properly analyzed and possibly integrated into future versions, if it will be necessary to minimize impacts.

Unfortunately I do not think this is related - installing HTTP proxy would help with "creation" of the installer itself, which is indicated by progress dialog in the console itself and it involves downloading of installer for ESET repository servers through HTTP proxy, and only in case installers are not cached locally yet. Once generated installer is ready, download as reported in this issue is performed, and in this case, file is hosted by Apache Tomcat (where PROTECT console is hosted) and downloaded directly by your browser, so it might indicate problem with connectivity between browser and console, or performance degradation of Apache Tomcat. I would recommend to focus on those two aspects in case this issue reoccurs.

I would recommend to double-check that WMI works properly on such device, as OS information should indeed update itself automatically after some time, or when change is detected.

Unfortunately this is not possible in this way - we do rely on data that operating system provides us, and it is just an "description" stored most probably in the bios itself. We also see that content is not standardized and it highly depends on manufacturer - so it was just an hint that it might help in your case, but it might be completely useless for certain motherboard vendors.

For better understanding of your use-case, we you considered one of two currently available actions for export in a CSV format? As of now, it is possible to: export directly from the computers screen table (cogwheel action) but it honors paging, i.e. only devices on current screen/page will be actually exported It is possible to define custom report and download it in CSV format. This provides much more control, can be even scheduled to be saved or sent via email regularly. where especially second one should provide possibility to fetch data in required format.

Just for clarification, but does that mean that current mechanisms for fetching bios/firmware version & description is not sufficient in your environment or it provides inaccurate or no data at all? It should be visible in client details and it can be also reported in a list for all devices:

Could you please double check your management server can actually communicate with ESET repository servers (http://repository.eset.com) without any problems? From provided logs it seems that data received from this server is malformed or completely wrong - which might indicate some network error, including possible intervention of various network-scanning or forwarding proxies in between. In other words, remote deployment attempt fails in initial stage where AGENT installer is to be fetched, even before connection attempt to remove device is made. If this is the true, the same problem would be indicated when you will try to manually create either all-in-one or live installer directly in the console = and this is what I would recommend to check and possibly diagnose.

Could you please provide trace logs from AGENT for analysis? From provided screenshots it seems that problem might be with WMI on this device as WMI interface is used to fetch OS and HW related data, which seems to be exactly part that is missing in our case. If this is the case, there would be an error indicated during statrup of AGENT's service and regularly when attempt to refresh data will be performed.

Actually by manual uninstallation I meant from standard user desktop / remote desktop. In case it would not work even from there, I would recommend to open support ticket as it is definitely not a correct behavior in case uninstallation would require use of safe mode, especially not in case product is running normally and there is no obvious reason for corruption.

Yes, that is correct. You will have to use "manual" execution of upgrade, i.e. by using one-click action on dashboard, creation of components upgrade task (documentation), or other upgrade methods suitable for your environment (GPO/SCCM).

Thanks, installation/repair logs show some issue with registries or product - is this product actually working properly? Would it be possible to try manual uninstallation on affected machines? Otherwise I have suspicion that we are attempting to uninstall wrong "application" with different identifiers -> this seems to be an result of SCCM where "wrapper" installation might be created when deploying.

In this case, no upgrade of ESET Management Agents will be made after upgrade to ESET PROTECT 9.0 as there is also minimal requirement of v8.1 for AGENTs (this is first version where auto-update mechanisms was present) for this feature to work. There is no reboot requirement after AGENT upgrade between any versions, so there should be no risk of business continuity. Also note that upgrade of AGENTs is not immediate, even after upgrade of ESET PROTECT itself, it would take at least 2 weeks until first device would attempt to upgrade itself, and those attempts will be randomly distributed throughout few weeks to minimize possible impact. Therefore there would be enough time to execute planned upgrade if this is required in your environment.

Could you please check and possibly provide more details of what details as currently present in the console are supposed to be reported? Asking as I am not aware of collecting age of device explicitly, so either age is part of some hardware details (shown currently in device details) or it won't be possible to provide such report.

I would recommend to collect logs from affected machine via console (diagnostic subsection of specific client details) - it should contain also msiexec logs that might show more details, even that generic MSIEXEC errors seems to be reported.

Hard to say what was going on, but it is probable that after AGENT upgrade, re-synchronization of wakeup identifiers is required. In other words, once AGENT has upgraded, it will most probably get new identity from ESET's push notification service, and this identity has to be sent to ESET PROTECT Server (via standard replication connection) so that wakeup of this specific device can be targets. This normally takes quite a short time and that is why I am not sure this was the issue...

Seems that this will be unexpected impact of changes that were introduced and were supposed to resolve complains of users that reboot is performed immediately after various actions, without notifying users. That is why there is a 4 hour delay, and also notification for user if there would be any logged in in desktop environment (if present). There are also planned and ongoing changes in this behavior in a more proper way that would enable administrator to configure certain aspects of reboot behavior, as is possibility to f users to postpone/delay reboot, etc, but as of now, there is no other alternative than to reboot those machines explicitly if 4 hour delay is too much.

Thanks for clarification - now it makes sens as you are actually not performing standard/recommended upgrade using components upgrade task (https://help.eset.com/protect_admin/90/en-US/client_tasks_upgrade_components.html) but you are actually using re-deployment, which is capable of changing configuration. Regarding revocation of certificate as available in the console, it actually performs two actions: adds this certificate to list of revoked certificates, which will technically block it's usage in the environment from security perspective it remove this certificate in terms it will be no longer visible in the console - this should also prevent it's usage in various installers, especially those that try to detect proper certificate automatically.

Could you please provide more detail of this issue? In case components upgrade task is used to upgrade AGENT, there should be no configuration change involved.

Just got information that one of the servers should be fixed now, but we do have question of where did you get those other servers listed in your post? Asking because those servers are long time obsolete (current list of active update servers are listed here: https://support.eset.com/en/kb332-ports-and-addresses-required-to-use-your-eset-product-with-a-third-party-firewall) and should be no longer used by any our product.

Just to let you know, this issue was reported for further analysis and should be resolved soon.

I would recommend to start by: checking that all relevant services (database, ESET PROTECT Server service and Apache Tomcat service) are stable, i.e. I would check they are constantly running. This check would exclude "crash" or service instability of those backend services that might possibly result in failure of loading data check ESET PROTECT's Server trace logs for any relevant "Error:" entries, which might indicate some problems. For example with database connectivity. Even it seems there might be some console issues, those might be just consequence of failure in lower layers. In case this won't give any clues: is issue with editing policies reproducible? Is it some specific policy type / setting that triggers these problems? What is actually recovery method you used to make it work again - just relogin? or Apache Tomcat service has to be restarted?

Unfortunately it is not possible as of now. But you have mentioned two different states: Task is running for too long -> actually task should be timouted (as seen in console) after 24 hours, but this timeout information has to be delivered from client itself - is this client actually connecting? If client is not connection, in console there will be information of last status as reported by client, and only possibility how to clean this state is to remove trigger or task, but be aware that might remove also data for other clients, in case it was shared between multiple devices. Also note that task and trigger configuration (configuration of when should be task executed) is delivered to clients upon its next connection, and it residues on client - so even of device is offline in terms of network connectivity at the moment of planned task execution, it will be actually executed -> this is by design. concept of management as implemented by ESET PROTECT counts with offline/roaming devices, and thus automation logic can operate without connectivity to ESET PROTECT. This also means, that in case such client already received this task, it cannot be removed in case connectivity is not available.