Azure Local 12.2610.1004.50 stuck at 85% – Automatic CAU retries and repeated production node drains

Lerch Alfred (IAS Admin) 0 Reputation points
2026-11-08T13:38:39.3466667+00:00

Hello Azure Local Community,

We are experiencing a serious update orchestration issue on our production Azure Local cluster.

Environment:

  • 3-node Dell Azure Local cluster

Current installed version: 12.2609.1003.7

Target update: 12.2610.1004.50 (2026.10 Feature Update)

Dell SBE: 5.0.2609.1715

Production Hyper-V workloads

Problem:

The update repeatedly reaches 85% completion, fails, and automatically starts another attempt without administrator intervention.

We have observed four solution update runs: three failed and one reported as InProgress.

Each retry can trigger Cluster-Aware Updating (CAU), causing node drains, VM migrations and reboots during business hours.

We attempted to disable the CAU clustered role:

Disable-CauClusterRole

The role was successfully disabled and reported Offline. However, Azure Local subsequently brought it back Online and continued the update process.

Additional findings:

CAU reported failed to complete failback successfully on one node.

Another node experienced an ECE RemoteTask orchestration timeout on TCP port 8888.

The Azure Local Action Plan showed Run PostUpdateScript as InProgress.

CAU reported Found leftover state from a previous Updating Run.

The automated Azure Local diagnostic suggested a possible update orchestration retry/concurrency loop.

All three nodes subsequently returned to Up, and ECEAgent services were Running.

One production VM temporarily entered a Failed/Saved state before recovering.

Multiple solution update Run IDs were observed, although actual concurrent execution has not been conclusively verified.

Our main question:

Is there a Microsoft-supported way to safely pause or stop the Azure Local update orchestrator and prevent further automatic CAU retries, node drains and reboots until a scheduled maintenance window?

We do not want to forcibly terminate PowerShell processes, stop ECEAgent or manually remove orchestration state.

We would also appreciate guidance on resolving the repeated failure at 85% and safely resuming the update later.

This is a production environment, and preventing unexpected VM downtime during business hours is our highest priority.

Thank you for your assistance.Hello Azure Local Community,

We are experiencing a serious update orchestration issue on our production Azure Local cluster.

Environment:

3-node Dell Azure Local cluster

Current installed version: 12.2609.1003.7

Target update: 12.2610.1004.50 (2026.10 Feature Update)

Dell SBE: 5.0.2609.1715

Production Hyper-V workloads

Problem:

The update repeatedly reaches 85% completion, fails, and automatically starts another attempt without administrator intervention.

We have observed four solution update runs: three failed and one reported as InProgress.

Each retry can trigger Cluster-Aware Updating (CAU), causing node drains, VM migrations and reboots during business hours.

We attempted to disable the CAU clustered role:

Disable-CauClusterRole

The role was successfully disabled and reported Offline. However, Azure Local subsequently brought it back Online and continued the update process.

Additional findings:

CAU reported failed to complete failback successfully on one node.

Another node experienced an ECE RemoteTask orchestration timeout on TCP port 8888.

The Azure Local Action Plan showed Run PostUpdateScript as InProgress.

CAU reported Found leftover state from a previous Updating Run.

The automated Azure Local diagnostic suggested a possible update orchestration retry/concurrency loop.

All three nodes subsequently returned to Up, and ECEAgent services were Running.

One production VM temporarily entered a Failed/Saved state before recovering.

Multiple solution update Run IDs were observed, although actual concurrent execution has not been conclusively verified.

Our main question:

Is there a Microsoft-supported way to safely pause or stop the Azure Local update orchestrator and prevent further automatic CAU retries, node drains and reboots until a scheduled maintenance window?

We do not want to forcibly terminate PowerShell processes, stop ECEAgent or manually remove orchestration state.

We would also appreciate guidance on resolving the repeated failure at 85% and safely resuming the update later.

This is a production environment, and preventing unexpected VM downtime during business hours is our highest priority.

Thank you for your assistance.

Azure Update Manager
Azure Update Manager

An Azure service to centrally manages updates and compliance at scale.

0 comments

1 answer

Sort by: Newest
Most helpful Newest Oldest

  1. AI answer

    2026-11-08T13:39:07.9166667+00:00

    There is no documented Microsoft-supported method here to pause or stop the Azure Local update orchestrator mid-run by disabling CAU, stopping agents, or manually altering orchestration state. The documented supported actions are to identify the failing step, review the failure details, mitigate the issue, and then resume the update through the Azure portal or PowerShell.

    For a production cluster with repeated retries and node drains, the supported path is:

    1. Identify the exact failing step.
      • In the Azure portal, open the failed update and review:
        • failing step name and description
        • machine where the step failed
        • failure message string
      • This is the key data to determine whether the issue is transient, a known issue, or requires support.
    2. Review the update run details in PowerShell if needed.
      • Get the failed update version and run details: 
             $Update = Get-SolutionUpdate | ? Version -eq "12.2610.1004.50" -Verbose
     $Failure = $Update | Get-SolutionUpdateRun
     $Failure
      • Use the ResourceID from the failed run as the ActionPlanInstanceID to view the summary: 
             Start-MonitoringActionplanInstanceToComplete -actionPlanInstanceID <Action Plan Instance ID>
      • Important: use Start-MonitoringActionplanInstanceToComplete only after the system installs the 2503 update. Before 2503, using this cmdlet to monitor update progress can cause failures in the orchestration.
    3. Check for known issues before retrying.
      • Review the release notes for the installed version and the target version.
      • Search the official AzureLocal-Supportability TSG repository using the failing step or exception text.
      • If the issue involves an SBE update path, also review Dell SBE known issues from the hardware vendor.
    4. Do not blindly rerun the update.
      • Best practices explicitly say not to re-run a partially failed update blindly.
      • First retrieve error logs from Update history in the Azure portal.
      • In disconnected scenarios, also check offline logs such as the ClusterAwareUpdating log on the affected node.
      • Ensure the cluster is stable before retrying.
    5. Resume only after mitigation or if the failure is confirmed transient.
      • Azure portal: use Try again on the failed update stage.
      • PowerShell: 
             Get-SolutionUpdate | ? Version -eq "12.2610.1004.50" | Start-SolutionUpdate
      • If the failure is only due to update health checks in a Warning state: 
             Get-SolutionUpdate | ? Version -eq "12.2610.1004.50" | Start-SolutionUpdate -IgnoreWarnings
    6. If retries continue or the failure cannot be clearly remediated, collect logs and open a support ticket.
      • In the Azure portal, use View details on the error.
      • Use How to collect logs / collect diagnostic logs.
      • Then use Open a support ticket and attach the logs.

    Based on the symptoms listed, the most relevant supported troubleshooting focus areas are:

    • the first CAU failure, not later retries; for repeated CAU failures with max retries exceeded, investigate the first failure and correlate it with Get-CauReport -Detailed
    • leftover update state or a known issue documented in release notes or the AzureLocal-Supportability TSG
    • the specific failing action plan step such as Run PostUpdateScript

    Because this is a production environment and an update attempt has already caused VM impact, the safest supported approach is to avoid unsupported intervention, capture the failing step and logs, investigate the first CAU failure, and open a Microsoft support ticket before allowing further retries during business hours.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    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.