Azure VM Extension Provisioning Failure Fix
VM extensions fail when the agent can't talk to Azure backend. Usually a network or agent version problem. Here's how I fix it fast.
Quick answer for advanced users
Restart the Azure VM agent service, verify NSG allows outbound to Azure management endpoints, and reapply the extension via portal or CLI.
Why this happens
I've seen this error hundreds of times. The VM extension provisioning failure (error code VMExtensionProvisioningError) always boils down to the same root cause: the Azure VM agent can't talk to the backend properly. Either the network is blocked, the agent is stuck, or the extension itself is broken. Don't waste time checking logs first — go straight to the agent and network.
Step-by-step fix
- Check the VM agent status — Run this on the VM (Linux or Windows):
# Windows (as admin)
Get-Service -Name WindowsAzureGuestAgent
# Linux
sudo systemctl status waagent
If the agent is stopped or stuck, restart it:# Windows
Restart-Service -Name WindowsAzureGuestAgent
# Linux
sudo systemctl restart waagent
Wait 2 minutes, then reapply the extension. - Verify network rules — The VM must be able to reach the Azure management plane. Check NSG rules, firewalld, or iptables. For Windows, check Windows Firewall. Required outbound endpoints are:
*.*. management.azure.com
login.microsoftonline.com
If you have a proxy or forced tunneling, that's the culprit. I've seen it a dozen times — someone locked down outbound traffic and forgot these endpoints. - Reapply the extension — In the portal, delete the failed extension (under VM > Extensions + applications). Then add it again. If you're CLI person, use:
az vm extension set --resource-group myGroup --vm-name myVM --name CustomScriptExtension --publisher Microsoft.Compute --version 1.10
This forces a fresh deployment. - Check the extension logs — Only if the above doesn't work. On Windows, look at:
C:\WindowsAzure\Logs\WaAppAgent.log
C:\Packages\Plugins\<ExtensionName>\<Version>\Status\<StatusFile>
On Linux:/var/log/waagent.log
/var/lib/waagent/extension.log
Look for "Timeout" or "Connection refused" errors — that's network.
Alternative fixes if main steps fail
Reinstall the Azure VM agent
On Windows, download the latest agent from Microsoft and install it manually. On Linux, run sudo apt-get install walinuxagent (or yum for RHEL). Reboot after install.
Use a different extension version
Sometimes a specific version is buggy. If you're trying CustomScriptExtension 1.10, try 1.9 or 1.11. You can specify --version 1.9 in the CLI command above.
Check guest firewall rules
If you use iptables or Windows Firewall, make sure outbound port 443 is open for the Azure agent process. On Linux, run sudo iptables -L -n to check. I once spent an hour debugging this — someone had blocked all outbound except SSH.
Try a different VM SKU
If nothing works, move the VM to a different series (e.g., from D-series to B-series). Rare, but I've seen certain SKUs have odd extension behavior. Redploy the VM with the new size.
Prevention tip
Don't mess with the default NSG rules unless you really know what you're doing. The easiest fix is to allow outbound to the AzureCloud service tag. Set it in the NSG:
Destination: AzureCloud
Port: 443
Protocol: TCP
Action: AllowAlso, always keep the VM agent updated. Set automatic updates for the agent in the portal or use Azure Update Manager. I've seen old agents silently break after a backend change. That's saved me a lot of headaches.
Was this solution helpful?