Windows Server limits concurrent interactive sessions to two by default — and one of those slots is reserved for the console session, so in practice you often get one usable RDP session. If you have ever logged in and immediately kicked yourself out of an existing session, or seen the “another user is connected” warning, you have hit this limit. The good news: you can raise it, but the right method depends on whether you want two sessions or twenty. This guide covers the licensing reality, the registry setting that controls the hard limit, and the proper Remote Desktop Services path for real multi-user workloads. Everything below assumes a server with a public IP, like the ones in Windows VPS hosting plans.
Why the limit exists
Windows Server ships with a Remote Desktop “administrative mode” that allows up to two concurrent sessions at no extra license cost. That mode is intended for administrators managing the box, not for hosting multiple users. Once you need more than two simultaneous interactive sessions, you are running Remote Desktop Services (RDS), which legally requires RDS Client Access Licenses (CALs) per user or per device. Microsoft enforces this with a 120-day grace period — the server keeps working without a license server, but after day 120 it stops accepting new RDS connections until CALs are installed.
So the decision tree is simple:
- Two admins max, no CALs: keep the default, just make sure both slots are usable.
- More than two concurrent sessions: install the RDS role and add RDS CALs. Period.
Raise the hard limit to 2 (reclaim the console slot)
Many providers’ images have the console session disabled, which makes the effective limit one. You can reclaim that slot via the RDP-Tcp listener properties in the registry:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MaxInstanceCount /t REG_DWORD /d 2 /fThen restart the service or reboot. This guarantees both administrative sessions are available to interactive users. Do not be tempted to raise MaxInstanceCount to 5 or 10 as a “workaround” — beyond two sessions you are in RDS territory legally, and the 120-day grace period will eventually lock out your users at the worst possible moment.
The proper path: install Remote Desktop Services
For a genuine multi-user workload — a team of developers sharing a build box, support staff working from a central desktop, a small office running line-of-business apps — install the RDS Session Host role:
Install-WindowsFeature RDS-RD-Server -IncludeManagementToolsThen, from Server Manager → Remote Desktop Services → Overview, run the deployment wizard and add the RD Session Host. You will also need an RD Licensing server. The licensing role can run on the same box for a small deployment:
Install-WindowsFeature RDS-Licensing -IncludeManagementToolsActivate the license server through Remote Desktop Licensing Manager (you need a Microsoft account and the server’s ID), install your CALs, and set the licensing mode to Per User or Per Device to match how you bought them. Per-device CALs are simpler to track in a small office; per-user CALs make sense when the same people roam between machines. Budget for this: RDS CALs cost roughly $180–$250 each depending on volume licensing, and SQL Server or other server licenses are not affected by it.
Control who gets in and how many sessions they may hold
Add your users to the Remote Desktop Users local group. Then tighten the two policies that matter most, via gpedit.msc or the RDS collection properties:
- Restrict Remote Desktop Services users to a single session (Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Connections). This stops one user from hogging multiple sessions and hitting the session limit for everyone else.
- Set an idle session limit (Session Time Limits → Set time limit for active but idle Remote Desktop Services sessions → 30–60 minutes). Idle sessions quietly consume RAM; on a 4 GB VPS, three idle sessions can eat 1.5 GB of nothing.
Right-size the server for concurrent users
Sessions are not free. A baseline Windows Server session idles at roughly 300–500 MB of RAM, and an RDS session running a browser or an office app typically needs 1–1.5 GB. As a planning rule:
| Concurrent sessions | Minimum vCPU | Minimum RAM |
|---|---|---|
| 2 (admin mode) | 2 | 4 GB |
| 5 | 4 | 8 GB |
| 10 | 8 | 16 GB |
| 20+ | 16+ | 32 GB+ |
Undersized RDS boxes fail in a characteristic way: the server stays responsive, but each session takes minutes to render a window. If that happens, check memory pressure first — Get-Counter '\Memory\Available MBytes' should show at least 1 GB free — before blaming the network.
Common mistakes to avoid
- Bumping MaxInstanceCount past 2 without CALs. Works for 120 days, then locks out all non-admin sessions.
- Forgetting the firewall. RDS still uses TCP 3389; if you changed the RDP port earlier, the RDS listener uses the same value. Verify with
Get-NetFirewallRule -DisplayGroup "Remote Desktop". - Leaving Network Level Authentication disabled. NLA is what makes the login screen appear before a full session is created; disabling it increases the attack surface and can break the 2-session accounting.
- Confusing console with session. The
mstsc /consoleflag is deprecated; on modern builds the console session counts against the same two-slot limit.
Verify your configuration
After configuring, confirm the listener limit and the licensing mode:
qwinsta
Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" | Select MaxInstanceCount
Get-CimInstance Win32_TSLicenseServer | Select LicensingModeTwo admin sessions are fine for a single-operator VPS; anything beyond that is an RDS deployment and should be licensed and sized accordingly. If you are planning a multi-user setup, our Windows VPS configurations with 8 GB or more RAM are a reasonable starting point for five to ten concurrent users.
