MartinK

Could you please double check that there is no encrypted disk and reboot was performed after decryption was done?

Upgrade procedure is performed by ESMC Agent, so both failures and upgrade process should be trace in AGENT's trace.log. Regardless of that, during upgrade, ESMC Server should be stopped, and that should be recorded in ESMC's trace.log. It is very suspicious there are no entries from this year -> could you possibly verify that permissions do enable ESMC service to write to log and that file is not locked by different process, possibly preventing ESMC from writing to it?

I would stick to system that most suits your needs. Linux might require little more skill to administer, especially in case features like AD integation/login is required. Regardless of that, it is for the first time we hear that something like this can happen, but it might be triggered by fact that you are using "desktop" operating system, which is not recommended for server applications. Also more recent versions do use Tomcat 9 so it is possible that older version 7 was not compatible with latest operating system, which might have resulted in it's uninstallation that system upgrade is not blocked.

Could you possible use tools like wiresahark to check whether there can be observed some slow download? During installer creation, multiple packages are downloaded from ESET repository servers. We are trying to redirect users to most suitable data centers but sometimes even that results in slow downloads. It is also possible that from certain countries, or during certain time, download might be performed from public CDN services, where risk of blocking such connections by enterprise firewall is higher. In case slow download is observer, could you please provide your location (location of ESMC server actually) and possibly personal experience whether routing to EU/US/JPN is best?

There seems to be some kind of network issue preventing clients from connection. Endpoint read failed error indicates that connection is probably opened, but dropped prematurely - might be caused by firewall or proxies. I would recommend to check all such components in between of ESMC and not-connecting clients. From screenshot it seems that there is at least one device still connecting, so maybe it is affecting only part of network?

Only difference between those "repositories" is actually that no-cdn variant will never use public CDN services for hosting files. This mostly helps in case firewall are blocking access, as CDN providers are mostly using variable IP addresses. CDN services are used in specific countries (APAC) to improve overall download performance, as no-CDN variant relies purely on ESET infrastructure, which might experience overload.

It is hard to guess without trace logs, but issue might be also with WMI service, or other parts integrating AGENT with operating system, possibly resulting in slow responses.

Not sure I understand correctly, but in case you are using "domain login" (i.e. login using domain credentials) there is no requirement for synchronization -> authentication is performed using active communication with active directory and password is not stored in ESMC itself. This means that change of password in domain should be required upon next domain login into ESMC.

Could you also start installer with full msiexec logging? It might provide more detailed error directly from installer. As it seems that issue is triggered by change of hostname/IP, it might be caused by fact that ESMC server certificate is not signed for connection to this IP address, which might result in rejected connections from installer.

I would recommend to stick with some generic tutorial for tomcat in Ubuntu 18.04, as there might be some specific. We do prefer jks as it seems to be most reliable and supported on all platforms, but there are indications that even other formats might be supported - depending on tomcat version and platform.

I would recommend to open support ticket -> there seems to be some data corruption in database, related to tags as mentioned? Any chance there has been some incident with database? Or some manual modifications of ESMC database were performed? Or maybe ODBC driver was upgraded to incompatible version?

Could you be more specific of what kind of error you are seeing? Server-assisted installation relies on communication between installer and ESMC server (not WebConsole) so it should not depend on configuration of WebConsole. Could you verify that hostname of ESMC server and not hostname of console is used during assisted installation?

Could you please verify that you can download this file manually on client machine? Also is there any HTTP proxy used / set in installer to be used? Maybe it is not working as expected and providing wrong response ...

Unfortunately this glitch was not resolved yet. Problem is that ESMC shows versions, that are actually not available in JPN language, as last version supported in JPN probably version 7.1.2053.1 -> manual selecting of it should work.

Please check AD synchronization documentation and double check your ESMC configuration to meet all required criteria. There has been a change where ESMC now prioritizes secure (LDAPS) connection to AD servers, which might results in failures in case configuration of AD server is not meeting criteria. There should be also alternative using LDAP sychronization in case it is not possible to re-configure AD server to work properly with new ESMC requiring security connection.