VMProvisioningStateFailed
Azure reports `VMProvisioningStateFailed` when virtual machine provisioning ends in a failed state during OS, extension, image, or dependency setup.
Last reviewed: February 24, 2026|Editorial standard: source-backed technical guidance
What Does VM Provisioning State Failed Mean?
VM creation reached execution but one or more provisioning sub-steps failed, leaving the VM unusable until root causes are corrected.
Common Causes
- -Custom image was captured or uploaded with generalized/specialized mismatch, causing provisioning failure.
- -VM extensions or guest-agent startup scripts fail during initial configuration.
- -Required dependencies (NIC, disk, identity, key vault access) are missing or misconfigured.
- -Policy, quota, or access constraints interrupt provisioning sequence mid-flight.
How to Fix VM Provisioning State Failed
- 1Inspect VM instance view and deployment operation sub-status messages for the first failing step.
- 2Validate image preparation path (generalized vs specialized) and rebuild image if mismatch is detected.
- 3Fix failing extension or initialization script independently before full VM redeploy.
- 4Confirm dependency resources and permissions are valid at target scope, then reprovision.
Step-by-Step Diagnosis for VM Provisioning State Failed
- 1Collect deployment operation logs, VM boot diagnostics, and extension status outputs.
- 2Identify whether failure domain is image prep, guest provisioning, extension execution, or external dependency.
- 3Verify network, disk, and identity dependencies resolve correctly during VM creation.
- 4Retest with a known-good baseline image and minimal extension set to isolate regressions.
Image Preparation and OS Provisioning Validation
- -Confirm generalized/specialized image handling matches capture/upload path (example: specialized Windows image uploaded as generalized triggers provisioning failure).
- -Validate sysprep/cloud-init prerequisites for the selected image pipeline (example: custom image misses required prep state and stalls during OOBE/provisioning).
Extension and Dependency Failure Isolation
- -Inspect extension provisioning logs for first non-transient failure (example: Custom Script Extension fails due to missing package repo access).
- -Trace dependency readiness at provisioning time (example: NIC/NSG rule blocks agent outbound connectivity required for extension installation).
How to Verify the Fix
- -Redeploy VM and confirm provisioning state reaches
Succeededwithout extension/image errors. - -Validate extension health and guest-agent readiness after initial boot sequence.
- -Run smoke checks for network, disk, and identity-dependent workloads on the new VM.
How to Prevent Recurrence
- -Gate custom images through automated validation pipeline before publishing for production use.
- -Version-control VM extension configurations and test them against baseline images.
- -Add preflight checks for VM dependencies, permissions, and policy constraints in deployment workflows.
Pro Tip
- -keep a golden image canary deployment in each target region and block release when canary provisioning drift appears.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
AWS ThrottlingException vs GCP RESOURCE_EXHAUSTED
Compare AWS ThrottlingException and GCP RESOURCE_EXHAUSTED to separate rate limiting from quota/resource exhaustion and choose the remediation path.
Playbook
Rate Limit Recovery Playbook (429 / ThrottlingException / RESOURCE_EXHAUSTED)
Use this playbook to separate transient throttling from hard quota exhaustion and apply retry, traffic-shaping, and quota-capacity fixes safely.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.