GregA

There are multiple posts about this issue. ESET says they are 'evaluating' changing how these end of life alerts are done. Just FYI, you need to be on ESET version 9.1 or newer to get rid of the alerts unless ESET does something on their end to get rid of the alerts. There is no way for ESET Protect admins to disable the end of life alerts per ESET.

Hopefully ESET can disable these annoying 'year in advance' warnings that went out to everyone. Disable or give us the ability to disable. 3 months in advance would make sense, but not a year.

Sure, I can do that. I was hoping it was a little more granular somewhere, but if that is all that is available, I will change that setting. Thanks!

Sorry, to clarify it is not an MS Outlook pop-up, it is the ESET pop-up in lower right by the clock, but the malware detection is in Outlook email.

CONFIG: ESET PROTECT (Server), Version 9.1 (9.1.1295.0), ESET PROTECT Server OS, Windows Server 2019, ESET PROTECT Client Device Windows 10 with Office 365 Outlook I manage the main security mail box for the company. Every time an infected email comes into that box I get the pop-up that ESET detected the malware and cleaned it. The pop-up stays on the screen for about a minute. I am getting a steady stream of these pop-ups throughout the day now which is very distracting. What exact policy setting can I disabled in the ESET Protect console to remove these detection pop-ups when ESET detects malware? I don't see a setting that is obvious. Thanks

On fresh ESET 8.1 endpoint installs to a new computer we see the AMSI integration error message. But after a reboot it appears to go away even if the advanced browser script setting is still left enabled in the server policy. That is what I am seeing so far anyway. So if you want to keep the setting, a reboot would appear to be needed after a fresh install. FYI, if it's of any help. The bug seems to be in the latest version of 8.1. I didn't see it in the previous version 8.1 we had installed. We just started seeing it with the new 8.1.2037.9 version.

We have about 1500 end points. Since we don't know which one/s will have the issue next, would it hurt to enable Diagnostic for all end points for a while and leave other settings as the default, or would it create super huge logs and cause an issue?

Windows 7 and Windows 10. ESET A/V version 7.3.2032, 7.3.x, ESET Agent version 7.2.1266.0 I am seeing various random users complain their ESET is out of date and they are then blocked from connecting to our Corp network VPN as it checks to ensure A/V is up to date. This is random. I don't know how long this has been an issue since we just started looking into it. Looking at the remote Workstation or Laptop ESET tools, log files, Events.. it shows the updates just stopped running at a certain date. No errors after that date and no tries as far as the log shows. What would cause the auto updates to randomly stop at the remote workstation client? Example attached where the log just stopped. The image was taken on 2/25/2021 and as you can see the event log stopped showing updates on 2/15/2021. Having user reboot computer seems to get auto updates running again on most of the ones that have been reported.

This is my Dynamic Group rule.

Update... The file C:\windows\system32\slmgr.vbs actually exists on the system that I was looking at. Even though it shows in the Quarantine on both the local ESET GUI, and in the ESMC.

Ok, I went to one of the computers and pulled up the ESET End Point Security GUI. Went to tools, quarantine, restore, enter the ESET GUI password, yes allow UAC, restore file from quarantine failed. File attempted to restore: C:\windows\system32\slmgr.vbs

What do you mean by manually restore? ESMC is not manual and that is the only method I have been trying because it is multiple computers. I go to ESMC, Quarantine, Find the all computers with the hash causing the issue, try restore, one computer at a time, or multiple computers, same issue as described above in my post. So no, it does not work. Task log... Task failed: CNodcommChannel: Send request failed with 14, Command failed - Make sure that Agent runs with Administrator privileges. This is a little concerning as an admin. If ESET can't restore a system file like this, what would happen if ESET nuked an even more important file that the systems need on a ton of computers (hundreds, thousands) and ESET can't restore the file to computers? Is there a problem with the agent on these computers? We currently have over 1,500 computers and ESET quarantined slmgr.vbs on only about 14 of those computers it looks like.

That is not the case however. Try restore this... file://C:\windows\system32\slmgr.vbs And get this.... Task failed: CNodcommChannel: Send request failed with 14, Command failed - Make sure that Agent runs with Administrator privileges. Am I in the wrong forum? Should I be posting this in Remote Management section instead since it's multiple computers?

How do you define fix? People are not able to restore these from quarantine. Will the restore work after the fix rolls out?

Same here, luckily only about 30 computers. But the files are fairly important, as they are used to add the Windows 7 extended ESU license each year. C:\windows\system32\slmgr.vbs C:\windows\sysWOW64\slmgr.vbs Task failed error: CNodcommChannel: Send request failed with 14, Command failed - Make sure that Agent runs with Administrator privileges.

Will there be any version of ESET endpoint available that will work on Windows XP after the end date for the older products?

This is one of the screens I very much dislike in ESET. It is poorly worded and honestly, doesn't make sense. Step #1 Why would ESET make this so difficult? Step #2 This step removes the agent, but only if the agent doesn't have a password (see step #1). Why doesn't it just say "uninstall Agent" (because that is what it does) in plain language? Who wrote this? Step #3 Remove Computer from database. Apparently putting a check mark also removes the license. But it doesn't say that is what it does. Who wrote this? If you do can figure how to do the above steps with the poorly worded descriptions it would remove the ESET agent but still leave the ESET A/V package installed on the removed computer. I would think most people would want to remove both. I would purpose a better way of removing a computer is to make two uninstall tasks that can be pushed to computers. One uninstall task for the agent and one uninstall task for the A/V package. The two different tasks allow you to use an uninstall password so you don't need to do step #1 above. Once you have the two tasks created, you run the uninstall ESET A/V task on the computer first. After that completes, you next run the uninstall ESET Agent task. Wait to see the computer no longer connects to the ESET server. Now you have completely removed ESET from the computer, not just the agent. Then you can remove the computer from the database using step #3 above. I would also strongly recommend using the the EBA portal the tech recommended. Without that you are running blind on your license use count since that is where ESET counts your license usage and you can remove old computers there or make an automatic rule to remove ESET licenses from computers that haven't talked in XX days.

I created a GPO or SCCM script when the agent version was still 7.1.717.0. This is the one we have been using. But it still seems to be installing 7.1.717.0 agent even though 7.2.1266.0 is the current agent version. To clarify, does the GPO or SCCM script remember the old version it was built with and keep installing the old version until you recreate the .bat file, or is it supposed to automatically know what the new version is when the new version comes out and install the new version?

Dynamic groups show computers as soon as a computer ESET agent talks on each machine, assuming your Dynamic template rule is working. So active talking computers will show as soon as they talk to the ESET server. Offline computers won't show in the dynamic group.

You can also sync your computers from AD with a static group Sync task.

This is why I was concerned about going with the Cloud Administrator from any of the A/V vendors when we were doing demos. They were all pushing for the cloud admin. We instead went with the on-prem ESET Administrator and it has been up and working while the cloud admin has been having issues.

Update: One of our techs was working on this over the weekend and he says that he found the old Kaspersky A/V agent (our previous A/V provider) was still installed and after uninstalling the old Kaspersky A/V agent the "ESET Management Agent is outdated" message went away. He did this fix on about 30 workstations.

I have the latest ESET SMC server version and I see the same issue suddenly happening over the weekend. On the main computers screen it says "ESET Management Agent is outdated" on some computers but if I drill down to one of those computers from the dashboard and view it's installed applications, the ESET agent version (7.2.1266.0) says it is "Up-to-date version". So it seems to be a bug since one part of ESET says the agent it is up to date and another says it is out of date. I am going to call support later today to have them sort it out.

I'm curious, what does the ESET agent version report as when you look at one of those computers (SMC, computer, show details, installed applications). I have a group of computers incorrectly showing on the main console computer list screen as "ESET Management Agent is outdated" but when I drill down to the installed applications for that computer, the correct 7.2.1266.0 is showing installed and says it is "Up-to-date version" installed. So something is wrong on my Security Management Center reporting, as it says agent out of date on one screen and agent up to date on the other. I will call support Monday if it persists. This happened after I rolled out version 7.3.2032.0 A/V update to most of our computers over the weekend.

How long did you wait? It takes about 10-30 minutes after an upgrade before the database is ready and it lets you log in. That is normal.