MartinK

Hello, I guess you are using non-default OpenSSL library on you system. If it is your case make sure it is so called "universal" because ERA requires i386 (32bit) version of OpenSSL. For example in case you are using macports, you can use command: sudo port install openssl +universal to install OpenSSL libraries suitable for both platforms.

Use serial number as that is only one field to be unique - all others can be the same ...

There is a server task called "Rename computers" for this purpose.

Hope they we able to resolve it. There are two main reasons this type of error: ERA server is not running: can be check in "Services" and possible failure reason can be found in ERA server trace.log Apache Tomcat hosting ERA Webconsole is not running properly: this may happen after java update - especially in case old java runtime environment is removed during update

We have decided to rely on system to restart service in case it stops unexpectedly. Main ERA components have support for both systemd and upstart (added in version 6.3) init daemons with enabled automatic restarting of services - which should cover most of mainstream linux distributions (including ERA appliance which was really missing this feature).

This seems to be a performance problem. Could you please specify some HW/SW parameters of your database server (DB type, available RAM). As a workaround I would suggest to use more strict filter and clear old threats in smaller chunks.

Client task "Run command" works so that it creates regular bat file from task parameters and executes it. I think you will be able to run PowerShell command, but in form described here: hxxp://stackoverflow.com/questions/6037146/how-to-execute-powershell-commands-from-a-batch-file

Problem is that current implementation relies on ARP messages and therefore it's passive detection is limited to current subnet. Technically you have to install RDSensor (+AGENT) into each subnet. List of detected machines will be sent to ERA server automatically (through AGENT installed on the same machine as RDSensor) and merged on ERA server into one list as if detected by one sensor.

You should be able to modify trigger for already existing task - location depends on version you are using. But unfortunately there is no way how to explicitly set it as never expiring. Be aware that if you edit ASAP trigger, task will be re-executed even on targets it has been already executed

You may use installation repair in this case: you will need SERVER installer of the same version as currently installed. In case you have not performed components upgrade since your ERA Appliance deployment, it will be located in /root/eset_installers/. login into appliance with root password (i.e. get to command line) run repair using this command: ./root/eset_installers/Server.sh --skip-license --server-root-password=<PLACE YOUR NEW PASSWORD HERE> Reload Webconsole and login as Administrator with new password

Have you tried to look into appliance-configuratoin-log.txt as suggested? There may be more information about failure reason. This type of installation of VAgentHost requires active connection to ERA server .. could you verify there is open channel between them = check whether network is properly configured in failed appliance.

Other clients connecting through these proxies works correctly? Have you been doing any revert/restoring operations on machines running those proxies? What database types are using those proxies?

All I can tell you now is that it will be tracked as a bug, but this scenario is very problematic because of AGENT service restart required by components upgrade task.

What price i win ? :-) One big "děkujem"

Actually it depends on type tasks. All task are started in the same moment, but if they are to be executed in the same "module", they will be synchronized. Your scenario is of course bug caused by special handling of components upgrade task and also msiexec limitations. For example: if you run software installation, export configuration and on-demand scan, they will be executed completely parallel from start to end if you run two software installations, they will be serialized but both started almost in the same moment.

Not sure about ELA interface, but until MichalJ is available for qualified answers, you can check trace.log of both AGENT installation for something like this: Hardware Fingerprint: 00000000-0000-0000-0000-000000000000 It should be printed just after AGENT start regardless of currently set trace level, but I am not sure it was available before 6.3 release.

We are sorry for your inconvenience - you have just found a bug. Seems that Common name of certificate cannot contain non-asci characters (in your case it is á). Please create new certificate for AGENTs with Common name: Agent certifikat pro hostitele * instead of default value containing diacritics. There is also chance you will have to regenerate SERVER certificate if AGENT will be reporting the same error as AGENT is reporting currently.

So now I am also confused. Error Certificate common name contains ambiguous or no product string means that in CommonName of AGENT's certificates contains not only expected word "Agent" but also "Server" or "Proxy" (regardless of case sensitivity), but that would be invalid state that is checked during certificates creation wizard - or you are using your own certificates created outside of ERA? Could you please check status.html on not-connecting AGENT and verify that "Peer certificate" used conforms to this limits, i.e. check that it is certificate that it was supposed to be?

Now it is exactly the same error, but on other side of connection When AGENT connects to SERVER, its name is resolved to ip-xx-yy-zz-aa.net.upcbroadband.cz, but this is not matching any name nor IP address in AGENTs certificate which contains: era.mydomain.cz,xx-yy-zz-aa,10.0.10.99,127.0.0.1. Therefore SERVER rejects connection for security reasons. I would recommend you to create new AGENT certificate suitable for any hostname/IP using wildcard *.

I am sorry that I have to inform you there are no customization possible. Content of notification is technically a CSV representation of "event" that caused notification to be triggered. Currently there is no data processing or interpretation implemented, except source translation to human readable computer name and time of occurrence, which are common to all events. There are plans for complete redesign for both information content and presentation (email formatting, HTML, ...) but I can't give you any ETA. We have decided to use semicolon as separator because it is more suitable for supported locales (especially for locales using comma as decimal point in numbers). Could you specify locale and software you are using to "paste" data into? We may reconsider our choice and change separator (based on installation language) in case it is actually not usable.

Please follow this: hxxp://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-changes, when set in my.cnf it should be sql-mode , but there is also command line parameter --sql_mode that can be used to override configuration - but this depends on how your MySQL daemon is being started. In case you wont be able to make it work, I would suggest to downgrade database to MySQL 5.6 that is fully supported by ERA. You are using database that was released later than testing of latest ERA has begun.

Problem is that certificate you created is tied to hostname era.local but AGENTS are connecting to era.mydomain.cz. You will have to create new SERVER certificate that will be created for mentioned hostname, or with special wildcard "*" for matching all hostnames (less secure).

I will quote MichalJ's statement: Hope that helps at least until computers renaming is available.

Now I am almost sure it is problem with upstart which was introduced in 6.3. There containers (lxc, docker) are not able to handle upstart or systemd services properly, they are either completely mocked or requires advanced configuration to work properly. ERA installers are detecting upstart by searching for command "initctl" -> once found, fully operational upstart is expected. In case you will be able to confirm that it is problem with upstart service initialization, only solution we were able to come with is to fool upstart detection by temporarily renaming/removing initctl command => in case it is not found during installation, fallback SysV-init scripts for daemon startup will be used. Btw. ERA AGENT installed in this container should be having exactly the same problems ... is it upgraded to 6.3? Is it actually running/connecting to SERVER?

Installation (or in this case repair) failed during auto start service registration into system: 2016-02-01 13:17:03 Information: Installer: Setting auto-start service. therefore SERVER is not starting after reboot and you have to run it manually. It is almost last job to be done, therefore your installation should be working correctly, except service won't be started automatically after reboot (or after unexpected failure). Unfortunately we have not enough information to come to any conclusion. What linux distribution are you using? Any chance you are running ERA in docker? Are you using SELinux that could possibly block installation? In ERA 6.3 we have introduced support for upstart services but it seems to be failing, any known issues with upstart in your environment? Also you could try to run repair manually from console (download latest 6.3.148.0 installer + run it as root with only one parameter --skip-license) -> it will most probably print errors to console.