Azure Local: Hardware Update Stopped Due to NIC Driver/Firmware Mismatch — Guidance Needed

Georgi Mihalev 5 Reputation points
2026-10-21T06:25:32.21+00:00

Problem description

I am experiencing an issue during a hardware update on my Azure Local cluster. The update was initiated via Azure Update Manager using an HPE OEM SBE package, and it completed successfully on the first node. However, on the second node, the update stopped with a message indicating a difference in network adapter driver and firmware versions. Since then, Azure Update Manager no longer allows the SBE update to continue. I am seeking guidance on how to proceed with the update without disrupting the cluster.

Environment

Azure Local cluster with six nodes, hardware update initiated through Azure Update Manager using an HPE OEM SBE package, with HPE as the hardware partner. Specific OS version, build number, solution version, and NIC details are these:

Node NicName InterfaceDescription DriverVersion InfName PS


AZVH-01 MGMT1 Mellanox ConnectX-6 Lx Adapter #2 26.4.27095.0 oem10.inf

AZVH-01 MGMT2 Mellanox ConnectX-6 Lx Adapter #4 26.4.27095.0 oem10.inf

AZVH-01 STOR1 Mellanox ConnectX-6 Lx Adapter 26.4.27095.0 oem10.inf

AZVH-01 STOR2 Mellanox ConnectX-6 Lx Adapter #3 26.4.27095.0 oem10.inf

AZVH-02 MGMT1 Mellanox ConnectX-6 Lx Adapter #2 24.10.26603.0 oem8.inf

AZVH-02 MGMT2 Mellanox ConnectX-6 Lx Adapter #3 24.10.26603.0 oem8.inf

AZVH-02 STOR1 Mellanox ConnectX-6 Lx Adapter #4 24.10.26603.0 oem8.inf

AZVH-02 STOR2 Mellanox ConnectX-6 Lx Adapter 24.10.26603.0 oem8.inf

AZVH-03 MGMT1 Mellanox ConnectX-6 Lx Adapter #2 24.10.26603.0 oem8.inf

AZVH-03 MGMT2 Mellanox ConnectX-6 Lx Adapter #3 24.10.26603.0 oem8.inf

AZVH-03 STOR1 Mellanox ConnectX-6 Lx Adapter 24.10.26603.0 oem8.inf

AZVH-03 STOR2 Mellanox ConnectX-6 Lx Adapter #4 24.10.26603.0 oem8.inf

AZVH-04 MGMT1 Mellanox ConnectX-6 Lx Adapter 24.10.26603.0 oem8.inf

AZVH-04 MGMT2 Mellanox ConnectX-6 Lx Adapter #2 24.10.26603.0 oem8.inf

AZVH-04 STOR1 Mellanox ConnectX-6 Lx Adapter #3 24.10.26603.0 oem8.inf

AZVH-04 STOR2 Mellanox ConnectX-6 Lx Adapter #4 24.10.26603.0 oem8.inf

AZVH-05 MGMT1 Mellanox ConnectX-6 Lx Adapter #3 24.10.26603.0 oem8.inf

AZVH-05 MGMT2 Mellanox ConnectX-6 Lx Adapter #2 24.10.26603.0 oem8.inf

AZVH-05 STOR1 Mellanox ConnectX-6 Lx Adapter 24.10.26603.0 oem8.inf

AZVH-05 STOR2 Mellanox ConnectX-6 Lx Adapter #4 24.10.26603.0 oem8.inf

AZVH-06 MGMT1 Mellanox ConnectX-6 Lx Adapter #2 24.10.26603.0 oem8.inf

AZVH-06 MGMT2 Mellanox ConnectX-6 Lx Adapter #3 24.10.26603.0 oem8.inf

AZVH-06 STOR1 Mellanox ConnectX-6 Lx Adapter #4 24.10.26603.0 oem8.inf

AZVH-06 STOR2 Mellanox ConnectX-6 Lx Adapter 24.10.26603.0 oem8.inf

Region: West Europe

The OS version: 10.2609.0.6

build number: 12.2609.0.3009

Current OSE version: SBE 5.0.2604.21

Failed OSE version: SBE 5.0.2608.10

What I've already tried

The only action taken was starting the HPE SBE update; it completed on the first node but stopped on the second node due to Bitlocker recovery key waiting to be entered. After typing the bitlocker recover key it continues but stopped due to driver/firmware mismatch. No additional troubleshooting steps or diagnostic outputs have been provided beyond this.

Current status

The update is currently blocked after the second node reported a NIC driver/firmware difference, and Azure Update Manager will not proceed. I am requesting a detailed action plan to align the NIC driver and firmware versions across all nodes to safely continue the update process.

Best, Georgi

Azure Local
0 comments No comments

1 answer

Sort by: Newest
  1. Alex Burlachenko 26,695 Reputation points MVP Volunteer Moderator
    2026-10-21T14:03:31.6133333+00:00

    Hi Georgi Mihalev & thx for join me at Q&A platform,

    version comparison is pretty revealing. AZVH-01 is already running Mellanox driver 26.4.27095.0, while AZVH-02 through AZVH-06 are still on 24.10.26603.0. That strongly suggests the HPE SBE update applied a newer NIC driver to the first node before the update workflow stopped.

    One important distinction, tho: a temporary driver version difference between nodes is expected during a rolling hardware update. The update orchestrator should manage that transition. The real question is whether the second node failed because its NIC firmware is incompatible with the driver being installed, or whether the earlier BitLocker recovery interruption left the update workflow in an inconsistent state.

    I wouldn't manually push driver 26.4.27095.0 to the remaining five nodes yet. On Azure Local, the HPE Solution Builder Extension manages a validated combination of drivers, firmware, and platform components. Updating individual NICs outside that process could introduce an unsupported configuration or disrupt the storage network.

    First, I'd check the cluster's health and the exact failed update step using PowerShell:

    Get-SolutionUpdateEnvironment |

    Format-List *
    

    Get-SolutionUpdate |

    Format-Table Version, State, HealthState, ResourceId
    

    Get-SolutionUpdate |

    Where-Object State -eq "InstallationFailed" |
    
    Get-SolutionUpdateRun |
    
    ForEach-Object Progress |
    
    ForEach-Object Steps
    

    Also compare the actual NIC firmware versions, not just the Windows driver versions. The table u provided shows the driver and INF package, but it doesn't establish whether the firmware differs between nodes. Use Get-NetAdapterHardwareInfo and the HPE-supported inventory tools to collect the NIC model, hardware revision, firmware, and driver information for all six nodes.

    I'd then ask HPE to confirm the validated ConnectX-6 Lx driver/firmware combination for SBE 5.0.2608.10, including whether that package supports ur exact server and NIC hardware revisions. Also verify whether HPE has published any update-specific advisories or prerequisites for moving from 5.0.2604.21.

    Before attempting recovery, make sure the cluster is healthy, storage is synchronized, and all six nodes are online. Check that the interrupted BitLocker recovery hasn't left AZVH-02 in an unexpected state, and confirm the appropriate recovery keys are available before any further reboot.

    Once HPE confirms the firmware/driver combination and any required remediation is complete, the preferred approach is to resume the existing SBE update through the Azure Local lifecycle manager, not install NIC packages manually. For a failed update, the supported PowerShell recovery command is:

    Get-SolutionUpdate -Id "<SBE-update-ResourceId>" |

    Start-SolutionUpdate
    

    Use the actual ResourceId returned by Get-SolutionUpdate. Don't use -IgnoreWarnings to bypass a driver or firmware compatibility failure, and don't launch another independent update while this one is unresolved.

    If Azure Update Manager still refuses to resume, I'd open a joint case with HPE and Microsoft Azure Local support. HPE should validate the OEM SBE payload and NIC firmware requirements, while Microsoft can investigate the failed orchestration state. Include the update run ID, failure details, cluster health results, and the BitLocker recovery interruption timeline.

    One thing I'd really like to see is the exact driver/firmware mismatch error from the failed AZVH-02 update step. Does it identify a particular NIC and required firmware version, or does it simply report inconsistent versions across the cluster? Those are quite different failure scenarios, and the safest recovery path depends on which one you're dealing with.

    rgds,

    Alex

    p.s. if my answer is help - pls mark it as an answer

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.