Diagnose an RDP failure by separating server availability, network reachability and authentication. Record the exact error and whether it appears before or after the credential prompt; each points to a different stage of the connection.
IN THIS ARTICLE
01 Check the server and network
- Use the provider console to confirm Windows is running and responsive. If the console shows a boot failure or a frozen system, investigate that condition before changing RDP rules.
- Verify the hostname resolves to the intended server. Compare it with the approved management address, especially after migration or a DNS change.
- From the permitted management computer, test the actual RDP TCP port. For the default port, the example is
Test-NetConnection -ComputerName server.example.com -Port 3389. Replace the hostname and port with the real values. - If
TcpTestSucceededis false, inspect the route, VPN or gateway, provider firewall and Windows Firewall scope. A failed ping alone does not establish that RDP is unavailable. - Through the console, run
qwinstaand look for therdp-tcplistener in theListenstate. Check that Remote Desktop is enabled and inspect the Remote Desktop Services service.
02 Investigate authentication separately
If the TCP connection works but sign-in fails, verify the account name, password, permitted remote users and relevant policy. For a domain account, check domain-controller reachability, DNS and time synchronisation. Group Policy can override a local setting, so investigate the effective policy instead of repeatedly toggling the same control.
Preserve the exact authentication or certificate message. Avoid disabling Network Level Authentication, all firewall profiles or endpoint protection as a general troubleshooting sequence. Make a targeted correction supported by the observed failure.
03 Verify the correction
Open a new RDP session from the normal management route and confirm the intended account can work. Record the cause and remove any temporary diagnostic access. If escalation is needed, provide the timestamp, target, listener state and redacted connection result.
04 Example: test the RDP TCP path from the client computer
On the Windows workstation that cannot connect, run this PowerShell test using the approved server hostname and RDP port. The sample uses the common default port 3389. It tests connectivity and does not change firewall rules or submit a Windows password.
Test-NetConnection -ComputerName server.example.com -Port 3389 -InformationLevel DetailedRead the result: Read TcpTestSucceeded and confirm the RemoteAddress is the intended destination. A successful TCP test establishes a connection to that port, not permission to log in through RDP. A failed test can involve DNS, routing, the provider firewall, Windows Firewall or a stopped listener.
If the TCP path works, investigate the precise RDP error, Network Level Authentication, account rights and server events. If it fails, use the authorised console to inspect the server. Do not expose RDP to every address as a shortcut when your design requires a VPN, bastion or source restriction.
Common questions
Does a successful TCP test prove that RDP sign-in will work?
No. It establishes a connection to that port. Authentication, policy, certificate and session problems can still prevent a usable desktop.
Should I restart the whole server first?
Collect the failure evidence and assess active workloads. A restart can interrupt services and erase useful transient information without resolving the underlying cause.