Can't RDP into your Windows VPS after joining a domain

What this is#

You joined your Windows VPS to an Active Directory domain (or promoted it, or restructured its roles as part of a domain setup), and some time later, immediately or months after, RDP stopped letting you in. The most recognizable version is this exact message:

The remote session was disconnected because there are no Remote Desktop License Servers available to provide a license.

Others look like authentication failures: credentials that worked yesterday are "incorrect", or the connection succeeds and immediately closes. These are different failures with different fixes, but they share a root: a domain join hands significant control of your server to domain configuration, licensing expectations, Group Policy, firewall profile, and how usernames resolve all change. This page takes them in order of likelihood, after getting you back in first.

First: get back in#

Three doors, in the order to try them:

1. mstsc /admin from your computer (run mstsc /admin /v:YOUR.VPS.IP). The /admin switch requests the administrative session, which is exempt from Remote Desktop licensing. If your error is the license-server message, this usually connects immediately, because the licensing check applies to normal user sessions, not administration.
2. A local account with the explicit prefix. At the RDP credential prompt, the username .\Administrator (or VPSHOSTNAME\Administrator) forces a local logon instead of a domain one. After a join, a bare Administrator may silently resolve against the domain, where that password is different or the account is restricted, entering the same credentials with .\ in front is the fix for a surprising share of "wrong password after domain join" cases. Local accounts keep working after a join unless a domain policy disabled them, more on that below.
3. The Console in your client area. This isn't just "RDP by another route", it attaches to the machine's local console session, the virtual equivalent of a physical monitor and keyboard, and RD licensing only gates sessions that come through the Remote Desktop stack. A server with an expired licensing grace still accepts console logons, exactly as a physical terminal server would at its own keyboard. On Windows VPS the Console opens on the Support Account's already-signed-in session; signing out and logging in as your own account there is a local logon, governed by the "Allow log on locally" right rather than the Remote Desktop one. (A harsh domain policy can restrict local logon too, see the GPO cause below, but the licensing error never applies here.)

Cause 1: the RD licensing grace period expired#

The license-server error has a precise mechanism behind it:

• Out of the box, Windows Server permits two concurrent administrative RDP sessions with no licensing at all (the two-session model). This never expires.
• Installing the Remote Desktop Session Host (RDSH) role changes the deal: the server now expects per-user or per-device RDS CALs served by a licensing server, and grants a 120-day grace period to set that up. Domain deployments are exactly where this role tends to get installed, sometimes deliberately (multi-user plans), often incidentally, ticked in a role wizard during the domain setup because it sounded relevant.
• For 120 days everything works, which is what makes this failure so disorienting: the grace expires months after whoever installed the role touched the machine, and RDP "suddenly" refuses normal sessions.

Diagnose in one line (in an /admin session or the Console):

Get-WindowsFeature RDS-RD-Server

If it shows Installed and you never intended to run a multi-user terminal server, the fix is simply removing it, the server returns to the unlicensed two-admin-session model:

Uninstall-WindowsFeature RDS-RD-Server -Restart

If you do need more than two concurrent user sessions, the role is right and the licensing is what's missing: you need an RD Licensing server with purchased RDS CALs, and the Session Host pointed at it (deployment properties or the Licensing GPO under Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services). CALs come from Microsoft or a reseller, they're not something a VPS plan includes. Timer-reset tricks for the grace period circulate on forums; note that they don't license anything, they postpone the same wall.

Cause 2: domain Group Policy took the right away#

Joining a domain subscribes your server to its Group Policy, and hardened domains commonly ship policies that assume "server in the office LAN", not "VPS administered over the internet":

• "Allow log on through Remote Desktop Services" (the user right) may be restricted to specific groups that your account isn't in, and a matching Deny right wins over everything.
• Remote Desktop Users group membership may be enforced by policy, removing the accounts you added locally.
• Local accounts can be disabled or denied network/RDP logon by policy, this is standard hardening (it's how domains stop lateral movement via shared local admin passwords), and it's the case where "local accounts still work" stops being true. If .\Administrator is rejected outright rather than failing on password, suspect this. The strictest variants also deny "log on locally", which is the one policy that can close the Console door as well.
• A GPO can also disable RDP entirely or enforce NLA/security settings your client can't meet.

See what actually applies with gpresult /r (or gpresult /h report.html for the readable version) from the Console or an /admin session, look at the winning GPOs under Computer Settings. The clean fixes are on the domain side: put the server in an OU with policies fit for a remotely administered machine, or adjust the offending GPO. Editing local policy is futile while a domain GPO overrides it, it will reapply on the next refresh.

Cause 3: the domain firewall profile#

Windows Firewall keeps three profiles, and which one is active changes at domain join: the network is now classified as a Domain network, so the domain profile's rules apply. If domain policy configures that profile with no RDP allowance, or scopes the built-in Remote Desktop rule to the corporate subnet, external RDP dies even though "the firewall was fine" before, a different profile was fine.

Check and fix from the Console:

Get-NetFirewallProfile | Select Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select DisplayName, Enabled, Profile
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

If a GPO manages the firewall, the same OU/GPO reasoning as above applies, local changes get overwritten on refresh. The general firewall guidance is in Using Windows Defender Firewall.

Cause 4: DNS and reachability of the domain controller#

Domain joins usually repoint the server's DNS at the domain controller. If that DC is unreachable from your VPS (a lab DC that's off, a corporate DC behind a VPN that isn't up), domain logons fail or hang at "Please wait", and even local logons can slow down. Cached credentials mask this for a while, then it "suddenly" breaks. If your domain lives elsewhere, make sure the VPS can actually reach a DC at logon time, and keep a local account as the fallback that doesn't depend on it.

Before the next risky change: precautions#

A domain join is one of a family of changes (VPN clients, firewall tightening, RDP hardening) that can cut off the very connection you manage the server through. The pattern that keeps you safe:

• Install an independent remote-access tool first. TeamViewer, AnyDesk, or RustDesk connect outbound from the VPS, so they don't care what happens to RDP licensing, logon rights, or inbound firewall rules. Five minutes of setup before the change buys you a full desktop afterwards, whatever went wrong. (For assist-style use these are also the sane alternative to RDS CALs.)
• Know the Console exists and how its login works, it's the recovery path that needs nothing installed.
• Test in a second session. Keep your working RDP session open, make the change, and verify a fresh RDP login works before signing out, the same discipline as changing the SSH port on Linux.
• Keep a local admin account with a known password, and note the .\ login syntax somewhere you'll find it while stressed.
• Don't install the RD Session Host role casually. If you're not deliberately building a multi-user terminal server with CALs budgeted, you don't want it.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• the exact error text, and whether mstsc /admin and .\Administrator behave differently,
• whether the RD Session Host role is installed (Get-WindowsFeature RDS-RD-Server), and roughly when the domain join happened.

Related questions#

• "Why can't I RDP into my server after joining it to a domain?"
• "What does 'no Remote Desktop License Servers available' mean?"
• "My RDP worked for months and suddenly stopped with a licensing error."
• "How do I log in with a local account instead of a domain account?"
• "Does mstsc /admin bypass the license error?"
• "Do I need RDS CALs on my VPS?"
• "What should I install before joining my VPS to a domain?"