6.6.2068 vanishes from the repositoy during upgrade

[e3z 3]

So frustrating. Thoroughly test a new release on willing participants, contact staff at multiple locations, begin pushing out an upgrade to 1000+ machines only for the version you are pushing out vanishes half way through the cycle. The exact same thing happened during the 6.6.2064 upgrade. Weeks worth of work down the drain with over half of the network still on 6.5.2107.1.

I completely understand that other users were experiencing issues with v6.6xx; however, no issues here. At this point it looks as though there has not been a stable version released at all in the 6.6 cycle. ESET, you guys are wearing me out.

End of rant

[Marcos 5,074]

We do not recommend re-using older software install tasks since the installers used in this task might have been already removed from the repository. It's a good practice to always create a new software install task if there's a bigger time gap between deployment.

Today we've released a new Endpoint 6.6.2072 which addresses an issue with upgrading to EP6.6 and a license selected in the Software install task. All previous versions 6.6 were removed from the repository. Please create a software install task from scratch which is a matter of a few seconds.

As of ESMC v7 (ERA), older software install tasks will be invalidated automatically and you will be able to enable notifications about this in ESMC as well.

ERA 6.5 already displays a notification that the referenced install package is not available if you hover the mouse cursor over the task:

[e3z 3]

Marcos you are a great support person. You have helped myself and so many others. I just wish you could look at this from an Enterprise level. Yes the sending a new package to an office is a simple matter which takes only a couple of minutes. Now think bigger. 

Each new package needs to be tested for at least a week on a few PCs here in IT. Then contact an office manager and convince everyone bring in any laptops that they use at home. Leave leave those laptops and desktops powered on and logged off with all applications closed and saved. Install & reboot overnight.  Deal with the users who did not listen and would like you fired because they did not save some Excel sheet. If there are no issues and no major problems reported here; repeat the process 41 more times.

After loosing access to the version that I have been working with twice now; I have little faith in v.6.6.2072. This is certainly not meant  as an insult to you. I just wish ESET could realize the time that goes into deploying these packages at an Enterprise level. I do not know many Network Engineers who push out untested upgrades to the entire network. This goes for Windows, ESET, Deslock etc. Removing these packages is an admission that they should not have been released in the first place. Trust in a security provider is not something to be taken lightly these days but I am beginning to wonder if our trust was misplaced.

[Marcos 5,074]

21 minutes ago, e3z said:

Each new package needs to be tested for at least a week on a few PCs here in IT. Then contact an office manager and convince everyone bring in any laptops that they use at home. Leave leave those laptops and desktops powered on and logged off with all applications closed and saved. Install & reboot overnight.  Deal with the users who did not listen and would like you fired because they did not save some Excel sheet. If there are no issues and no major problems reported here; repeat the process 41 more times.

If you need to be sure that an installation package will remain available in the repository for a longer time, use the previous major version, e.g. if Endpoint 6.6.xxxx is the latest and has been available for the public for a longer time, install the latest v6.5. In case that a serious problem is found in the latest major version which is what has happened recently, all affected installers have to be removed from the repository. Normally this should not happen and even in case that a severe issue was found, it should only concern the very latest or recent minor versions and only these would be removed from the repository.

If you look at the list of available 6.5 installers, we keep quite a lot of older versions in the repository:

If you want, we can provide you with EP6.6.2068 and you can install it from a local url. If the install task doesn't have a license selected, you'll avoid the issue that v6.6.2072 addresses.

[e3z 3]

smh...

[BenjaminMH 0]

I'm with you on this. Same thing happened to us. 

Spend time testing, begin rolling out, only to have the package disappear. Process starts over from scratch, and now we have machines on inconsistent versions. 

1 hour ago, e3z said:

Marcos you are a great support person. You have helped myself and so many others. I just wish you could look at this from an Enterprise level. Yes the sending a new package to an office is a simple matter which takes only a couple of minutes. Now think bigger. 

Each new package needs to be tested for at least a week on a few PCs here in IT. Then contact an office manager and convince everyone bring in any laptops that they use at home. Leave leave those laptops and desktops powered on and logged off with all applications closed and saved. Install & reboot overnight.  Deal with the users who did not listen and would like you fired because they did not save some Excel sheet. If there are no issues and no major problems reported here; repeat the process 41 more times.

After loosing access to the version that I have been working with twice now; I have little faith in v.6.6.2072. This is certainly not meant  as an insult to you. I just wish ESET could realize the time that goes into deploying these packages at an Enterprise level. I do not know many Network Engineers who push out untested upgrades to the entire network. This goes for Windows, ESET, Deslock etc. Removing these packages is an admission that they should not have been released in the first place. Trust in a security provider is not something to be taken lightly these days but I am beginning to wonder if our trust was misplaced.

 

[MichalJ 434]

@e3zI personally meet a lot of enterprise customers, during the customer research.

We are fully aware, that enterprises are having very rigorous processes, before they deploy security software company wide. However, this time we have identified a serious issue, that could result in the broken Endpoint after upgrade from previous versions. After attempting multiple ways how to mitigate the issue remotely, by deploying changes to ERA Agent behavior, and our licensing servers, we have decided, that we have to remove the affected package from the repository.  PS: The issue was happening only in case, that you have upgraded via ERA, and have chosen also a license, in the "software installation task". Unfortunately, many customers were doing this unnecessary step. 

We are however tracking various improvements, to address concerns you have mentioned:

1. Local version of repository, where you will be able to keep the versions, which might be no longer available online - meaning, if the build works for you, and you are confident, you can keep it and use it. 
2. Better "communication" from ESET towards the user of the ERA console about the "support status" of a particular build - meaning, if some serious issues happens, and version "vanishes" from the repository, you will be given a proper explanation. You will also know, when the version / product will EOL, or will be able to see any BETA / Early Access versions there as well. 

I can´t promise now a delivery date, but we really want to have both addressed towards the next (7.1+) release of ERA. 

You can be assured, that those are not the kind of issues that we do not take seriously. We are aware, that it´s very difficult to gain a trust of an enterprise-grade organization, however it´s very "easy" to loose it. We do not want to loose trust from you, our customers, so we are improving our processes and products to prevent such issues from happening. This individual case was done for "your protection", and the only thing we can do, is to apologize to you. 

If you want to affect future development of ESET products by the means of participating in a customer research with PM / UX people of ESET (it will cost you max 2 hours of time) juts let me know. We are really working to make solutions for our customers, so you can influence what you will get from us. 

Than you for your understanding.
Michal 

[brandobot 2]

It's issues like this that make me feel like ESET was not Enterprise Ready -- especially on the Mac side.

We've seen issues from machines mysteriously losing connection or being completely removed from the ERA, to auto-run tasks that just do not work, to tremendous slowdown issues with the Web Control feature on Macs. It's extremely tiring having to contact support, send countless number of logs and to hear no resolution for months.

[MichalJ 434]

@brandobot

Thank you for your feedback. Can you be more specific, in particular with the first two/three issues - machines losing connections and machine being removed from ERA without user interaction + automatic tasks that do not work.

I am aware of few tickets with sporadicaly crashing agents on mac, and that a fix is on the way. But the other two issue are unknown to me by your definition, so please provide more details (not logs, just description what is it about). 

Per my knowledge, Web filtering issues on mac were solved, and our mac product is among the best and highly rated on mac OS platform, trusted by some of the most famous companies in the world. 

[Marcos 5,074]

Quote

... tremendous slowdown issues with the Web Control feature on Macs. It's extremely tiring having to contact support, send countless number of logs and to hear no resolution for months.

If you had a support case opened, please provide me with the ticket ID so that I can inquire colleagues from ESET LLC about that. If it's really Web Control and not Web Access protection which slows down browsing, this usually happens if there's a problem with receiving response to DNS TXT queries and a simple tcpdump pcap log should confirm that. Changing the DNS to Google's 8.8.8.8 or 4.4.4.4 would likely resolve the issue. If you want discuss different issues that you have run into, please create a separate topic(s) in the appropriate product forum.

[brandobot 2]

@michalJ @marcos

I've opened a forum post here. It is case #103515 Machines missing from ESET Remote Administrator console"   --

Web control case is # 33848. This case stemmed back from early 2017, we worked on this for months with no resolution. Support came on-site and was able to replicate both onsite and on ESET provided machines; however, no resolution was ever found.

The machines missing and losing connection from the remote administrator is extremely urgent in our environment as we have no way of actively telling which machines are missing from the console. We've had to uninstall/reinstall the agent on all machines numerous times to ensure we're able to manage 100% of our Macs.

The automatic task that wasn't working was for removing stale machine entries. Support told me there was an issue with checking the "remove license" option. After unchecking the option, removing stale machines began working.

Edited February 23, 2018 by brandobot