LesRMed

I think there are 2 different categories of customer here.
1st category uses a proxy. (Some have proxy installed on Linux, and some have proxy installed on Windows Server.) 2nd category doesn't use a proxy.  We have ESET Endpoint Security installed on Windows 10 endpoints.  You have to read between the lines in the posts above to tell which customer is in which category.
I'm in the 2nd category, we don't use a proxy, and yet we get the same error message.  (Please go back to my original post to see my screenshots.)  So, our problem is not caused by a proxy.
It seems to me, just based on experience, this seems like a problem with startup order.  When the Windows 10 endpoint boots up, maybe ESET client attempts to contact the management system before the OS has all the networking services up and running.  If this wild guess is correct, it could be solved by changing the startup order, or trying again later long after bootup is complete.
I solved the problem for myself by switching the License Interval Check from Limited to Automatic.  So, if my wild guess is correct, the Limited setting only checks once early in Windows bootup.  So, I switched the setting to Automatic, and the error went away with repeated connection attempts.
I'm well aware this is a wild- guess, I could be completely wrong about the reasons.  But the end result - problem solved by switching to Automatic.

I for one am feed up with this constant Eset log upload issue due to their excessive size!
If Eset requires users to create diagnostic logs for them to be able to perform problem resolution, then it is Eset's obligation to provide a "nob" user method to do so from the existing Eset GUI interface. It should not involve user input as to what log options should be selected and the like.
Most important is the upload of these logs be performed automatically after logs have been created to appropriate Eset receiving servers. It is not the user responsibility to figure out how these logs should be uploaded to Eset.

Why would you want to do that? An admin maybe, but personally, I wouldn't want an end-user undoing it. To me, that's a huge security breach.

I hate when things are changed for the sake of change. I like that ESET maintains the same interface throughout multiple versions and yearly updates. Antivirus isn't like an ide that you maybe staring at for a while. It should sit in the background and rarely be interacted with. Last thing anyone should want to do is waste 10 minutes looking for a setting because the interface has been updated.

I will add to what marcos has put above  by adding over the years, new features have been introduced e.g. ransomware protection, network device monitoring and just with the new version 15, ransomware shield.
I have seen other AVs in the past change their UI each year and sometimes it felt like a way to hide there wasn't much new. While I always like to try new versions and see changes, changing the UI just because makes no sense. If it is for making things easier then fine but just to change the look could cause more issues. I'd much rather see Eset add more features over changing the interface 

ESET is a vendor of antivirus software and as such should have a consistent interface with only minor changes over the time to avoid confusion by users after upgrading to newer versions. Moreover, users should not keep the AV's gui open often, watching it for a long time so adding visual effects does not matter unlike in the case of operating system for instance which must attract home users.
Last but not least, I'd like to remind that this topic is intended for posting suggestions. It's not for lengthy discussions which would spoil it. If you have a comment or want to discuss something, please create a new topic.

There are various ways a departing employee could put your organization at risk of a data breach. How do you offboard employees the right way and ensure your data remains safe?
The post Employee offboarding: Why companies must close a crucial gap in their security strategy appeared first on WeLiveSecurity
View the full article

Thank you this is what I was looking for.  And exactly as you said - it made no difference.  However, now I can go back to CDK and tell them this did not work and they can keep looking for someone else to blame...

Maybe I'm being a little stupid but if malwarebytes can remove the full extension why can't eset?

US support strikes again! Totally useless!!

There is another topic with the same issue
We're experiencing the same issues since upgrade to 8.1. It's random as far as the users; some are remote users in another office or working from home, and some are here at our main office. Sometimes they resolve the issue on their own after a short period, some after a few days, but I have a couple of others that are still showing errors after about a week.

I'm split. I wouldn't mind if Eset introduced it but there's the debate if AVs should basically focus on being AVs and leave the other stuff to other users.

I hear you. The last 2 replies from the support tech by email was totally useless to my issue. They must be replying to another ticket and not mine. I just don't understand it.
I am getting more help from this forum than the actual tech support.

This was never resolved for us.  The recommendation to turn on advanced logging was of no use as the reboot cleared the problem on that computer.  Randomly happens every few days.   I chatted with ESET Support and no one can give me a resolution.  Very annoying.

I believe what the user is meaning is using the password manager as an authenticator. Found this for 1Password https://support.1password.com/one-time-passwords/
What this basically seems to suggest is with some password managers you can use the app to also show the 2FA codes, similar to the Google Authentication App. I myself use an app called Authy for this.
This is an interesting idea but not sure what i think as having your passwords and the authentication tokens in the same place could also be risky 

I will also add that running an Eset engine update which is over a 100 MB download at system boot time is not desirable activity at system boot time. This may very well be the source of this sporadic Eset update behavior issue. An engine update should be delayed to after Windows has fully initialized itself.

I will also add that this posting is out of scope for this forum. This forum is about Eset product questions and issues.

Gotta love the Good Deeds Service touch lol. 

This forum is not intended for disputing blocks or detections. Since the malware has been removed, the website was unblocked but the applications will continue to be detected.
Having said that, we'll draw this topic to a close.

Glad you got your site clean, if in fact you did as it is debatable. but, while I am not in way part of Eset, I don't see the PUA classification being removed, you literally advertise being able to hack other people's IG accounts which is actual malware by definition, and illegal in every country I'm aware of it's laws, so you should be happy with just being classified as a PUA. and call it a day.  Password stealing trojan seems more appropriate to my view. 

If the Eset update hang issue was related to this, it would have not resolved itself after a system reboot as I see it.

What I find funny is the people behind pegasus keep saying this person and this person etc. weren't being tracked by the software and the next thing they say they don't have access to customer data so can't see who/what their customers are spying on, which contradicts the previous statements 

It appears that everything has been said and continuing the topic makes no sense for other users either. Having said that, we'll draw it to a close.

My guess is that this is just included in case the user requires remote help, and it is just there to cover themselves i.e. it's made quicker by the fact the user has to already agree to it. I think they would still need to send the download, but it gets the legal stuff out the way ready. I could be wrong but I think this is probably most likely

Thanks for the clarification, but it would have been nice if the hot fix and feature update were released on the same day.  This way, those users who like to keep their devices up-to-date would have had the option to install v8.0.2039.0 or v8.1.2031.0.  I would have never updated our PCs to 8.0.2039.0 if I had known 8.1.2031.0 was going to come out a week later.