Why is my VMSS AMA in the 'provisioning failed' state?

Hello @Simon Haines

To remove all extensions from your VMSS except for 'CustomScript' and 'AzureMonitorLinuxAgent', use the Azure CLI to first list all extensions, then iteratively delete the unwanted ones using az vmss extension delete. Ensure you remove any legacy monitoring agents that may be causing conflicts. Finally, re-apply the 'AzureMonitorLinuxAgent' extension configuration and monitor the VMSS provisioning status.

Re-apply the AMA extension to ensure configuration is clean:

If you suspect the configuration of the existing AMA extension might be corrupted, you can remove it and re-add it cleanly.

Remove the AMA extension (if it exists):

1.

--resource-group $RESOURCE_GROUP
--vmss-name $VMSS_NAME
--name "AzureMonitorLinuxAgent"
--no-wait

**Re-add the AMA extension:** You need the specific settings (like the workspace ID, if applicable for older configurations, though AMA primarily uses Data Collection Rules - DCRs). Assuming the AMA configuration is defined via a DCR association:


yaml
az vmss extension set \
    --resource-group $RESOURCE_GROUP \
    --vmss-name $VMSS_NAME \
    --name "AzureMonitorLinuxAgent" \
    --publisher "Microsoft.Azure.Monitor" \
    --version "1.0" \
    --settings '{"dstrSettings": {"dataSources": [{"streams": ["Microsoft-InsightsMetrics"], "name": "Microsoft-InsightsMetrics"}]}}' # Example minimal settings, adjust based on your DCR association

If the Answer is helpful, please click Accept Answer and Up-Vote, so that it can help others in the community looking for help on similar topics.

Hello Simon Haines,

Welcome to the Microsoft Q&A and thank you for posting your questions here.

I understand that you would like to know reason your VMSS AMA in the 'provisioning failed' state and resolved it.

@Manish Deshpande has given some direction, however, the below will guide you to permanently resolve it:

Most of all, regarding your initial question. What can cause VMSS provisioning fails are majorly in three ways listed here https://learn.microsoft.com/en-us/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-troubleshoot#extensions and https://learn.microsoft.com/en-us/azure/azure-monitor/agents/azure-monitor-agent-migration and as listed:

• Residual OMS/MMA extension metadata conflicts with AMA.
• AMA requires proper DCR association and Managed Identity.
• VMSS model may still reference old extensions even if instances are cleaned.
• Among many others, network connectivity and policy.

So, to resolve all these:

1. Check VMSS Model Extensions using bash command:

      az vmss show \
        --resource-group <RG> \
        --name <VMSSName> \
        --query "virtualMachineProfile.extensionProfile.extensions"
   

   Remove OMSAgent or any unwanted extensions from model:

      az vmss update \
        --resource-group <RG> \
        --name <VMSSName> \
        --remove virtualMachineProfile.extensionProfile.extensions[<index>]
   

2. Remove extensions from Instances too

      az vmss extension list \
        --resource-group <RG> \
        --vmss-name <VMSSName>
      az vmss extension delete \
        --resource-group <RG> \
        --vmss-name <VMSSName> \
        --name <ExtensionName>
   

3. Force cleanup of residual OMSAgent from SSH into instance and remove stale handler:

      sudo rm -rf /var/lib/waagent/Microsoft.EnterpriseCloud.Monitoring.OmsAgentForLinux-*
   

4. Validate AMA configuration to ensure Managed Identity is enabled:

      az vmss identity assign \
        --resource-group <RG> \
        --name <VMSSName>
   

   Also, check and confirm the DCR association:

      az monitor data-collection rule association create \
        --name <AssociationName> \
        --resource <VMSSResourceID> \
        --rule-id <DCRResourceID>
   

5. Apply rolling upgrade

      az vmss update-instances \
        --resource-group <RG> \
        --name <VMSSName> \
        --instance-ids "*"
   

6. Then, verify AMA health

      az vmss extension show \
        --resource-group <RG> \
        --vmss-name <VMSSName> \
        --name AzureMonitorLinuxAgent
   

   Finally, you will need to monitor network, and policy should there be any case MA still fails
   • Check network connectivity to Azure Monitor endpoints.
   • If OMSAgent keeps reappearing, check Azure Policy or Automation scripts enforcing legacy agent.

I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications.

Please don't forget to close up the thread here by upvoting and accept it as an answer if it is helpful.

Hello @Simon Haines

I wanted to check if my last response made sense. I’d be glad to assist further or explain anything in more detail and please accept as Yes and upvote if the answer is helpful so that it can help others in the community.