Remote Desktop Won't Connect: RDP, NLA and Licensing Errors Fixed

Remote Desktop is the tool everyone reaches for, so when it fails the ticket is urgent. The error messages are not much help. "Remote Desktop can't connect to the remote computer" covers everything from a wrong hostname to a firewall to a dead service. The NLA and licensing errors are more specific but still leave people guessing.

Work from the outside in. Can you reach the port? Does the service answer? Do the credentials pass Network Level Authentication? Is there a licence to hand out? Each stage has one or two commands that settle it.

Can you reach port 3389?

Start with the network. RDP listens on TCP 3389 by default. If that port is not reachable from the client, nothing else matters. `Test-NetConnection` from the client answers this in one line, and it also tells you whether the name resolved to the address you expected.

If the port is closed, check in this order: the target is powered on and on the network, the Remote Desktop service is running, the Windows Firewall rule for Remote Desktop is enabled for the active profile, and no firewall between client and server blocks 3389. A machine that just joined a new network often gets the Public firewall profile, where the RDP rule is off by default.

1. From the client: `Test-NetConnection server01 -Port 3389`. TcpTestSucceeded should be True.
2. On the target: `Get-Service TermService` should be Running. Start it if not.
3. On the target: `Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select DisplayName, Enabled, Profile`. Enable the rules for the Domain and Private profiles.
4. Confirm remote connections are allowed: `Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections` should return 0.
5. Check the network profile with `Get-NetConnectionProfile`. Public on a domain machine means the domain was not detected at boot; restart the Network Location Awareness service.

Test-NetConnection server01 -Port 3389
Get-Service TermService
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select DisplayName, Enabled, Profile
Get-NetConnectionProfile

NLA and CredSSP errors

Network Level Authentication checks your credentials before the session starts. The error "The remote computer requires Network Level Authentication, which your computer does not support" or "An authentication error has occurred. The function requested is not supported" comes from a CredSSP mismatch or from the target being unable to reach a domain controller to validate you.

The classic cause is a target that lost contact with the domain: time skew, a broken secure channel, or a DC that is down. The CredSSP error usually means one side is missing a security update.

1. Try connecting with a local account on the target, `.\localadmin`. If that works, the target cannot reach a domain controller. Check DNS and the secure channel with `Test-ComputerSecureChannel` on the target; repair it with `Test-ComputerSecureChannel -Repair -Credential domain\admin`.
2. Check time on both ends with `w32tm /query /status`. Kerberos fails past five minutes of skew.
3. For the CredSSP error, install pending Windows updates on both client and target. Do not set the Encryption Oracle Remediation policy to Vulnerable as a fix; that only hides the missing patch.
4. If you must get in right now on an unpatched machine, disable NLA temporarily on the target from another admin session: `Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication -Value 0`. Turn it back on afterwards.
5. Confirm the user is in the Remote Desktop Users group on the target, or is an administrator.

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential yourdomain\admin
w32tm /query /status

Licensing errors on RDS hosts

On a Remote Desktop Session Host, once the 120-day grace period ends the server refuses connections with "The remote session was disconnected because there are no Remote Desktop License Servers available". Plain Windows admin RDP, with two concurrent sessions, is not affected. Session hosts serving many users are.

The fix is to have a licensing server with the right CALs installed and to point the session host at it with the right licensing mode. Per User and Per Device CALs are not interchangeable, and a session host set to Per Device with only Per User CALs installed will still fail.

1. On the session host, open Remote Desktop Licensing Diagnoser from Server Manager > Tools. It names the licence server it is trying to use and the reason it failed.
2. Confirm the licence server has activated CALs: open Remote Desktop Licensing Manager on the licence server and check the installed licences and their type.
3. Set the licensing server and mode by Group Policy under Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Set Use the specified Remote Desktop license servers and Set the Remote Desktop licensing mode.
4. Run `gpupdate /force` and reboot the session host.
5. If the grace period was consumed and the fix is in place, remove the GracePeriod registry key under `HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod`. Take ownership of the key first, back it up, then reboot.

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core' -Name LicensingMode
gpupdate /force

Other things that look like RDP failures

A black screen after connecting is often a stuck session. Run `query session` on the target and `logoff <id>` to clear it. A certificate warning is normal for self-signed RDP certificates and is not a connection failure.

Finally, if you are forwarding 3389 from the internet, stop. RDP exposed directly is a frequent way ransomware gets in. Put it behind a VPN or a Remote Desktop Gateway, and if the site has neither, that is the ticket to open next.

query session /server:server01
logoff 2 /server:server01

Frequently asked questions

Takeaway

RDP failures split cleanly into port, service, authentication and licensing. Test-NetConnection settles the first, Get-Service and the firewall rules settle the second, a local account login and the secure channel test settle NLA, and the Licensing Diagnoser settles the last. Fix the cause and keep NLA on. If RDP is open to the internet, that is a bigger problem than the ticket you started with.