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

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.

To preserve IIS/configs, avoid redeployment and instead:

Snapshot the OS disk for backup.
File a Severity-A support ticket with your subscription ID, VM details, and NSG logs.

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.

Share via

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.

1 answer

Your answer