MartinK

Could you please attach log file: /var/log/eset/RemoteAdministrator/EraServerInstaller.log It contains more detailed information - might helps with Analysis. From provided output it indeed seems that OpenSSL verification fails, but OpenSSL version seems to be correct. Any chance multiple versions are installed? Or were there made any changes in appliance itself? Asking as I am surprised by "german" error in output of logs, which is suspicious as we are not localizing such messages - maybe locale of system was changed from default en_US? Also there is an alternate method for upgrade, using migration to completely new appliance: https://help.eset.com/esmc_deploy_va/72/en-US/?va_upgrade_migrate.html which would probably helps, but it might consequences in case some custom modifications of system or administrative operations were made (i.e. manual joining into domain, etc.).

History is not collected by default, but it is possible to create "history" report template for IP addresses, and once it is created, history will be collected -> but you won't be able to get changes that happened before management agents are notified of your intent to collect such data.

It is not possible to retrieve password. You will have to use "installation repair" to reset it to new value. Please check documentation for more details as it might depend on platform and version of ERA/ESMC you are using.

Unfortunately it seems that this system is very old. It is missing base64 command line utility, which might be probably installed, but I am not sure there will be any solution except manual modification of installer script. In order to solve "sudo" issue, just remove it's invocation from script and run it in root terminal so that sufficient permissions are available.

Any chance you tried to "repair" AGENT installation using standalone (MSI) installer? Hard to guess what is going on, but seem that more files might be corrupted or missing. MODILE_ID_SSL is stored in Modules directory, side-by-side with Logs directory where trace logs are located, but failure is indicating either corrupted or missing file. Also as there is a ESET security product installed, AGENT's files should be protected from unauthorized access - any chance there are some special HIPS policies applied in security product that might block access to files on disk?

Could you also attach trace.log for analysis? It seems to be some kind of network issue, where most common problem is DNS related, i.e. problem with resolving DNS name of ESMC and thus failing to connect. From configuration it is visible that HTTP proxy is used, but also "proxy fallback" is enabled, which meant that AGENT will be attempting to connect also directly, which probably also fails.

Could you please check whether trace.log file is updated during such startup? This error indicates that something fails during initialization, which might be related to some missing dependencies (visual studio runtime libraries) or possibly permissions related issue. Also we have seen that specific files might be blocked (for example logs) and thus preventing startup. As an alternative, you might try to start ERAAgent.exe from administrator terminal and check whether output to console or possible error popup dialog would help to locate source of the problem.

Yes, tomcat configuration should be retained, but probably only settings there were set previously by ESMC installer,i.e. custom settings will be probably lost. But certificate should remain original.

Upgrade of SQL Server is not required from technical perspective and ESMC 7.2 will work without any issues. Regarding tomcat7, the same applies, but I am not sure of minimal supported tomcat7 version. Is there actually any specific problem with upgrading (reinstalling) tomcat? Asking because it is not so problematic, and even complete re-installation of tomcat+ESMC console is matter of a few minutes, except that certificate configuration might be retained.

Unfortunately from logs it seems that setting of max_allowed_packet=33M is not effective. Could you please check MySQL configuration and verify that: that there are not two conflicting settings for max_allowed_packet that max_allowed_packet=33M is placed in correct configuration sections? It has to be placed in sections that applied to MySQL server, not client. Also be aware that changing configuration of MySQL requires service restart.

Could you please verify that resolving actually works on the client device? For example using ping or nslookup tools in command line. Just to be sure there is no network-related problems, which is most probable in this case.

This issue was resolved recently (for upcoming major releases) so there should be no longer problem with large configuration policies embedded into installers.

Also note that this policy which breaks installer is embedded into installer automatically when you select some "Initial static group" when generating installer. So leaving it empty would probably resolve issue once installer is re-generated, but AGENTs will be shown in Lost & Found group as this is default.

Actually it is the problem that Marcos asked you to check ... check for eraa_policy_data= in data you posted. You will see that value is huge. Please remove it, si that there is only eraa_policy_data=, i.e. value stored into variable is empty. Also I would recommend to remove your post with installer content, it might contains sensitive data of your ESMC environment.

Check-boxes should be populated based on present of components and also preselected or disabled in case of already-u-to-date component versions. Feel free to check it as it will be shown before actual upgrade process is started. Regarding SQL Server, I would recommend to upgrade to SQL Server 2019 in case your operating system do support upgrade to this version (I hope you won't be offered upgrade in case it is not supported by OS). There are currently no technical limitations or issues with version 2014, but it has reached it's end-of-life and is no longer supported by Microsoft, which might cause issues in the future. That is why we currently install it only on systems where version 2019 is not supported (If I recall correctly, minimal requirement is Windows Server 2016).