[vMode][Tool, Solution, or Feature Name] - Unable to add Host/Cluster as a resource after installing WAC

[Curious12No]

Gateway Version: 2.7.4.20
Extension Version 2606

To Reproduce
Steps to reproduce the behavior:

1. Go to 'resource group'
2. Click on 'Add Resource'
3. Input Server/Cluster name into Wizard
4. Prerequisite checks run and fail at OS subversion check, the OS version on my servers is later than the minimum required version specified. Version requested is Windows Server 2022 (OS Build 20348.4294). My servers are currently running on Windows Server 2022 (OS Build 20348.4773).

Expected behavior
Expecting the onboarding of my cluster to be simpler so that I can explore the capabilities of WAC vMode as we transition away from VMWare

Screenshots & Additional context

[HaraBria5]

I have had a look at how the add resource wizard gets the information its looking for and how it evaluates this. I have written up a short PowerShell script using similar logic that you can run on one of your nodes that connects to each node in your cluster and grabs some more information for you to hopefully find what node it may be complaining about. It would normally fail if one node for what ever reason does not have the March 2026 or above update which I assume you have checked. It would be useful if gave you back a proper assessment of why it cannot use those nodes

$nodes = Get-ClusterNode | ForEach-Object {
$reg = Invoke-Command -ComputerName $_.Name { Get-ItemProperty 'HKLM:\Software\Microsoft\Windows NT\CurrentVersion' } -ErrorAction SilentlyContinue
$sku = Invoke-Command -ComputerName $_.Name { (Get-CimInstance Win32_OperatingSystem).OperatingSystemSKU } -ErrorAction SilentlyContinue
$pass = ($sku -in 7,8,12,13,79,80,145 -and ([int]$reg.CurrentBuild -gt 20348 -or ([int]$reg.CurrentBuild -eq 20348 -and $reg.UBR -ge 4893)))
[PSCustomObject]@{ Node = $_.Name; State = $_.State; Build = $reg.CurrentBuild; UBR = $reg.UBR; Result = if ($pass) { "PASSED" } else { "FAIL" } }
}
$nodes | Format-Table

[Curious12No]

Many Thanks HaraBria5

So from what I see, all the nodes are on the compliant UBR version according to the check criteria (4294), but are below the 4893 version you have listed in your script. Is the version actually supposed to be 4893 and not 4294? Is the pre-check displaying an outdated version but actually checking against 4893?

[Sir-Jigston]

I ran into a very similar failure with Windows Admin Center Virtualization Mode 2.7.4.20 while adding an Azure Local / Azure Stack HCI cluster.

The error presented as:

PowerShell validation failed: One or more nodes in the cluster do not have a valid
server version. All nodes must be Windows Server 2022 (OS Build 20348.4294) or higher.

What I found

In my case, the OS build was not the actual problem.

The affected nodes were running build 26100.x, well above the Windows Server 2022 minimum.

The Add Resource workflow appears to validate both:

• OS build/revision
• OperatingSystemSKU

The relevant logic was effectively:

$SUPPORTED_SERVER_SKUS = @(7, 8, 12, 13, 79, 80, 145)

$status = (
    $osInformation.Sku -in $SUPPORTED_SERVER_SKUS -and
    (
        $osInformation.Build -gt 20348 -or
        (
            $osInformation.Build -eq 20348 -and
            $osInformation.Revision -ge 4893
        )
    )
)

Checking the nodes with:

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OperatingSystemSKU

showed:

OperatingSystemSKU : 406

So in this environment:

• Build validation passed
• SKU validation failed

SKU 406 was not present in the allow-list.

The UI still surfaced the failure as:

must be Windows Server 2022 (OS Build 20348.4294) or higher

which made the issue look like a build/version problem rather than an SKU validation problem.

---

Workaround I used

I was able to bypass the validation using a Chrome/Edge DevTools Local Override.

1. Enable Local Overrides

Open:

DevTools -> Sources -> Overrides

Choose a local folder for overrides and allow the browser access to it.

2. Locate the WAC JavaScript bundle

Find:

/assets/index-<hash>.js

In my case, searching the bundle for:

20348

located the embedded Get-NodeInfo validation logic.

3. Add the missing SKU

The supported SKU list originally contained:

@(7, 8, 12, 13, 79, 80, 145)

I added:

406

so the effective list became:

@(7, 8, 12, 13, 79, 80, 145, 406)

4. Save the override and reload

Then:

1. Save the overridden bundle.
2. Enable Disable cache in DevTools.
3. Perform a hard reload.
4. Retry Add Resource.

After adding SKU 406, the same nodes passed the server-version validation and the wizard continued.

---

Important caveats

This is only a workaround and not something I would treat as a supported production modification.

A few observations from testing:

• The override is browser-local.
• It does not modify the WAC gateway itself.
• It was only required during the Add Resource validation.
• Once the nodes were added, I could disable the override.
• WAC updates change the index-<hash>.js bundle, so the override would need to be recreated.
• Azure Local is not currently documented as a supported target for this Virtualization Mode onboarding flow.
• Other preview limitations still apply.

For example, the Storage workflow did not expose the native Azure Local / S2D hyperconverged storage profile in the build I tested, so I had to use:

Use existing storage already configured on the system

---

Suggested troubleshooting for this issue

For anyone seeing the same error despite running a valid Windows Server 2022+ build, I would check:

Get-CimInstance Win32_OperatingSystem |
    Select-Object Caption, Version, BuildNumber, OperatingSystemSKU

If the build is valid but OperatingSystemSKU is outside the validator's allow-list, the same underlying issue may be occurring.

It would also be useful if the validation error distinguished between:

• unsupported OS build
• unsupported OS SKU

Right now both appear to surface as the same Windows Server build/version error, which makes the root cause difficult to identify.

[HaraBria5]

I noticed that the build is showing as 4773 that matches what is returned on all of your nodes. I have now realised that this build seems to match the one released in Feb 2026 where the tool checks for 4893 which is the March update so it seems the error it gives you needs to be adjusted. The PowerShell script also did not make it clear what SKU you have and I did see references to other SKUs listed online for 2022 like 147 and 148 so what Jarod Roberts (@Sir-Jigston) mentioned above could also be a factor here