Two admin sessions versus Remote Desktop Services
Out of the box, Windows Server runs Remote Desktop for administration. Microsoft's troubleshooting guide states that it supports two concurrent remote connections and that no Remote Desktop Services client access licences (RDS CALs) are required for them. More than two administrative connections, or any multi-user setup, requires the RD Session Host role and the appropriate RDS CALs.
| Remote Desktop for administration | Remote Desktop Services | |
|---|---|---|
| Role to install | None | RD Session Host, plus RD Licensing somewhere |
| Concurrent sessions | Two | Bounded by hardware and CALs |
| Licences beyond Windows Server | None | One RDS CAL per user or per device |
| Intended use | Managing the server | People working on the server |
If two people administer the box and nobody else logs in, stop here: enable NLA, fence the port and you are done. If a team will run desktop applications on it, you are building an RDS deployment and the next section applies.
RDS CALs, the grace period and the workgroup rule
When a user or device connects, the session host checks whether a CAL is needed and, only if it is, requests one from a Remote Desktop Licensing server. Microsoft documents two CAL types:
- Per device: assigned to the client machine. A temporary CAL is issued on a device's first sign-in and lasts 90 days; permanent ones renew after a random 52-89 days.
- Per user: assigned to a user in Active Directory. It cannot be tracked in a workgroup, and over-allocating it breaches the licensing agreement.
- Grace period: 120 days in which no license server is required. After it ends, users need a valid CAL from a license server to start a session; an administrator can still get in with
mstsc.exe /adminto repair licensing.
The constraint that bites on a single rented machine: per user CALs can't be tracked in a workgroup, and a standalone dedicated server is a workgroup machine unless you build a domain for it. So Per Device is the practical choice here. Microsoft's licensing guide goes further for deployments with the RD Connection Broker role: there, workgroup servers have to use Per Device CALs. Version matters too: a CAL must be for the same Windows Server release as the session host or a later one, and the license server must run that CAL's release or newer.
Budget for RDS CALs separately from the server. Buy them through Microsoft or a Microsoft licensing partner and install them on your own RD Licensing server.
Choosing the machine
Our Windows dedicated servers install Windows Server 2025, 2022 or 2019 (the FAQ on that page adds 2016) and arrive with Remote Desktop ready from the control panel. Which images a server can take depends on its line: the widest lines run Windows Server from 2008 R2 to 2025, and no ARM line runs Windows at all, because the images are x86 builds.
- Licence: Windows Server is billed per core, every month, with no term discount. The core count you pick is also a licence decision, so size cores to the applications your users run rather than to the biggest box.
- Console: rack servers and blades each carry an out-of-band controller (HPE iLO, Dell iDRAC or a Supermicro BMC), which the dashboard publishes after you create console credentials. That is your way back in if a firewall change locks RDP out. Moonshot cartridges other than the m510 and m710x have power control only.
- Port: unmetered, 1 Gbps on 10 of the 18 configurable lines and 500 Mbps on the other 8, on our own AS19624 network.
- Addresses: one IPv4 included; IPv6 is added at checkout at no charge and is in no default build.
A racked machine is live about 30 minutes after the order is approved; a build to order takes 4-24 hours. Choose the city nearest the users who will sit in the sessions; each has a test IP on the locations page.
Building a single-server session host
- In Server Manager, select Manage > Add Roles and Features, choose role-based installation, tick Remote Desktop Services and select the Remote Desktop Session Host and Remote Desktop Licensing role services.
- Open Tools > Remote Desktop Services > Remote Desktop Licensing Manager, select the server and run Action > Activate Server. The automatic method talks to the Microsoft Clearinghouse outbound on TCP 443.
- Install your CALs with Action > Install Licenses.
- On the session host, open the Local Group Policy Editor at Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Licensing. Enable Use the specified Remote Desktop license servers with this server's name, then enable Set the Remote Desktop licensing mode and pick Per Device (Per User CALs can't be tracked in a workgroup).
- Add the people who need access under Remote Desktop users in the Remote Desktop settings, with non-administrative accounts.
Microsoft notes that the workgroup credential steps it describes for reaching a separate licensing server can be skipped when the RD licensing server and the session host are the same machine, which is the layout above.
Port 3389 on TCP and UDP
The listener is 3389 by default, stored as PortNumber under HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Microsoft's connection troubleshooting shows the Remote Desktop service bound to TCP and UDP 3389 on both 0.0.0.0 and [::], so it answers on IPv6 as well as IPv4. The firewall side is two built-in inbound rules, Remote Desktop - User Mode (TCP-In) and Remote Desktop - User Mode (UDP-In), in the display group Remote Desktop.
Moving the listener to another port is documented. Microsoft's procedure then creates two new allow rules, RDPPORTLatest-TCP-In and RDPPORTLatest-UDP-In, which are not in the Remote Desktop display group, so the group command below does not fence them. Our view: a different number cuts log noise but does not replace an address fence.
Fencing RDP by source address
Windows Defender Firewall applies explicit allow rules over the default block, explicit block rules over any allow, and has no rule ordering. So the fence is a change to the existing allow rules, not a new rule beside them. Set-NetFirewallRule takes -RemoteAddress as IPv4 or IPv6 addresses, subnets or ranges, and -DisplayGroup changes every rule in a group at once. Run this from an elevated PowerShell, with your own addresses in place of the documentation ones, and keep the console login ready:
# Restrict both built-in RDP rules (TCP-In and UDP-In) to your addresses
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 203.0.113.10, 2001:db8:10::/48
# Confirm what each rule now accepts
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilter
# List enabled inbound allow rules (local and Group Policy) that name 3389 or any port
Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound -Action Allow -Enabled True |
Where-Object { ($_ | Get-NetFirewallPortFilter).LocalPort -match '^(3389|Any)$' } |
Format-Table DisplayName, ProfileOn IPv6: the address list is one list for both families. Our reading of the precedence rules is that an IPv6 client outside the list matches no allow rule and falls to the default block, so the fence holds on IPv6 as long as no other allow rule covers 3389. The last command finds rules that name 3389 or any port; review each one. If you moved the port, use the new number there, and fence RDPPORTLatest-TCP-In and RDPPORTLatest-UDP-In by name with Set-NetFirewallRule -DisplayName and the same -RemoteAddress list. If you work from IPv6 yourself, put your prefix in the list.
NLA and account lockout
- Network Level Authentication: the user authenticates before a session is created. Microsoft recommends keeping it on. Enforce it with the policy Require user authentication for remote connections by using Network Level Authentication under Remote Desktop Session Host > Security.
- Account lockout threshold: under Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy. A value of 0 means accounts never lock, and Microsoft's page lists 0 as the stand-alone server default. The built-in Administrator account is excluded from the policy, so a threshold does not protect it: give it a long, unique password and do daily administration through a separately named admin account. The same page says the Windows security baselines treat 10 as an acceptable starting point, and warns that a threshold also lets an attacker lock accounts on purpose.
- Licensing lockout: if the grace period lapses without a license server,
mstsc.exe /adminis Microsoft's documented way to reach a host that cannot contact one.
A VPN or RD Gateway instead of an open port
Microsoft's guidance on outside access is blunt: it advises against opening the machine up to the public internet and calls a VPN preferable. With a VPN, the RDP client behaves as if it is on the same network and 3389 never has to face the public internet. One way to build that here is a WireGuard VPN server on a separate machine, with the Windows firewall allowing only its address.
The other route is the RD Gateway role service, which wraps RDP in HTTPS on TCP 443, so once 3389 is closed to the public in the firewall, only the gateway faces the internet; Microsoft's overview adds MFA and conditional access policies. It needs the RDS role and a certificate imported in RD Gateway Manager. For a single admin box, a VPN is the lighter of the two.
Questions
How many people can use RDP on Windows Server without extra licences?
Two concurrent connections, and only for administering the server. Microsoft states that these need no RDS CALs. A third connection, or any user who is not administering the machine, needs the RD Session Host role and an RDS CAL.
Per user or per device CALs on one standalone server?
Per device, unless you join it to a domain: per user CALs can't be tracked in a workgroup. In deployments that include the RD Connection Broker role, Microsoft's licensing guide makes Per Device mandatory for workgroup servers. Per device also suits shared machines, such as shift workers on the same PCs.
What happens when the 120-day grace period ends?
Users need a valid RDS CAL issued by a license server before they can start a session. Activate the RD Licensing role and install CALs before then. An administrator can still connect with mstsc.exe /admin to fix licensing.
Does RDP need UDP 3389 as well as TCP?
The service listens on both, and Windows ships separate TCP-In and UDP-In rules for it; the display-group command fences both. If you move the port, Microsoft's procedure adds RDPPORTLatest-TCP-In and RDPPORTLatest-UDP-In, which sit outside that group: fence them by name with Set-NetFirewallRule -DisplayName and -RemoteAddress, and run the rule check with the new port number.
Are RDS CALs covered by the Windows Server licence?
Not for user sessions. The two administrative connections need nothing beyond Windows Server, which our servers bill per core. Past them, Microsoft requires an RDS CAL for each user or device: buy them separately, through Microsoft or a licensing partner, and install them on your own RD Licensing server.
What if a firewall change locks me out of RDP?
On rack servers and blades, create console credentials in the dashboard and open the out-of-band console (iLO, iDRAC or BMC). From the local desktop you can correct the rule without RDP. Set the console up before you touch the firewall, not after.