Install Failing on 2008R2 Servers with ACS Support

[LesRMed 23]

I'm trying to update ESET Server Security on five 2008R2 servers, and they're all failing; it doesn't matter if I do a security product update task from the cloud or if I try to manually run it from the server. They all fail with: "SoftwareInstallation: Installation failed with Fatal error during installation. Error code 0x643 (0x643), The app that you are trying to run is not supported on this version of Windows. See https://go.eset.com/acs23, see software-install.log for more..." I have verified that KB4474419 and KB4490628 have been installed. Any help would be greatly appreciated.

software-install.log

[itman 1,659]

2 hours ago, LesRMed said:

I have verified that KB4474419 and KB4490628 have been installed. Any help would be greatly appreciated.

Per Microsoft: https://support.microsoft.com/en-us/topic/kb5022661-windows-support-for-the-azure-code-signing-program-4b505a31-fa1e-4ea6-85dd-6630229e8ef4 , KB5006728 must be installed on Win Server 2008 R2.

Also refer to this Eset article: https://support-eol.eset.com/en/trending_weol2023_10_2022.html .

Edited October 2, 2023 by itman

[LesRMed 23]

11 minutes ago, itman said:

KB5006728 most be installed on Win Server 2008 R2.

Well ! I installed that on all of them on Friday, but it's not showing up any of them now. I just did it again on one of them and it looks like when it's installing after the reboot, it fails and the changes are reverted. Back to the drawing board. Thanks @itman.

[itman 1,659]

Did you verify this Win root CA cert. is installed?

Quote

NOTE To correctly verify modules signed by Azure Code Signing, computers are required to have the "Microsoft Identity Verification Root Certificate Authority 2020" certificate authority (CA) installed. By default, root certificates are installed automatically if the computer is connected to the Internet. If the "automatic root certificates update" setting is disabled or the computer is offline, you must install this root certificate into the certificate store of "Local Computer" under "Trusted Root Certification Authorities". To download the certificate, see PKI Repository - Microsoft PKI Services.

 

Edited October 2, 2023 by itman

[LesRMed 23]

Well, after further research, it appears that KB5006728 can no longer be installed. The error message from the failed install shows that the failure is expected "If you are installing this update on a device that is running an edition that is not supported for ESU" and references KB4497181. So, unless you paid for ESU support AND installed KB5006728 prior to 1/10/23 (when ESU support ended for 2008R2), you're pretty much screwed.

The funny thing is, I'm no longer receiving the "Missing support for Azure code signing" warning in the console for any of these servers. @Marcos Any idea why?

[itman 1,659]

19 minutes ago, LesRMed said:

So, unless you paid for ESU support AND installed KB5006728 prior to 1/10/23 (when ESU support ended for 2008R2), you're pretty much screwed.

I assumed you had a LTSC license.

[LesRMed 23]

Nope. Just old servers. LOL

[itman 1,659]

3 hours ago, LesRMed said:

The funny thing is, I'm no longer receiving the "Missing support for Azure code signing" warning in the console for any of these servers

Pondering and then theorizing, it appears Windows installed KB5006728 and subsequently uninstalled it when it realized the device didn't have ESU support.

Eset upon recognizing KB5006728 was installed, deactivated the ACS warning and very possibly now believes all is well in regards to this issue. Appears Eset is cluelesss as to the subsequent uninstall of KB5006728 .

The "clear and present danger" is if Eset will attempt to update these servers assuming ACS support is installed and what might be the impact of this on the OS and the existing Eset installation.

Edited October 2, 2023 by itman

[Marcos 5,074]

1 hour ago, itman said:

Eset upon recognizing KB5006728 was installed, deactivated the ACS warning and very possibly now believes all is well in regards to this issue. Appears Eset is cluelesss as to the subsequent uninstall of KB5006728 .

This assumption is wrong. We do not check for installed Windows update but perform an actual test to determine if the OS has ACS support.

[LesRMed 23]

12 hours ago, Marcos said:

This assumption is wrong. We do not check for installed Windows update but perform an actual test to determine if the OS has ACS support.

If that's the case, why am I no longer receiving the warning in the console that says "Missing support for Azure code signing"? And if I'm reading the log correctly that I attached earlier, it's failing because it doesn't have ACS support.

[Marcos 5,074]

20 minutes ago, LesRMed said:

If that's the case, why am I no longer receiving the warning in the console that says "Missing support for Azure code signing"? And if I'm reading the log correctly that I attached earlier, it's failing because it doesn't have ACS support.

Either the OS supports ACS or the application status is disabled via a policy.

[LesRMed 23]

1 minute ago, Marcos said:

Either the OS supports ACS or the application status is disabled via a policy.

There is no policy that disables the notification. I had the warnings showing before I started all of this, and I still have two laptops that are showing the warnings (that I haven't tackled yet).

[itman 1,659]

You might want to check out this posting: https://forum.eset.com/topic/36845-eset-endpoint-products-compatibility-issue-with-azure-code-signing-acs-program/?do=findComment&comment=173276 . OP indicates ESET Server Security 9.0.12017 works w/o KB update.

[LesRMed 23]

Thanks. I did see that. That's the version they're all on now. But I don't think that's going to help after the end of the year.

[LesRMed 23]

16 hours ago, itman said:

Eset upon recognizing KB5006728 was installed, deactivated the ACS warning and very possibly now believes all is well in regards to this issue.

@Marcos I believe @itman may be on to something. I just did an update on a Windows 10 laptop that was on version 1909 (one of the two I mentioned earlier). It was showing the ACS support warning in the console. The update failed, but it is no longer showing the warning in the console.

[Marcos 5,074]

Does the value HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1?

[LesRMed 23]

Yes.

[Marcos 5,074]

It means that the ACS test passed and the ACS signature could be verified and is trusted. It is weird that the Windows update failed though.

[itman 1,659]

17 minutes ago, Marcos said:

It is weird that the Windows update failed though.

Was this certificate added: https://forum.eset.com/topic/38212-install-failing-on-2008r2-servers-with-acs-support/?do=findComment&comment=173230 ?

I assume Eset ACS signed binaries need that Win root CA cert.? 

Edited October 3, 2023 by itman

[itman 1,659]

Let's "take it from the top."

Quote

The /INTEGRITYCHECK linker option provides Windows kernel digital signature verification for user mode Portable Executables (PE) files. This linker option is required for anti-malware and anti-cheat scenarios to register components with the Windows Security Center.  

You must sign IntegrityCheck-linked user mode PEs using Azure Code Signing (ACS). The cross-signing program is deprecated and new signing certificates will not be issued. Windows will continue to trust the existing binaries signed by the cross-signing program.

First, we are talking about AV WSC initialization processing only as I see it.

Could this whole issue be simply resolved by installing the Microsoft Identity Verification Root Certificate Authority 2020 certificate?

Or, is what these KB patches do is modify existing INTEGRITYCHECK processing? Let's check that out;

Quote

By default, /INTEGRITYCHECK is off.

The /INTEGRITYCHECK linker option sets a flag, IMAGE_DLLCHARACTERISTICS_FORCE_INTEGRITY, in the PE header of the DLL file or executable file. This flag tells the memory manager to check for a digital signature in order to load the image in Windows. This option must be set for both 32-bit and 64-bit DLLs that certain Windows features load. It's recommended for all device drivers on Windows Vista, Windows Server 2008, and all later versions of Windows and Windows Server. Versions of Windows prior to Windows Vista ignore this flag. For more information, see Forced Integrity Signing of Portable Executable (PE) files.

Signing /INTEGRITYCHECK files

Microsoft has new signing guidance for DLL and executable files linked by using /INTEGRITYCHECK. The guidance used to recommend a cross-signed certificate from the cross-signing program. However, the cross-signing program is now deprecated. You must now sign your /INTEGRITYCHECK files by using the Microsoft Azure Code Signing program instead.

https://learn.microsoft.com/en-us/cpp/build/reference/integritycheck-require-signature-check?view=msvc-170&viewFallbackFrom=vs-2019

Based on the above, I don't see any changes in INTEGRITYCHECK processing other than the ACS signing requirement. So I assume these required KB's modified INTEGRITYCHECK to do this.

Putting it all together, Windows requires this INTEGRITYCHECK modification for AV's to register in WSC. Without the KB's being applied, Eset won't be able register in WSC. I assume this means Eset will run concurrently with Microsoft Defender. Is this really a problem?

Edited October 3, 2023 by itman

[LesRMed 23]

I thought I had checked the certificate, but apparently not, I didn't exist, so I installed it. Unfortunately, it made no difference, KB5006728 still fails, as does an update task.

[itman 1,659]

49 minutes ago, LesRMed said:

KB5006728 still fails,

As noted previously, this fails because Windows checks for ESU support. Without it, Windows won't allow the KB update to remain installed.

49 minutes ago, LesRMed said:

as does an update task

Eset must be checking for something other than if this reg key value exists; HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1. Of note is this reg key value does not exist on my Win 10 22H2 build.

Edited October 3, 2023 by itman

[Marcos 5,074]

6 minutes ago, itman said:

Eset must be checking for something other than if this reg key value exists; HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1. Of note is this reg key value does not exist on my Win 10 22H2 build.

That's expected because Windows 10 22H2 has ACS support by default so the ACS test does not need to be performed.

[LesRMed 23]

I guess I'll just leave them all on 9.0.12017.0 for now and see what happens. Too many other end-of-year projects to upgrade them right now. Thanks for your help and input @itman!

[Marcos 5,074]

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.