Windows2022 - Install VS error - Component.Unreal.Android not found

[bmv0161]

Description

Have been stuck with the following error since last friday, 3/10. We use Packer build to create images for VMSS from the Windows2022.json template file.
Image creation fails at the install Visual Studio step. Pester tests fails as shown in the following:

vhd: Running tests from 'C:\image\Tests\VisualStudio.Tests.ps1'
...
    vhd:    [-] Component.Unreal.Android 473ms (470ms|3ms)
    vhd:     Expected 'Component.Unreal.Android' to be found in collection @('android', 'Component.Android.Emulator.MDD', 'Component.Android.NDK.R23C', 'Component.Android.SDK.MAUI', 'Component.CPython39.x64', 'Component.Dotfuscator', 'Component.HAXM.Private', 'Component.Linux.CMake', 'Component.Linux.RemoteFileExplorer', 'Component.MDD.Android', ...255 more), but it was not found.
    vhd:     at $installedComponents | Should -Contain $ComponentName, C:\image\Tests\VisualStudio.Tests.ps1:22
    vhd:     at <ScriptBlock>, C:\image\Tests\VisualStudio.Tests.ps1:22

Platforms affected

• Azure DevOps
• GitHub Actions

Runner images affected

• Ubuntu 18.04
• Ubuntu 20.04
• Ubuntu 22.04
• macOS 10.15
• macOS 11
• macOS 12
• Windows Server 2019
• Windows Server 2022

Image version and build link

Image version: 20230307.2

Do not have a public example, currently.

Expected behavior

Virtual Studio installation passes Pester tests successfully

Actual behavior

vhd: Tests Passed: 120, Failed: 1, Skipped: 1 NotRun: 0

Repro steps

Using Packer build with the following template file:
https://github.com/actions/runner-images/blob/win22/20230307.2/images/win/windows2022.json

Deployment through Azure DevOps self-hosted agent. Packer backend hosted in Azure.

[bmv0161]

After some further testing, when Packer is set to use a public IP, the build succeeds. When configured for a private IP, by passing vnet and subnet values to the build command, the build fails with the error above.
I have attempted to skip over the failing component, Component.Unreal.Android, which allows the Install-VS step to succeed. However, further installation steps such as vsix fail with similar errors.

Has anyone else encountered similar issues with private IP configurations?

[KendoChris]

We have similar setup, Azure and Packer. Getting exact same error, last working build for us was March 2nd.

[vpolikarpov-akvelon]

Hi, @bmv0161. I can't reproduce this issue in my environment unfortunately. Could you please share a list of the parameters you are running build with?

Also it would be helpful to see full building log, not just a test failure message.

[Riisko]

Experiencing the same issue. Having the VM on a private network, behind a FW and a proxy is causing a lot of issues with Android SDK, Bazel, Bazelisk and Haskell.

[vpolikarpov-akvelon]

Hey @Riisko. Could you describe your environment in more details and share build log so we can try to investigate it?

[KendoChris]

Having the exact same issue, building the image in Azure. Is there any update on a fix?

[vpolikarpov-akvelon]

Hi, @2E0MHQ. I can't reproduce this issue in my environment unfortunately. Could you please share a list of the parameters you are running build with and a full building log?

[bmv0161]

Hi @2E0MHQ @Riisko @vpolikarpov-akvelon, my team was able to resolve the image generation issues by updating our firewall rules.

We identified the the IDPS signature rules of 2027390 and 2033055 as the causes of the image generation failing for the install bazel and vsix steps. By updating them to alert only, the issue was resolved for those packages. Otherwise, we were able to set firewall rules to resolve the rest of the issues, such as the Component.Unreal.Android error I highlighted in the main post.

[Riisko]

Hi, can you please specify what I need to tell my 3rd party vendor to change in the firewall?

[bmv0161]

It could be different based on your firewall settings. You can have an allow any rule for the subnet where packer deploys to. Otherwise, you would have to set individual rules for the traffic that is being denied by the firewall. This is easy to spot with log analytics.
If you have IDPS enabled, then setting the signature rules I highlighted above to alert only should help.

[samus-aran]

We're locking this discussion because it has not had recent activity and/or other members have asked for more information to assist you but received no response. Thank you for helping us maintain a productive and tidy community for all our members.