JimChev3

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!