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