st3fan

We have not used the "Check for product update" task in all our branches yet, as we prefer to roll this out in stages. Yesterday I noticed that all branches had already received the Endpoint Antivirus version 10.1.2063.0 - so even branches where we never ran the new task. It seems the auto-update deployment started working again in the last few days. We have not made any changes to any policies. The only change we made was the upgrade to PROTECT 11.0.14.0. Very strange.

I am not sure unfortunately and Support did not spend any time on troubleshooting. It might be a bug. Or maybe this update has not been fully released yet. It just does not make sense to me that auto-updates work for the servers but not for the endpoints, and that a manual "check for product update" is required now.

Support suggested upgrading ESET PROTECT to version 11.0.14.0. And then we were able use the new "Check for product update" task (https://help.eset.com/protect_admin/11.0/en-US/check_for_product_update.html) in order to force the auto-update for Endpoint Antivirus.

We configured the PROTECT server as the proxy server for all endpoints. And all endpoints have direct connectivity to the ESET services too. Unfortunately it is still not working for us. Servers where Server Security is installed are configured the same way. And here we are receiving the uPCU version 10.0.12015.2, without having to do a manual check for updates. I will open a ticket.

And I noticed that this does not affect the uPCU 10.0.12015.2 for Server Security. No problem there. Our servers are receiving this update automatically. However, uPCU 10.1.2063.0 for Endpoint Antivirus is still a problem. None of our endpoints are receiving this update, unless we check manually. @Sec-C, are you still having this problem or does it work for you now? @Peter Randziak, is there anything else that we can try?

I checked again today but it is still not working unfortunately. Only a manual check for updates works in my case.

Hmm strange. It does not work for me yet. I just sent an "update modules" task to one of the endpoints (currently on 10.1.2058.0) but it has not downloaded the 10.1.2063.0 update yet. Auto-updates are allowed on all endpoints and I selected "Stop updates at 10.1.2063.0" in our auto-updates policy. I will try again later today.

Thanks a lot for clarifying this @Peter Randziak Out of interest, do you know when the throttling will be removed? Or is there a way to deploy the uPCU remotely, without having to do the manual check for updates?

@Marcos do you perhaps know more? Thank you.

Does anyone know when Endpoint Antivirus version 10.1.2063.0 will be available via the auto-update mechanism? We would like to upgrade to this version due to the reported vulnerability (CVE-2024-0353) but our endpoints are not receiving this update yet (auto-update policies are applied). The update is only downloaded if a manual "check for updates" is done but it is not automatically deployed via the auto-update option yet. Thanks, Stefan

We sometimes get the below warning. So far we noticed this on Endpoint Antivirus 10.1.2050.0 and 10.1.2058.0. It is an intermittent problem, so we can't reproduce this, and it seems to affect random devices... never the same ones. It always happens after a notebook is started and the message always clears after a reboot. All our notebooks are on Windows 10 22H2. This is a new phenomenon that only started recently (November/December). I can't really say much about v11 yet as we only have a handful of devices on that version. Is anyone else seeing this? What can be done to prevent this? Is there a way to fix this without having to reboot the endpoint? Thank you.

We had to uninstall ESET on all affected servers that were rebooted. I can confirm that this is definitely not related to the December Windows updates. In most cases we had to remove ESET using the uninstaller in safe mode as the ESET service could not be stopped/removed properly anymore. Before you reboot any other servers, make sure that you install a more recent ESET version. I doubt this problem is caused by this (which I believe is what Marcos meant). This should not affect existing installations according to the article.

Assuming the above article was the one that you were referring to @Marcos, I am not sure if this applies in our case but please correct me in case I misunderstood. What is described in this article should only impact new installations or upgrades (“Existing installations of ESET products will not be affected and will keep receiving module updates.”). In our case, only existing installations were affected. Our issues did not start after any upgrades etc. The issues started after a simple server reboot, without any other changes. Our Windows servers are up-to-date and they should support ACS (still checking). If this was not the case, I assume we would not be able to do a fresh install of version 10.0.12014.0 (includes an installation block if the OS does not support ACS).

Are you referring to this @Marcos? https://support-eol.eset.com/en/trending_weol2023_10_2022.html

A few more updates on this: I have prepared the auto-update for version 10.0.12014.0 for all 9.0.12013.0 servers that have not been rebooted yet. Afterwards I rebooted a few servers for testing purposes. All good. The 9.0.12013.0 servers that have been rebooted before the auto-update was prepared are broken. I had to remove ESET in Safe Mode and reinstall it. All other upgrade attempts were unsuccessful. So to summarise for any other ESET admin who might run into this: Do not reboot your Windows servers if you are still running ESET Server Security 9.0.12013.0. @Marcos, surely we can't be the only ones who still use ESET v9. I am curious what the plan is for all other customers who might run into this problem. And I am assuming there will be a lot of problems this week, when Windows servers are rebooted after Patch Tuesday.

But why would this cause problems with HIPS drivers, firewall services etc? For testing purposes I rebooted another server where 9.0.12013.0 is installed - and now we see the same issue there too. So this essentially means that ESET will break on all servers that are rebooted now, if 9.0.12013.0 is installed there? I am assuming this will affect other ESET customers too, i.e. anyone who uses 9.0.12013.0 or lower (and I am sure there are plenty)? FYI, upgrading ESET does not seem possible after the reboot anymore. All upgrade attempts fail, showing the error I mentioned above.

We are in the process of upgrading to 10.0.12014.0 but we still have a few servers that are on version 9.0.12013.0. Even though this is not the most recent version, 9.0.12013.0 is still supported if I am not mistaken (even 8.0.12015.1 is still in limited support afaik). Please correct me if I am wrong. I am unable to upgrade ESET on any of the affected servers. Auto-update fails. Software deployment task fails. And manually running the MSI file fails too. Event Log shows this: Product: ESET Server Security -- Error 1922. Service 'ESET Service' (ekrn) could not be deleted. Verify that you have sufficient privileges to remove system services. FYI, this problem only affects 15 servers. We still run 9.0.12013.0 on about 50 servers (same OS etc.) where we don't see any problems yet. I have opened a ticket with our local Support.

Hello, we noticed that real-time file system protection is non-functional on about 15 servers. This all started after the last reboot. The first server started reporting this on Friday after a reboot. We have rebooted all the affected servers but the error did not clear. The ESET Service (ekrn) is up and running. Detection Engine;28381;12/11/2023 Rapid Response module;23441;12/11/2023 Update module;1039;10/23/2023 Antivirus and antispyware scanner module;1605.2;11/15/2023 Advanced heuristics module;1227;10/30/2023 Archive support module;1345;11/27/2023 Cleaner module;1245.1;12/5/2023 Anti-Stealth support module;1187;8/28/2023 Firewall module;1439.2;11/15/2023 Translation support module;1990;11/10/2023 HIPS support module;1466;9/19/2023 Internet protection module;1457;9/4/2023 Database module;1124;9/12/2023 Configuration module;2099.6;11/23/2023 Direct Cloud communication module;1134;10/5/2023 Rootkit detection and cleaning module;1033;9/16/2022 Network protection module;1692;7/15/2022 Script scanner module;1170;11/8/2023 Cryptographic protocol support module;1082;11/6/2023 Advanced Machine Learning module;1146;11/22/2023 Security Center integration module;1038;7/28/2022 Is anyone else seeing this?

Thanks for your reply and the link. I have a few follow-up questions please: As mentioned in the article you shared, the PROTECT Apache HTTP Proxy component will be uninstalled during the upgrade. I am therefore assuming that we will immediately lose access to the WAN agents once we start the PROTECT upgrade, is this correct? Are you suggesting to create these new Bridge policies in advance (while we are still on PROTECT v9 and while the Apache Proxy is still running)? Can we apply these new Bridge policies to WAN agents that currently use Apache Proxy policies, before we start the PROTECT upgrade? How to test this best, just to make sure that the current proxy chaining config will still work once PROTECT has been upgraded? Just to summarise, we will have to consider 3 proxies here: PROTECT's Apache HTTP Proxy (will be uninstalled/upgraded during the v9-v10 upgrade) DMZ Apache HTTP Proxy (runs on a separate server... will have to be upgraded manually somehow) And 10 Apache HTTP Proxies that are set up in each remote office where we have limited Internet/Satellite access (each proxy runs on a dedicated server, which will also have to be upgraded manually somehow) My main concern is regarding the proxy chaining. I have read the article you shared but I am still not sure how to approach this without losing access to WAN agents.

Hi everyone I would like to upgrade our on-prem ESET PROTECT server from version 9.1.1295 to version 10.1.28.0. Once the upgrade is done, we will also have to migrate ESET PROTECT from the current Server 2012 R2 (soon to be end-of-life) to Server 2022, but first things first. We do make use of the Apache HTTP Proxy and since this is no longer supported once we migrate to 10.1.238.0, I am not sure how to approach this best. Our PROTECT server is not reachable from the Internet. WAN agents communicate via an Apache HTTP Proxy (located in our DMZ), which in turn forwards everything to the PROTECT server. We also have locations with very limited Internet access. Each of these locations make use of a local Apache HTTP Proxy, which in turn forwards everything to the DMZ HTTP Proxy (via the Internet / no VPN), which in turn forwards everything to the PROTECT server. If I run the v10 All-in-one installer in order to start the upgrade, it tells me that "Upgrading Apache HTTP Proxy will install ESET Bridge HTTPS Proxy. The deprecated Apache HTTP Proxy will be uninstalled", which sounds as if all agents and proxies that communicate via the DMZ Apache HTTP Proxy at the moment will lose connection to PROTECT afterwards. How could I approach this best, without interrupting communication too much? How can I e.g. migrate the current httpd.conf to the new ESET Bridge HTTPS Proxy? Thank you.

We are seeing this too, especially Outlook not keeping up with keystrokes. Not everyone is affected by this. Users with 1 shared mailbox seem to be fine. Users who use several shared mailboxes are complaining about slow performance and the keystroke issue. We had to install 9.0.2046.0 there.

@Marcos @Peter Randziak do you perhaps know if security updates are still going to be provided for PROTECT v9? Thank you.

Hi everyone We are still on on-prem PROTECT version 9.1.18.4. This version is still supported (limited support) for quite a while. I wanted to find out if security updates are still going to be released until limited support ends? For example, Apache Tomcat was updated in v10 due to discovered vulnerabilities. Will the same happen for v9? Thanks, Stefan

Has anyone tested 10.0.2045.0 yet and if so, what is your experience? Version 9.1.2060.0 seems to work for most of our users, as long as we configure the settings I mentioned further above. However, 10% of our users are still having problems regardless (they use Outlook 2016 and have a few shared mailboxes added). We had to go back to version 9.0.2046.0 as their Outlook kept freezing.

I also just tried this on a test server. I don't receive the update either if I run a manual "check for updates". Auto-update settings are enabled/enforced. What I also noticed and what I can't understand: If I enforce the auto-update policies on all endpoints in a certain branch, some notebooks receive the update on the same day. If they don't receive it, then I usually do a manual "check for updates". However, there are always a few devices were none of this works. They simply don't receive the update, even though the same policies apply. I ran into this issue two weeks ago. No matter what I did, the auto-update did not arrive. And then yesterday morning, all affected devices suddenly received the update (I noticed the device restart required/recommended notification on the management console). There were no policy changes on my side, so I am not sure what causes this.