Fixing an RDP error: This computer can’t connect to the remote computer

9K

An attempt to establish a Remote Desktop connection to a remote computer using the built-in Windows RDP client (mstsc.exe) may fail with an error.

This computer can’t connect to the remote computer.
Try connecting again. If the problem continues, contact the owner of the remote computer or your network administrator.

An RDP connection to a remote computer on Windows can fail for many reasons. This guide covers the most common ways to fix an RDP connection error This computer can’t connect to the remote computer on Windows 10/11 and on Windows Server hosts with a Remote Desktop Services (RDS) role deployed.

Quick Fixes for RDP Connection Errors

Start with the simplest solutions:

Connect Using IP Address Instead of DNS Name

Try to establish a connection to the remote computer by using an IP address instead of a DNS name.

Clear DNS Resolver Cache

Clear the DNS resolver cache on the client using the command:

ipconfig /flushdns

Restart Remote Desktop Host

Try connecting again a little later (if the TermService service is busy), or to reboot the Remote Desktop host.

Common Causes of RDP Errors

If these steps don’t help, check the following causes that may prevent you from connecting to the remote computer over RDP.

• Network connectivity issues;
• Firewall restrictions;
• Incorrect settings on the RD host;
• RDS licensing issues (grace period expired/license server unavailable)

Checking Network Connectivity to Remote Desktop Host

Test RDP Port Using PowerShell

Check that you are able to access the remote computer over the network and that the RDP port (TCP 3389) is responding. Check connectivity to the RDP host using PowerShell:

Test-NetConnection rdp_server_name1 -Port 3389

Note that RDP also uses UDP 3389 port (performance and fallback transport). In case TCP 3389 is open but RDP still fails or is unstable, you need to also verify if UDP transport is available for RDP (note that native PowerShell does not provide a simple built-in method to test UDP 3389 availability). You can do this using Windows built-in tracing (you need to run this command from an elevated command prompt):

netsh trace start capture=yes scenario=RemoteDesktop tracefile=c:\rdp.etl

Reproduce the RDP connection, and then stop tracing:

netsh trace stop

You can check UDP usage in RDP logs under Event Viewer → Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices-RdpCoreTS → Operational.

Note. Keep in mind that Test-NetConnection only tests TCP connectivity. You can’t test UDP 3389 with this cmdlet. To test the port, you should use a network capture tool (Wireshark/NetMon)/verify through RDP Shortpath logs.

In case UDP is blocked, RDP will fall back to TCP only. This may cause slow session performance/intermittent connection failures.

Note that UDP is only used after successful negotiation and may not be present in all sessions (e.g., Gateway, policy restrictions, NAT environments).

If Test-NetConnection command returns False, then the RDP port on the server isn’t responding, it may be blocked by a firewall, or it may not be listened to by the remote host. It is also possible that the remote computer is simply switched off or is in a sleep mode.

Note that RDP traffic may also be tunneled over HTTPS (TCP 443) when using RD Gateway. In case it’s your scenario, note that port 3389 is not directly exposed to the client.

Validating Remote Host Configuration

Check the Remote Desktop configuration on the remote host:

Enable RDP on the Remote Host

Make sure that RDP is enabled on the remote host. You can remotely enable RDP on a Windows computer by changing the fDenyTSConnections value in the registry.

Check Required Windows Services

Check that the following services are running on both the local client computer and the remote (target) computer: Remote Desktop Services (TermService) and Remote Desktop Services UserMode Port Redirector (UmRdpService).

Diagnosing RDS Licensing Problems

Keep in mind that in Remote Desktop Services (RDS) environments, RDP connections may fail in case the licensing grace period has expired (or the RD Session Host cannot contact a valid RD Licensing server).

Common symptoms include:

• Users cannot start new RDP sessions;
• RemoteApp connections fail;
• RDP disconnects immediately after authentication;

You may also encounter such errors:

• “The remote session was disconnected because there are no Remote Desktop License Servers available”
• “The remote computer disconnected the session because of an error in the licensing protocol”

You need to use the RD Licensing Diagnoser tool to check the licensing config:

lsdiag.msc

You should check the following:

• RD Licensing server is activated;
• RDS CALs are installed;
• Licensing mode matches your deployment (Per User/Per Device);
• RD Session Host can contact the license server.

You should also check the Event Viewer logs by navigating to Applications and Services Logs > Microsoft > Windows > TerminalServices-Licensing;
and
Applications and Services Logs > Microsoft > Windows > TerminalServices-RemoteConnectionManager.

Here are common RDS licensing-related Event IDs:

Event ID	Description
1128	RD Licensing grace period expired
4105	License server unavailable
4106	Licensing mode mismatch
44	RDS licensing configuration problem

You can check the current RDS licensing config using PowerShell:

Get-CimInstance -Namespace "Root\CIMV2\TerminalServices" -ClassName Win32_TerminalServiceSetting

We recommend you using Get-CimInstance in modern Windows environments because it uses WSMan-based remoting, is more secure, and better supported in PowerShell 7+.

Verify RDP Port and Firewall Settings

Check that Remote Desktop Services is listening on the default TCP port 3389 and that the default RDP port has not been changed. Use the Invoke-Command command to check the RDP port on a remote host:

Invoke-Command -ComputerName computername1 {Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" -Name PortNumber | Select-Object PortNumber}

If a non-standard port number is configured, specify the RD host address and port in the client as follows:

rdp_server_name1:3320

Verify Firewall Rules for Active Network Profile

Now check your network connection profile. Note that on Public network profiles, Windows Firewall may block inbound RDP connections unless the Remote Desktop firewall rule is enabled for Public networks.

You should verify if the built-in Remote Desktop firewall rule is enabled for the active network profile, or temporarily switch the network location to Private for testing purposes. You can do that from the Control Panel (Settings > Network & Internet > Status > Network status > Change connection properties) or using Powershell command:

Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

You need to ensure the rule is enabled for the active network profile (Domain/Private/Public).

If you use a third-party firewall or antivirus, make sure it does not block incoming RDP connections. You can temporarily disable your antivirus software.

Adjusting Remote Desktop Security Layer Settings for Legacy RDP Clients

In some cases, RDP connection issues may be related to security layer/authentication compatibility problems between the client and server (for example, older clients without modern TLS/NLA requirements). You might get a ‘This computer can’t connect to the remote computer‘ error when you try to connect from a computer running an earlier version of Windows (for example, Windows 7 or 8.1) to a host running a newer Windows 10/11 build. In this case, you can change the security level of Remote Desktop from the default Negotiate to a less secure RDP layer.

In modern Windows OSs like Windows 10/11 and Windows Server 2016+, RDP uses:

• TCP 3389 for control channel (TLS protected)
• Optional UDP 3389 for transport optimization (RDP Shortpath/performance improvements)
• CredSSP for authentication (NLA)

In case you will lower the security layer to “RDP”, it disables TLS and this method should not be used as a permanent solution (this leads to security risks and we recommend you to use it only for compatibility with older clients).

Warning. You should lower RDP security settings only temporarily (for troubleshooting legacy clients). Note that you should not permanently disable TLS, NLA/strong encryption in production environments.

1. Open the local GPO editor and navigate to Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security;
2. You can force the RDP Security Layer to test compatibility with legacy clients as a temporary troubleshooting step. Enable the policy Require use of specific security layer for remote (RDP) connections and select RDP. If this fixes the issue, it indicates a problem with TLS/NLA config or client compatibility. In such case, to secure communications between the client and RD Session Host server less secure native RDP encryption will be used. Once finished, don’t forget to revert this setting back to Negotiate or SSL and properly troubleshoot the root cause (TLS certificates, CredSSP configuration, or client version compatibility). Note that this disables TLS and should be used only for isolation testing of TLS/NLA issues.

   

3. Then enable the policy Set client connection encryption level. In the Encryption level drop-down box, select Client compatible. In such case RDP clients that don’t support 128-bit encryption will be allowed to establish RDP connections to the host. Setting the encryption level to Client compatible may allow older clients to connect, but reduces security. Use this option with caution and only for testing.

   

Save the changes, update the local GPO settings using the “gpupdate /force” command, and restart the Remote Desktop Services:

net stop TermService && net start TermService

Fixing RemoteApp Error: Can’t Connect to the Remote Computer

In some cases, you may receive an error when connecting to an RDS host through a Remote Desktop Gateway running Windows Server 2012/2012R2:

RemoteApp Disconnected

Your computer can’t connect to the remote computer because an error occurred on the remote computer that you want to connect to. Contact your network administrator for assistance.

Note that modern RDP uses multiple transports:

• TCP 3389 — main control channel (authentication, session setup, core RDP data)
• UDP 3389 — optional transport for performance (graphics, latency optimization, RDP UDP/Shortpath)
• RD Gateway (if used) — tunnels RDP over HTTPS (TCP 443) for secure external access

UDP is negotiated independently and may be used even when RD Gateway tunnels traffic over HTTPS.

Note. UDP transport is independent of RD Gateway. Even with Gateway, you can still use UDP if supported by the client, policy, and network conditions.

Force RPC/HTTP Protocol for RemoteApp

1. Open the Registry Editor on the client (regedit.exe);
2. Go to the registry key HKEY_CURRENT_USER\ Software\ Microsoft\ Terminal Server Client;
3. Create a DWORD parameter with the name RDGClientTransport and the value 1 (Value 0 means HTTP/UDP transport (default), Value 1 means RPC over HTTP transport;
4. Restart the computer.

You can create this registry parameter with the command:

reg.exe add "HKCU\Software\Microsoft\Terminal Server Client" /v "RDGClientTransport" /t REG_DWORD /d "1"

When the client is connecting through an RD Gateway, the Transport parameter forces the client to use RPC over HTTP transport (instead of the default HTTP/UDP used by modern RDP clients). Note that this setting affects the transport protocol used by Remote Desktop Gateway, it is not related to RDP security layer (TLS or RDP encryption).

Note. RDP clients prefer HTTP/UDP transport, it gives better performance. You should force RPC/HTTP only for compatibility or troubleshooting tasks, and may reduce performance.

If the above solution didn’t fix the RDP connection error, try to change the collection settings on the RDSH server side. Open properties of your problematic application collection, go to the Security tab, and uncheck the option “Allow connections only from computers running Remote Desktop with Network Level Authentication”.

If the RemoteApp Disconnected error occurs on only a single not-domain joined computer, it is possible, that the different LAN Manager/NTLM policy settings are used on the RDSH host and the client computer. Often, this can cause authentication problems.

Update LAN Manager and NTLM Settings

Now check current Network Security: LAN Manager authentication level policy settings on the RDSH server using either gpresult or RSOP. In order to generate an HTML report with applied Group Policy settings, run the following command:

gpresult /h c:\tmp\gpreport.html

In order to display applied Group Policy settings directly in the console, use the command below:

gpresult /r

Make sure that both client and server are configured to use secure authentication protocols (recommended configuration is NTLMv2 only or Kerberos). Note that you shouldn’t downgrade security settings (such as enabling LM or NTLMv1) to resolve compatibility problems.

1. Open the local GPO editor (gpedit.msc);
2. Go to the GPO section above;
3. Verify that the policy Network Security: LAN Manager authentication level is set to Send NTLMv2 response only on both client and server;

   

4. Update the policies on the client with the gpupdate command;
5. Check your RemoteApp connection.

If authentication fails, investigate the following, but do not lower authentication security:

• Time sync (Kerberos dependency)
• SPN config
• Domain trust issues

Configure EnforceChannelBinding on RD Gateway

You should enforce Channel Binding Token validation on RD Gateway (it is recommended for security):

reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\TerminalServerGateway\Config\Core" /v EnforceChannelBinding /t REG_DWORD /d 1 /f

Note that this setting enforces Channel Binding Token validation on the RD Gateway, this helps to protect from man-in-the-middle attacks.

Reboot the RDGW host to apply the changes.

Resolving RDP Gateway Connection Issues

There is another bug related to Remote Desktop Gateway which is used to deliver RemoteApps to users:

RemoteApp Disconnected.

Your computer can’t connect to the remote computer because the Remote Desktop Gateway server address is unreachable or incorrect. Type a valid Remote Desktop Gateway server address.

This error can also look like this:

Your computer can’t connect to the remote computer because the Remote Desktop Gateway server is temporarily unavailable. Try reconnecting later or contact your network administrator for assistance.

If you are facing one of the errors above, then, most likely, the problem is that your computer can’t resolve the public FQDN name of your Remote Desktop Gateway server. In most cases in real life, the public name of the RDGW doesn’t match the hostname.

Fixing the problem

1. Open the Internet Information Services (IIS) Manager (Inetmgr.exe) console on the RD Gateway host;
2. Go to the Sites > Default Website > RDWeb > Pages > Application Settings;
3. In the DefaultTSGateway field, enter the server’s FQDN public name of your RD Gateway server, and then restart the web services with the command:
   

   iisreset

4. Also, check your RDGW certificate. You can find your SSL certificate info by going to Server Manager > Remote Desktop Services > Collections > Your_Collection > Tasks > Edit Deployment Properties > Certificates > RD Gateway > View Details. Check the certificate expiration date.
   

   

5. Go back to your client’s machine, and try to start a new RDP session.

Other RDP Error Codes and Solutions

This section lists other common RDP connection errors that can cause the “This computer can’t connect to the remote computer” error.

Error 0x904 – Network or VPN Issues

Error Code: 0x904, Extended Error Code: 0x7 – this error usually indicates transport-level connectivity problems, VPN instability, packet loss, or interrupted secure channel negotiation.

Error 0x108 – RDS Host Timeout

The two computers couldn’t connect in the amount of time allotted, Error code: 0x108 Extended error code: 0x0 – just restart the RDS host to quickly resolve the problem (in case the error recurs, check the RDS host for resource exhaustion (CPU, memory, session limits) before restarting). Disable the use of the UDP protocol for RDP connections if the problem occurs frequently. Create the registry parameter fClientDisableUDP on the RD host by using the command (note that you should disable UDP only for troubleshooting unstable WAN/VPN environments):

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP /d 1 /t REG_DWORD

Or using GPO (Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn off UDP on Client = Enabled).

Error 0xc07 – User Account Restrictions

Error code: 0xc07 – User Account Restriction is preventing you from logging on. If the local user does not have a password set (blank password), the Remote Desktop Host will reject the connection. This is the default behavior configured by the local security policy “Accounts: Local accounts with blank passwords only allow console logins“.

RDP Cannot Find the Remote Computer

Remote Desktop can’t find the computer“computer_name”. This might mean that ” computer_name ” does not belong to the specified network – means that your computer cannot resolve the target host name.

This error occurs when the client cannot resolve the remote computer name through DNS. To fix it follow the steps:

• Check DNS resolution:

  nslookup computer_name

  If DNS resolution works incorrectly, you can specify the DNS server manually to verify whether the issue is related to the configured DNS servers on the client:

  nslookup computer_name dns_server_ip
  
  # Example below
  nslookup rdpserver01 10.0.0.10

• Flush DNS cache:

  ipconfig /flushdns

• Try connecting by IP address instead:

  mstsc /v:192.168.1.100

In case the machine is in a domain, you need to verify if the DNS suffix is configured correctly on the client.

Frequently asked questions