Fix ERROR_RM_DISCONNECTED (0x00001AA3) on Remote Desktop

When This Error Hits

You're on a Windows 10 or 11 client, connecting to a Remote Desktop Services farm running on Server 2019 or 2022. You type your credentials, hit Connect, and after a brief loading spinner, get booted back to the login screen. The client shows error ERROR_RM_DISCONNECTED (0x00001AA3). No desktop ever appeared.

This error is specific to environments using RD Connection Broker (RDCB) to redirect sessions to one of several session hosts. It's not a generic network drop—it's the broker telling the client it lost contact with the session host after the initial handshake.

Root Cause

What's actually happening here is the RDCB successfully received your connection request, picked a session host, and forwarded you there. But the session host never acknowledged the handoff back to the broker. The broker waits a few seconds, then fires ERROR_RM_DISCONNECTED and kills the connection.

The usual suspects causing this:

• DNS mismatches — the session host's FQDN in the RDCB farm doesn't match what the host thinks its name is. The broker sends the client to an IP, but the session host rejects the redirect because it doesn't recognize the name.
• Firewall rules blocking RPC traffic — the broker talks to session hosts over RPC (ports 135, 49152–65535). If a third-party firewall or Windows Defender Firewall profile changed, that traffic gets dropped.
• Broken RD Licensing — if the session host can't get a valid license, it refuses to complete the connection. The broker sees no response and throws the error.
• Load balancer timeout — in farms with a hardware load balancer, the session host might take longer than the balancer's timeout to respond, causing the broker to give up.

The Fix

Skip the shotgun approach—test these in order. Most cases are DNS or firewall.

1. Validate DNS Resolution on the Session Host

On the session host, open an admin PowerShell and run:

nslookup $env:COMPUTERNAME

Does it return the host's own IP? If not, fix the DNS record so the host's FQDN resolves to its actual IP. Also check reverse lookup:

nslookup (ip-of-session-host)

This should return the same FQDN. If either fails, update DNS and flush cache on broker and session host:

ipconfig /flushdns

2. Check RPC Connectivity Between Broker and Session Host

From the broker, test RPC to each session host using wmic (it leverages RPC):

wmic /node:"session-host-fqdn" os get caption

If it hangs or gives "Access denied," RPC is blocked. Open Windows Defender Firewall on the session host and ensure these inbound rules are enabled:

• Remote Desktop Services (TCP 3389)
• Remote Desktop Service Management (TCP 135)
• Remote Desktop – User Mode (TCP 49152–65535)

If they're already on, check the scope—make sure they allow traffic from the broker's IP (not just "Local subnet" if they're on different subnets).

3. Verify RD Licensing Mode Matches

On each session host, open Server Manager → Remote Desktop Services → Collection → Properties. The licensing mode must match what's set on the RD Licensing server. Common mismatch: host set to "Per User" but license server only has "Per Device" cal. Change to match:

Set-RDLicenseConfiguration -Mode PerUser -ConnectionBroker "broker-fqdn"

After changing, restart the Remote Desktop Services service on the session host.

4. Increase RPC Response Timeout (For Slow Networks)

This is a registry tweak—only do it if steps 1–3 didn't help and you're behind a slow VPN or MPLS link. On the broker server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\ClusterSettings
DWORD: SessionHostRpcTimeout
Value (decimal): 60000  (default is 30000, increase to 60 seconds)

Reboot the broker for the change to take effect.

Still Failing?

If you've done all four steps and still hit 0x00001AA3, check the event logs. On the broker, go to Applications and Services Logs → Microsoft → Windows → TerminalServices-SessionBroker → Operational. Look for Event ID 1007 or 1024—they'll tell you exactly which session host failed and why (e.g., "license error" or "connection refused").

Also try connecting directly to the session host's IP (bypass the broker). If that works, the problem is 100% between broker and host—re-check DNS and firewall. If direct connection fails too, you've got a problem on the session host itself (bad RDS role install, or antivirus blocking RDP). Re-run the RDS role deployment wizard on that host.