MartinK

There is a "Diagnostic" tool available in AGENT's programs files directory and it can export current configuration. Passwords will be redacted but connection parameters should be exported in readable format.

Sorting of this kind should be definitely possible. As previously mentioned, only possible issue might be that multi-column sorting is actually used (indicated by index number in column header you described). Could you check all other columns for sorting indicator and disabling sorting by those other columns to be sure only computer name is used?

It is not documented but I would recommend to check tables tbl_certification_authorities and tbl_certificates.

Depends on you, whether DB migration effort will be not worth of migrating data and AGENT's connectivity. My preference would be to migrate data, or at least to try to do that. For example Management studio might be installed on different machine as it can connect to DB via TCP.

In ESMC's log one can found: 2020-01-13 14:24:35 Error: Service [Thread 35c0]: [Microsoft][ODBC SQL Server Driver][SQL Server]Could not allocate space for object 'dbo.tbl_logbackup_prevlogs'.'PK__tbl_logb__3213E83FAA0C3AA4' in database 'era_db' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup. which is considered as fatal error during startup. It indicates that either database got really corrupted, or more probably that there is no space on disk where database is located. Could you please verify it? Error on screenshot indicates there might be problem also with local system service account - if something in system went wrong, it might happen that database is not able to write data because of missing permissions instead of insufficient space ... EDIT: seems that upgrade of database is failing and it is very space consuming -> during upgrade almost all data is duplicated, which means that there must be enough free space on disk where whole database will fit.

In case you decide to deploy on different server, or more specifically on different database, you can migrate data from old DB to new. It is described also in ESMC documentation for migrations. If you will follow described steps, there will be no loss of data nor AGENTs connectivity (but this depends also on network configuration).

Installing on domain controller is not recommended as there might be conflicts during SQLExpress installation, resulting in deployment failure - this recommendation was present in all previous ESMCv7 and ERAv6 versions. In your case you were clearly able to install ESMC in such environment, so I would not consider this recommendation as relevant = what is crucial is that you have to upgrade SQL database in order to upgrade ESMC. Any chance you tried to install SQLServer 2014+ on DC, side-by-side with existing database and with required settings (especially enabling TCP connectivity to such server)? Or maybe even better would be to upgrade existing database, if possible. Unfortunately this scenarios are not tested so I would be cautious, especially in case DB is used also for other services.

Is there actually any problem to upgrade database and ESMC on the same machine? Could you please pin-point me to documentation or KB that mentions that ESMC 7.1 should not be installed on DC?

Yes, inode limit is fine until you are not using EDTD. We have significantly increased some time ago so you are probably using older appliance (deployed more than year ago) but there will be no problem, as there is not much files cached otherwise. I am little confused by fact that there is much much more inodes than cached files, which makes no sense for me, but this is something that can be changed in configuration of htcacheclean service. In this case it seems that cleanup was not running for very long time and thus so many removed files.

Please double check Tomcat's operational status. In this case not even console is loaded, which indicates problem with it. I would recommend to: check that tomcat is actually listening on port 8443. It might happen it is not in case of missconfiguration or port conflict check that ESMC console is deployed in tomcat's webapps directory, i.e. there has to be directory named "era" in webbapps folder. check that Java compatible with ESMC 7.1 is installed, otherwise it might happen that ESMC console fails to start

Could you please check also more detailed log file: /var/log/eset/RemoteAdministrator/EraAgentInstaller.log for possible clues? You are performing so called server-assisted installation which requires active connection to ESMC. It might happen due to multiple reasons, mostly network or SSL/TLS related.

I think that crucial part of log is 206503 expired which indicates that most of the entries were removed as they were considered as expired. If I recall correctly, most of the files ara cached for 7 days, and if not used, they are considered as expired. Only exceptions are results of EDTD analysis (is used at all) where much more files is cached.

Mentioned product should activate with mentioned license - fact that is is installed on the same machine as ESMC makes no difference. As indicated on provided screenshot, product was activated manually. My best guess is that there were some activation issue (offline environment? Inaccessible internet?) which resulted in manual activation. As you mentioned that activation with current license fails, I think there is still original problem with activation, and I can only recommend to try activation with this license locally, as it might provide more details of activation error.

I cannot verify, but it was supposed to be released on download page today - unfortunately I cannot verify now. It is the same version I have provided to those that asked previously.

From provided logs, especially %TEMP%\ra-upgrade-infrastructure.log mentioned in previous comment we were able to detect original issue: which means that SQL database used is no longer supported by ESMC 7.1, and this manual upgrade is required prior to upgrade of ESMC. In case SQLExpress variant is used, it is fairly simple, using standard MS SQLExpress installers where all data and configuration will be retained during upgrade.