+
+ | Name |
+ AzStackHci_SBEHealth_Test-Endpoint-Matches-ModelSKU |
+
+
+ | Display name |
+ Solution Builder Extension manifest matches hardware model and SKU ("Validate SBE manifest matches hardware model, sku") |
+
+
+ | Validator / test |
+ Test-Endpoint-Matches-ModelSKU (an SBE health check emitted during pre-update validation) |
+
+
+ | Component |
+ SBEHealth (Environment Validator / Environment Checker) |
+
+
+ | Severity |
+ Informational: this check reports whether the SBE manifest at your configured endpoint lists this server's model and SKU, but it does not block the update. A failure still means this hardware would not receive SBE updates from that endpoint and should be resolved. |
+
+
+ | Requirement |
+ When a custom (override) SBE update endpoint is configured, the Solution Builder Extension (SBE) manifest published at that endpoint must list this server's hardware model (and, where restricted, its SKU) among its supported models. |
+
+
+ | Applicable Scenarios |
+ Pre-update SBE health validation (update readiness). Only evaluated when the SBE endpoint is an override that differs from the default; a default endpoint skips this check. |
+
+
+ | Affected Versions |
+ Azure Local, version 23H2 and later. |
+
+
+
+## Quick fix
+
+If you just want the short version: this check failed because you have a **custom (override) SBE
+update endpoint** configured, and the SBE manifest at that endpoint does **not** list this server's
+hardware model (or its SKU). Either the override endpoint is wrong for this hardware, or the
+manifest there is missing this model. Confirm with your hardware partner (OEM) that the override
+endpoint is correct for this server, or **reset to the default endpoint** with
+`Set-OverrideUpdateConfiguration -ResetDefaultOemUpdateUri`, then re-run the pre-update health
+check. Full detail and how to verify the fix are below.
+
+## Overview
+
+A **Solution Builder Extension (SBE)** is the hardware partner (OEM) content that ships alongside
+the Azure Local solution. The SBE content is published at a **manifest endpoint**. By default that
+endpoint is a Microsoft-hosted `aka.ms` URL that redirects to your vendor's content; some
+environments instead configure a **custom (override) endpoint** (for example to serve SBE content
+from an internal location).
+
+The SBE manifest lists the hardware **models** (and optionally the **SKUs**) it supports. This
+check confirms that, when an override endpoint is in use, the manifest published there actually
+lists **this** server's model and SKU, so this hardware can receive SBE updates from that endpoint.
+The outcome is one of:
+
+- **SUCCESS (matched).** The manifest lists this server's model (and SKU). The detail reads *"The
+ current SBE discovery manifest endpoint ... has matching entries for the server model ... and
+ SKU ..."*.
+- **SUCCESS (skipped).** The SBE endpoint is the **default** (not an override). The check does not
+ compare model/SKU in that case, because Microsoft does not advise changing from the default, so
+ it is a benign skip.
+- **FAILURE.** An override endpoint is configured, but its manifest does **not** list this server's
+ model (or the model is present but the SKU is excluded). The detail reads *"System model '...' is
+ not supported by SBE. Supported models: ..."*, and the remediation is to confirm the override is
+ correct for this hardware or reset to the default.
+
+This check is **Informational**: a failure does **not** block the deployment or update. It is an
+early warning that this hardware would not get SBE updates from the configured endpoint, so it
+surfaces the mismatch now while it is easy to fix.
+
+## Before you start: who should do this, and is it safe?
+
+- **Who owns this.** This is a Solution Builder Extension / update-configuration task, owned by
+ whoever configured the custom SBE endpoint, together with the **hardware partner (OEM)** whose
+ manifest lists the supported models. It is **not** a generic Windows task and **not** a
+ networking task.
+- **This is safe to investigate read-only.** Reading the check result, the event log, the
+ configured endpoint, and this server's model/SKU changes nothing.
+- **It does not restart nodes or bounce running workloads.** This is a pre-update validation
+ signal, not a runtime operation. Reading the check, and either correcting the override endpoint or
+ resetting it to the default, do not restart cluster nodes or move running VMs.
+- **Reset to the default endpoint is a safe, supported action.** `Set-OverrideUpdateConfiguration
+ -ResetDefaultOemUpdateUri` returns SBE update discovery to the Microsoft-hosted default, which is
+ the configuration Microsoft recommends for most environments.
+
+## Where this failure appears
+
+You can see this failure in two places, the Azure portal and the node itself.
+
+### In the Azure portal
+
+When you run update readiness (or update validation) from the portal, the validation phase runs
+the Environment Checker and surfaces SBE health results on the cluster's **Updates** view. A failed
+`Test-Endpoint-Matches-ModelSKU` appears there under the SBE health checks with the "Validate SBE
+manifest matches hardware model, sku" title and the "not supported by SBE" detail.
+
+### On the node
+
+The Environment Checker writes each check result to the `AzStackHciEnvironmentChecker` event log as
+the JSON body of an **Event ID 17205** entry, and to the cluster-wide `HealthCheckResult.*.json` on
+the infrastructure share. Read this check's most recent result on a node with:
+
+```powershell
+Get-WinEvent -LogName AzStackHciEnvironmentChecker -FilterXPath '*[System[(EventID=17205)]]' -MaxEvents 2000 |
+ ForEach-Object { $_.Message | ConvertFrom-Json } |
+ Where-Object { $_.Name -like '*Test-Endpoint-Matches-ModelSKU*' } |
+ Select-Object -First 1 Name,
+ @{n='Status';e={$_.AdditionalData.Status}},
+ @{n='Detail';e={$_.AdditionalData.Detail}}
+```
+
+The `Name` on the node carries a domain prefix (`AzStackHci_SBEHealth_`) and can carry a node
+suffix, so the query uses `-like '*Test-Endpoint-Matches-ModelSKU*'` (leading and trailing wildcard)
+to match it. In this JSON the human-readable status and message live under `AdditionalData` (the
+top-level `Status` and `Severity` are numeric enums, and the top-level `Description` is a generic
+check description), which is why the query projects `AdditionalData.Status` and
+`AdditionalData.Detail`. When the model/SKU is not supported, `AdditionalData.Status` is `FAILURE`
+and `AdditionalData.Detail` reads *"System model '...' is not supported by SBE. Supported models:
+..."*, listing the models the manifest does support (so you can see whether this server's model is
+simply absent).
+
+## Troubleshooting Steps
+
+> **First, confirm you even have an override endpoint.** This check only fails when a **custom
+> (override)** SBE endpoint is configured; on the default Microsoft-hosted endpoint it skips and you
+> would never see this failure. If step 2 below shows you are on the default endpoint, this check is
+> not the issue and no model/SKU change is needed. Throughout, **SKU** means a hardware sub-variant /
+> configuration code that distinguishes builds of the same server model.
+
+### 1. Read this server's model and SKU
+
+The check compares the manifest against the values Azure Local reads for this server. Read the same
+values so you know what the manifest must list:
+
+```powershell
+[pscustomobject]@{
+ Model = (Get-ItemPropertyValue -Path 'HKLM:\HARDWARE\DESCRIPTION\System\BIOS' -Name 'SystemProductName')
+ SKU = (Get-ItemPropertyValue -Path 'HKLM:\HARDWARE\DESCRIPTION\System\BIOS' -Name 'SystemSKU')
+}
+```
+
+Note the exact model and SKU strings. The failure detail (`AdditionalData.Detail`, from the step in
+**Where this failure appears**) also lists the models the manifest currently supports, so compare
+that list against this model.
+
+**This is per server.** Model and SKU are read per node, so on a **mixed-hardware cluster** some
+nodes may match the manifest while others do not. Check each node's model and SKU against the
+manifest, not only the node that flagged, so you catch every affected server.
+
+### 2. Confirm the configured SBE endpoint (and whether it is an override)
+
+This check only fails when a **custom (override)** endpoint is configured, so confirm what the
+cluster is using:
+
+```powershell
+(Get-SolutionDiscoveryDiagnosticInfo).SbeManifestResult | Format-List ManifestSource, *
+```
+
+`ManifestSource` is the endpoint the manifest was read from. If it is the default Microsoft-hosted
+`aka.ms/AzureStackSBEUpdate/