MichalJ

Hello, I do not see anywhere "license is expired". Basically, we do have something as "grace period", meaning that 14 days after the license expiration, updates are still being provided. What is displayed in the "about" screen indicates information from the parsed license file, which really shown when your was set to expire.

Direct download link for the webconsole is: hxxp://download.eset.com/download/ra/v6/standalone-installers/webconsole/era.war(it downloads the version 6.3, which is needed for you).

Your webconsole has not been updated. You need to manually download and place the era.war into the tomcat directory (while tomcat service stopped) and previous era webconsole folder (webapps/era) either removed or renamed to smth. else. Once you restart the tomcat and wait a while, until it extracts everything it should all work normally.

What is needed to be done is to also update the license file, in the ESET Mail Security application as it is not possible to update it automatically, by renewing the license. This would be my first tip, on how to resolve this issue. The "license valid until" is get from expiration servers, and tells you when the username / password expires, however EMSX also uses a license file, to enable the mail filtering functionality. When you update / replace the license (.lic) file in the application, it should get back to normal.

Hello, please contact your local support representative and open a support ticket, as we were unable to determine the cause of the problem from the info attached. Also please comment, if you have configured your product, to update via apache http prpxy, or it has direct access to the internet. The same is valid for the ERA server. Concerning the repository issue, it might happen, that the software install task, you want to run, linked to a package, that is no longer available in the repository (it was replaced with a newer version, for example). I would suggest creating a new software deployment task, and trying it again.

Hello, Problem with the solution you have mentioned, and Sam has recommended to you is that: If you choose the mirror from a specific Endpoint version, it gets updates only from update server appointed for that version. If you update V5 / 4 products, it might happen, you won´t get the updates. Also, it depends, if you have installed EEA / EES on the server (I assume EEA), so it might not download all of the files needed to update EES. Mirror from a specific Endpoint version is not able to get updates for ERA components, which we are going to release as of now (it will bring some new functionality, like import of lists into the policy editor, and support for new settings in Endpoints for Windows / Max + support for Domino / SharePoint. You won´t get it, if your agents are updating from Mirror. Also, if your company is using some proxy server as of now, you could not install the Apache HTTP proxy, but instead of that, configure ERA server / agents / endpoints, to communicate via your proxy server, and cache updates there. This way is far more effective from the perspective of data traffic, and once setup properly, it provides better user experience than the legacy mirror. We are working on documentation change, that will explain benefits of using Apache HTTP Proxy, over the standard mirror, respectively guide customers to use the proper scenario of their environment.

Hello, as of now, it is possible only by manually defining the scan targets. It is not possible to configure such setting remotely from ERA as of now (we are tracking improvement for that).

Hello, As of now, when you sets "Do not ask for protection type of new networks. Automatically mark new networks as public." - each new network is recognized / marked as public in ESET firewall, regardless the Windows settings. Solution is only by importing the list of networks which are marked as home/work, all others will be marked as public. Other option is to not enable the checkbox, however a popup will be displayed to the user, and unless he has admin privileges, he would be able to mark networks only as public. For the future MAJOR (7) generation of Endpoint, product will be able to overtake the network preferences from Windows (this seems to be the feature you want). It will be first time included in ESET Consumer products V10, which are scheduled for release in Q3/Q4 2016. Endpoint 7 will inherit some of the changed behavior, including this, but as of now, there is no clear time set, except the fact, that it will be fore sure in 2017. Hope that this helps.

Hello zfactor, you can PM me your region / country, and we will follow up from there with the partner / office directly. Thank you.

Module release posts are not shared publicly, we only share them with ESET Partner network. Basically what I have mentioned here, is the full release notes for this CE release.

What is important to say is, that you need to use the newest (6.2 / 6.3) builds of Endpoint, with the updated hips module. You can configure password to protect installation since ERA 6.3 (just create a new agent policy and configure password protected configuration in "advanced settings").

Problem with the solution you have mentioned, and Sam has recommended to you is that: If you choose the mirror from a specific Endpoint version, it gets updates only from update server appointed for that version. If you update V5 / 4 products, it might happen, you won´t get the updates. Also, it depends, if you have installed EEA / EES on the server (I assume EEA), so it might not download all of the files needed to update EES. Mirror from a specific Endpoint version is not able to get updates for ERA components, which we are going to release as of now (it will bring some new functionality, like import of lists into the policy editor, and support for new settings in Endpoints for Windows / Max + support for Domino / SharePoint. You won´t get it, if your agents are updating from Mirror. Also, if your company is using some proxy server as of now, you could not install the Apache HTTP proxy, but instead of that, configure ERA server / agents / endpoints, to communicate via your proxy server, and cache updates there. This way is far more effective from the perspective of data traffic, and once setup properly, it provides better user experience than the legacy mirror. We are working on documentation change, that will explain benefits of using Apache HTTP Proxy, over the standard mirror, respectively guide customers to use the proper scenario of their environment.

Yes, that will basically only contact our licensing servers, and ships you with the new format of the license, needed for V6 applications. Old username & password is still valid, as it is used also by V6 applications. What we have changed is, that the username & password is included in the license file, you silently receive upon activation and it is encrypted inside. So feel free to continue using both old and new apps. Only difference is, that you won´t see the old applications are activated from ESET License Administrator, as only new apps reports there.

Thank you for your inputs. Support for agent-less scanning was a demanded feature from the market, especially from the ease of deployment / ease of change point of use perspective. Once you have deployed entire VMware infrastructure and tweaked it properly, switching for another vendor was just a matter of minutes (you exchange one scanning appliance to another one). However, as you have correctly mentioned, it has certain drawbacks. The level of security is limited to the abilities of the API we are integrating with, which is the reason why ESET has chosen dual approach. You have the freedom of choice, whether you install our agents (Endpoints / EFSW) into the guest systems, and connect them with our Shared Local Cache, which prevents duplicate scanning on hosts, where there is a large duplication of files (usually all VMs share the same code). Our you can opt-in for the agent-less approach. VMware was solving the AV storms problem with vShield, not a strengthening of security problem.

New Endpoints are already signed with the new certificates, which is the change that caused the problem in this case.

In case you upgrade to the latest endpoint (5.0.2260) future upgrades will go smoothly. It should be possible to use PCU update, to force upgrade the clients. Is this way not acceptable for you? Here is the link to the KB article: hxxp://support.eset.com/kb3308/ This has nothing to do, with us forcing anyone to upgrade to ERA 6. It was caused by Microsoft, which dropped support for the certificates (old ones) used to sign our installation packages, so it was unable to download them using MS browsers (file was marked as dangerous). Also, those certificates will expire in a short period of time, so there was no other way for us, than to change them to the newer ones. We are sorry for any inconvenience.

Tank you mackintire for your inputs. What you have shared, is a very nice workaround taking into account the current state of things in ESET products. It really works as you have described (apply policy, remove "apply flag" to "unlock the settings", and let the users to change what they want ...). It requires more manual work, and supervision, to achieve the desired state (required rules are enforced, and user-defined rules are applied on top). This will be covered with the improvement/change I was talking about, as I got the impression, that that was the result the customer above was trying to achieve.

Those are not module based fixes, meaning that you have to do a upgrade. Please note, that due to different signatures, used for signing of previous and current build, upgrade task won´t work. You can however do the PCU, or initiate a new push deployment, which will install the new version over the older one.

You have to create a list of exclusions in ERA policy for our security product, and assign that policy to the group of machines. hxxp://help.eset.com/ees/6/en-US/index.html?idh_config_exclude.htm

There will be a summer release too, however this change is a more complex one, so it would take some time, unfortunatelly.

Once released to general public, you will get it automatically once server and agents are updated. Here is the internal release post (for the pre-release module). For the OSX product, it brings custom UI configuration settings, possibility to set dual update profiles and other changes, added to the new OSX build. Before the public release of OSX build, we will release the CE module for all users. NOTE: To ensure proper functionality of your ERA infrastructure it is highly recommended to perform CE module update on all components (ERA Server (change update type in server settings to "Pre-release update") and ERA Agent (change update type in ERA Agent policy to "Pre-release update")). New features: - Added: Support for new ESET Mail Security 6 for IBM Domino - Added: Support for new ESET Security 6 for Microsoft SharePoint Server - Added: Support for new settings in ESET Endpoint Security / Antivirus 6.2 for OS X - Added: Support for new settings in ESET Endpoint Security / Antivirus 6.4 for Windows - Added: Possibility to import from file to lists in ESET Remote Administrator policy editor - Improved: Other bug-fixes and improvements Known issues: - Policy/Configuration of ESLC product displays error (will be fixed by CE module release on regular update servers) - Some settings may be displayed as untranslated (will be fixed by new translator release) - Apply policy with new settings to old ERA 6.1 components can cause that policy will not be applied (workaround: update all ERA components to the newest available version (6.3) or replace component CE module manually) - Apply policy with new settings to old EES for Mac 6.0 products can cause that policy will not be applied (will be fixed in future CE for EES for Mac update, workaround: update EES for Mac to the newest version) - ERA Web Console requires logout and login after CE update on ERA server - Personal firewall Zones lists is not displayed in exported configuration (will be fixed by CE module release on regular update servers) - Import functionality is not functional when ERA Server is running on 64bit Linux OS including ERA virtual appliance (will be fixed in next release of ERA Server for Linux and ERA virtual appliance)

For the festures, some of them (like real time protection) could be disabled locally and it is (currently) possible to re-enable them only by forcing computer restart. We are tracking an improvement for adjusting this behavior, it shoul be fixed in the winter release of ERA 6 and Endpoints.

Just a note, that we will change this behavior and in case of remote install from ERA, we will push default config as in case of Endpoints. As Marcos has said, just configure livegrid switch with apply flag in your EFSW policy and the error will go away.

Just to give you a short heads-up. As of today, we have released the new Configuration Engine Module for ESET Remote Administrator, that brings support for the new settings needed to configure new options in the OS X build. OS X build testing continues, and based on the quick discussion with the head of OS X developers and my colleague from PM, it seems realistic, that the build will be released within the first two weeks of May.

Hello, that seems to be as a weird issue. I would recommend you to update the ERA to the newest version, as you are obviously not running ERA 6.3 (UI for handling client tasks was changed).