Forum Discussion

MattENZ's avatar
MattENZ
Copper Contributor
May 06, 2026

Two node Azure Local cluster updated to different versions

I'm not really sure how it's happened, but after trying to run an update against my Azure Local cluster, one of the two nodes has ended up at a higher version and now the update process is failing as it's detected that the nodes are at two different versions.

Node 1 is at 26100.32690

Node 2 is at 26100.32522

Retrying the update process is failing as it's obviously detecting that the two nodes are at different update versions. Is there a way to update the node that has fallen behind to the the same version as the other?

azure local

1 Reply

  • kyazaferr's avatar
    kyazaferr
    MCT
    May 08, 2026

    Yes — this can happen if one node successfully completed the cumulative update while the other node either:

    failed during orchestration,

    exited maintenance mode early,

    lost connectivity,

    or had the update staged but not committed.

     

    Your versions indicate:

     

    26100.32690 → updated node

    26100.32522 → older node still pending previous CU

     

    In Azure Local / Azure Stack HCI clusters, mixed patch levels are usually only tolerated temporarily during orchestrated updating. Once the process breaks, the cluster update service may refuse to continue because version consistency checks fail.

    The good news is that you normally do NOT need to downgrade the updated node.

    The usual approach is to manually bring the lagging node up to the same build.

    I would recommend:

    Pause and drain the older node:

    Suspend-ClusterNode -Name NODE2 -Drain

    Verify the currently installed updates:

    Get-HotFix

    Manually install the missing cumulative update (KB5082063) on the older node.

     

    You can:

    use Windows Update

    Microsoft Update Catalog

    or install the .msu manually

    Reboot the node completely.

    Verify the build now matches:

    winver

     

    or:

    Get-ComputerInfo | Select OsName,OsVersion,OsBuildNumber

    Resume the node:

    Resume-ClusterNode -Name NODE2

    Finally validate cluster health:

    Test-Cluster

    Get-ClusterNode

     

    Also check whether any update orchestration service is stuck:

     

    Get-Service *update*

    Get-Service *cluster*

     

    Microsoft-Windows-ClusterAwareUpdating

    Microsoft-Windows-WindowsUpdateClient

    FailoverClustering event logs

     

    One important note:

     

    Do NOT attempt to uninstall the newer CU from the updated node unless Microsoft specifically advises it. In most cases, bringing the older node forward is the supported recovery path.

     

    If the older node refuses the CU because of cluster validation/version checks, you may need to:

     

    temporarily evict the node,

    update it standalone,

    then rejoin it to the cluster.

     

    But usually manual CU installation on the lagging node resolves the mismatch.