MartinK

It should be possible even without configuration (actually it is not possible to install pre-configured v6 products) but I am not sure it will be completely silent. To avoid it, you may try to deploy Endpoint Security installer with parameter INSTALLED_BY_ERA=1 to suppress activation and network zones configuration popup windows. Once installed, configuration (and possibly activation task) from AGENT will be delivered.

Big thanks I get it. What about version of webconsole, I get the enviroment about one week ago from another peson. So I must download MSI with ESET Remote Administrator 6.3.136.0 and from there extract era.war ? Webconsole is separate component. You should be able to download it directly (era.war file) and follow installation steps from documentation: hxxp://help.eset.com/era_install/63/en-US/component_installation_webconsole_windows.htm

It is definitely caused by version mismatch. Webconsole must be from the same release batch as there is no backward compatibility. Please upgrade to latest Webconsole.

Yes, already installed AGENT will almost immediately detect newly installed ESET product and start managing it. There is no difference when installing v6 products manually or by ERA, except that products installed using ERA are installed silently and thus using some default set of configuration.

For future reference: error "Error: Problem unpacking installer data" means that either installer is corrupted or there is other problem preventing it from unpacking files. Most common corruption problems are caused by broken installer download or distribution as text file even that installer is binary file (i.e. wrong FTP configuration).

There are two interresting errors in log: First one indicates there is something wrong with HTTPS certificate. Does file /home/administrator/eraserver.keystore exists? Are there sufficient permissions for user that is tomcat7 running under? Maybe SELinux is blocking access? SEVERE: Failed to load keystore type JKS with path /home/administrator/eraserver.keystore due to /home/administrator/eraserver.keystore (Brak dostępu) Second one is: java.net.BindException: Adres jest już w użyciu which indicates that tomcat failed to open port for listening because it was already taken. You can use command "netstat -tulpn" to check what processes are listening on which port. Maybe your original Webconsole port was taken by other application.

In case any won't help, try to restart Apache Tomcat, and also check JAVA_HOME and related environment variables are set correctly, especially in case you have updated Java runtime (jre/jdk) in the meantime.

Password could have been override by configuration policy from SERVER, have you tried empty password to be sure?

This most probably means that connection to DB was not opened properly. Could you please verify that database is properly configured according to ERA manual and that it is listening on selected TCP port?

You may also use "Software installation task" but provided package must be .msi and must support quiet (non-interactive) installation.

And I forgot to mention, that Apache HTTP Proxy is not able to rely AGENT<->SERVER communication. For this purpose, you should either redirect port from outside network to SERVER, or install ERA Proxy component (this is something different than HTTP proxy).

Apache HTTP proxy relies only communication from ERA components and Endpoint Security products to ESET servers and is primarily intended to safe network traffic especially for larger networks. It has also advantages over standard offline mirror: less traffic to outside network (mirror downloads much more data in case synchronization is executed multiple times a day). clients get latest files version from ESET server and not version from last mirror synchronization (this is crucial for security) proxy handles also other security-related connection(cloud) not handled by offline mirror You may also use your own HTTP proxy, but it may require configuration tweaking. There is still alternative - classic offline mirror, but unfortunately no longer available/manageable by ERA, but instead available either as separate tool (MirrorTool: downloads files but does not shares them) or bundled in Endpoint Security as in v5.

Please check ERA logs, especially SERVER's trace log. In status.html you should also see whether AGENTs are connecting. Are relevant ERA services running? Is network on this system working, as it may be affected by RogueDetectorSensor. What kind of error do you get when logging to SERVER, or not even login page is shown?

Seems you have two (maybe related) issues. Seconds one you mention is problem with reverse DNS resolving that may lead to rejecting client connection. It is a known issue and you can use fixed libraries available from here (package contains also firs for other issue and I would suggest to replace both libraries). Other problems are caused by network sockets exhaustion on your system. I would suggest to use command lsof to analyze what process and what type of file descriptos/sockets is causing this. In case it crashes after 2 days, I would wait at least day until running command, so that possible leak is visible.

We would appreciate if you could check or provide logs from target client. Especially software installation log containing full-verbosity MSIEXEC log of last software installation task execution: C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\software-installation.log In case there won't be any log there is a chance installation not even started -> it may have failed during package download from ESET servers (has this client computer direct visibility to internet?). If this is the case, there would be record in main AGENTs trace log: C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\trace.log listed either as "Error:", or most probably also under subdomain "SoftwareInstallation".

Hello, you have not mentioned how you installed ERA, so can only guess. Could you please verify ESET Remote Administrator Webconsole is properly installed in directory C:\Program Files\Apache Software Foundation\Tomcat 7.0\webapps\era\. In case it is missing, please follow installation steps from documentation: Web console installation.

This happens very often in my company. We have clients that have notebooks. In one part of company they are connected with LAN, but when they move to conference hall they are connected to WLAN. There are also clients that connect via VPN and they get IP in different subnet. Exactly what I wanted to describe. Most people here have MacBooks and Thunderbolt display. When moving around the office, they are using Wifi. When connected to the monitor, it's using the ethernet interface. When connected from home, it's through a VPN tunnel. In mac, I can choose which network adapter will update DNS by running this command : dsconfigad -restrictDDNS "en0, en1, en2" where en0, en1 are my interfaces. It prevents virtual network interfaces or VPN connections to be registered in my DNS thus making the computer unreachable from hostname. There is the same type of configuration in Windows to prevent a network connection from registering its IP on the DNS server. Could these settings be used so that ESET inventories all network interfaces that would normally register an IP to the DNS server? Thanks both of you. It is reported as bug/improvement as it may require more work. We have one more question: how do you use rogue computers list in ERA? From this report it seems you regularly monitor list of new machines, is it correct? We expected it to be used primarily before first deployment in network and that is why we missed this issue.

Your assumption is correct. It is caused by incomplete list of detected network interfaces on this client - we are collecting only data for ethernet interfaces with assigned IP address . As a temporary workaround you have two possibilities: modify report template of this report (filters section) so that mentioned computer is excluded from list. create new configuration policy for ESET Rogue Detection Sensor with blacklisted specific mac addresses. Policy has to be applied on client(s) running sensor. We would also appreciate if you could describe what type of network interfaces are those missing from client details? Their are missing IP address because they are currently not connected to network, but were previously and thus detected by Rogue Detection Sensor?

C:\ProgramData\ESET\RemoteAdministrator\Server\EraServerApplicationData\Logs\trace.log

For some reason, SERVER is able to successfully connect to target machine, but used user has no rights to open service manager remotely - that is mentioned NT_STATUS_ACCESS_DENIED error. Unfortunately we are seeing this error quite often but we are not able to find out what could possibly be wrong. In most cases, using local administrator account (= user with name "Administrator" that is mostly disabled by default) helps. Sometimes also connection from computer in domain helps (is appliance connected to domain?). EDIT: glad to hear you were able to solve this. Maybe it was only temporary issue related to latest Samba security vulnerabilities -> maybe windows was not updated...

In case it won't be possible to repair connection to SERVER, only possibility will be repairing AGENT, which can be achieved: manually directly on target machine using GPO or other automated method for software deploying using Remote Installation from SERVER but in case it is certificate problem on SERVER side, it will be possible to repair it - this can be checked also in SERVER's trace log -> you should see "Error" line for each failed connection attempt - identified by IP address (this may be IP address of your NAT/Gateway from outside network).

When AGENT connects to SERVER, both sides are verifying remote peer. In case you used default agent certificate, SERVER will have no problem verifying it. Problem is that AGENT also verifies SERVER's certificate, and this is most probably problem. But to be sure, please check previously mentioned status.html. It will print exactly where problem is and in case it will be certificate-related, we will know how exactly should look new certificate.

Default AGENT certificate is most probably created for all hosts (using wildcard *) -> this means AGENT can connect from everywhere. You can actually see it in Admin section -> Certificates -> Peer certificates, it is column named "Host". More problematic is SERVER's certificate. There will be probably list of signed hostnames/IP address, and AGENT can use only one of those. To get mentioned list, go to SERVER's configuration -> Connection and you should see there description of currently used certificate. Search for something like Subject Alternative names (DNS:<hostname>) possibly containing hostnames or IP addresses of your SERVER resolved during setup.

Is there any chance there is message like this "Creating remote installer service" in omitted section of log? It was most probably first call after "Removing previous instance of remote installer service".

In case there was no previous remote installation attempt, mentioned call to net -i -k rpc service delete eset-remote-installer will be attempted 20 times to be sure there are no remnant of previous installation. After this, there should be attempt to start service regardless of previous 20 delete attempts. I think it fails on starting - could you search for it in log output? There is high probability it will be also failing with access denied, as is common when using domain user instead of local admin (Administrator) account.