Two admin environments, ERA and ELA

[Roger Nyman 0]

The setup with two adminstration environments, one being setup internally (and quite sufficent, I'd say, if one choose that option) - ERA, and the other being some unwanted bastard being mandated by ESET, - ELA, is both confusing and time consuming and beyond unjustifiable, especially since the two of them never show the same status, most notably perhaps regarding license usage and differences in terminology and handling. Given all the time & resources wasted on this ERA/ELA it's almost that I begin to suspect that this confusion, especially regarding licenses, is deliberate. And why is the two environments that practically do the same thing?

[Marcos 5,074]

ELA is going to be discontinued and will be replaced by EBA soon (ESET Business Account). We would like to hear from you as to what is confusing and what discrepancies you have found. If changes are made through either one, they normally take effect (sync) within seconds. If there are actual issues that we are not aware of, of course we will be glad to address them.

ELA/EBA provides management of licenses. In EBA you also define sites, users, distribute units, etc.  while in ERA you add an EBA account and use the license assigned to the particular user for activation of products.

 

[Roger Nyman 0]

Thanks for the response.

However, you didn't adress the question about two environments doing basically the same administrative thing (and why this is). Even with EBA replacing ELA there still be two, and I fail to see how the future ERA+EBA combo would change the adminstrative burden that this causes.
Afaik with an ERA server setup internally, such environment in practice is all that is needed for ESET administration.

Regarding ELA, one of the biggest and repeating hassles is the double/tripple/-n registrations of the same computer each with an allocation of a license. It's beyond me that this erroneous behaviour in ELA hasn't been solved since it has been around for such a long time! To your reply in another thread in this forum (topic/16254-two-admin-environments-era-and-ela) regarding the outcome of this issue (i.e. ELA's false claim of overuse of licenses); "We are working on a permanent resolving this by implementing a more sophisticated hardware detection logic, that should fix it for all" I just want to add; that *sophisticated hardware detection logic* should have been worked out BEFORE shipping to market. It would have save you, and us, the end users and your customers, both time, money and resources.

Edited July 31, 2018 by Roger Nyman

[MichalJ 434]

Primary reason for existence of two systems is that usage of ERA is not mandatory and we have quite a few customers that are using ERA-less environments.

So for those, we have created a license entity portal, that allows them to have license usage under control / visibility.

EBA is taking over + being also used as identity provider / authentication platform for upcoming cloud services. Idea is to have just one “account” via which customer will get access to trials, define license usage restrictions / access rights, and basically exchange “cryptic” license key for easily memorable e-mail based account. Current seat identification mechanism has its issues, we are actively working on resolving the issues, and improving the behavior.

Also, ELA usage is optional, you can simply add licenses to ERA and never login to ELA at all. Only shortcomming (and I do agree that it brings user discomfort / annoyance) is the multiplication and therfore communicated potential overusage of the license in case of cloned computers or computers frequently changing their network adapters.