MartinK

Hostname we see on bottom is reported by client, and in case client is connecting (according to last connection time) we can be almost sure this computer is WHSWIN703704B. I know it may be confusing, but name shown on top is static (it does not change automatically) and for some reason it is different than expected. Most probable reason is that DHCP server and DNS server were out of sync (or maybe only DNS caching caused this if enabled, see: https://support.microsoft.com/en-us/kb/245437).My guess is that AGENT was actually deployed to different computer than it was supposed to be during mentioned out-of-sync interval. In case my hypothesis is correct, you may be able to verify it from DHCP logs as those two computer should have shared the same IP address during time of deployment. Regardless of reason, I would suggest you to regularly execute task Rename computers which will rename specified computer to current value - value from bottom of your screenshot. In case computers are using stable hostname and only IP addresses are changing, one-time execution should be sufficient. In case computers are changing also hostname, I would consider scheduling this task, to get current computer names.

Did it took 20-40 minutes to deploy on one or multiple computers? Only difference with previous versions is that we are not deploying parallel as it cause more problems, but this seems to be more issue with slow downloading of data, most probably caused by slow HTTP Proxy. In case you are using Apache HTTP proxy distributed ERA, could you specify version you are using? If I recall correctly, previous versions had bugs that may have caused similar behavior - especially in case it was running longer - have you tried to restart it and check updates download speed? There is also chance that ESET download servers were overloaded at that time, as both updates and installer are downloaded from the same infrastructure. Regarding missing AGENT after successful deployment: could you please verify that it was actually being installed on correct machine? We have seen cases where customers were using dynamic IP addresses and remote deployment of the same computer was installing AGENT on different PCs. Deploying the same "computer" to multiple PCs may cause serious problems because multiple AGENT will be reporting as one computer in Webconsole.

Just for clarification, when re-installation of SERVER is required, database must be restored from backup prior to SERVER installation, so that installer has access to data from database. Otherwise it won't work as database is tied to SERVER installation through unique identifier stored in both windows registry (on linux it is file config.cfg) and database itself.

Please try to check with related article KB2434. In case EDF server are manually available from target client, there may be problem with Endpoint configuration (i.e. invalid HTTP proxy) or certificate of https://edf.eset.com/edf is considered as invalid.

During remote deployment to windows machine, service is registered and started to perform actual download & installation. In this case, service was already there (previous deployment attempts?) and we are unable to remove it. There may be multiple reasons for this (for example see this: hxxp://stackoverflow.com/questions/20561990/how-to-solve-the-specified-service-has-been-marked-for-deletion-error)and sometimes there is no other way than restarting system. Does this happen often? Or only specific machine?

According to log, remote installation process got almost at the end. There is no connection, nor authorization problem - but installation process is stuck. Unfortunately we are not able to find out what exactly caused it, but remote installer was supposed to: Download AGENT installer from ESET software repositories (using HTTP Proxy as configured in SERVER's settings) Install downloaded package using msiexec. Both of mentioned operation could possibly take too long. Download can be stop either on slow line, or on connection timeouts. Installation can be stopped because of other msiexec process being run on target machine. Is there a chance to monitor client machine during repeated remote installation attempt? There should be instance of process RemoteInstallService.exe running during installation.

I guess you are using client task "Software installation" that is actually executed on client machine (AGENT) and therefore is uses it's own HTTP Proxy setting that can be configured using configuration policy. Please verify HTTP proxy is properly configured on your clients (request exported configuration from this client) and check whether HTTP proxy is accessible from client machines using parameters from exported configuration. In case you used all-in-one installer, there will be pre-defined configuration policies for AGENTs with HTTP Proxy parameters, but they may be invalid (for example they may contain IP address not accessible from outside network).

In case you mean IP address shown next to computer name in main view, it is reported by AGENT -> in case AGENT is not connection, it will show IP address it used in moment it last connected and reported change. Regardless of this, computers in Webconsole are paired with AGENT installation using unique identifier, that is not associated with IP, FQDN or MAC address. Therefore it is not affected by HW or Network configuration. In case computer is marked as unmanaged means, that this computer has never connected or last connection time has been erased. When you open client details for this particular computer, can you see any information that has been received from AGENT? How was this unmanaged computer created? manually or using synchronization? How you installed AGENT on this system - using remote installation task? Actually something like this is being prepared, but I cannot give any ETA.

Name of computer is chosen in moment it is created - in your case it was named after IP because reverse resolving failed or DNS entry was not available. Even this computer changed IP address since first connection, it will be still visible as original name. I guess that is what caused confusion. In order to rename computers, you have to either rename them manually (seems not practical in case computer are changing name very often) or you may use "Rename computers task" which can be scheduled to rename computer to FQDN they are reporting itself - I think this task has been added in 6.2 and improved for 6.3. For more details, please see documentation: hxxp://help.eset.com/era_admin/63/en-US/st_rename_computers.htm Tip: you may manually name your computers as you wish. It is interpreted as IP/Hostname only when targeting it for remote installation (AGENT deploy) task.

Anything I need to do manually to upgrade or will the components upgrade themselves? In default configuration, modules upgrade attempt will be made every 6 hours and most probably also when related configuration changes (i.e. changing regular to pre-release may force update attempt).

Actually I was little wrong. They are fully compatible and this error means that this EES 6.1.2227.0 does not protects AGENT (= its. HIPS module is too old for it). You can safely ignore this error as it is expected for this versions combination. If I understood you correctly, status.html of those AGENTs contains recent successful connection to your SERVER which indicates problem may be on SERVER. We have met with this problem, and most probable cause were: AGENT is connecting, but it is visible in Webconsole under different name than expected There are two installations of AGENT with the same unique identifier (cloning disk or VM machines) which causes two different installations to be represented with only one entry in Webconsole. Could you please try to find this computer by last connection time when comparing status.html data and data visible in console? It may be possible for smaller networks.

Running remote administrator components upgrade replaced modules with version available in installer package as it either runs upgrade, or repairs ERA products - so this is expected behavior. Regarding current version of configuration module, version 1277.6 is rolled out these days, and there may be some download limitation applied (i.e. not all users are getting newest version at the same time). I would wait few days, and possibly check whether there are no related errors in trace.log in case it won't update.

Location of webapps directory varies from distribution to distribution and version to version... I guess it will be /usr/share/tomcat6/webapps in "SUSE Linux Enterprise Server 11".

When using Task Manager -> Processes -> Show processes from all users you should see ERA processes separately (ERAAgent, ERAProxy). In case even in this view it look like svhost.exe is taking CPU, tools like Process Explorer (https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx) may be useful, they are able to show what is running under specific services host. As you noted, it may be virtually anything .. from bug to standard post-upgrade processes (maybe some kind of reindexing...).

We are not aware of any issues on Windows 7 (even it is not official supported system for ERA SERVER installation). Could you be more specific what process is taking CPU? If we ignore performance, does ERA actually work, or services are not even running?

Remote installation should run "repair" on AGENT installation -> it won't be successful in case DB was corrupted, so I guess problem is so called HIPS module of EES blocking AGENT's attempts to access its files. Unfortunately I am not sure where exactly could be problem. Is is possible to uninstall EES from target machine and attempt to repair AGENT (after system restart)? Or maybe manual upgrade of EES to never version?

Hello, short list of generic recommendation: I would strongly recommend to create snapshot/backup before proceeding. You must also expect outage of ERA services, especially in case there will be update of critical packages (i.e. MySQL database, core system libraries, linux kernel). Certain packages may require you to restart whole system afterwards. There is a chance system won't be remotely accessible after update, therefore I would plan updating to time you have access directly to linux console and do not rely on SSH/ERA Webconsole - especially in case you are updating after longer time. In case you do not want to risk possible functionality problems there is also possibility to update only selected packages (for example OpenSSL or java security updates), which will reduce impact on system. Even there is possibility to perform update from ERA Websonsole, It is recommended to perform it directly from command line, so that you have full control and can handle possible problems. Before you update, you must be aware of that we were testing appliance in state as it was released, and therefore cannot guarantee, nor predict what could possibly happen after future updates.

I would suggest to get C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html from broken client computer. It should contain connection error.

Hello, this kind of errors is caused by MySQL 5.7 which introduced changes ERA is not compatible with (ERA 6.3 was released before). We have fixed this issues for upcoming release. In the meantime easiest solutions is to use MySQL 5.6 instead. Alternatively you could try to configure MySQL 5.7 not not use mentioned sql_mode, but we have reports that it is not possible every-time (especially with linux installations). Regarding MySQL driver installation on Ubuntu, it is much more complicated since current release -> you could try to find some custom packages, or use official MySQL driver, which will work correctly, but installation procedure is not easy.

So there are two errors: Replication (network) connection to 'host: "EraServer" port: 2222' failed with: Unable to resolve any endpoints.resolve: (0x2af9), Host desconocido caused by EraServer to be not resolvable by AGENT. Could you try to ping this host from client machine? Maybe problem is different case (EraServer != eraserver). There is also another error: Certificated user verification failed with: VerifyDnsSubjectAltName: Certificate SubjectAltName extension does not have any supported records after a minute gap in trace log. this indicates wrong certificate has been used to install AGENT, have you been doing some kind of repair?

Please check C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html on target computer (client computer). It should highlight most significant error.

Regarding failed remote installation attempts: is ERA Server machine joined to the same domain as target computers? Is ADMIN$ share remotely available from other machines? In case ERA Server is not in domain, administrative shares may not be available because of Remote UAC feature, which can be disabled on target machine (see official KB) Please check C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html on target computer connection problems.

In case you meant ESET Remote Administrator Proxy it won't help. Both software installation task and remote installation are downloading packages on client, i.e. so called "push" installation is not supported. Yes, you can set up your own "mirror" for this packages to be sure no traffic leaves sub-network. In case you are in windows-only environment, even file on network share should be sufficient.

Actually this assumption is not correct. Package to be installed by software installation task is downloaded on client machine, by AGENT itself directly from internet ESET repositories. This can be avoided using HTTP proxy. If I understood you correctly, for your case would be best if AGENTs on targeted clients are not using any HTTP proxy and thus downloading packages directly from internet. Alternative is to install HTTP Proxy in targeted sub-network to avoid extensive bandwidth usage during packages download, as it may be huge (installer size * number of client computers at least).