MartinK

Could you please specify version of AGENT installed on this client machines? If I recall correctly, there has been some improvements made into 6.5 release.

Please check SERVER's trace log for "license" related errors. In case not even synchronization works correctly, there may be some problem with ERA->ELA communication

I will add some hints/question as it is almost impossible to understand what is going on without more details. in log from so called "managing" AGENT (installed on the same masine as SERVER), we can see: 2017-08-10 11:11:19 Error: NetworkModule [Thread 7f87df7fe700]: Verify user failed for all computers: 127.0.0.1: NodVerifyCertificateChain failed: NodVerifyTrustResult: 6, NVT_NotTrustedRoot, X509ChainStatus: 0x1, X509CSF_NotTimeValid which tells us that AGENT is not able to connect to SERVER on localhost because SERVER's certificate or CA certificate used to sign it is valid in terms of time (X509CSF_NotTimeValid). In SERVER's log there are multiple failures of installer creation. During installer preparation, it is required to find CA certificate that was used so sign currently used SERVER certificate (i.e. the one set in server settings), and this fails with: 2017-08-10 10:33:07 Error: CRepositoryModule [Thread 7f415c7f0700]: OnlineInstallers: exception on certificate issuer request: GetCertificateIssuer: First try failed with: GetCertificationAuthorityCertificate: certificate record was not uniquely identified by serial number '01e728fabbc4a94ea586d5d62b1d64835501' (found=0), Second try failed with: Build chain failed with NodVerifyTrustResult: 0, NVT_Trusted, X509ChainStatus: 0x1, X509CSF_NotTimeValid the same problem = CA certificate that was found is currentl not valid, it is expired. You mentioned, that this server is newly installed, and I would expect that newly generated certificate will be valid -> this brings us to question: have you changed SERVER certificate in server settings of newly installed SERVER? Or this is not even log from newly installed SERVER? Have you imported old CA certificate from old SERVER to newly installed one? Regarding of error on remote client, following entry: 2017-08-10 14:25:48 Error: NetworkModule [Thread ad8]: Verify user failed for all computers: 192.168.164.12: NodVerifyCertificateChain failed: NodVerifyTrustResult: 6, NVT_NotTrustedRoot, X509ChainStatus: 0x10000, X509CSF_PartialChain means that AGENT is not able to connect to SERVER hosted on 192.168.164.12 because it is missing correct CA certificate, i.e. AGENT is missing CA certificate used to sign SERVER certificate. Is this client reinstalled? Is it connecting to correct IP address of new SERVER? Regardless of possible issues, in case AGENT are no longer able to connect to old SERVER because of invalidated or expired certificate, there won't be any simple migration possible -> those AGENT's has to be "repaired" so that new hostname and certificates are applied. Repair may be performed by running AGENT installer (live, bundle) with new certificate. Just be aware, that new certificate won't be applied during upgrade. For example if youy "lost" AGENT have version 6.4 and you are using installer of 6.5, upgrade will be performed, not repair. For repairing, another execution of installer will be required.

What is this task execution state (history) on client where SERVER is installed? Could you also check version of AGENT on the same device? It it will be already 6.5, it means that for some reason, upgrade of SERVER failed (maybe failure during installer download,...). The fact that you are able to login means that upgrade attempt is not running (i.e. it is not in state when waiting is required). You may try to re-run task in case it is reported as finished (failed). Alternativelly manual upgrade may be possible (download SERVER installer + run)

So initial problem was that AGENT was not able to resolve hostname "eset1" of your server - this is network related issue. Regarding certificate, this output means that AGENT is missing CA certificate used to sign AGENT's certificate, which most probably means, that you have different CA certificate for SERVER and AGENT certificates. During installation, it is critical to provide SERVER' CA certificate, which may result in this non-critical failure. Once AGENT connect o SERVER for the first time, it should receive all CA certificates and this error should disappear. Unfortunately I am not able to help with licensing issue.

As you already found out, currently there is no alternative except modifying this value directly in database. It is string field: tbl_servers.server_identificator Once changed, it will be used as "default" hostname when creating AGENT installers.

Ple check AGENT logs to diagnose connection issues (see documentation fo details). Otherwise we can only guess what could have possible went wrong. In most cases there are problem with network connection. Is this operatig system somehow differnt from other ones?

Is it possible to check this configuration parameters in configuration of product manually? Does splash screen shows next time GUI is started - for example after reboot?

ERA 6.5 appliance (based on CentOS7) uses apache http proxy available from official CentOS repositories. Configuration file enabling http proxy with ERA specifics is located in file /etc/httpd/conf.d/proxy.conf. It should be possible to enable authentication as is described in Apache 2.4 documentation but it was not tested, nor it is documented by ESET. Could you also ask customer for his reason to require authentication? Apache proxy distributed in ERA appliance is configured so that it forwards requests only to ESET servers. This significantly reduces risk of proxy misuse.

There is installation parameter P_INITIAL_STATIC_GROUP, but it is considered as internal. It takes special token, which cannot be generated manually and thus only possibility is to create live installer for each static group (BAT file) and copy token from it. This token guarantees that user installing AGENTs won't be able to change initial static group to different, which may give him access to objects that does not belong to him.

Random part of this expression will be reinitialized each time AGENT service is started. Technically those special symbols "R" are during initialization replaced with random constant, so for example your cron will be interpreted as: * 11 7 * * ? * and after next AGENT startup it may be: * 43 17 * * ? * This also means, that until AGENT is restated, interval of execution is fixed. In your case, task will be executed exactly every 24 hours in the same time. Just one warning: cron configuration like you provided is not suitable for replication, nor any other task. It you configure trigger this way, task will be started exactly 60 times a day, but in one minute at 11:07:00, 11:07:01, 11:07:02, ..., 11:07:59. It is caused by "*" in seconds section of cron configuration.

You will have to temporarily disable firewall using command: service iptables stop It is also possible, that user you will be using to acces database is not configured for acces from outside of appliance. For example there is no root@% available in appliance by default. If you encounter this problem, you will have to create new account or modify existing, using command line MySQL client. For example existing root@localhost user may be updated using: UPDATE mysql.user SET host = '%' WHERE host = 'localhost' AND user = 'root'; FLUSH PRIVILEGES;

Seems that you have missed step 19b from referenced documentation. Clients (AGENTs) has to be configuired to use custom repository using configuration policy. You just have to create new policy for "ESET Remote Administrator Agent", change repository configuration and assign policy.

This is very common problem with upgrade of ERA 6.4 -> ERA 6.5. Most probable cuase is that upgrade process was interrupted (service restart, appliacne reboot,...). Please follow steps described in documentation.

Could you please check /var/log/eset/RemoteAdministrator/Server/trace.log for errors? Seems that eraserver daemon is not running.