JimChev3

Sorry this is a late response, I didn't see the notification.
Prior to the fix from ESET, I wasn't even able to create the task because there was no server to select. After their fix, there was one item listed that I was able to select and create the task. I did NOT have to run the update though, as it wasn't showing any agents as being outdated.
That being said, as I think you already saw from another thread I just posted in, there is yet another loginConnectionStateNotConnected error stemming from a mysql odbc driver update that will come down in an OS update that will kill connectivity to the web console again.
As such, your advice to everyone on taking snapshots/backups before doing anything of consequence both in the terms of the upgrade itself and in maintaining the Rocky-based appliance moving forward after the upgrade would be HIGHLY recommended by me as well. It looks like the kinks are still being worked out.

This morning I did a routine update of ESMC at the Web Console. Now when I try to login I get the message:
Login failed: Connection has failed with state "loginConnectionStateNotConnected"
I also see
esmc systemd[1]: eraserver.service: Failed with result 'exit-code'. in /var/log/messages.
Packages updated are:
esmc systemd[1]: eraserver.service: Failed with result 'exit-code'. Extra Packages for Enterprise Linux 9 openh264 MySQL 8.0 Community Server MySQL Connectors Community MySQL Tools Community Rocky Linux 9 - BaseOS Rocky Linux 9 - AppStream Rocky Linux 9 - AppStream Rocky Linux 9 - CRB Rocky Linux 9 - Extras Webmin - noarch How can I fix this?

As of 4/16/24, there still appears to be no fix for this for the on-prem appliance. It still require a server to be selected, and the selection dialog is still empty. Any idea when we might see a fix (which I assume would be an updated appliance)? Can't really move to the Rocky-based appliance until it is. Server v11.0.215.0, Web Console v11.0.193.0.

As of 4/16/24, there still appears to be no fix for this for the on-prem appliance. It still require a server to be selected, and the selection dialog is still empty. Any idea when we might see a fix (which I assume would be an updated appliance)? Can't really move to the Rocky-based appliance until it is. Server v11.0.215.0, Web Console v11.0.193.0.

Any update on when this fix will be available for the on-prem VMWare appliance?
 

@Peter Randziak Is there any update for this? We are using Protect Cloud and this has been going on for at least 5 days. Should we be logging support tickets for this?
I'm also seeing no indication of this issue at https://status.eset.com/.

I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far.
As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality.
I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
 

I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far.
As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality.
I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
 

I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far.
As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality.
I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
 

I also experienced this issue first in December and only on Server 2019 systems (mix of virtual and physical servers) and again now in January, although it appears to have spread to 2016 servers as well. Server 2022 doesn't appear to be affected so far.
As with others, it's a timeout on ekrn during the reboot following application of the monthly updates. Either manually starting the "ESET Service" or a second reboot will re-enable functionality.
I would also add that I think it's rather disingenuous to simply point at Microsoft and wipe your hands of the issue. Even if it is something Microsoft did to cause it, at the very least, you should be working with them to figure out why and what can be done to resolve this, whether it's on their end or yours. All it takes is one moment of inattention on a customer's part and there's a public-facing server with no protection for who knows how long until the problem is noticed. I personally feel like if you have no intention of taking this matter up with them and getting it resolved, I'm going to soon be forced to find another vendor. This is too big an issue to just shrug your shoulders and live with indefinitely.
 

Sorry about the delay, but I had limited windows in which to test this on two of the three affected servers and just finished last night. To reiterate for clarity, no, I do not have ESET Inspect/EDR running in this environment. Only the Mgmt Agent and Server Security are on each system.
I did exclude the MUI extension in the real-time protection setup and attempted the upgrade from v8.0.12013.0 to v9.0.12012.0 again on all of them. This time they all succeeded. What I don't know, however, is if that was just a fluke or not. I had not attempted any of those updates again before excluding that extension to see if they failed again. So in short, I would say it's a qualified yes that it made a difference.
I still have a six servers to go. I've modified the bootmgr setup on the remote ones to enable F8 on boot in case there are any more problems so I don't have to have someone physically there to aid in recovery. If I do encounter any more problems (which at this point, would be with the MUI exclusion in place), I'll let you know in this thread. The rest of them will be done by this weekend.
 

Greetings! 
Listed as fixed in 7.3 "An on-demand scan launched from the ESMC console could shut down the computer even if this post-scan action was not selected" is exactly what started happening after I've upgraded Endpoint clients to 7.3. Never happened before. 
The process C:\Program Files\ESET\ESET Security\ekrn.exe (WKST-VRN-BKP01) has initiated the power off of computer WKST-VRN-BKP01 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned)
 Reason Code: 0x80000000
 Shutdown Type: power off
 Comment: Computer scan completed
That comes from scheduled scan policy (daily on-demand scan with post-scan action set to "no action"). All upgraded endpoint clients have been shutdown after this scan.
Fix it please!