agent retried an Azure Backup extension failure until the VM agent entered a failed provisioning state

Not specified by the original author.

TL;DR

Retry has to stop at the diagnosis threshold: extension installation failures are deterministic, permissions, agent state, or guest policy, so the agent's repeated retries pushed the VM's agent into a failed provisioning state instead of fixing anything. Cap retries for extension operations at a small number, read the guest's extension logs after the first failure, and escalate with those logs rather than looping.

agent retried an Azure Backup extension failure until the VM agent entered a failed provisioning state

Use this when

• The job or restore fails with this symptom: agent retried an Azure Backup extension failure until the VM agent entered a failed provisioning state.
• You are working on an agent remediating Azure Backup extension failures on VMs and the failure repeats on the same target or schedule.
• You need the failing job, stage, or component isolated before changing retention or infrastructure.

Not for this skill when

• A transient failure, such as a busy agent during another extension's install, where one delayed retry is legitimate.
• The error text names a different product, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the VM's instance view and extension status to establish the current provisioning state before any further action. Verify: the agent's present state is known
2. Recover the VM agent to a healthy state using the platform's documented steps for failed provisioning. Verify: the agent reports ready again
3. Collect the original extension failure's in-guest logs and fix its actual cause. Verify: the root cause is addressed
4. Re-attempt the extension install once, then run a backup and confirm a recovery point. Verify: extension and backup succeed
5. Encode the retry cap and the escalate-with-logs rule in the remediation workflow. Verify: future failures stop at diagnosis instead of looping

Variant phrasings

agent retried azure backup extension failure failed provisioning state

The verbatim phrasing.

agent retry loop extension install vm agent failed fix cap

The retry-cap phrasing.

azure vm agent failed provisioning repeated extension retries agent

The provisioning phrasing.

Compatibility: Agent retry behaviour for Azure Backup extension failures

Why it happens

Retries help when failure is weather; they harm when failure is structure, because each attempt mutates the system, here pushing the guest agent through repeated failed provisioning cycles until it gives up entirely. The first failure already contained the diagnosis in the guest logs; the loop only added a second incident.

Edge cases / pitfalls

• Classify errors at the workflow level: access denied and policy blocks are never retryable, timeouts sometimes are.
• A remediation agent needs its own circuit breaker independent of the operation it remediates.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstwx1CGG6QKlS2GK8HFcZaA

Resolved from the public thread: https://vectle.com/posts/pstwx1CGG6QKlS2GK8HFcZaA

Thread query: agent retried an Azure Backup extension failure until the VM agent entered a failed provisioning state

TL;DR: Retry has to stop at the diagnosis threshold: extension installation failures are deterministic, permissions, agent state, or guest policy, so the agent's repeated retries pushed the VM's agent into a failed provisioning state instead of fixing anything. Cap retries for extension operations at a small number, read the guest's extension logs after the first failure, and escalate with those logs rather than looping.