Troubleshoot Remote Desktop TCP 3389 Connection Failures

Before you begin

Applicable to supported Windows Server/client environments where the named role or feature is installed. Run read-only checks first from an elevated PowerShell or Command Prompt as appropriate. Replace example hostnames, domain names, addresses, ports and paths with values from the affected environment. Record the exact error, timestamp, OS build and scope of impact.

Production safety: obtain change approval and a verified backup before modifying AD DS, DNS, DHCP, firewall, IIS, storage or Hyper-V configuration. Ensure console/out-of-band access before network or remote-access changes.

Symptoms and likely root cause

RDP cannot connect to a Windows Server by hostname or IP, or reports the remote computer is unavailable.

DNS, route, TCP listener, RDP disabled, active firewall profile, upstream ACL/NAT or non-default port.

Diagnostic commands

Resolve-DnsName server01.corp.example.com
Test-NetConnection server01.corp.example.com -Port 3389
Test-NetConnection 10.20.0.25 -Port 3389
Get-Service TermService
qwinsta
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-NetFirewallRule -DisplayGroup Remote Desktop | Select DisplayName,Enabled,Profile,Direction,Action

Run the commands in order and save the complete output. The commands above are intended to establish the failing layer before a configuration change is attempted.

How to interpret the results

TcpTestSucceeded True means TCP port is reachable from that client. If IP works but name fails, fix DNS. If both fail, check server listener and firewall. Registry fDenyTSConnections 0 allows RDP; 1 denies. Confirm listener exists.

Practical correction

Enable only the correct Remote Desktop inbound rules for active profile and approved management source. Check VPN ACL, NAT and cloud security group. Never expose RDP directly to public internet; use VPN/RD Gateway/zero-trust path.

Make one change at a time. Re-run the failed diagnostic after each change so the cause-and-effect relationship is clear.

Fallback and recovery

Before registry/firewall changes, record original values and ensure console/iLO/iDRAC/Hyper-V access. Restore prior rule if remote access is lost. Validate both TCP and an authenticated RDP session.

Verification checklist

Success: authorised source can establish RDP session and unauthorised sources remain blocked. TCP 3389 reachability alone does not prove authentication.

• Repeat the original failing operation from the affected client/user or service.
• Test from a second approved endpoint or subnet where relevant.
• Review the relevant event log/IIS log after the fix.
• Record the change, actual result and any remaining limitation.

Frequently asked question

Should I turn off firewall to test RDP? No. Inspect the specific inbound rule and use console recovery.

Official technical reference

Microsoft Learn — remote desktop cannot connect remote computer

Use the official documentation for exact version support, prerequisites and any procedure that differs between Windows Server releases.

Technician field note

This runbook describes a controlled diagnostic path; it is not a universal guarantee that every environment has the same cause. If evidence does not match the expected result, stop and investigate rather than applying unrelated fixes. Do not mark the incident resolved until the original symptom is verified as cleared.