LesRMed

Those are probably old log files that were renamed and retained when a new log is started. They wouldn't be locked, so they are accessible for scanning.

Try running he ESET uninstaller in safe mode. See this link: https://support.eset.com/en/kb2289-uninstall-eset-manually-using-the-eset-uninstaller-tool.

Tasks-->New Client Task. Shutdown computer is the command you're looking for and then check restart under Settings. When you create the trigger, you can choose a time for it to kick off.

Maybe try turning off Memory integrity under Core isolation in Settings. Just a guess though.

If you uninstall ESET, can you then install Adobe?

I don't believe this only for ESET. It is my understanding that all AV companies will have the same requirement as this is a Microsoft requirement.

Been there, done that. See

I updates several of my computers on Friday from the Computers screen by clicking the ones I was ready to update and then selecting Update installed ESET products. I assume it would be the same as from the dashboard like you're doing, but I saw no problems. All computers updated and restarted within a couple of minutes.

Will do.

Description: Active session doesn't timeout Detail: Numerous times I've had my session time out and return to the login screen while I was working. It just did it to me again, timing out literally two seconds after I clicked a checkbox to select a computer to push an update. Very frustrating! It appears there is a timeout, which is understandable, but not if I'm actively doing something.

No. It just resets the MBR.

Obviously, this is not the case, since the OS does not actually support ACS. If, according to Microsoft, KB5006728 has to be installed to have support for ACS, and the installation fails, then the OS does not support ACS. I'm sorry, but your developer is wrong. As @itman said, at system restart it might, but it doesn't after it's rolled back. And once the registry key is added, ESET thinks everything is good (which it's not). Your developers need to take a closer look at when that test is done or do a test at each boot.

Really? I just showed you that's not the case. It shows no ACS support prior to updating, but shows ACS support after the FAILED update. It looks to me that ESET is adding the key when it sees the update, before it's rolled back, resulting in a false entry.

The saga continues. Thank you @Marcos. The passwords should have been the same, but I just went ahead and uninstalled the existing installation (in safe mode) and reinstalled using the AIO installer. Everything installed fine. Went to the Protect console and it was showing the warning about missing ACS support. I checked the registry and found that the HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key does not exist. Knowing it wouldn't work, but just wanting to see when things changed, I installed KB5006728 again. After the install, but before restarting, I again verified that the ACSSupport registry key did not exist. I restarted the server, and on reboot I got the screen about applying updates, but then got Failure configuring updates (as expected) and reverting changes. After the reboot, the warning went away in the Protect console and the ACSSupport key now exists and is set to 1. So @Marcos, somebody's lying to you about how it checks for support. I give up.

It is right now. We have one server here and four at a client's site, one of which is a SBS2011 domain controller which is also running their Exchange server. For the cost and headaches of moving all of them to Azure, I'd rather wait until next year (after a big conversion we're working on that has to happen before the end of the year) to see about upgrading the OS on all of them. The conversion is eating up a lot of my time as it is and I'm basically a one man show.