AzurePolicyforLinux not updating VM, also won't uninstall extension, vmassist flags nothing

Question

I have a RedHat 9 VM that was being routinely updated using Azure maintenance configuration.

The updates stopped working without errors being indicated.

The AzurePolicyforLinux VM extension reports as 'Transitioning' when I list the extensions in the portal.

I tried uninstalling the extension with the intent to reinstall to see if that fixes the patching issue, but uninstall times out.

I have rebooted the VM and retried uninstall without success.

I have also tried:-      az vm extension delete --resource-group <YourResourceGroup> --vm-name <YourVMName> --name AzurePolicyforLinux

az vm restart --resource-group <YourResourceGroup> --name <YourVMName>

[obviously substituting <YourResourceGroup> and <YourVMName> as appropriate]

.

I ran the vmassist tool, but it doesn't indicate errors apart from "2026-05-06 16:27:20,946 py INFO {'waaUpgStat': {'status': 'not up to date - Local:2.15.2.0 Wire:2.15.1.3', 'description': 'GoalState version mismatch to wireserver'}}" but I don't know if that's relevant or not.

.

I tried logging a support request, but that process drops me here on this forum.

Is there a support engineer that can provide assistance please ?

Answer 1

hi Gary Spencer & thanks for join me here at Q&A portal,

waagent/extension goal state is stuck, clean /var/lib/waagent manifests, restart waagent, reapply VM, then retry. That GoalState version mismatch to wireserver is relevant. It points to Azure Linux Agent / extension state desync, not directly to Red Hat patching. If AzurePolicyforLinux is stuck in Transitioning and uninstall times out the Guest Configuration extension state on the VM is probably corrupted or incomplete. Actually msft has a current Linux extension issue where extensions stop processing because of stale .manifest.xml files under /var/lib/waagent/, the documented workaround is to remove those manifest files and restart the agent. I would do this carefully take snapshot/backup first, then on the VM run sudo systemctl stop waagent, remove stale manifests with sudo rm -f /var/lib/waagent/.manifest.xml, optionally move the broken extension folder like sudo mv /var/lib/waagent/Microsoft.GuestConfiguration.ConfigurationforLinux* /tmp/, then sudo systemctl start waagent. After that run az vm reapply -g <rg> -n <vm> and retry extension delete or reinstall. Msft docs recommend VM Reapply when extensionstate is stuck.

If delete still fails after waagent cleanup + reapply, open support and ask for backend cleanup of the stuck AzurePolicyforLinux / Guest Configuration extension state.

rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

Answer 2

Azure Update Manager (AUM) does not generate updates independently it only reports what the OS (package manager) detects.

in Linux: run

sudo apt update && apt list --upgradable

or yum check-update

If OS shows no updates > AUM is correct

If OS shows updates > issue is AUM assessment pipeline

AUM relies on package manager output for Linux updates [docs.azure.cn]

Check repository / source configuration - AUM does NOT provide updates, it only reads configured sources.

Please verify:

1. Repo enabled (/etc/apt/sources.list, yum repos, etc.)
2. Repo reachable (no proxy/firewall issue)
3. AUM update source is configured on the VM
4. Confirm periodic / fresh assessment

Ensure: Periodic assessment = Enabled or trigger manual “Check for updates”

Without periodic assessment, results can be stale or empty [docs.azure.cn]

Please validate Linux patch extension logs (now that extension is healthy)

Check:

Logs explicitly show patches assessed and failures if any [learn.microsoft.com]

Please check VM agent + service health

Ensure: that Azure Linux Agent running

1. Patch service (auto assess) active
2. AUM depends on agent to trigger and report assessment [learn.microsoft.com]

Rule out timing / refresh delay

1. AUM UI does not refresh instantly
2. Wait ~15–60 min or retry

Status sync delay is expected in some cases.

Azure Update Manager is only an orchestrator if the OS/package manager does not report available updates, AUM will show “No pending updates.” Microsoft References-

1. Troubleshoot known issues with Azure Update Manager - https://learn.microsoft.com/en-us/azure/update-manager/troubleshoot?tabs=azure-machines
2. How Update Manager works - https://learn.microsoft.com/en-us/azure/update-manager/workflow-update-manager?tabs=azure-vms%2Cupdate-win

PG team completed backend validation for the reported operation (ID: -d1e5-475c-b7b5-79) and identified that the failure is related to the AzurePolicyforLinux (Guest Configuration) extension during the delete/uninstall phase.

The extension timed out during removal, resulting in the observed provisioning failure.

Here logs confirm that the extension entered a “NotReady” state due to an internal configuration inconsistency, specifically related to missing sequence/configuration data required during the disabled operation.

Other VM extensions on the instance are functioning normally, indicating this is isolated to the Guest Configuration extension only.

What this means:

This behavior is a known issue pattern where the extension cannot cleanly uninstall due to corrupted or incomplete state on the VM, leading to timeout rather than graceful removal.

Next Steps / Recommendations:

We recommend manually cleaning up the Guest Configuration extension state on the VM and reattempting the operation.

Typically, this involves removing or recreating the extension configuration files and then retrying the uninstall (or reinstall > remove flow). From the results you’ve shared, Azure Update Manager is currently behaving as expected. It relies on the underlying OS package manager to detect available updates, and since the RHEL package manager is reporting “Nothing to do”, the platform is correctly reflecting that no pending updates are available at this time. - Azure Update Manager Operations | Microsoft Learn

 Given this, the behavior points to the update source and repository state on the VM rather than an issue with Azure Update Manager itself.

 As the next step, I would recommend proceeding with upgrading the VM to the latest supported minor version (for example, RHEL 9.6). Performing a minor version upgrade helps refresh the repository metadata and ensures the system aligns with the latest available package streams, which in turn allows the package manager and therefore Update Manager to properly detect applicable updates.

 

Once the upgrade is completed, please rerun:

yum check-update on the VM “Check for updates” from Azure Update Manager  

Answer 3

Both solutions Accepted

Answer 4

I'm grateful that a combination of recommendations from Himanshu and Alex resolved the issues, namely:-

.

1. Check for multiple or incomplete directories for: Microsoft.GuestConfiguration.ConfigurationforLinux

Clean up stale or inconsistent extension folders

Remove older or partially created extension directories

Ensure only a single, consistent extension folder remains

tar zcvf var-lib-waagent-Microsoft.GuestConfiguration.ConfigurationforLinux-archives.tar.gz --xattrs --exclude "Microsoft.GuestConfiguration.ConfigurationforLinux-1.26.104" --remove-files /var/lib/waagent/Microsoft.GuestConfiguration.ConfigurationforLinux-1.26.*

(where ...1.26.104... above is most recent)

Restore missing configuration files (if applicable) - If multiple versions exist, copy the missing configuration/sequence file (e.g., 0.settings) from a healthy extension folder

   ```yaml

   sudo systemctl restart waagent

.

followed by:-

2) checking for and removal of 'version lock' files:-

tar zcvf etc-yum-vars-releasever-archives.tar.gz --xattrs --remove-files  /etc/yum/vars/releasever /etc/dnf/vars/releasever

.

These two steps have returned the extension status to '**Provisioning succeeded**' and regular system updates to be offered for the VM again.

thanks for everybody's assistance with this.

Answer 5

Gary Spencer - The issue is most likely due to a VM Agent / WireServer communication problem, not just the extension itself.

• The AzurePolicyforLinux extension depends on the Azure Linux Agent (waagent) for lifecycle operations.
• Your log shows: GoalState version mismatch to wireserver > this indicates agent > WireServer desync or connectivity issue.

As per Microsoft troubleshooting guidance:

• When the VM cannot properly communicate with WireServer (168.63.129.16), extensions may remain stuck in Transitioning/Failed state and cannot be removed or updated - https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/linux/linux-azure-guest-agent

Recommended next steps (MSFT standard guidance)

Please validate WireServer connectivity from VM

curl http://168.63.129.16/?comp=versions

If this fails > root cause confirmed (network/firewall/proxy)

Check firewall/proxy rules

• Ensure 168.63.129.16 is NOT blocked on ports 80 / 32526 [Troublesho...soft Learn | Learn.Microsoft.com]

Check waagent health

If connectivity is fine > restart agent

sudo systemctl restart waagent

If still stuck:

This may be a stale extension state in control plane