[windows] Don't fail Windows Update test if an update failed but later succeeded

[AtOMiCNebula]

Description

Bug fix

I've been trying to build the Windows Server 2025 image this month, and eight of nine attempts to build have failed due to Windows Update failures (the ninth was a fluke failure during VS installation). I kept the OS disk and debugged into it, and the issue was that the "Windows Malicious Software Removal Tool x64 - v5.130 (KB890830)" update was failing due to the machine being rebooted. It appears the install was starting around the time Install-PowerShellCore.ps1 was running. On a hunch, I tried updating the PS installer to set ENABLE_MU=0/USE_MU=0 but the failures didn't go away.

Broken Test Output (note duplicate entries for MSRT):

azure-arm.image: Describing Windows Updates
azure-arm.image:   [+] WindowsUpdateDone.txt should exist 5ms (2ms|3ms)
azure-arm.image:   [+] 2024-11 Cumulative Update for .NET Framework 3.5 and 4.8.1 for Microsoft server operating system version 24H2 for x64 (KB5045934) 57ms (56ms|1ms)
azure-arm.image:   [+] Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.421.1098.0) - Current Channel (Broad) 4ms (2ms|2ms)
azure-arm.image:   [+] Security Intelligence Update for Microsoft Defender Antivirus - KB2267602 (Version 1.421.1101.0) - Current Channel (Broad) 2ms (1ms|1ms)
azure-arm.image:   [+] Security Update for Microsoft OLE DB Driver for SQL Server (KB5040711) 2ms (1ms|1ms)
azure-arm.image:   [+] Update for Microsoft Defender Antivirus antimalware platform - KB4052623 (Version 4.18.24090.11) - Current Channel (Broad) 2ms (1ms|1ms)
azure-arm.image:   [-] Windows Malicious Software Removal Tool x64 - v5.130 (KB890830) 175ms (173ms|2ms)
azure-arm.image:    Expected collection 'Installed' to contain 'Failed', but it was not found.
azure-arm.image:    at $State | Should -BeIn $expect, C:\image\tests\WindowsFeatures.Tests.ps1:76
azure-arm.image:    at <ScriptBlock>, C:\image\tests\WindowsFeatures.Tests.ps1:76
azure-arm.image:   [+] Windows Malicious Software Removal Tool x64 - v5.130 (KB890830) 3ms (2ms|1ms)

To address this, I've updated the WU logic to ignore an earlier failure for a given update if it is followed by a successful attempt.

I don't know if there is a larger issue here...should WU be running in the background at this point? I only encountered this issue on the WS2025 image, and have also been building WS2022 and WS2019 a bunch without issue, so maybe something's still off with the new image?

Related issue:

I haven't created one, but can if you'd like me to.

Check list

• Related issue / work item is attached
• Tests are written (if applicable)
• Documentation is updated (if applicable)
• Changes are tested and related VM images are successfully generated

[AtOMiCNebula]

@bearycool11, I don't think your issue is at all related to mine. My change is unrelated to devcontainer or the software-report.

[shamil-mubarakshin]

Hey @AtOMiCNebula, thanks for contributing. We are aware of this issue and working on the same solution.
I am currently testing a simpler approach to skipping failed updates that succeeded later, but due to sporadic nature of this error I am rarely hitting it with some debug code so it takes time

[AtOMiCNebula]

Hey @shamil-mubarakshin, thanks for the follow-up. Unfortunately for me, I've been hitting this issue constantly. 😦 Happy for your team to land your own fix for this, but this worked well to unblock me in my private testing, and I felt it was pretty safe, so I wanted to offer it up as an option.

Some additional changes I made to build with (that might help you hit it more consistently) are using the Standard_D8ds_v5 SKU in East US 2, and also I bumped the image to the Gen2 equivalent (2025-Datacenter-g2). Not sure how far that'll get you, but I figured it can't hurt. 😄