Virtual machine agent status is not ready- Not able to take RDP in Azure

Question

Suddenly I am not able to take the RDP of the azure Machine. There is error that the virtual machine agent status is not ready

I checked that RDP connectivity is OK.

Tried to find from the internet to re-install the agent in that VM but not found any solution yet.

Even i can not reset the password from the Portal also. Not sure how to get in the machine.

Appreciate the help if anyone knows any solution to this.

Answer 1

It could be due to an internal firewall such as palo alto, which detected what it might deem as "suspicious activity" and put the machine into isolation mode

Answer 2

i had the same problem, after restarting the vm it got resolved.

Answer 3

Make sure to follow this article first:

https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows-azure-guest-agent#troubleshoot-a-not-ready-status

---

If you cannot access 168.63.129.16 on ports 80 and 32526

It turns out the agent can ONLY contact Microsoft's servers via the primary static IP. I had ended up with two private IP addresses and the one that Azure thought was primary wasn't the one set to primary on the NIC.

Reason for the switch is I had two VMS that I had to redeploy to a new size. That involved taking snapshots and recreating a whole new VM and then moving over IP addresses. And they ended up backwards because I never knew about this potential issue.

Solution: flip primary and secondary

The solution was just flipping these. You might think would be as simple as clicking 'Make Primary', but that gave some weird error so I had to manually flip them. Try clicking 'Make Primary' first and see if you get an error!

• Do NOT attempt this with high traffic, it may take a few minutes
• Take a screenshot or photo of the initial IP configuration
• Change the secondary IP to something unused 10.0.0.110
• Wait until the operation is complete
• Change the primary IP to the initial secondary value.
• Wait until the operation is complete
• Change the secondary IP back to the initial primary value
• Make any DNS or other changes needed if you need the public IP to map to the private one. (Another reason not to do this at peak hours).

If you don't wait until the operation is complete you'll get an error saying something about 'cleaning up the IP'.

I then had to reboot my VM and it took longer than I'd expect for it to come up again.

This took about 12 minutes for me to flip and wait for IP cleanup.

But the agent now works.

Answer 4

We've had this a few times, where simply rebooting isn't enough. There seem to be various fixes, listed in the order I'd consider attempting them:

If you stop and then start the VM, the stop causes it to be deallocated (which a reboot doesn't) - in most cases that will resolve the issue.

Similarly, redeploy and reapply as suggested in Aatif Akhter's answer will stop-start the device, and also helps the VM get back to a valid/healthy state. Note: this is not deploying a new, blank VM, but rather fixing the existing VM (just to reassure those who find the term redeploy a bit scary).

If you still have issues, you can resize the VM (pick something similar); again, that seems to give it a bit more of a push (likely it makes it more likely that the VM will be reprovisioned on a different host, thus more likely to avoid the underlying issue.

Beyond that, check the Boot Diagnostics page - sometimes that will show you a screenshot explaining the issue (e.g. a System Recovery Options screen or similar). In this case the issue seems more at OS level than just a hosting glitch. For this, you're probably best off restoring the VM from an old backup... Before doing this consider the impact - i.e. a lot of servers just run logic / don't hold data, so going back a week will have negligable impact - but some servers will hold stateful data (obvious examples are database servers and file servers; though application/web servers can have stateful content too); so this comes with risk.

If your system has multiple disks and you know that only the OS is on your C drive (or only your OS and easy-to-reinstall programs), whilst anything stateful is on data disks, you can issue a fresh VM, then detach your data disks from your unhealthy VM and attach them to the new, healthy one.

We've also found issues with the VM's resource definition, rataher than on the OS disk... To fix that we recover the VM from a healthy backup using the create new virtual machine option, then switch the OS and DataDisks from the faulty VM with those in the recovered VM, and the recovered VM works without any loss of data (as the disks contain the stateful content we care about).

Beyond this you're in really painful territory. Raise a support ticket with MS for their assistance to see if they can give you any options not suggested here / shed more light on what's causing your issues. ... Or these documents have some other good tips to help you progress with issue invesigation:

• Using your OS Disk to run your VM in a nested Hyper-V instance
• Docs on various VM troubleshooting scenarios

Answer 5

I was facing same issue yesterday and could resolve it after I redeployed and reapplied my VM from azure portal -

Sometimes you might need to restart the virtual machine after redeploy and restart. The agent extension blade still shows the extension to be unavailable sometimes but RDP works.