Windows Server RDP Connection Refused: Causes and Fixes

Overview

RDP refused errors happen when your Remote Desktop client can’t establish a connection to port 3389 on your Windows Server. The error usually shows as “Your computer can’t connect to the remote computer” or simply times out without explanation. This is one of the most common issues on Windows VPS and dedicated server environments, and the official Microsoft docs aren’t great at explaining root causes.

The most likely culprits are: the Remote Desktop service isn’t running, a firewall (local or cloud-level) is blocking port 3389, or RDP has been disabled entirely on the server. Less obvious causes include NLA (Network Level Authentication) mismatches and certificate errors that silently kill the handshake before you even see a login prompt.

This article covers every common scenario in order of likelihood. Start from Step 1 and work through it — don’t jump ahead unless you have a specific reason to believe it’s a firewall issue.

Prerequisites

• A Windows Server instance (2016, 2019, or 2022) — steps below are consistent across all three
• Administrator credentials for the server
• An alternate way to access the server if RDP is completely down — this means console access (VNC, KVM, or your hosting provider’s out-of-band console). At Host & Tech, you can access this directly through the client portal for VPS and Dedicated Servers
• The server’s public IP address
• Basic familiarity with Windows PowerShell or Command Prompt

Step-by-Step Fixes

Step 1: Verify RDP is Actually Enabled on the Server

This sounds obvious, but RDP is disabled by default on fresh Windows Server installs, and it sometimes gets turned off after Windows Updates or Group Policy changes. If you have console access, check this first.

Open PowerShell as Administrator and run:

Get-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' -Name "fDenyTSConnections"

If the value returned is 1, RDP is disabled. Fix it with:

# Enable RDP
Set-ItemProperty -Path 'HKLM:SystemCurrentControlSetControlTerminal Server' -Name "fDenyTSConnections" -Value 0

# Allow RDP through Windows Firewall
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Confirm the Remote Desktop service is running
Set-Service -Name TermService -StartupType Automatic
Start-Service -Name TermService

After running this, try connecting again before moving to the next step.

Step 2: Check the Remote Desktop Services (TermService) Status

Even with RDP enabled in the registry, the TermService (Remote Desktop Services) process can crash or fail to start. This is more common than people expect, especially after unclean reboots.

# Check service status
Get-Service -Name TermService

# If it shows Stopped, start it
Start-Service -Name TermService

If the service fails to start and throws an error code, check the Windows Event Viewer: Event Viewer > Windows Logs > System. Filter by Source = TermService. Error 1067 (process terminated unexpectedly) often points to a corrupted RDS role installation.

Step 3: Check the Windows Firewall

Windows Firewall can block port 3389 even when RDP is technically enabled. Run this to confirm the rule exists and is active:

Get-NetFirewallRule -DisplayName "Remote Desktop*" | Select DisplayName, Enabled, Direction, Action

You should see rules for both TCP and UDP on port 3389 with Enabled: True and Action: Allow. If they’re missing or disabled:

# Re-enable the built-in RDP firewall rules
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Or manually add a rule if the built-in ones are gone
New-NetFirewallRule -DisplayName "Allow RDP" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow

Step 4: Check Your Cloud or Network-Level Firewall

This is the one people miss most often. Your Windows Firewall might be wide open, but if your hosting provider’s network firewall (sometimes called a Security Group, Firewall Policy, or ACL) is blocking port 3389, you’ll never get through.

Log into your Host & Tech client portal and review the firewall rules attached to your server. Make sure there’s an inbound rule allowing TCP port 3389 from your IP address (or from any, if you’re troubleshooting and want to confirm this is the issue).

📝 Note: If you’re on a shared or office network, your ISP or corporate firewall may also block outbound port 3389. Test from a different connection (mobile hotspot works) to rule this out.

Step 5: Confirm the Correct Port and IP

Some administrators change the RDP port from the default 3389 to something else as a basic security measure. If that’s been done on your server and you’re still using 3389, you’ll get a refused connection every time.

Check the actual listening port from console access:

# Shows what port RDP is actually listening on
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp' -Name PortNumber

If it’s not 3389, use the custom port in your RDP client: your.server.ip:PORT

Also confirm the server is actually reachable from outside. From your local machine:

Test-NetConnection -ComputerName YOUR_SERVER_IP -Port 3389

If TcpTestSucceeded returns False, the port is blocked or the service isn’t listening. If it returns True but RDP still fails, the problem is at the application layer (NLA, certificates, or licensing — see below).

Step 6: Check for NLA Mismatch

Network Level Authentication (NLA) requires the connecting client to authenticate before a full RDP session is established. If NLA is enabled on the server but your client doesn’t support it — or if there’s a credential mismatch — you’ll get a refused or immediately dropped connection with a vague error message.

To temporarily disable NLA for testing (re-enable it after):

# Disable NLA
(Get-WmiObject -Class Win32_TSGeneralSetting -Namespace rootcimv2terminalservices -Filter "TerminalName='RDP-Tcp'").SetUserAuthenticationRequired(0)

⚠ Warning: Disabling NLA reduces security. Only do this temporarily to isolate the issue, then re-enable it with SetUserAuthenticationRequired(1) once you’ve confirmed the connection works.

Common Issues & Troubleshooting

“Remote Desktop can’t connect to the remote computer” with no further detail

Cause: This generic message usually means the TCP connection to port 3389 failed outright — the server never responded. The firewall (Windows or network-level) is the most common reason.

Fix: Run Test-NetConnection -ComputerName YOUR_IP -Port 3389 from your local machine. If it fails, work through Steps 3 and 4 above. Check both the Windows Firewall and your hosting control panel’s network firewall rules.

RDP connects but immediately disconnects

Cause: Usually a Remote Desktop Licensing issue. Windows Server requires valid RD Licensing after the 120-day grace period. When the grace period expires or the license server can’t be reached, RDP sessions are terminated immediately after login.

Fix: Check the licensing grace period status:

Get-WmiObject -Namespace root/CIMV2 -Class Win32_TSLicenseServer | Select GracePeriodDays

If this is a VPS you’re using for personal remote access (not a multi-user environment), you may just need a single RDS CAL or you can connect using the built-in administrator account, which is exempt from licensing restrictions.

“The remote computer requires Network Level Authentication” error

Cause: Your RDP client is older and doesn’t support NLA, or you’re connecting without cached credentials that match what the server expects.

Fix: Update your Remote Desktop client (mstsc.exe version 10 or later, or the Microsoft Remote Desktop app from the Microsoft Store). Alternatively, disable NLA on the server temporarily as shown in Step 6 to confirm this is the issue, then configure credentials properly before re-enabling it.

RDP was working yesterday and stopped after a Windows Update

Cause: Certain cumulative updates have been known to reset firewall rules or disable the TermService. This is annoyingly common and not well-documented in the update changelogs.

Fix: Use console access to check the TermService status and firewall rules (Steps 2 and 3). Also check Event Viewer > Windows Logs > System around the time of the last update for any service-related errors. If an update broke something specific, Microsoft’s support forums and Patchday posts on relevant subreddits often document it faster than official channels.

Port 3389 shows as open but RDP client says connection was refused

Cause: The port is open at the network level, but RDP itself is rejecting the session — often due to a certificate error, a full session limit (default is 2 concurrent sessions on Windows Server without an RDS role), or a corrupted RDP listener.

Fix: Check concurrent session limits and reset the RDP listener:

# Check active sessions
query session

# Log off a hung session (replace ID with the session number from above)
logoff SESSION_ID

# Reset the RDP listener if sessions look fine
netsh interface show interface
sc stop TermService
sc start TermService

FAQ