An Azure Windows VM stopped accepting RDP: isolate the failing layer first

An RDP failure can originate in the client, an Azure network rule, a missing route, Windows Firewall, the Remote Desktop service or an unhealthy operating system. Start by recording whether the connection times out, refuses the connection or reaches a sign-in error. Those observations are more useful than repeatedly pressing Connect.

Confirm the target and access path

Check the VM’s power state, intended IP or DNS name and the route your client should use. An address can change independently of the machine you meant to reach. If access is private, confirm that the VPN or other approved route is established. Do not create a new internet-wide inbound rule just to see whether the error changes.

Review effective NSG rules rather than only the rule attached to the network interface. Subnet and interface rules can both influence traffic. Network Watcher’s IP flow verification can help evaluate the relevant source, destination and port. A rule allowing a previous office IP will not allow a client that now exits through another address.

Look for guest and platform evidence

Check Azure resource health and boot diagnostics. A VM shown as running may still be waiting at a recovery screen or failing during startup. If you have an already authorized guest-management path, inspect the RDP service and Windows Firewall configuration. Collect observations before resetting the RDP configuration or redeploying the VM.

Credential problems belong to a different branch. If the desktop listener responds but authentication fails, verify the account type, intended sign-in method and applicable policy. Reopening the network does not repair a password or identity issue.

Recover deliberately and verify persistence

Use Microsoft’s documented recovery operation that matches the evidence. Explain whether it changes guest settings, restarts the VM or moves it to another host, and make sure the recovery prerequisites are available. For a business-critical system, preserve diagnostics and consult its backup and change procedures before a disruptive operation.

After access returns, verify the original approved connection path again. Check that restrictive network rules remain in place and that the relevant services survive a planned restart if that is part of the change. Write down the root cause and the evidence supporting it; an RDP session opening once is a useful result, but it does not explain why access failed.