MartinK

You can create policy for ESET Remote Administrator Agent and in section Connection -> Servers to connect to list both internal IP and also external IP. Agents will be trying to connect to them in specified order, in case internal network connection will fail, it will try alternative. Regarding your connection issues, we will need more precise error description, i.e. C:\ProgramData\ESET\RemoteAdministrator\Agent\EraAgentApplicationData\Logs\status.html from one of notebooks. My guess is that either there is network issue, or SERVER's certificate is not prepared for this scenario (maybe AGENTs are configured to IP/hostname that is not signed in SERVER's certificate?).

I know it is confusing, but 6.3.12 represents whole package of components released this year. Each component has it's own version and 6.3.148.0 is one of them.

In case AGENT is not connection, it won't be able to receive task, nor configuration policy. ERA does not uses HTTP proxy to communicate with SERVER (port 2222) -> for this purpose, ERA Proxy component was supposed to be used- or maybe port redirection. In order to specify steps for "repairing" AGENT you will have to provide more information, but If I understood you correctly, they are not connecting only because SERVER is not available for them from outside of network. If this is the case, connecting notebooks to internal network should enable them to connect and receive task/configuration policies.

Seems this is known issue - in case restarting SERVER service help, please follow my previous post. Fixed version of module is available for ERA 6.3.12 for Linux x64.

Relevant error from trace log is: Error: NetworkModule [Thread c5c]: bind: (0x2740), Only one usage of each socket address (protocol/network address/port) is normally permitted indicating that at leas one of TCP ports used by SERVER are already used. Have you been changing ports after installation? Are you running ERAv5 on this machine? Or maybe both ERA Server and ERA Proxy. You may try to stop SERVER and run command netstat -b from administrative cmd.exe to get list of opened ports with owning process. Default ports for ERA are 2222 and 2223.

Could you try to search targeted machine for failed connection attempts? There should be alerts in Event viewer -> Windows logs -> Security that could possibly contain reason why access was denied. In case they will be none record on client machine, deployment failed on SERVER side. Are you deploying to computers named by hostname or IP address? We have received reports that in certain cases deploying to IP address helps (you can try to rename certain client computer to its IP address). You may also try to connect to problematic computer directly from root terminal on SERVER using commands: mkdir /tmp/testdir mount -t cifs -o username=<username_without_domain>,password=<password>,domain=<domain> //<computer_name>/ADMIN$ /tmp/testdir and attempt to find suitable parameters. I would also suggest to change share name to some other, or even use non-existing share -> in case you will get different error, connection is working, but user has no access to administrative shares on target computer.

A am not sure I understand you - mentioned configuratoin block: <Connector server="OtherWebServer" port="443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="/home/eset/tomcat.keystore" keystorePass="yourpassword" keyAlias="tomcat"/> has to be written (more precisely existing block has to be modified) into tomcat configuration and not executed in command line.

Are there any errors DB-related in SERVERs trace.log file? This seems to be something different.

Are you using MySQL as database server? As there is a known issue (DB cleanups executed at midnight of SERVER's local time are causing this). Workaround for MySQL is described in topic, and in your case, increasing MySQL configuration parameter innodb_lock_wait_timeout may help until proper fix is available in next 6.3 release.

Seems you are missing configuration of parameters: innodb_log_files_in_group=2 innodb_log_file_size=128M Please before applying, confirm it in /var/log/eset/RemoteAdministrator/EraServerInstaller.log -> it should be mentioned there.

Can you point me in the direction on how to do that ? It doesn't mention activation in the software installation task for me. In task configuration, there is section called "ESET License" and next to it is clickable <Choose ESET License> which will let you choose license to be used to activate installed product.

Unfortunately you have chosen most problematic linux distribution for ERA deployment. This error means that your MySQL driver is not compatible with unixODBC package you have currently installed. What is exact package name of unixODBC and MySQL driver you installed? If I recall correctly, SuSe has two distinct unixODBC packages, and one of them named unixODBC_23 -> which I guess is the correct one, but it may depend on source of your MySQL driver. Just found this hidden in ERA documentation: NOTE: You should use unixODBC_23 package (not the default unixODBC) in order for the ERA Server to connect to the MySQL database without any issues. This is especially true for SUSE Linux

My guess is that you are using HTTP proxy and it is not accessible from outside of your network? Could you check AGENT configuration whether it is using HTTP proxy? What error do you see in Webconsole as last status of installation task?

Try to install package glibc for i686 platform: yum install glibc.i686

Try to start your command with sudo /root/downloads/Server-Linux-x86_64.sh instead of sudo zypper install /root/downloads/Server-Linux-x86_64.sh. You were actually not starting ERA installer, but rather program called zypper with parameters unknown for it. EDIT: previous command also expects that download ERA installer is marked as executable, which can be set using command: sudo chmod +x /root/downloads/Server-Linux-x86_64.sh

Never seen such error - maybe only installation command line is malformed or containing special characters without escaping that could break installation script? Please check proper characters are used in command line, for example double dash "--" may have been accidentally replaced with one long dash "—" (this happens especially when copying from HTML documents) and that could cause errors like this. There may be more information in installer log: /var/log/eset/RemoteAdministrator/EraServerInstaller.log. You may also try to execute installer script with tracing, i.e. "sh -x <commands>"

As already mentioned, it may be problem with self-defense, but also it could be that AGENT service was not able to stop in reasonable time (I think setup is waiting 30 seconds) which could have been caused by long-running task. Have you tried to upgrade manually, or re-tried using ERA?

Could you specify exact version of ERA installer you are using? Also what database type/version are you installing it to? This seems to be problem described in ERA documentation, see question Why is my ERA installation failing during database setup? I have binary logging enabled in MySQL in ERA documentation: hxxp://help.eset.com/era_install/63/en-US/faq.htm PS: you have now most probably ended up with broken (half-installed) ERA database, and you will have to manually drop it before another installation attempt.

This is known issue in ERA 6.3. Does restarting SERVER (command restart eraserver) or restarting makes any difference? In case restart helps, you may also use fixed libraries for ERA Appliance 6.3.12.0 (only for this) available as attachment. Provided archive contains steps for appliacation. Restart updated all the timestamps. I'll place the hotfix and see how it goes. What type of task are you using to activate product? Software installation of Software activation task? As first one should install security product and activate it after it is installed - this does not work for you? There is a software install task that installs the AV, it is set on a 'run ASAP' trigger on the lost and found + windows computer groups. The activation task is a Product Activation type and is set to the same groups. I did just notice there was a dynamic group that is supposed to have all the computers that lack activation but I was getting the impression that it wasn't always accurate. i assigned an activation task to that group earlier today with a */5 cron trigger so time will tell if that worked.. If the AV install fails it will occasionally also not try to install the software again, I considered making a dynamic group that has computers in it that report having no antivirus installed but I've seen computers that gave that alert when they boot and Eset 6 just isn't running fully yet. Not sure how to automatically deal with those. Easiest is to use one software installation task for both installation and activation -> it will execute activation after installation successfully ends, and that is probably what you want.

What type of task are you using to activate product? Software installation of Software activation task? As first one should install security product and activate it after it is installed - this does not work for you?

This is known issue in ERA 6.3. Does restarting SERVER (command restart eraserver) or restarting makes any difference? In case restart helps, you may also use fixed libraries for ERA Appliance 6.3.12.0 (only for this) available as attachment. Provided archive contains steps for appliacation. Server_Linux_x64_6.3.12.1.zip

ERA receives only events from pre-defined firewall rules (not from custom rules) mostly from IDS. Configuration on endpoint is located here: Personal Firewall -> Basic -> IDS and advanced options -> Intrusion detection

Fix for this issue should be available i next 6.3 release. Until that, another tap somewhere on the screen should re-open keyboard (I was not able to test it, but this workaround was reported as working).

Could you please try to find "Google Chrome" referenced in affected machines registry under key: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall] as that is main source of installed applications for AGENT. Please check whether there is only one entry, and what version it is registered with. From screenshot we can also see, that also support for quiet uninstall is different for those two Google Chrome versions .. what type of installer has been used for upgrade?

This error does not mean that ERA is connecting to wrong database, but it means user root in your database is not permitted to connect from IP 192.168.5.8 (so I guess 192.168.5.8 is IP of your current ERA installation?). In order to fix this issue, you will have to enter database management tools you use, and modify/create root user so that it is able to connect from current location of ERA. For example if you rename this user to 'root'@'192.168.5.8' or you can rename it to 'root'@'%' which means user root will be able to connect from any host (this may be security problem!).