Install Failing on 2008R2 Servers with ACS Support

[LesRMed 23]

9 minutes ago, Marcos said:

you should have no problems upgrading ESET to the very latest version now or after December.

But that's not the case. See the software-install.log file in my first post.

[Marcos 5,074]

Please provide logs collected with ESET Log Collector from the server.

[LesRMed 23]

@MarcosAttached are logs from two servers.

BAML_efsw_logs.zip MedAR_efsw_logs.zip

[itman 1,659]

17 hours ago, Marcos said:

If the AcsSupport registry value exists, the ACS test passed and you should have no problems upgrading ESET to the very latest version now or after December.

It appears Eset must be performing additional validations. Perhaps to verify that the applicable KB has been installed. Note that in @LesRMed installations, KB5006728 update was subsequently rolled back by Windows.

Edited October 4, 2023 by itman

[itman 1,659]

@LesRMed been pondering if there is a way "to fake out" Windows in regards to this KB5006728 rollback issue. Perhaps disable Win Updating prior its installation? Something is informing Windows that this KB can't be installed due to lack of ESU support. This implies some type of communication to Microsoft servers. It also might be a license status lookup.

My reasoning is it appears on Win Server 2008 R2 at least, current license status is not available from the Win installation itself. If it was, KB5006728 would not have been allowed to be installed in the first place.

[LesRMed 23]

In my research through all of this fiasco, it looks like ESU actually looks for a MAK to determine if the update is allowed. The MAK, of course, has to be purchased from Microsoft and can no longer be purchased. Thank you Microsoft.

[LesRMed 23]

@Marcos Were you able to determine anything with the logs I submitted?

[itman 1,659]

 

On 10/4/2023 at 10:30 AM, LesRMed said:

it looks like ESU actually looks for a MAK to determine if the update is allowed.

 

Quote

How you get ESUs depends on where your server is hosted. You can get access to ESUs through the following options.

• Non-Azure physical and virtual machines - If you can't connect using Azure Arc, use Extended Security Updates on non-Azure VMs, by using a Multiple Activation Key (MAK) and applying it to the relevant servers. This MAK key lets the Windows Update servers know that you can continue to receive security updates. See Access your Multiple Activation Key from the Microsoft 365 Admin Center to learn more. ¹

https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-deploy

Edited October 5, 2023 by itman

[LesRMed 23]

The only way you can get ESU on 2008 R2 now is to move the server to Azure, and that (ESU) is only good until January of next year. MAKs are no longer available for purchase.

[itman 1,659]

6 minutes ago, LesRMed said:

The only way you can get ESU on 2008 R2 now is to move the server to Azure

Is that that a big deal? The whole point is to get ACS installed on the device. After that, you don't need ESU anymore.

[LesRMed 23]

34 minutes ago, itman said:

Is that that a big deal?

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.

[Marcos 5,074]

You've used an All-in-one installer and the agent is failing with:

ERROR: (CheckAgentSetupPasswordWin) Password is incorrect.

Is agent actually password protected? If you use ESET Bridge, does clearing its cache help? (https://forum.eset.com/topic/37875-eset-management-agent-10112920-installation-upgrade-error/#comment-172673)

Does running an msi installer work?

Should the problem persist, please raise a support ticket for further investigation of the root cause.

[LesRMed 23]

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. 

[itman 1,659]

56 minutes ago, LesRMed said:

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.

The anomaly here is on Win 10, these KB updates won't even start installing. Therefore,  HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key never gets created. I attribute this to the age of Win Server 2008 R2 and that Win Updating was in a developing state then. Also and very much evident is Eset never tested that these Microsoft KB's actually worked on EOL and EOS OS versions.

56 minutes ago, LesRMed said:

I give up. 

Same here. I am "throwing in the towel" on the ACS support baloney since there is no way to implement it on EOL and EOS OS versions w/o ESU.

Edited October 6, 2023 by itman

[Marcos 5,074]

41 minutes ago, itman said:

Therefore,  HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key never gets created.

This value is created regardless of what updates are installed. It's created when an ACS test is successful and the signature is confirmed to be trusted.

[itman 1,659]

9 minutes ago, Marcos said:

This value is created regardless of what updates are installed. It's created when an ACS test is successful and the signature is confirmed to be trusted.

1 hour ago, LesRMed said:

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.

At system restart, ACS support did exist via KB5006728 previous install. However, due to lack of MAK license; i.e. ESU, KB5006728 install was rolled back resulting in the device without ACS support.

[LesRMed 23]

14 minutes ago, Marcos said:

This value is created regardless of what updates are installed. It's created when an ACS test is successful and the signature is confirmed to be trusted.

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.

[Marcos 5,074]

19 minutes ago, LesRMed said:

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.

We don't check for installed updates but perform a true ACS test instead. This information is from the developer who implemented the test routine that creates the said registry value.

[LesRMed 23]

4 minutes ago, Marcos said:

but perform a true ACS test instead

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.

[itman 1,659]

Belaboring to the nth degree on this subject, the problem is how Win Server 2008 performs Win updating.

Note that in Win 10, a cumulative update is actually installed after a system restart when Windows enters its isolated startup mode; i.e. blue screen with circle rotating mode. Such is not the case for Win Server 2008. It appears, the update is fully installed with only a system verification done as to its status after system restart.

What happened with the KB5006728 update was upon required system startup after installation, Eset verified that ACS was installed and set the HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key. Windows then completed the verification for the KB5006728 update by verifying if ESU existed since this update was only allowed in this status. Windows seeing that ESU was not in effect, then rolled back the KB5006728 update by uninstalling it. Eset did not recognize that KB5006728 was uninstalled removing ACS support. From this point on, Eset thinks ACS support is still installed because HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\ACSSupport key states it is.

This issue doesn't exist in Win 10 EOL/EOS  versions because Windows checks for ESU support prior to beginning the KB installation processing and terminates it at that point with appropriate lack of ESU support reason for installation failure.

Edited October 6, 2023 by itman