John.From.VT

I see, so it's just downloaded and waiting. Thank you. Does linking a disabled auto update policy not mean they won't download at all? So I can better control when I'm ready to apply updates?

I have had two domain controller servers automatically update ESET server products and be waiting for a restart (according to the ESET Protect Console). While that Windows Server 2019/2022 server is pending a reboot the domain trust seems to be unavailable. A reboot of the server fixes the problem. One updated yesterday and one today. Not sure if this is coincidence or not but the server needing the ESET update, when rebooted, corrects the issue. I'm still researching and scouring event logs. How do I disable automatic updates? I created an auto updates policy with auto updates disabled. I had put it at the bottom of applied policies for all computers (applied last). Should I instead put it as #1, applied first, before the enabled auto updates policy that ESET created automatically?

So far so good running 10.1.2046. Unfortunately could not collect logs to send along. Time was of the essence to get people working again.

Hey @Jasonleigh no kidding. We've had July updates installed since July 14th and are just seeing this issue this week. HIPS is on. Very interesting. So far today we've been installing 10.1.2046 and seeing the issue being resolved. But tomorrow will tell if the issue continues...

Hi @Jens Holmkvist yes that's exactly what's happening, and so far uninstalling ESET has resolved the issue. I am still trying to get logs but even the ESET Log Collector is having trouble running. Interesting solution, on a PC I can test and dupe the issue with, Edge is currently on Version 115.0.1901.188 but the latest appears to be 117.0.2007.0. By running the update from ESET did you go to 10.1.2046 or are you talking about definition updates, etc?

Thanks @Marcos I will attempt to get some logs if possible when the issue is occurring and will report back.

Is anyone else having issues with PCs today simply dragging? W10 22H2 with the July Windows security updates installed 7/13/23. Trying to rule out a number of changes in our environment from the last week (BIOS updates, Dell Command Update installs, other automated application updates). We have some PCs with ESET email integration in Outlook, others without due to a prior issue which I feel has since been resolved. ESET is just another cog in the wheel so I'm reaching out to see if others are seeing similar issues today.

Things seem to be resolving now...

Is this issue still occurring today? Everything was ok this morning but now about half of our managed computers are reporting functionality problems stating "The ESET Push Notification Service servers cannot be reached"

Hi, thanks for the reply. I can't seem to edit the task name for new custom tasks either, I will probably bring this up when I submit a ticket for my scanning problems.

I can't seem to edit the task name on any new scheduled task created through ESMC 7.1. It's grayed out. Anyone else seen this? Below image is what I see when I click Add. This is a minor gripe, but the reason I've come across it is because I have unexpected repeat on-demand scans running daily and/or hourly even when no schedule like this is set through ESMC or the client itself.

An easy fix that worked for me is right-clicking the Detected Items folder that crashes Outlook and deleting it (then deleting the folder in Deleted Items as well). Not sure why a user or two had duplicates but this corrected it for them. Outlook 2016 MSI using cached Exchange mode and EES 7.2.2055

So I disabled idle-state scanning and decided to also exclude the C:\Windows.old directory from scanning. Doing this stopped the creation of multi-GB log files throughout the day. The only logs created from the scheduled scans or external device scans are much more reasonably sized.

Hmm. On the subject of logs, every idle-state scanning log is about a mile long and has issues in the C:\Windows.old directory (from the OS upgrade). I tried to export one of the logs to see how many lines of errors it has and the XML export ended up being 550MB. This is probably the issue. One line item from the log: C:\Windows.old\ProgramData\Microsoft\Windows\Containers\BaseImages\d8e0d7f1-c4b1-4fcd-a8cf-3900f85d9c2b\Files\Documents and Settings\All Users\Microsoft\Windows\Containers\BaseImages\19444ac6-99e9-4afc-84fc-efb454400ffb\BaseLayer\Files\ProgramData\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Application Data\Microsoft\Windows\Containers\BaseImages\19444ac6-99e9-4afc-84fc-efb454400ffb\BaseLayer\Files\Users\All Users\Application Data\Application Data\Microsoft\Windows\Containers\BaseImages\19444ac6-99e9-4afc-84fc-efb454400ffb\BaseLayer\Files\ProgramData\Application Data\Microsoft\Windows\Containers\BaseImages\19444ac6-99e9-4afc-84fc-efb454400ffb\BaseLayer\Files\ProgramData\Application Data\Microsoft\Windows\Containers\BaseImages\19444ac6-99e9-4afc-84fc-efb454400ffb\BaseLayer\Files\Windows\System32\LockScreenContent.dll - unable to open [4]

I will throw the couple of computers with the large log files into a new policy where idle state scanning is disabled, see what happens, and report back. Thanks for the idea!

Yes, is there some known issues with the idle-state scanner?

On Friday we test upgraded a few PCs from 1809 to 1903. These PCs have had EES 7.2.2055 installed for about 2 months. Since Friday, the .dat files in C:\ProgramData\ESET\ESET Security\Logs\eScan on only a couple have ballooned from being 2KB-2MB in size to anywhere from 2KB-77GB in size. There's been no changes to ESET policies and the same policy is in use on all machines using 1809 or 1903. From other forum postings regarding similar log issues - Real-time file system protection > Threatsense > Log all objects is OFF. It is also off under Malware scans > Threatsense > Log all objects. Tools > Log files > Minimum logging verbosity is informative and we are deleting logs automatically that are older than 90 days. Outside of trying a complete uninstall/reinstall, are there any other suggestions or thoughts?

I don't have a license for ESET mail security, so it is not being scanned on the server by ESET, but it is likely being scanned by numerous clients who all have access to the same mailboxes. The plugin does catch the occasional email that gets by our spam appliance, so I may keep it enabled for now and wait for the next version. Thanks Marcos. Any idea on when 7.0 may be released?

I have an Exchange 2013 server (Version 15.0 ‎Build 1365.1)‎ with a mixture of Office Professional Pro Plus 2010 and 2016 32-bit clients (updating all to 2016 later this year) running Windows 7 Professional or Ultimate. I am running ESET Endpoint Security 6.6.2064 and 6.6.2072.4 and am currently in the process of updating all to 2072. I am using the email client integration with ESET and Microsoft Outlook. I noticed in some client's Outlook that every message delivered to shared mailboxes that they have access to also shows up in their Sync Issues - Conflicts folder with the reason "You have made changes to another copy of this item. Click here to view the other copy or to replace it with this version. Click here to view the other copy..." Clicking to view the copy opens up the original email that is in the shared mailbox. I have found that on my computer disabling the ESET Outlook Add-in from within Outlook stops the influx of conflict messages. When I re-enable, the conflicts start up again. Has anyone else seen similar issues?

The logs have been running for a while to troubleshoot other problems, hence the size. I think at this point this is no longer a problem, since I have not received any more alerts about this widget since Monday afternoon.

Experiencing the same issue with crashing EGUI.exe's on almost all of our W7 PCs, as well. No workarounds, but ESET assured me since the services are still running, clients are protected. Not sure if they will receive policy changes I push out though? Looking forward to the service release, hoping it corrects this and the "File not found on server" email alerts I am getting regularly since the update. All of my clients that were installed last month by pushing out from the ERA are installed to \Program Files\ESET\ESET Endpoint Security. The few clients I manually uninstalled and reinstalled by creating a packager appear to be installing to \Program Files\ESET\ESET Security.

I want to have clients download all updates from my single ERA server/proxy server. In ERA under Admin > Server Settings > Advanced Settings, should I configure the HTTP proxy settings here, or just under the Tools > Proxy portion of my policies? Things are working (mostly) aside from EGUI.exe crashes on clients and emailed errors about "File not found on server" since updating from 6.5.2107.1 to 6.6.2046, which I have an open support case about. Just trying to figure things out for myself here.

I can provide ELC logs from a machine with the latest definitions (today it's 16179) that has been alerting "addthis_widget[1].js contains JS/TrojanDownloader.Pegel.BH Trojan" every day since Wednesday 9/27 through yesterday 10/2. They are 2.3GB, so if I can get a sharefile.com link provided from ESET I'll upload them.

@Marcos, anything revealing in the log? My inbox is swamped with error emails. I also haven't heard back from ESET regarding the support ticket I sent in on Tuesday.

I enabled the update engine logging and waited for a client to throw the error automatically. Attached is the updater.etl log.