Azure Local cluster: validation passes 100% but "Recommended updates" shows 0 eligible updates and Azure connection Unknown

Question

Azure Local cluster: validation passes 100% but "Recommended updates" shows 0 eligible updates and Azure connection Unknown

Uniting Country SA 0

2-node Azure Local (Azure Stack HCI) cluster, Dell AX-6515, currently on OS 23H2 (build 10.0.25398.2274), LCM controller v10.2510.0.1126.

Previously blocked from upgrading due to a Network ATC comp_mgmt intent failure (PhysicalAdapterNotFound), traced to a stale Hyper-V vSwitch left behind after a prior Remove-NetIntent that conflicted with adapter binding on recreation. Resolved by removing the stale vSwitch and running Set-NetIntentRetryState on each node individually (nodes drained beforehand, zero VM downtime).

Invoke-AzStackHciUpgradeValidation (module v10.2605.0.2006) now passes 25/25 (100%) on both nodes.

However, in the Azure Portal, Azure Local > Recommended updates shows:

Status / Update readiness / Current version: all blank
Azure connection: Unknown
"There is no update available to install on this system" - 0 eligible updates

Separately, Azure Update Manager > Machines shows pending Windows Updates against the individual Arc machine objects (not the cluster) - unclear if these are meant to be applied directly or if they're outside the validated Solution Update process for Azure Local.

Questions:

Why would Recommended updates show 0 eligible updates and Azure connection: Unknown despite validation passing and LCM indicating an update is available?
Is this a registration/Arc connectivity issue? (Note: the individual node's Arc machine page also shows an outdated Arc agent version banner.)
What's the correct path to trigger the actual solution upgrade in this state, given no Windows Admin Center gateway is deployed?
Should the pending updates in Azure Update Manager be applied to these nodes directly, or does that fall outside the supported Azure Local patching process?

Uniting Country SA 0 Reputation points

2026-07-23T06:16:40.4533333+00:00

Confirmed via Get-AzStackHciUpdate (direct ARM query, authenticated) that zero Update resources exist for this cluster — not a Portal display issue. Given LCM shows 10.2605.0.2006 staged locally and the SBE role package/cmdlets are present, this strongly suggests the update is gated on Dell's SBE validation/publication rather than any fault in our environment. Can you confirm whether Dell has published this SBE update yet, or is there something on our side still blocking it?
Adithya Prasad K 1,395 Reputation points Microsoft External Staff Moderator

2026-07-23T23:15:50.66+00:00
Hi Uniting,

Thank you for sharing the detailed validation results.

I understand that the Azure Local upgrade validation now completes successfully; however, the Azure portal continues to display Azure connection: Unknown, blank update status fields, and 0 eligible updates.

A successful validation confirms that the local cluster readiness checks have passed. However, update discovery and visibility in the Azure portal also depend on the Azure Local registration, Arc connectivity, Cloud Management components, and availability of the applicable solution/OEM update bundle.

To help us isolate the remaining issue, please run the following commands from an elevated PowerShell session on one of the cluster nodes and share the complete output:

Get-AzureStackHCI azcmagent show azcmagent check Get-SolutionUpdate | Format-Table ResourceId, Version, State -AutoSize Get-ClusterGroup | Format-Table Name, State, OwnerNode -AutoSize Get-ClusterGroup -Name "Cloud Management" | Get-ClusterResource | Format-Table Name, ResourceType, State, OwnerGroup -AutoSize

If Get-SolutionUpdate returns an update, please also run:

$Update = Get-SolutionUpdate | Sort-Object Version -Descending | Select-Object -First 1 $Update | Format-List ResourceId, Version, State, HealthCheckResult $Update.HealthCheckResult | Where-Object Status -ne "SUCCESS" | Format-List Title, Status, Severity, Description, Remediation

Regarding the pending Windows updates shown for the individual Arc-enabled machine resources, we recommend that you do not install them directly at this stage. Azure Local should normally be serviced through the coordinated Azure Local solution-update workflow. We first need to determine why the cluster-level solution update is not being displayed and confirm whether the applicable Dell solution bundle is available for the current platform and baseline.

Windows Admin Center is not mandatory for this process. Once the solution-update object is available and the preparation checks complete successfully, the update can be initiated through the Azure Local resource in Azure Update Manager or through the supported Azure Local PowerShell solution-update workflow.

Once you share the requested outputs, we can review the registration, connectivity, and solution-update state and advise on the next supported action.

Thank you for your cooperation and understanding.
Uniting Country SA 0 Reputation points

2026-07-23T23:33:57.99+00:00
Hi Adithya,

Thanks for the detailed checks. Full results below - everything comes back healthy, no issues found:

Get-AzureStackHCI: Registered, Connected, LastConnected today

azcmagent show: Agent Status Connected, all dependent services running

azcmagent check: all 7 core endpoints reachable, TLS 1.3, no proxy issues

Get-ClusterGroup: all cluster resources online/expected

Cloud Management role: Online, Azure Stack HCI Cluster Agent resource: Online

Get-SolutionUpdate: cmdlet doesn't exist on either node (not installed/available)

Since Get-SolutionUpdate isn't present locally, we authenticated Azure PowerShell (Connect-AzAccount) and queried ARM directly instead:

Get-AzStackHciUpdate -ClusterName "UCSA-CLU01" -ResourceGroupName "AZHCI_RG" -SubscriptionId "<sub>"

This ran clean (authenticated, no errors) and returned zero Update resources - confirming this isn't a Portal display issue, Azure genuinely has no update object registered for this cluster yet.

Given full connectivity/registration/Cloud Management health confirmed above, plus finding the Dell SBE role package (Microsoft.AzureStack.Role.SBE.10.2510.1001.2024) already staged locally, our working theory is this is gated on Dell's SBE package validation/publication rather than anything on our side. Can you confirm whether that's the case, or whether there's a next step to formally request/trigger that from our end?

Thanks for your help working through this.
Uniting Country SA 0 Reputation points

2026-07-24T01:02:52.0633333+00:00
Hi Adithya,

One more piece of information - a colleague pointed us to the Dell SBE package directly. It's confirmed published and compatible with our hardware:

Dell AX System for Azure Local SBE, version 4.2.2512.1514

Released 8 Jan 2026

Explicitly lists AX-6515 (our model) as compatible

Targets Azure Stack HCI OS 24H2 (build 26100.1742)

Source: https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=DTD2M

Given this has been published for over 6 months and matches our hardware, this rules out "Dell hasn't validated it yet" as the cause of the 0 eligible updates result.

Given full connectivity, registration, and Cloud Management health already confirmed (previous message), and the SBE package confirmed published - could you help us understand the actual mechanism by which a published Dell SBE package gets associated with our specific cluster's Update resource in Azure? Is there a manual import/registration/ordering step required on our side that we're missing, separate from the package simply being available on Dell's site?

3 answers

Your answer

Uniting Country SA 0 Reputation points

2026-07-23T06:16:40.4533333+00:00

Confirmed via Get-AzStackHciUpdate (direct ARM query, authenticated) that zero Update resources exist for this cluster — not a Portal display issue. Given LCM shows 10.2605.0.2006 staged locally and the SBE role package/cmdlets are present, this strongly suggests the update is gated on Dell's SBE validation/publication rather than any fault in our environment. Can you confirm whether Dell has published this SBE update yet, or is there something on our side still blocking it?
Uniting Country SA 0 Reputation points

2026-07-23T23:33:57.99+00:00

Hi Adithya,

Thanks for the detailed checks. Full results below - everything comes back healthy, no issues found:

Get-AzureStackHCI: Registered, Connected, LastConnected today

azcmagent show: Agent Status Connected, all dependent services running

azcmagent check: all 7 core endpoints reachable, TLS 1.3, no proxy issues

Get-ClusterGroup: all cluster resources online/expected

Cloud Management role: Online, Azure Stack HCI Cluster Agent resource: Online

Get-SolutionUpdate: cmdlet doesn't exist on either node (not installed/available)

Since Get-SolutionUpdate isn't present locally, we authenticated Azure PowerShell (Connect-AzAccount) and queried ARM directly instead:

Get-AzStackHciUpdate -ClusterName "UCSA-CLU01" -ResourceGroupName "AZHCI_RG" -SubscriptionId "<sub>"

This ran clean (authenticated, no errors) and returned zero Update resources - confirming this isn't a Portal display issue, Azure genuinely has no update object registered for this cluster yet.

Given full connectivity/registration/Cloud Management health confirmed above, plus finding the Dell SBE role package (Microsoft.AzureStack.Role.SBE.10.2510.1001.2024) already staged locally, our working theory is this is gated on Dell's SBE package validation/publication rather than anything on our side. Can you confirm whether that's the case, or whether there's a next step to formally request/trigger that from our end?

Thanks for your help working through this.
Uniting Country SA 0 Reputation points

2026-07-24T01:02:52.0633333+00:00

Hi Adithya,

One more piece of information - a colleague pointed us to the Dell SBE package directly. It's confirmed published and compatible with our hardware:

Dell AX System for Azure Local SBE, version 4.2.2512.1514

Released 8 Jan 2026

Explicitly lists AX-6515 (our model) as compatible

Targets Azure Stack HCI OS 24H2 (build 26100.1742)

Source: https://www.dell.com/support/home/en-au/drivers/driversdetails?driverid=DTD2M

Given this has been published for over 6 months and matches our hardware, this rules out "Dell hasn't validated it yet" as the cause of the 0 eligible updates result.

Given full connectivity, registration, and Cloud Management health already confirmed (previous message), and the SBE package confirmed published - could you help us understand the actual mechanism by which a published Dell SBE package gets associated with our specific cluster's Update resource in Azure? Is there a manual import/registration/ordering step required on our side that we're missing, separate from the package simply being available on Dell's site?

Answer 1

Hi Uniting,

Thanks for the additional detail. Based on what you’ve shared, the fact that Invoke-AzStackHciUpgradeValidation passes 25/25 confirms the local readiness checks are now clean, but it does not by itself guarantee that an update will appear in Azure Update Manager or under Azure Local > Recommended updates. Microsoft’s update flow also depends on Azure Local registration, Arc connectivity/cloud management components, and whether an applicable solution/OEM update bundle has been published and made available for that specific system. The Q&A thread also shows that your portal state is currently Azure connection: Unknown, with blank update fields and 0 eligible updates, while Get-AzStackHciUpdate returns zero update resources, so this does not look like only a portal rendering issue. [learn.microsoft.com]

For the update path, please use the supported Azure Local update entry points rather than applying updates only at the individual Arc machine level. Microsoft’s Azure Local documentation states that updates should be applied from the Azure Local resource page or from Azure Update Manager > Resources > Azure Local, and that non-Microsoft tools to install updates are not supported. Azure Update Manager is intended to manage Azure Local system updates and reports update status/readiness for each system, but the Azure Local-specific update experience is different from treating the nodes as standalone Arc-enabled servers. [learn.microsoft.com] [learn.microsoft.com]

On the OEM/SBE point: Solution Builder Extension updates are hardware-vendor packages that can include firmware, drivers, hardware monitoring, WDAC supplemental policies, and validation logic, and these SBE updates are integrated into the Azure Local solution update process. Microsoft documentation also notes that latest feature updates can take time to appear because of hardware partner validation and sign-off. Dell’s public release notes show a Dell 2606 SBE release for AX-650/AX-750/AX-6515/AX-7525, version 5.0.2606.1510, but those notes list HCI OS 24H2 and supported solution versions 12.*.1003.* / 12.2603.1002.*; that public listing confirms Dell has published a 2606 SBE package for AX-6515-class systems, but it does not by itself prove that your current 23H2 cluster is eligible to receive it through the Azure Local update resource. [learn.microsoft.com] [learn.microsoft.com] [dell.github.io]

Given your Get-AzStackHciUpdate result shows zero update resources, I would focus next on confirming Azure Local registration/Arc health and whether the update catalogue is surfacing an applicable update for this exact cluster/hardware/solution version combination. Please also check whether the cluster is in an AdditionalContentRequired state if an SBE-related update is discovered; Microsoft documents that this state can occur when an update package requires hardware vendor content before preparation or installation can proceed. [learn.microsoft.com]

Regarding the pending Windows Updates shown under Azure Update Manager > Machines for the individual Arc machine resources: I would not apply those directly as a substitute for the Azure Local solution update flow unless Microsoft support confirms they are appropriate for this cluster state. The supported path is the Azure Local resource or Azure Update Manager > Resources > Azure Local, because the solution update process orchestrates the full stack rather than only patching the OS on individual nodes. [learn.microsoft.com]

Suggested next checks:
Confirm Azure Local registration/resource state

Get-AzStackHci

Check Arc agent state on each node

azcmagent show

azcmagent check

Check discovered Azure Local solution updates

Get-SolutionUpdate

If using Az.StackHCI ARM queries

Get-AzStackHciUpdate

If those still show healthy local validation but no update resource in Azure, the remaining likely areas are: Azure/Arc connectivity and cloud management state, the update catalogue not publishing an applicable update for this exact installed version, or OEM/SBE eligibility/version gating for the current Dell AX-6515 cluster configuration. I would recommend opening/continuing a Microsoft support case with the output of the above commands plus the Dell SBE version currently installed/staged, because the backend update discovery state will need to be checked from Microsoft/OEM side.

Answer 2

Uniting Country SA 0

Confirmed via Get-AzStackHciUpdate (direct ARM query, authenticated) that zero Update resources exist for this cluster — not a Portal display issue. Given LCM shows 10.2605.0.2006 staged locally and the SBE role package/cmdlets are present, this strongly suggests the update is gated on Dell's SBE validation/publication rather than any fault in our environment. Can you confirm whether Dell has published this SBE update yet, or is there something on our side still blocking it?

0 comments

Answer 3

Follow-up: found Invoke-AzStackHciSBEHealthValidation and Test-SBEEndpointConnectivity

cmdlets exist in AzStackHci.EnvironmentChecker v10.2605.0.2006, suggesting our update

path may be gated by Solution Builder Extension (SBE) validation from our hardware

vendor (Dell). However, both cmdlets fail immediately with:

"Unable to find type [CloudEngine.Configurations.EceInterfaceParameters]"

This suggests they require the ECE/LCM engine execution context rather than being

callable standalone. Can you confirm:

Whether our update path is SBE-gated pending Dell validation
How to properly invoke SBE health validation given this dependency