MichalJ

Don't know the technical details but wouldn't that require either constant connection or polling at specified intervals? doesn't sound like a good idea for corporate firewalls. How about some kind of management mode? for instance when you switch on management mode(provide a way on both server side and client side, obviously on server side this is like setting the 60 second policy), then Agent will force it's connection interval at 60 seconds, then automatically revert back to the original connection interval after 1 hour or something, in case people forget to unset it. In fact this would be a good idea for deployment too, make management mode the default and have a sensible default connection interval like 10 minutes. I've seen many people not applying connection interval policies and left it on default(I believe Agent default is 20 seconds) even when they have already deployed hundreds of clients. This is something we do have planned for the future versions (not ERA 6.5). Basically implementing a logic IFTTT (if this then that). It would allow us to specify policies with a set expiration, and other things. Also some local interface for agent, allowing to do certain operations over agent is being evaluated for future versions.

Hello, high level scope of changes is described in my first reply. As 6.5 is still under development we are unable to provide more details now. But please stay tuned, more news will be shared as the time goes closer to the release.

Hello, it should be there later today or early tomorrow.

We are currently evaluating a new method of "push-like notifications", that might be used to wake-up agents / force connection to ERA. However, internet connectivity might be needed for such functionality to work correctly. Would this be acceptable solution?

You can not see a device control "log". You can however create a report, that collects data from device control rules. However, ERA V6 by default only collects the logs with severity "warning" / "error", so configure the device control rules, to be reported with this severity.

Please provide more granular explanation of your question, as from what you have provided, I am not able to identify the use-case you would like to achieve.

Hello, If the ERA is installed on a Windows machine, you should upgrade the server manually. Stop the tomcat, era server service, install the new era server over the old one and then start the era server again. You can download 6.3 installers from here:hxxp://support.eset.com/kb6114/ If I may ask, why you are not upgrading to version 6.4?

I would suggest using ESET Uninstaller to manually remove the ERA agent, in case it is not working: hxxp://support.eset.com/kb2289/

Installation of EEA / EES on server is not supported. What problem you would like to solve, with installing a firewall on a server directly? (this is a unique request, and we currently do not have any such plans). Thank you for your response.

Hello, 6.5 is planned to be completed in December 2016, meaning the release should occur in early Q1/2017 (but as it is still under development, there is a possibility of a change). Concerning the feature news, besides full multi-tenancy, improved user interface, performance, redesigned notifications, it will bring a lot of changes / improvements that will please all of you here. We will share more news as the time goes...

This will be solved in Endpoint 6.5, currently scheduled for December 2016 / January 2017 (together with the ERA 6.5).

In case of PUAs, you have to have your scanning profile set to "strict cleaning" instead of "normal cleaning" (default value), in order to remove them. So first apply a policy on your endpoints, with strict cleaning set for your scanning profile, and then re-execute the scan again.

Hello, this behavior happens due to the way how firewall / ERA configuration is currently handled. When you manage FW via ERA, it means that the configuration on the Endpoint is read-only (regardless when you set "apply" or "force" flags. Difference between the "force" and "allow" flags is, that when a setting is set with "force" flag, it prevents it from being overwritten with a setting from another policy, which is lover in the hierarchy (you can have the same setting set to "ON" on "root" (all) level, and you can have set it to "OFF" on the specific group / client level. If both policies have the same setting with "apply", the one lover (client/group) will overwrite the root policy. However, if the "root" was set to "force", its value will be kept, regardless the lover policies). Issue is, that when you define one "master" FW policy, and some "more specific" policies, it handles them as "one setting" meaning that it overwrites the master list, with the specific exclusion. This behavior will be changed in the upcoming versions of ERA / Endpoint, where it will be possible to merge lists in policies. If you put the FW into "learning mode", and you still keep the "rules set" with either "apply/force" flag, it won´t work, as the Endpoint client will not be able to save generated rules into configuration, as configuration is "read only" due to list being enforced from ERA. So the it will work only in the case, that you set remove the policy flag from the list. You can then "request the Endpoint configuration" via task, and convert it into the policy, for the requested clients. That is a current workaround that popped to my mind. However, as said above, it will be changed in the upcoming release of ERA 6.5 and Endpoint 6.5 which are scheduled for December (but it might happen that they will be released in January).

This is a result of installing ERA Server using either "all in one" or "appliance" and checking the option to install "apache http proxy" on the same machine as ERA Server. This will configure ERA server settings, agent policy and policies for Endpoints to communicate with ESET servers using this proxy server, for caching of AV updates, installer packages and it also forwards the communication with ESET Live Grid and licensing servers. However, your ERA Server should have a static IP address set, to make this work properly.

Hello, ESET Endpoint Antivirus / Security is not intended to be installed on Server operating systems (valid for version 5/6). We do recommend installing ESET File Security (ideally V6, but as you are running v5 of ESET Remote Administrator, you will have to install version 4.5 which is compatible with ERA 5).

Original ESLC is compatible only with VMware vIrtualization solutions. In order to use it on Hyper-V you have to install a Linux distribution and then an ESLC package which is as well available for download. There will be a new version of appliance published in few weeks, which will be natively compatible with Hyper-V.

No, license will be kept from previous installation.

Hello, the appliance is based on CentOS, so what is needed is to perfrom the standard procedure for CentOS: Edit files: /etc/sysconfig/network-scripts/ifcfg-eth0 , /etc/sysconfig/network & /etc/resolv.conf and then perfrom the restart of the network.

If you have a license for EEA and have upgraded to EES, it might explain the failed activation, as license for EEA is not eligible to activate EES. It would also explain the task results, as the "failed", refers to the sctivation part of the task (you can check execution details, where you will see that the installation finished successfully).

Hello tbsky. Seat ID is generated upon a part of the process, which is called "association". This happens, as a part of the activation scenario, when client installation first contacts ESET Licensing server. This happens in two cases: Normal activation - client is activated using license key / security admin account, and it connects intentionally to edf.eset.com to register Silent association - to verify offline file potential misuse. Client is activated using offline license, however it still tries to reach edf.eset.com. When it succeeds, seat is generated. I (or some of my colleagues) will post a second response, concerning the "seat ID" information.

This is weird. Upgrade procedure is done in a way, that when you install a newer version of Endpoint over the old one (like 6.4 over 6.3), the license information is kept. If this is not the case, it should be reported by a support ticket and troubleshooted. Can you please report here the version of the configuration engine module, you have in your Endpoint product (go to about / modules / configuration support module). Just out of curiosity, have you applied some policy, that was converted from previously exported configuration on those clients, or this is not the case?

Could you please provide details about the used dynamic group template? It might happen, that when you have used a condition "installed aplication name" fir the dynamic group, it will hit before the agent has established the connection with the endpoint, as it gets the installed software name from the Operating System. Please add also a condition for "managed product mask", with the "security product" (little monitor icon). This would prevent the task from triggering before the agent/endpoint communication is fully established.

Hello, this is related to the "configuration engine/ support module". This component is updatable remotely, via an updateable module, and it might happen that a different version is used locally (by product) and different version is on server. On September 7 we have released a new set of windows server products, with new configuration (policy) options. To support this release, we have also published a newer configuration module, which resolved the issue for you. Server restart / console logout / login might be needed for all changes to fully take effect.

Hello, this is currently not possible.

Hello, this is a tracked known issue. After upgrade, connection between ERA agent and ESLC kernell breakd. It however works OK. You should re-deploy the appliance and prevent it from upgrading the agent. We are working on a newer version of appliance, which will fix this behavior. The same applies for the cerrently released ESET Virtualization Security Appliance.