MartinK

Log indicates that AGENT is missing CA certificate not only for new ESMC Server, but also for itself. Could you specify how it was actually installed? Also what is suspicious there are two different hostnames listed - new ESMC is deployed on different hostname?

I would recommend to double check configuration of proxy (or security-related network device) you are using whether it is configured in a way that communication with ESET licensing servers is not only enabled, but also TLS introspection is disabled, so that traffic is not modified. In provided network capture there is no attempt to bypass HTTP proxy configuration - is HTTP proxy fallback explicitly disabled in configuration? In case activation works manually, it might be because of HTTP proxy available to logged-in user, which might have different configuration and thus working.

I would recommend to consider following possibilities: in case you have domain, there might be possibility to "repair" connectivity of AGENTs by distribution certificates via domain configuration. This would work in case AGENT are connecting to correct hostname, but they are "rejected" because of wrong certificates. In order this solution to work, you would have to: Import original CA certificate used by previous ESMC installation into new instance. Only public part of CA certificate is required, it is part of all ESMC installers so there is a high possibility you have it somewhere. Distribute new CA certificate (used to sign new ESMC's server certificate) via domain, so that it gets into "local computer" certificate store on each machine with installed AGENT. Another possibility is to use "repair" functionality of ESMC Agent installer. This would enable you to change AGENTs configuration without uninstallation -> you just have to re-run installer of AGENT with new settings and AGENT. It would have to be tested, but this might be possible also via GPO. Ideally exactly the same version of AGENT installer should be used for re-deploy, but latest installers should handle reconfiguration even during upgrade,

There is most probably "ESET Rogue Detection Sensor" that uses those ports for operating system detection. You have technically two possibilities: Completely uninstall this component from ESMC appliance Configure it in a way that it uses different ports or ignores specific machines (via configuration policy)

Error "Deadline Exceeded" in this context means that requests from AGENT are not handled in time. As timeout is set to 60 minutes, it might indicate some network problem. Could you verify that AGENTs are actually connecting to ESMC? Is there any network component in between them? HTTP proxy or some kind of load balancer? Any chance you tried to restart ESMC service or possibly whole system? Just to be sure there is no problem with insufficient sockets for all AGENT connections

In trace logs, relevant error is: 2019-07-08 15:55:48 Error: CRepositoryModule [Thread 7f44257e2700]: GetFile: Host 'repository.eset.com' not found [error code: 20002] 2019-07-08 15:55:48 Error: CRepositoryModule [Thread 7f44257e2700]: GetFile: Host 'repository.eset.com' not found [error code: 20002] which indicates some kind of network problem. Most probably outside network was unreachable at the moment of connection. Unfortunately wireshark log did not capture any attempt to connect to repository.eset.com, not there is any DNS request with this hostname. I think it it because repository synchronization is performed every 60 minutes and it was not executed during wireshark capturing. Repository synchronization is performed each time it's configuration is changed, which might be way how to force synchronization and capture it. In case connection works from browser, it might be related to HTTP proxy or firewall configuration. In case proxy is used, could you verify it works correctly? Is there any firewall that could possibly block connections?

There is no such functionality available in ERA6+/ESMC. Could you be more specific of scenario you would like to employ it? Is it due to environment size or just fail-over? If second, active-passive configuration is supported for ESMC server.

Forgot to mention, but issues has been resolved for next releases.

As you wrote, there was an issue in ESMC 7.0, where random language was downloaded. This is no big deal in normal case as all of those files are actually identical, but it makes problems with language-filtered mirrors. Unfortunately workaround is to copy file. As downloaded locale is random, it might stop work next time and new copy of file will be required.

Unfortunately I am not able to provide answer in german, but I will provide required steps to replace certificate in ESMC appliance to verify that nothing was missed. Link you provided provides steps to install custom certificate into Apache HTTP Server, which is used as HTTP proxy -> you have to change configuration of Apache Tomcat instead. Technically you have to: obtain your new certificate. Either in Java keystore format or possibly in PFX format (this was not tested) Locate proper section of Apache Tomcat configuration file /etc/tomcat/server.xml. You have to find section that looks like this: <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslEnabledProtocols="TLSv1,TLSv1.1,TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA" keystoreFile="/etc/tomcat/.keystore" keystorePass="thisissomerandompassword" keyAlias="tomcat" /> You have to adapt configuration to use your custom certificate. For this purpose, parameters keystoreFile, keystorePass and keyAlias are used. In case PFX certificate is used, you will have to use keystoreType="PKCS12" instead of keyAlias.

I would recommend to check apache logs for access from unknown IP addresses. Relevant logs, including access logs, are available in /var/log/tomcat. Regarding port 8443, If I recall correctly, this is default port used by Apache, but it is not available from external environment. Port 443 is just redirection to 8443, handled by iptables service, which has to be running for it to work. Please check status of iptables via command: service iptables status I would also check utilization of resources, especially RAM, which might be increased, possibly resulting in instability of application.

Could you please provide logs located in directory %temp%\eset\ (i.e. in temporary directory of user that executed installer)? This specific error means that it was not possible to find installer matching requirements. Most commonly when in case: version of product is no longer available (if version was explicitly requested when configuring installer) operating system is not supported by selected product (desktop vs. server products) ESET repository servers (repository.eset.com) are not available. Access might be blocked by other security-related software, or HTTP proxy configuration might be required.

I would recommend to check ESMC logs for possible clues -> there will be most probably synchronization failures reported. My best guess is that ESMC lost access to repository.eset.com, maybe due to firewall or HTTP proxy problem, which results in this state. I would recommend to check those components if used.

It is available in ESMC help: https://help.eset.com/esmc_install/70/en-US/era_serverapi.html

Unfortunately manual changes to database are not documented nor they are safe. In this case only possibility is to use ServerApi, but it definitely requires some sort of programming skills.