Unable to access our production VM via RDP or Azure Bastion. The VM is running and booted, but port 3389 is unresponsive despite NSG and diagnostics showing RDP is enabled and rules are correctly configured.

Question

Current State:

• VM is running and booted
• Public IP is available
• NSG rules allow inbound TCP 3389
• Diagnostics confirm RDP setting is enabled, DHCP succeeded, platform is healthy

Core Issue:

• RDP port 3389 is not reachable from host (as confirmed by Azure diagnostics)
• Azure Bastion (Developer SKU), which is our usual connection method, is currently unavailable due to an active service health issue

What we've done:

• Used chntpw after attaching the OS disk to a recovery VM to ensure local admin account is enabled with no password

Attempted to connect using Get-AzRemoteDesktopFile (fails to connect, port unreachable)

Avoided redeploying or rebuilding the VM to preserve all existing IIS config, bindings, and Classic ASP app

What we need:

• Microsoft support to restore access to the VM without full rebuild

Ideally inject credentials or resolve port 3389 blockage

Ensure we don’t lose config by redeploying or replacing the VM

This is a critical production system

What we've done:

• Used chntpw after attaching the OS disk to a recovery VM to ensure local admin account is enabled with no password

Attempted to connect using Get-AzRemoteDesktopFile (fails to connect, port unreachable)

Avoided redeploying or rebuilding the VM to preserve all existing IIS config, bindings, and Classic ASP app

What we need:

• Microsoft support to restore access to the VM without full rebuild

Ideally inject credentials or resolve port 3389 blockage

Ensure we don’t lose config by redeploying or replacing the VM

Again, this is a critical production system

Answer 1

Hello Kehinde Oderemi,

Thank you for posting your question in the Microsoft Q&A forum. 

The inability to access your production VM via RDP or Azure Bastion, despite confirmed NSG rules and a healthy boot state, suggests either a Windows OS-level network misconfiguration or an underlying Azure platform issue. Since Azure Bastion is unavailable due to a service incident, and direct RDP remains blocked despite open port 3389, consider these steps: 

• Verify Windows Firewall Rules: Even if NSG allows RDP, the VM’s local firewall may block traffic. Use Azure Serial Console (if enabled) or attach the OS disk to another VM to check netsh advfirewall rules. 
• Check TCP/IP Stack Corruption: Network driver issues or corrupted TCP/IP settings can silently drop packets. Boot into Safe Mode with Networking via recovery. 
• Leverage Azure Run Command: If the VM agent is healthy, use RunCommand to reset RDP settings: 

powershell 

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server" - Name "fDenyTSConnections" -Value 0   

• Review Azure Service Health: Confirm no ongoing network virtualization or host node outages in your region. 

For credential injection, Microsoft Support can assist with emergency access via: 

• VM Guest OS Disk Swap: Temporary attach to a helper VM for config edits. 
• Azure AD Login Extension: If configured, reset credentials via Azure AD. 

Few related documentation links you may want to review: 

• https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request 
• https://learn.microsoft.com/en-us/azure/virtual-machines/run-command-overview 
• https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/serial-console-overview  

If the above answer helped, please do not forget to "Accept Answer" as this may help other community members to refer the info if facing a similar issue. Your contribution to the Microsoft Q&A community is highly appreciated. 

Answer 2

Hello Kehinde Oderemi,

Based on the detailed resource history and diagnostics, the issue you're facing with the production VM being unresponsive on port 3389 despite it showing as running and properly configured stems from multiple changes made to the VM in a short span of time.

The VM has undergone several size swaps, disk detachments and reattachments, and repeated restarts between May 7 and May 13. From the evidence collected so far, between May 7–13, the VM was repeatedly stopped/deallocated and restarted, resized between Standard_D4s_v3, D4ds_v4, E4bds_v5, even had its OS disk detached/attached (and even swapped with a recovery disk). I can also see presence of enablevmAccess Extension installed around 2025-05-13T17:17:00Z, same time the issue was reported.
This indicates an attempt to regain access, possibly by resetting credentials or repairing SSH/RDP settings. PowerState consistently flips between deallocated, starting, running, stopped — pointing to instability or recovery attempts.

The primary cause for your blocker is due to residual misconfiguration or corruption in the OS or RDP stack after multiple VM size swaps and disk reattachments, likely exacerbated by a failed or incomplete enablevmAccess extension run. This left the VM booted but unreachable.

As of now what you can do is use Serial Console (Boot Diagnostics) to help you verify whether the OS is booting cleanly or hanging on login services.

Re-run enablevmAccess with explicit RDP fix

az vm extension set \
  --resource-group Expandable-Web-RG_group \
  --vm-name Expandable-Web-RG \
  --name enablevmAccess \
  --publisher Microsoft.Compute \
  --version 2.4 \
  --protected-settings '{ "username": "adminuser", "password": "abcd" }'

As you said this is a production VM, I would recommend you to save time and create a new VM using the same disk.

And as for updating your superiors regarding cause of this blocker, I have shared a detailed RCA with you both in private message and our chat for your ease to update them with data points.

Hope I was able to clear your query here. Please feel free to accept the answer for anyone else in the Microsoft QnA community having similar query can refer to it and be benefited. Thanks