Share via

Troubleshooting RDP Error 0x50331670: Persistent connection block for remote contractor

Advait Mohammad 20 Reputation points
2026-03-16T08:55:34.14+00:00

Hi all! I'm trying to get an external contractor into our environment to run a specific app but we are completly blocked. The guy is trying to dial in from his corporate Win 10 machine, but it flat out refuses to establish the session, throwing Error Code 0x50331670 every single time. I already proved it's not a password issue because I logged in fine with his account from my desk. We even swapped out the built-in remote desktop client for the newest Microsoft RDP app from the store, but no luck. Since he cant test from home or another laptop right now, I'm heavily leaning toward his local office firewall or some restrictive group policy blocking the outbound connection. Has anyone dealt with this specific 0x50331670 block before?

Windows for business | Windows Client for IT Pros | User experience | Remote desktop services and terminal services
0 comments
Answer accepted by question author
  1. Jason Nguyen Tran 15,510 Reputation points Independent Advisor
    2026-03-16T09:40:11.37+00:00

    Hi Advait Mohammad,

    Error 0x50331670 usually indicates that the connection attempt is being blocked before the session can even initialize, and since you’ve confirmed credentials are fine, the focus should shift to the contractor’s local environment. In many cases, restrictive outbound firewall rules or corporate group policies prevent RDP traffic from leaving the machine. If his company enforces outbound filtering, the RDP client may never reach your gateway.

    One way to confirm this is to have the contractor run a simple telnet or PowerShell test to your RDP host on port 3389. If the connection fails immediately, that points to a local block. Another angle is to check whether his corporate VPN or endpoint security software is interfering, some vendors explicitly disable RDP connections for security reasons. If possible, ask him to test from a different network segment or temporarily bypass his corporate VPN to see if the behavior changes.

    On your side, it’s worth confirming that your RDP gateway and firewall are allowing external connections and that no conditional access policies are rejecting his device. Since you were able to log in with his account locally, the account itself is not the issue. This really narrows it down to his client environment.

    I hope the response provided some helpful insight. If it clarified the issue for you, please consider marking it as Accept Answer so others with the same issue can find the solution.

    Jason.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

  2. Q&A Assist
    2026-03-16T08:55:53.8166667+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Error 0x50331670 on RDP is consistent with the client being unable to establish a working RDP session at all, which aligns with a local firewall, network security device, or endpoint security policy blocking outbound RDP traffic from the contractor’s machine or network.

    Since the same user account works from inside the environment, the issue is almost certainly on the contractor’s side (client/network), not with credentials or the target host.

    Based on the available guidance, the following checks are relevant:

    1. Verify that the RDP listener and server side are healthy
      • Because sign-in with the same account from an internal machine already works, the RDP-TCP listener and server configuration are effectively validated. The server’s RDP port (default 3389) is listening and accepting connections.
      • If needed, RDP connectivity can be validated from another machine in the same network using: 
             Test-NetConnection -ComputerName <server-name-or-ip> -Port 3389 -InformationLevel Detailed
        If TcpTestSucceeded is True, there are no server-side connectivity issues and focus should remain on the contractor’s client/network.
    2. Focus on network/firewall restrictions on the contractor side From the server perspective, when the RDP listener is working but a specific client cannot connect, the next steps are to investigate network and firewall elements between that client and the server:
      • Engage the contractor’s network/IT team to verify that outbound TCP 3389 (or the custom RDP port, if changed) is allowed from the contractor’s corporate network.
      • Ask them to check any corporate firewalls, proxies, or security appliances for blocked RDP traffic to the server’s public IP and port.
      • If possible, have them run an equivalent of Test-NetConnection or another TCP connectivity test from their network to the server’s IP and port to confirm whether TCP 3389 is reachable.
    3. Confirm the server’s RDP port and DNS
      • On the server, confirm that the default RDP port is still 3389:
        • In Registry Editor, check: Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp and verify that PortNumber is 0x00000d3d (3389).
      • If the port is non‑standard, ensure the contractor is connecting with hostname:port or IP:port.
      • If DNS is in play and the contractor is using a hostname, have them test with the raw IP address instead, in case their corporate DNS resolution is misconfigured.
    4. Rule out server-side Windows Firewall only as a sanity check
      • Since internal clients can connect, the Windows Firewall on the server is already allowing RDP. For completeness, ensure the inbound rules are enabled:
        • Open wf.msc on the server and confirm that Remote Desktop - User Mode (TCP-In) and Remote Desktop - User Mode (UDP-In) are enabled for all profiles.
        • Alternatively, run on the server in an elevated PowerShell session: 
                 Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Set-NetFirewallRule -Enabled True
      • If other network elements (for example, Azure NSGs, on-prem firewalls, or VPN devices) sit in front of the server, verify that they allow inbound RDP from the contractor’s public IP range.
    5. Consider endpoint security/AV on the contractor’s device
      • Corporate endpoint protection can block or inspect RDP traffic and cause connection failures before the session is fully established.
      • The contractor’s IT should check whether any endpoint security, VPN client, or DLP/inspection tool is blocking or interfering with outbound RDP.
    6. If all server-side checks pass, treat it as a client/corporate-policy issue
      • With the server confirmed reachable from other clients and the account verified, the remaining path is for the contractor’s corporate IT to:
        • Confirm outbound TCP 3389 is permitted to the server’s IP.
        • Review firewall/proxy logs for denied connections.
        • Temporarily test from a less‑restricted network (if/when they can) to prove the issue is their corporate network.

    In summary, the environment and account are functioning correctly; the persistent 0x50331670 for a single external contractor strongly indicates that the contractor’s corporate firewall or security policy is blocking outbound RDP, and resolution requires changes on their side.

    References:

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.