MichalJ

I have checked with the development, and there is an update to this topic. We will issue the update of our configuration engine module, that will enable this functionality (multiple entries in the notification field allowed). This should happen in next 2 months.

As Apache HTTP Proxy is an external component, we do not have the report integrated in ESET Remote Administrator Web-console. We are evaluating options, if this can be done somehow, but no promises yet. More details about how to enable better logging for the Cache itself is listed here: https://forum.eset.com/topic/6751-era-6-not-pushing-updates-via-apache-http-proxy/?hl=apache.org#entry39576 Concerning your other point, about the reasons to stay with V5. We are constantly improving the user experience of V6 and are interested to hear any feedback, about what was working better for you, or what use-cases are problematic within the new product. Is there any particular thing, that you consider problematic, or any use-case that is absent in ERA 6, that was available in ERA 5? What was better in the V5 GUI compared to the V6 web-console?

As of now, this is not possible as there is integrated validation for e-mail address format in both Endpoint 6 & ERA 6 policy editor. Statement that it was working in Endpoint 5 is correct, but was never officially supported. We will however track the improvement, and would work on changing the behavior of e-mail notifications for ESET Endpoint Antivirus 6 in the future releases.

This happens, when you have multiple computers with the same name. Imagine that you have an "image.computer" name which you clone 5 times. So in ELA you will end up with: - image computer - image computer-1 - image computer-2 - image computer-3 - image computer-4 In the next release of ESET License Administrator, we will display not only the seat name (which is constructed from the computer name, but as it needs to be unique, it always appends that -x at the end), but also the full computer name as stored on the computer. You will be able to see the seat name also in Endpoint applications + you will be able to rename the seat-name to the one of your choice. This change will transfer backwards to the Endpoint installed.

We have 30% internal notebook workstations that don't have any access to internet, so they don't hit proxy at all. This is why we need mirror tool in LAN. In future we will be implementing network access control and will isolate clients to part of network with antivirus update server that won't have access to internet. Also having single point where updates are downloaded is really handy for troubleshooting. @bbahes => Basically, you want to distribute the updates from the ERA server (machine on which you have your ERA V6 installed), which will act as the mirror, which basically means, that ERA server will have access to the internet (will be able to download update). Is this assumption correct? Exactly for this reason, we have added the option to install the Apache HTTP Proxy, on the same machine as ERA server, to act as the updates cache. But it does not work only for updates (and installers), it also allows Endpoints to utilize ESET LiveGrid, our cloud-based reputation system, which drastically improves the security (as it significantly minimizes response time to new threats and thus improves the detection). LiveGrid does not work in case Endpoints does not have connection to the internet. If you will divert Endpoint communication inside your LAN via the proxy, it will cache the updates, and also allows LiveGrid requests to go through. The same is valid for the new licensing system, via proxy, it will be able to communicate to EDF, and utilize the "transparent license update functionality". I assume, that you are currently using offline license file for activation, which you will need to manually replace after the license renewal. Thank you for your feedback.

You need to check ESET License Administrator interface, how the machines are activated. If you rename the machine, it might happen, that it remains activated under the old name, as the machines are tight by the “hardware fingerprint. You need to check “unit management” section in ESET License Administrator, to review the number of activated machines, and if multiple entities are activated as the same seat (they share the same HW fingerprint). This could happen especially in case, that the same VM is cloned multiple times, or you have multiple machines on the same OS (Mac with OS X and Windows partitions). Please note, that Windows activated in Fusion, would most probably ends up with different HW fingerprint, as the logic is different. We are working on enhancing the HW fingerprint functionality, and we will shortly release a new version of ELA, that would allow renaming of the seats, which will transfer the new computer name to ELA interface, and would even enable changes of the seat name in ELA,, which would transfer back to the Endpoint (if version 6.3+ of Endpoint security is installed).

I have tried on both pages: hxxp://www.eset.com/us/support/download/business/remote-administrator-6/ hxxp://www.eset.com/int/download/business/detail/family/259/#offline,,,26,34, And it works just fine. You may try the direct download link which is: hxxp://download.eset.com/download/ra/v6/Appliances/era_appliance.ova

In general, you can now do both use-cases from ERA. You can "activate" the product, using product activation task. You can "deactivate" the product, by choosing the computer in era, and clicking "computers => deactivate products".

Server assisted installation requires manually executing the installer on a machine, and machine has to have visibility to ERA Server. You need to ship the webconsole credentials during this procedures, as this will basically create a new computer in the server, so you need to be authorized for such action. Possible workaround is to take advantage of certificates and dynamic groups. You create separate certificates for every branch office, and then create dynamic groups every one branch office (dynamic group template, with condition based on the used certificate). This won´t place the agent into the static group however, you will need to do it manually from time to time. But should help with the identification of machines. We are working on improving this process for the future versions of ERA 6.

As Marek stated, old HTTP Server was not optimal for large-scale deployments. Also, with the introduction of nano-updates, there is practically no reason to utilize mirror, for customer below 100 seats (size of nano updates for 100 computers is approximately the same, as size of one level update, which is downloaded by update mirror). Also, for customers that want to use the old mirror with integrated http server, they can do it, by enabling the functionality on any of the installed products (EEA / EES / EFSW), which is basically as simple, as setting a policy (which equals to configuring server settings for mirror). For customers that have their own web server (IIS for example), they can easily deploy the offline mirror tool, and execute it simply by running a task via ERA agent (instructions are provided in the ERA documentation). What is important to state, is that the primary replacement for the mirror is the apache http proxy (or actually any web proxy with caching enabled) which could now cache the update files and installers. We do understand, that migration from V5 to V6 is not an "in place upgrade" as it was in case of previous 4 versions. Mirror concept was simply replaced by the proxy, as after internal analysis this concept was showing as more suitable compared to the old fashioned mirror which was included in V5 & older versions of ERA. However, as we want to listen to your feedback, I would like to ask you, what are the main issues / reasons, why you would prefer using the old fashioned mirror in comparison to the proxy caching? What problems are you solving by using mirror, that proxy is not able to solve?

What we would need: create agent policy, with logging level set to "information" (at least) wait until the policy is applied (replication interval), ideally verify this by requested configuration attempt to launch software install task with the activation collect the agent trace logs from the affected machine provide a snapshot (screenshot) of tasks executions / history from the affected machine when collected, revert the agent policy back, to normal logging level, in order not to collect not necessary data We would like to investigate the issue deeply, in order to determine the root cause of the problem, why the activation when a part of software install task is failing. Thank you for your cooperation.

In this case, task failure is triggered by the activation part of it failing (it is simple computer logic = task could be either failed or OK). In this case, as the activation failed, it fails. There could be multiple reasons for activation failure: 1, you have chosen incorrect license (license was not issued for the product) 2, you computer does not have access to ESET licensing server (try to troubleshoot by trying to activate one client locally, on the affected machine, if possible). If this is the case, you need to check whether the target machine is able to access the ESET licensing servers. To check the addresses, please check the following KB article: hxxp://support.eset.com/kb332/ If your computer is completely without the internet access, you can activate using offline license file. You can generate offline license file using license administrator portal (ela.eset.com). However, this is recommended for usage only in the completely offline environments, as the license is not automatically updated in case of any change.

Are you familiar, that you actually need to execute two independent tasks, to have the Agent & Endpoint deployed / Installed? For agent, you need to use "Agent deployment task". As soon as agent is deployed, you need to execute "software installation task" which is located in admin/client tasks. In this task, you need to select the product / version / language to install & ship a valid license. Upon execution, ERA agent connects to ESET repository, downloads the installer and installs the product, with subsequent activation. If the task is failing, what is needed is checking the trace message in the task executions history (I am not aware, of what version you are using, if you are using the latest 6.3, then locate the installation task, click on "show failed", and there click on the latest execution attempts, and choose "history". Trace message should be located there.

As of now, you can see the full list of activated clients using ESET License Administrator on https://ela.eset.com You will need your license key & license administrator password (you should have received both upon your license purchase / conversion / renewal) in order to login to ELA. There go to the "unit management" tab, where you will see all clients. Regards, Michal

Hi Jim, For your future upgrade, we would like to recommend you to upgrade the ERA server & webconsole manually. As webconsole is quite large file, some customers have experienced time-outs upon downloading era.war file during the upgrade task. Concerning the webconsole, please follow the instructions (please first stop the tomcat service, and era server service, and rename the previous version of the console to something else "era2". hxxp://help.eset.com/era_install/62/en-US/index.html?component_installation_webconsole_windows.htm Then, for the ERA agents, I would use the components upgrade task. Michal

Yes, uninstallation requires reboot of the computer. So basically the process should be: - uninstall the Endpoint product in the wrong language (check the option "automatically reboot when needed") - wait for the computer to report back to ERA, and install Endpoint product again, in the correct language (restart won´t be required)

In ESET Remote Administrator 6 you need to follow the instructions: - Install ESET Mobile Device Connector and have it accessible from the external / mobile network - Add mobile devices (Add new - mobile device in "Computers" tab), which will open the "mobile device enrollment task" and you will need to specify names (under which the devices will be presented in ERA) and device identification number (IMEI / WIFI MAC for WIFI only devices). - If you have SMTP connection configured for your ERA server, you will be able to specify also e-mail addresses to which ERA will send the enrollment link, if you do not have that, you can display the enrollment link and send it other way (sms message for example). - This task will "whitelist" mobile devices on Mobile Device Connector (please make sure, that the you have your connection interval for MDC configured for the shortest time period possible), and after that, your users would be able to click the enrollment link and enroll their devices to ERA. If the application (ESET Endpoint Security for Android) is not installed, first click on the link will initiate Google Play download, if it is installed, it will start the enrollment process. - We recommend to create an activation task with corresponding license, placed on group "mobile devices/android" so devices which are connected to ERA, are automatically activated with the license of your choice Please note, that this process is valid for ESET Remote Administrator 6.3 (which will be released later today), as we have streamlined the process, and reduced the number of necessary steps. Later today, also the documentation for ERA 6.3 will be published (check help.eset.com for updates), where a specific section for "Mobile Device Management" was added. Hope that this helps, M.

Hello, First of all, I feel very sorry, that you feel that you are being forgotten about. All of us, at ESET Support & Product Management departments are carefully monitoring all feedback channels, monitoring the problems reported from the market and constantly prioritizing the work of development & other teams to make our products better. It´s however pretty difficult to anticipate the specific release dates for products, including the specific fixes to be included, as there are many external factors, that might influence the final date. So every date published on this forum, except official ESET Release Announcements, and every feature-related promise should be taken in a way, that it is possibly a subject of change. However, as we are pretty close now, we do anticipate to release ESET Remote Administrator 6.3 in the second half of January - to be more specific, on January 21, 2016 (however, actual release date might differ from country to country, but we will update the download links, download page contents and ERA repository to version 6.3 on this date, if everything works OK). Concerning the future plans, for the year 2016, we do plan to keep the release pace of two releases per year, one towards the end/beginning, and one towards the mid-year (summer & fall). However, detailed road-map is still a subject of negotiations (and therefore a change), despite the fact, that we are already working on the next version. We will work on improving the way we communicate the progress with you, our customers, as we really appreciate every feedback we receive, either positive, but also the negative one.

As of now, this is not possible, as ESLC appliance is "hardened appliance". We will add VMware tools to the default appliance image in the planned service release, which is scheduled for early Q1/2016.

I have to clarify the above posted information. Although the release date was originally anticipated to happen in December 2015 (first two weeks), as it was still an unconfirmed information, it was possibly a "subject of change". In this specific case, it was decided to postpone the release for January, 2016 (second half of January). Postponement is due to the feedback from the partner network, closing of the Christmas season, and other non-product related issues. We will still reach the "technical readiness" in December, however we would like to get well prepared for the launch, due to the extensive change-log for this release. Please stay tuned for more official info. Thank you for your understanding.

Hi Icp, you are not forced to use ESET Security products of 6th generation with ERA 6. You can deploy ESET Remote Administrator 6, and manage ESET Endpoint Security 5, and ESET File Security 4.5 from the new console (just install ERA agent next to them). However, those products are not including all of the newest security technologies as in the next generation. If you still insist on downgrading to ERA 5, as stated above, you can get "legacy license credentials" (username / password + legay license file (.lic)) from ESET License Administrator portal.

Hello Santoso. Sorry for our late reply. Your use-case is currently not supported by ESET licensing architecture. This requirement is however tracked for future generations of our products.

Hi Jim, Deactivation task is coming for ESET Remote Administrator 6.2 (so really soon). Concerning the second issue, there is a workaround / it was designed to work little bit different (as Marek stated above) => If you would have entered the license first to security admin account, and then to ESET Remote Administrator, you would not face the issue. As now, even though you have activated the license from ERA, it was activated using "license key", means that for security admin who is by design an entity with lower level of rights it is not possible to perform deactivation. It would be the same, as if you would have activated the clients locally, by shipping the license key instead of the account credentials. For now, I would recommend that you: Remove the licenses currently entered in ERA Enter the licenses again, by means of entering the security admin account Reactivate your seats again, using the same licenses, via a software activation task To deactivate (under current conditions), you unfortunately need to enter ELA as "license owner", meaning you need to log in using your license key & ELA password. Then you will be able to deactivate all units, however only with "per license granularity". For the future versions of ELA, we are preparing a change/improvement, so you will be able to grant "the same rights as in the case of owner" to the security admin account.