LesRMed 21 Posted October 2 Share Posted October 2 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 Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 2 Share Posted October 2 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 2 Author Share Posted October 2 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. Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 2 Share Posted October 2 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 2 Author Share Posted October 2 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? Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 2 Share Posted October 2 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 2 Author Share Posted October 2 Nope. Just old servers. LOL Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 2 Share Posted October 2 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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 Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 3 Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 Does the value HKEY_LOCAL_MACHINE\SOFTWARE\ESET\ESET Security\CurrentVersion\Info\AcsSupport exist and is set to 1? Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 Yes. Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 3 Share Posted October 3 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 3 Share Posted October 3 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
itman 1,629 Posted October 3 Share Posted October 3 (edited) 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 by itman Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
LesRMed 21 Posted October 3 Author Share Posted October 3 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! Quote Link to comment Share on other sites More sharing options...
Administrators Marcos 4,919 Posted October 3 Administrators Share Posted October 3 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.