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.

Commencez par le chemin de validation de deploymentSettings et l’erreur Activity Log/ARM pour les IDs de corrélation signalés ; comparez les builds distribués par Portal 12.2608.0.3020 et 12.2607.0.3096 avec les informations de version indiquant 12.2608.1003.8. La tâche est terminée lorsque le média actuel de Portal est accepté ou que la réponse de validation identifie le build OS requis et fournit une marche à suivre concrète.

Rédigé par le modèle d'indexation à partir du texte de l'issue.