Azure Windows VMs boot, but WireServer Goal State and IMDS persistently return 410 / ResourceNotAvailable

Question

Azure Windows VMs boot, but WireServer Goal State and IMDS persistently return 410 / ResourceNotAvailable

Sven Dierick 0

Two existing Windows Server 2022 Trusted Launch VMs (Standard_D2s_v7) in Germany West Central boot and accept RDP, but Azure Compute reports Updating/Failed VMStartTimedOut and the Azure guest agent is Unavailable. No production outage is involved.

Direct proxy-free requests reproduce:

WireServer versions: HTTP 200.
WireServer Goal State: HTTP 410 / ResourceNotAvailable.
IMDS instance metadata: HTTP 410 / ResourceNotAvailable.

The issue persists for hours, far beyond the documented short retry window. Guest DHCP is enabled, the guest/VM/NIC identity mapping matches, Windows setup is complete, Microsoft-signed RdAgent and WindowsAzureGuestAgent services run, and the expected existing managed identities are attached. The guest agent explicitly requests escalation to OneFleet Node/AzureHost-Agent because it cannot obtain Goal State.

Earlier reapply/restart/redeploy attempts failed with VMStartTimedOut. A new controlled full deallocation completed successfully for both VMs; Windows booted again after start, but direct Goal State and IMDS still return 410. A further bounded redeploy is currently being verified after the user logged off. Managed disks and configuration are retained. No additional identities, privileges, or billable resources have been introduced.

The current Basic support plan does not provide private technical ticket creation. A valid support-API request was asynchronously rejected as InvalidSupportPlan. We need a platform-side investigation of the existing Goal State/Fabric/AzureHost-Agent association. Resource Health reports Available despite this directly reproduced metadata failure.

What no-new-cost recovery path is available, and can an Azure engineer investigate the platform-side Goal State/IMDS association? Subscription/resource/correlation IDs and logs can be supplied through a private support channel if needed; they are intentionally omitted from this public question.

0 comments

1 answer

Your answer

Answer 1

Hello Sven Dierick,

Greetings! Thanks for raising this question in the Q&A forum.

Your troubleshooting is already thorough, and your results point to a platform-side problem. The WireServer versions call returns 200, so the VM can reach 168.63.129.16, but the Goal State and IMDS calls return 410, which means the host and fabric have not published a goal state for these VMs. The guest agent is working as designed and is asking for escalation because it cannot get a goal state. That also explains VMStartTimedOut and the Agent status Unavailable, while Resource Health still shows Available. Nothing inside the guest can fix this, and I can't confirm the exact backend cause from here. Q&A volunteers also cannot see or change your subscription's host or fabric state, so the realistic paths are to move the workload to a new host or to reach Microsoft engineering through a support channel. Please consider the following.

Stop repeating redeploy and reapply on the same VMs. Repeating them on the same allocation is unlikely to change the outcome. Record the evidence first for later use: the Activity log correlation IDs of the failed Start and Redeploy operations, the UTC times, and the output of:

az vm get-instance-view --name <vm-name> --resource-group <rg-name> --query "{power:instanceView.statuses, agent:instanceView.vmAgent}" -o json

Also keep the guest logs from C:\WindowsAzure\Logs\WaAppAgent.log and C:\WindowsAzure\Logs\TransparentInstaller.log.

Try forcing a fresh allocation by changing the VM size. A resize while deallocated makes Azure allocate the VM on a different cluster or hardware generation, which can bypass a broken host association. Check which sizes are offered in your region and zone, then:

az vm deallocate --name <vm-name> --resource-group <rg-name>

az vm resize --name <vm-name> --resource-group <rg-name> --size Standard_D2s_v5

az vm start --name <vm-name> --resource-group <rg-name>

Use az vm list-skus --location germanywestcentral --size Standard_D2s --output table to see what is available. Costs are for the same class of size while you test, and you can resize back later.

Rebuild a new VM from the existing managed disk. Your disks and data are retained, so you can move the workload to a new VM resource without a platform fix. Deallocate the VM, create a snapshot, make a new disk, and create a new VM from it, keeping the Trusted Launch settings:

az snapshot create --resource-group <rg-name> --name <snap-name> --source <os-disk-id>

az disk create --resource-group <rg-name> --name <new-disk-name> --source <snap-name> --security-type TrustedLaunch

az vm create --resource-group <rg-name> --name <new-vm-name> --attach-os-disk <new-disk-name> --os-type Windows --size Standard_D2s_v5 --security-type TrustedLaunch --enable-secure-boot true --enable-vtpm true

Reattach any data disks and the managed identities (az vm identity assign), then delete the old VM once the new one is healthy. The only extra cost is the short overlap of the snapshot and the temporary second VM. Please keep the original disks until you have verified the new VM.

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,
Jerald Felix