Deployment rejected with "Unsupported Azure Stack HCI OS Version" on Portal-distributed 24H2 media, no environment change

IMPORTANT: Do not share any personal data in the bug report. This repository is a public forum and this report will also be public.

Bug description

A single-node Azure Local 24H2 deployment that completed successfully has been rejected by deploymentSettings validation on every attempt since, with no change to the node's installed OS. The error is:

Unsupported Azure Stack HCI OS Version. The version of Azure Stack HCI OS
currently installed on your system is not supported for new deployments.
Please download and install the latest version from the Microsoft Azure
portal. For more information please go to: https://aka.ms/AAvs1aj

The node was never reimaged between the successful deployment and the first failure. Four independent from-scratch rebuilds since — including one using an older installation media train than the one that originally succeeded — reproduce the identical error, which rules out anything specific to that one node's state. The Azure Portal's own "Download software" flow continues to serve the same media build that is now being rejected, so there is no way to self-serve past this from the Portal.

Repro steps

1. Deploy Azure Stack HCI OS 24H2 on a single node using media obtained through the Azure Portal's Azure Local "Download software" flow (build 26100.32230, package 12.2608.0.3020).
2. Complete AD/Arc prerequisites, form a single-node WSFC cluster, Arc-register the node.
3. Trigger deployment settings validation/deployment (Portal wizard, or az stack-hci-vm/ARM Microsoft.AzureStackHCI/clusters/deploymentSettings, or the equivalent Terraform azapi_resource).
4. On a first attempt with this exact media, validation can succeed after iterating through unrelated, fixable orchestration errors (hardware-check timing, CloudAgent reachability, storage pool sizing, Arc notification delivery — none reference OS version).
5. On any subsequent attempt — same node without reimaging, or a fresh from-scratch rebuild with the same or an older media train — validation fails immediately with the OS-version error above, with no further detail and no per-step breakdown.

Expected behavior

Deployment validation should succeed using currently Portal-distributed installation media, or at minimum should fail with an actionable message identifying which specific OS build is required. It should not reject the exact media the Portal itself still hands out through its official download flow.

Environment

• Build: 12.2608.0.3020 (OS build 26100.32230); identical failure also reproduced on the older 12.2607.0.3096 train
• One-node
• Non-production (lab)
• Region: reproduced in both Germany West Central and East US

Screenshots

None — evidence below is Activity Log/ARM error text pulled directly from the subscription rather than screenshots.

Correlation ID

Collected from the subscription's own Activity Log rather than the standalone log-collection tool. First and most recent confirmed occurrences of the exact error above:

• e775aa26-9c82-9db9-77c0-bfe53bb894eb (first occurrence)
• 7f142fba-db72-707b-1797-1392afec9095 (most recent confirmed occurrence)

10 occurrences of this identical error were logged between these two, across three independently renamed cluster resources — renaming had no effect, indicating the gate evaluates the node, not the cluster resource name.

Additional context

• The deployment that succeeded did so on the last of several attempts, ending with a successful deploymentSettings/write. The 9 failures leading up to it were all ordinary, resolvable orchestration issues (hardware-check step, an Arc operation timeout, insufficient storage pool capacity, CloudAgent unreachable, an Install-ArcHciMgmt exception, a stale prior-attempt cleanup issue, a failed Arc notification post) — none referenced OS version.
• From the very next validation attempt onward, the error changed to the flat OS-version message above and has not changed since, across a 2-day span and multiple rebuilds.
• Four independent from-scratch rebuilds were performed specifically to rule out an environment cause, all producing the identical error: (1) a fresh rebuild on the same media; (2) a rebuild correcting the host OS version and node memory to match the originally successful build exactly, with Secure Boot re-enabled post-install; (3) a rebuild on the older media train noted above. Also ruled out: Secure Boot state, vTPM, MAC address configuration, time-sync configuration, Key Vault RBAC propagation, the Arc Device Management extension, and a Terraform schema-version field that turned out to represent the request-payload schema, not the node OS version.
• The node's own Arc-reported osVersion had progressed to 10.0.26100.33158 via Windows Update at the time of testing, despite never being reimaged from the original 26100.32230 install — this appears to be ordinary patch drift, not a separate cause.
• Microsoft's own release-information documentation for the 2608 release train lists a newer package version (12.2608.1003.8) as current, while the Portal's download link — re-checked a day apart — continues to serve a signed URL for the older 12.2608.0.3020 build now being rejected. We have not found a way to obtain media the validation gate currently accepts.
• This is a free-tier subscription with no active support plan, so a formal support ticket could not be opened directly — filing here instead.

从 deploymentSettings 验证路径以及针对所报告关联 ID 的 Activity Log/ARM 错误入手；将 Portal 分发的构建版本 12.2608.0.3020 和 12.2607.0.3096 与列出 12.2608.1003.8 的发布信息进行比较。完成的标准是当前 Portal 媒体被接受，或者验证响应指出所需的 OS 构建版本并提供可执行的后续路径。