Peter Randziak

It's all working well for me now. (9.0.12013.0)

For what its worth, we tested the updated 9.0.12013 client on one of our AWS VMs, and it came back up successfully after a reboot.

I created a Modules Update task with the Clear Update Cache option set (see https://help.eset.com/protect_admin/90/en-US/client_tasks_virus_db_update.html) and ran it on the other affected clients.
It looks like they are now also updating to 9.0.2046.0 (only know for sure when they have restarted).

It's a known bug that cached metadata was not invalidated (e.g. after changing the product). It would resolve automatically soon after the cached metadata was re-generated automatically, however. Clearing update cache erases also the downloaded metadata which is subsequently downloaded from the repository.

A detection (Win32/Exploit.CVE-2022-30190.H) was added at 13:00 CEST, included in update 25402 which is currently being uploaded on update servers. The url with payload was blocked at about 13:10 CEST.

Hello @New_Style_xd,
the updates are being served from datacenters in Europe and USA and it might happen that the routes are overloaded temporarily.
Was it a one time issue or do you experience such slow download speeds on regular basis?
Peter

Hi and thank you for posting your question.
You are correct, there are some policies that may overlap. Office 365 protection cannot be completely disabled, so you are always partially dependent on the setup in the Office 365 admin panel.
In regards to knowing what policy is applied, think of it in two stages - Firstly, the O365 policy is applied and ECOS comes in after. For instance, if the O365 policy is set up to delete spam right away, ECOS will not even see this email and it can´t therefore even apply any policy and perform specified action. On the other hand, if O365 is set up to let everything pass through, then ECOS will apply policies to emails it receives. Because of Office 365´s design, ECOS acts as a second layer of defense.
I hope this answers your question
 

According to the developers excluding the TimeMachine volume always worked.
Please create a script set_exclude.sh with the following content and run it:
 
product="endpoint_mac" json=$(cat <<EOF { "id": 0, "method": "_CE.rpc_api.screen_values_set", "params": { "values": { "daemon.settings.excludes": {"enabled": 1, "files": [{"path": "/Volumes/com.apple.TimeMachine.apple*.*"}]} }, "major": -1, "product": "$product", "minor": -1, "product_name": "$product" } } EOF ) /Applications/ESET\ Endpoint\ Security.app/Contents/MacOS/esets_daemon --json-rpc="$json"  

here’s an interesting comment:
 
https://www.dell.com/community/Virus-Spyware/UEFI-infiltration-found-by-ESET/td-p/6191946
”CompuTrace is a commercial product that is embedded into firmware to help people recover stolen laptops.  Doing that requires it to exhibit some virus-like behavior, such as phoning home, and it can also be used to remotely wipe the system since some companies might want to do that if their laptops are stolen.  But before you can do any of that, you first have to activate your system's CompuTrace instance.  Dell includes the actual application in the firmware, but it doesn't do anything until it's activated.  If you haven't yet activated it, you also have the option of deactivating it, but if you do that you will NEVER be able to reactivate it.  And if you've already activated it, I believe it can never be fully deactivated.”
 
 

Hi Mauricio, you could try two things:
There is an option to report spam/malware/phishing in ECOS - it´s under HELP and Submit Sample where you would upload the email and it is sent off for review, so if the email turns out to be SPAM or phishing, it is centrally logged for all future occurrences.

The second option is that if you are also using ESET Endpoint Security on your devices, you can install one of the email client plugins which gives you the option to report SPAM straight from the client, which what I assume you had before. https://help.eset.com/ees/7/en-US/idh_outlook_toolbar.html?idh_config_mailplugins.html
 

 

A detection was added at about 13:00 CEST, ie. will be released with the next update 25364. However, the url with a payload was blocked at about 12:45 CEST so users have been protected since then. We're going to make a minor change shortly which would allow a file like this to be detected earlier, independently of the engine update.

Added in engine 25352, via streamed (pico) updates on May 30, 15:30 CEST.

Hello@ Peter,
Hello@Nightowl,
I agree with you.
Thank for your advice.
 

Hi Peter,
Thank you, it turned out to be related to blocked connection to eu01.agent.edr.eset.systems:8093 due to the unusual port. 
For anyone else experiencing similar issues, there is a log file which helped me to identify which connection is failing. The log file is named 'EIConnector-yyyy-mm-dd' and you can find it here: C:\ProgramData\ESET\Inspect Connector\Logs.
Best Regards,

Hello @Ufoto,
the domains and ports used by ESET Inspect Cloud are listed at https://help.eset.com/ei_cloud/en-US/?prerequisites.html 
Peter

I would ignore their advice and keep ESET running , I would just allow it with NordVPN
Shutting down security services is not an advice.

Hello guys,
I would recommend to check this forum topic https://forum.eset.com/topic/24859-management-protocol-reverse-proxy/ as it contains info, which might be interesting to improve the configuration of the setup...
Peter
 

We've already released an engine which addresses the issues related to processing mui files. Please check if the issue had been resolved and remove the mui extension from the list of extensions excluded from scanning, if applicable.

We've already released an engine which addresses the issues related to processing mui files. Please check if the issue had been resolved and remove the mui extension from the list of extensions excluded from scanning, if applicable.

Hello @BenoitR,
The uPCU is released with a throttling from the start, the Criterion is randomness 😉 
This release has a 20% throttling set, meaning every fifth request will be served to make the rollout curve smooth.
The ratio is expected to growth to full 100% in upcoming 7-14 days.
Manually requested updates will override the throttling.
Peter

Hello. In my case it was the FusionLogViewer that caused filling up the temp folder with thousands of files.
Run fuslogvw.exe from an elevated prompt and disable logging (or select the level you want)
Forgot to mention the solution here earlier, sorry about that.

Good afternoon Thomas, 
Automatic updates will be available tomorrow.

Kind Regards
Jozef Cheben, Product management

Thanks for reporting. It will be forwarded for further analysis, but it definitely seems to be wrong. I would expect it reports last recorded scan instead of latest as similar issue was present long time ago also in client details view.

It looks like 1440.2 has been released. This strange problem is solved. Does it work for everyone?

Thanks to the ESET Team, the problems were fixed and the GPU worked again, with the correction made.

Another GPU image back.