MartinK

There is one cumbersome way how to get at least list of installed updates -> list is part of SysInspector log that can be individually requested from client machines and rendered in ESMC console. Unfortunately it is suitable just to verify that specific update is installed on specific device ...

For this purpose, so called GPO installer created in ECA console could be used. It is actually just test file that contains installation parameter for already downloaded Agent MSI installer. When placed in the same directory, installer will automatically load parameter from file. Not sure whether it works in interactive mode, but silent installation should work definitely.

Could you please verify state of database used for ESMC? According to logs, there were some issues with connectivity: [Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied. (17) but currently ESMC seems to be running for more than hour.

There has been support for cloning implemented in ESMC, which means this scenario should be handled automatically if properly configured, without executing mentioned task. Once machine was cloned, new Cloning Question for ESMC administrator should have been created -> until it will be resolved, cloned devices won't be able to communicate with ESMC and thus not able to reset itself. There is possibility to resolve it in a way that every other clone of specific device will automatically results in creation of new devices, as if reset cloned task was executed. I would recommend to check whether there are any cloning questions available -> they should be accessible through client details of "master image" or in status overview in ESMC console.

Please check documentation article Configuration of Apache HTTP Proxy, especially first chapter Configuration of Apache HTTP Proxy for replication (Agent - Server) which describes minimal requirement to enable proxy for AGENT communication. Technically you have to whitelist hostname and non-default port in proxy configuration by modifying existing directives. Unfortunately your configuration is more complicated. It teems that you have been inspired by special configuration used for "EDTD" requests, but that won't work for AGENT-to-ESMC communication. In this specific configuration, there is directive which explicitly blocks so called "CONNECT" TLS request, which are used by AGENT -> this is most probably reason for blocked communication.

For future reference: there is a client task Rogue Detection Sensor Database Reset that is supposed to speed up cleanup of cache after changing detection filters. Just be aware that sensor does not utilize active scanning which mans it might take some time after all device are detected again.

Please check also state of HTTP proxy is product is configured to use some for updates. There is a chance it is not working correctly.

Could you please double-check filters used to show threats of this device in console? Especially time interval and severity filter should be set in a way all threats are shown. It is possible that it has no "information" severity and thus possibly not shown in console by default. Could you also check "Filtered websites" tab in client logs? This one is collected by ESMC, but not shown in threats view (was integrated to future release).

No, it think it should work without quotes.

I guess target "/" (= root of filesystem as path) should be equivalent for all targets on macOS.

As @Marcos mentioned, this scenario will most probably not work correctly as it was not tested nor it was designed to work. Most probable problem you have with communication is indeed related to certificates. It should be resolved fairly easy, you just have to export CA certificates from ESMC1 and import them into ESMC2 and vice versa. Once AGENT connects to such ESMC, it will receive both CA certificates that will enable it to connect to both ESMC servers. What might be problem is that each time AGENT migrates between ESMC servers it will most probably result in duplication in console, i.e. device will be not paired after migration. It is even possible that administrator of ESMC will have to explicitly accept connection of such AGENT (there would be "Questions" due to HW changes) as it might trigger spoofing protection introduced in ESMC. But maybe that is acceptable in case it would not happen very often.

Could you please double check HTTP proxy configuration on clients and also verify proxy is running correctly? In case it is Apache HTTP proxy installed with ESMC, could you restart it to be sure it is in correct state? As you mentioned that activation on client takes long time, it might be result of not responding or inaccessible HTTP proxy. It is possible that local activation is able to use also system HTTP proxy and that is why it is successful. Also could you verify that ESMC itself can synchronize licenses?

Mentioned error indicates problem during creation of installer itself, which is performed after all MSI installers are successfully downloaded so we can exclude network related errors. It is not clear from trace log message, but I/O error most probably indicates problem with disk space or insufficient free memory. Could you please verify there is enough space (temporary directory for system services) and also enough free RAM (at leas 512MB)? There is also possibility that ESMC service is not able to access disk due to some security restriction, but I guess there is no SELinux enabled on Debian system.

Problem seems to be in MySQL ODBC driver used. Unfortunately ESMC 7.0 does not support latest versions as there is some bug in driver itself. It was supposed to be fixed in ODBC driver 8.0.16 released recently but seems there might be some another issue. I would recommend to check documentation where latest supported version of MySQL ODBC driver is mentioned. If I recall correctly, latest working version is 5.3.10.

Please note that this is considered as an bug and hopefully will be resolved in upcoming releases.