FYI, We managed to find the reason and a possible solution for this issue which is described in detail in this GitHub Issue: https://github.com/ansible-collections/ansible.windows/issues/588
TLDR: Make sure to never enable Dynamic Code Security with AppLocker, even if AppLocker is just run in Audit only mode (which means it shouldn't block anything — it will block Ansible with DCS anyway…) Alexander Schomburg schrieb am Montag, 19. Februar 2024 um 14:28:49 UTC+1: > Another week passed and unfortunately all other Windows 11 PCs we set up > during the last week are now affected by the issue too. They've been > working on Thursday evening and the issue appeared on Monday morning (for > this client, Friday to Sunday are limited working days). Interestingly, we > have around 80 Windows 10 PCs setup previously with Ansible that are in the > same Windows Domain and that are applied the same Group Policies, none of > those Windows 10 PCs are impacted by the issue. But all Windows 11 PCs are > impacted. Pretty sure this has to be some recent Windows Update or strange > time-based internal Windows 11 policy that causes the problem. > > We also did some tests and tested connections with OpenSSH and NTLM > (instead of CredSSP) for the impacted PCs. The issue happens with all those > connection types — for any Ansible remote command (Gathering facts, > win_ping, chocolatey, ...) and any local/domain Windows user/admin > (obviously the path to the CS1504 reported source file changes for > different users). > > Can anybody help? > Alexander Schomburg schrieb am Mittwoch, 14. Februar 2024 um 22:06:54 > UTC+1: > >> Dear Ansible community, >> >> Initially, I wanted to reply to this old conversation: >> https://groups.google.com/g/ansible-project/c/UVyj6hxgDAA/m/W7VjjynPGwAJ >> >> As it has been closed for a few years, I can't directly answer to it. >> Back then, it was noted that one hadn't come across this issue before, and >> I couldn't find any other information about this online as well. >> >> We're just in the middle of setup and migration of about 70 Windows 11 >> PCs (23H2, x64, German) with Ansible Community Edition, Active Directory >> and Group Policies. The Ansible connection is made with WSMan & CredSSP. We >> managed to set up and migrate about 10 PCs in the first week and everything >> went smooth until Thursday last week (02/08/2024). Suddenly, all the PCs we >> set up with Ansible couldn't be managed by Ansible anymore — every >> task/playbook/ad-hoc connection with Ansible to the hosts failed with the >> mentioned error. >> >> Here is a “-vvv” output of the error (partly German) for one of the hosts: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> *The full traceback is:Failed to compile C# code:error CS1504: Die >> Quelldatei 'c:\Users\admin\AppData\Local\Temp\s3jrbyhw.0.cs' konnte nicht >> geöffnet werden ('Unbekannter Fehler ').In Zeile:369 Zeichen:13+ >> throw [InvalidOperationException]$msg+ >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : >> OperationStopped: (:) [], InvalidOperationException + >> FullyQualifiedErrorId : Failed to compile C# code:error CS1504: Die >> Quelldatei 'c:\Users\admin\AppData\Local\Temp\s3jrbyhw.0.cs' konnte nicht >> geöffnet werden ('Unbekannter Fehler ').ScriptStackTrace:bei >> Add-CSharpType, <Keine Datei>: Zeile 369bei <ScriptBlock>, <Keine Datei>: >> Zeile 19bei <ScriptBlock><End>, <Keine Datei>: Zeile 143bei <ScriptBlock>, >> <Keine Datei>: Zeile 11fatal: [WINDOWSPC]: FAILED! => { "changed": >> false, "msg": "internal error: failed to run exec_wrapper action >> module_powershell_wrapper: Failed to compile C# code: \r\nerror CS1504: Die >> Quelldatei 'c:\\Users\\admin\\AppData\\Local\\Temp\\s3jrbyhw.0.cs' konnte >> nicht geöffnet werden ('Unbekannter Fehler ')."}* >> >> Interestingly, we found that all PCs we set up since Monday this week >> (02/12/2024) are not affected by the error and continue working. All the >> PCs were set up and configured identically to the previous affected PCs and >> are of the same hardware batch, make and model. After a lot of digging, we >> found that PCs that were set up before that date and shutdown since then >> (for later installation) are not impacted by the issue for the first >> minutes after starting those PCs. Just after installation of the latest 3 >> Windows Updates on these PCs — even without rebooting — the issue starts. >> We also noticed that Windows Defender's (no other AV/EDR/… software is >> present on the PCs) CPU usage spikes for a few seconds if any Ansible >> connection attempt is made to those PCs (causing the error message). >> Unfortunately, no detections or blocks are reported by Windows Defender. >> Disabling all protections of Windows Defender or Windows Firewall doesn't >> help as well. AppLocker is not active / in use. The permissions to the TEMP >> directory are correct — even deleting the Windows user profile (and folder) >> and recreating it doesn't help. >> >> As a result, we are very positive that there has to be an issue with one >> of those three Windows Updates: >> >> - 2024-02 Cumulative Update for Windows 11 Version 23H2 for x64-based >> systems (KB5034765) >> - 2024-02 Cumulative Update for .NET Framework 3.5 and 4.8.1 for >> Windows 11, version 23H2 for x64 (KB5034467) >> - Windows Malicious Software Removal Tool x64 - v5.121 (KB890830) >> >> Unfortunately, removing all of these updates (the last one with “wusa >> /uninstall /kb:890830 /quiet /norestart”) didn't help. As a correlation >> with Windows Defender is to be expected, it's worth noting that all the >> older/affected Windows PCs had the previous version of Windows Malicious >> Software Removal Tool x64 v5.120 installed before — while the not affected >> / “newer” (technically identical) PCs never had v5.120 installed (fresh >> installation of Windows 11) and installed v5.121 directly. >> >> After lots of debugging and tests, we were unable to find a solution to >> the problem. Our current solution is to format the affected PCs and start >> again — which works and the issue doesn't appear anymore on those devices. >> Still, this isn't very satisfying, since we expect the issue to reappear >> with a later Windows Update again. >> >> Does anybody have any idea on how to further debug the issue or even fix >> it? >> >> Thanks in advance! >> >> Best >> >> Alexander Schomburg >> > -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/24ba4452-9386-4d4f-9898-9f9933b68ee4n%40googlegroups.com.
