How to solve the problem where Windows Remote Desktop prompts "Unable to connect to the remote computer due to the following reasons"?

SoraShiro 0 Reputation points
2026-04-05T10:21:49.3666667+00:00

When I used the Windows Remote Desktop application on my personal laptop running Windows 10 Home Edition to connect to a server running Windows Server 2022 remotely, after filling in the IP address and username, clicking on Connect would pop up this prompt box.User's image

I have tried changing both IPv4 and IPv6 addresses, but to no avail. Moreover, I have the username and password for the controlled computer.

Personal issue check attempt:

I checked the firewall settings, group policies, Internet settings, proxy settings, remote desktop switch, computer service settings and remote desktop port listening of the controlled computer's remote connection based on the retrieved internet information. All of these were normal. At the same time, I also tried to connect to the server using another personal computer running Windows 11 Professional Edition, but it was also ineffective.

I was able to successfully control my Windows 11 personal computer via the notebook, which proves that my notebook supports remote control of other computers. The remote-controlled computer was confirmed to be in an active state and had a normal network connection.

The key point is that I can access the server normally by using a Windows APP on the iPad with the same configuration information. Therefore, I believe the configuration information I have is correct and sufficient to enable remote desktop access. At the same time, it is well known that the Windows version of the Windows APP currently does not have the remote desktop function, so I cannot use this software to achieve remote control on the laptop.

The help we hope to receive:

I hope that those who have encountered similar situations before and managed to solve them could share some of their solutions. Or if there are any friends who have relevant tutorial files, configuration manuals, or common problem solutions related to MSTSC, please send them to me for me to check which part still has issues. Thank you.

Windows for business | Windows Server | User experience | Remote desktop clients
0 comments

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-04-05T10:22:28.0366667+00:00

    Based on the error dialog, the issue matches the generic “Remote Desktop can't connect to the remote computer for one of these reasons” problem. The context shows that the most common root causes are:

    • The RDP‑TCP listener on the server isn’t working
    • Network/firewall/port 3389 issues
    • Misconfiguration of Remote Desktop roles, certificates, or services

    A focused troubleshooting path on the Windows Server 2022 side is:

    1. Confirm the server is running and reachable
      Since the iPad client connects successfully, the server is powered on and reachable over the internet/VPN. That points away from power/state issues and toward listener or Windows‑client/network differences.
    2. Verify the RDP‑TCP listener on the server On the server, open an elevated Command Prompt and run: 
         qwinsta
      Ensure there is a line like: 
         rdp-tcp              65536  Listen
      If rdp-tcp is not in Listen state, follow these checks on the server:
      • Registry:
        • HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp → fEnableWinStation = 1
        • HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server → fDenyTSConnections = 0
        • If present, HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services → fDenyTSConnections = 0
      • Services: make sure these are running:
        • Remote Desktop Services (TermService)
        • Remote Desktop Services UserMode Port Redirector (UmRdpService) If changes are made, restart Remote Desktop Services.
    3. Test from the server itself (loopback) On the server console (or out‑of‑band console like iLO/Hyper‑V):
      1. Press Win + R, type mstsc, press Enter.
      2. In Computer, enter localhost and connect.
      • If this fails with the same error, the problem is on the server (listener/configuration). Continue with steps 2 and 5–6 below.
      • If this succeeds, the listener is healthy and the problem is network/firewall/DNS between the Windows PCs and the server.
    4. Check network connectivity and port 3389 from a Windows PC From a Windows 10/11 machine in the same network path as the iPad (same LAN or same VPN), open elevated PowerShell and run: 
         Test-NetConnection -ComputerName <server-ip-or-dns> -Port 3389 -InformationLevel Detailed
      • If TcpTestSucceeded = True, connectivity to port 3389 is fine; go to step 6.
      • If TcpTestSucceeded = False, there is a network or firewall issue; go to step 5.
    5. Firewall / NSG / security device checks On the server:
      • Open wf.msc → Inbound Rules and confirm these rules are enabled for all profiles:
        • Remote Desktop - User Mode (TCP-In)
        • Remote Desktop - User Mode (UDP-In)
      • Or in elevated PowerShell: 
             Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled True
      • If testing requires, temporarily disable Windows Firewall (be aware this is risky on internet‑facing servers): 
             Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
      If the server is in Azure or behind another firewall/VPN appliance, ensure that device allows inbound TCP 3389 from the Windows PCs’ source addresses. The fact that iPad RDP works but Windows MSTSC does not may indicate different paths or policies for those devices.
    6. Confirm the RDP port and port ownership On the server, verify the RDP port in the registry:
      • HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp → PortNumber should be 0x00000d3d (3389).
      • If a non‑default port is configured, the Windows clients must connect as server:port.
      Also confirm that TermService owns that port: 
         tasklist /svc | findstr TermService
   netstat -anob | findstr 3389
      The PID for TermService must match the PID listening on 3389. If another process is using 3389, stop that process and restart Remote Desktop Services.
    7. Check Remote Desktop certificate and roles on the server If the listener and network are fine but Windows clients still fail while iPad works, check for server‑side RDS configuration issues:
      • In the Certificates MMC (Computer account → Local computer → Remote Desktop), delete the RDP self‑signed certificate and restart Remote Desktop Services so it is re‑created.
      • In Server Manager → Manage → Remove Roles and Features → Server Roles → Remote Desktop Services, remove any unnecessary RDS roles (for example, Connection Broker) that are not part of a full RDS deployment, then restart the server.
    8. If all checks pass but MSTSC still fails The context recommends contacting Microsoft Support if:
      • The RDP‑TCP listener is working
      • Test-NetConnection to the server on 3389 succeeds
      • And the issue persists
      In that case, provide Support with:
      • qwinsta output
      • Test-NetConnection output from a failing Windows client
      • netstat -anob and tasklist /svc output from the server

    Following these steps isolates whether the failure is due to the server’s RDP listener, network/firewall, or an RDS configuration issue, and aligns with the documented troubleshooting flow for this exact error.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Domic Vo 32,220 Reputation points Independent Advisor
    2026-04-05T11:00:33.9333333+00:00

    Hello,

    From what you’ve described, the fact that you can connect to the Windows Server 2022 instance from your iPad but not from either of your Windows laptops points to a client‑side issue with MSTSC (the native Remote Desktop client) rather than a server configuration problem. Since you’ve already confirmed that RDP is enabled, the firewall is open, and the server is listening on TCP/3389, the next step is to focus on the Windows client stack.

    On Windows 10 Home, note that while you cannot host RDP sessions, you can still use MSTSC to connect to remote servers. The failure you’re seeing is usually tied to one of two things: TLS negotiation or credential format. Windows Server 2022 enforces NLA (Network Level Authentication) by default. If your MSTSC client is outdated or if CredSSP policies are misaligned, the connection will fail even though the credentials are correct. Make sure your Windows 10 Home and Windows 11 Pro machines are fully patched, especially with the latest Remote Desktop client updates. Then, when entering credentials, use the format DOMAIN\username or server-ip\localuser depending on whether the account is domain‑joined or local. If you’re using a local account on the server, the correct format is .\username.

    Another common cause is certificate validation. The iPad client ignores certain certificate warnings, but MSTSC enforces them. If the server’s RDP certificate is self‑signed, MSTSC may reject the connection. You can test this by running mstsc /admin /v:server-ip and seeing if you get a certificate prompt. If so, accept the certificate or install a proper one via Group Policy under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

    Finally, check the server’s Group Policy for RDP security settings. If “Require use of specific security layer for remote (RDP) connections” is set to SSL (TLS), try switching it to “Negotiate” so the client can fall back to RDP security if TLS fails. This is under gpedit.msc at Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Security.

    In short, the server is fine since the iPad connects. The Windows clients are failing due to NLA/TLS or credential formatting. Updating the MSTSC client, verifying the credential syntax, and adjusting the RDP security layer should resolve the issue.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.