Is it just you, or your whole team?
If one or two people only look after the server, the Remote Desktop already built into Windows Server is enough. Microsoft says it allows two connections at the same time for administration, with no RDS CALs needed.
The moment you want a third connection, or you want colleagues to do their everyday work in sessions on the server, the rules change. Microsoft then asks for two things: a Session Host role on the server, plus matching RDS CALs. That is the setup people usually mean by a remote desktop server for multiple users.
| What you want | What Windows needs |
|---|---|
| You and one colleague maintaining the server | Nothing extra: two admin connections are built in |
| A third admin connection | Session Host role, plus CALs |
| Staff running apps in their own sessions | Session Host role, plus CALs |
The licences a team setup needs
When someone connects, the session host first works out if that connection needs a CAL at all; if it does, it asks the licensing server you run for one. You choose between two kinds:
- Per device CALs belong to the computer people connect from. Microsoft's example is shift workers who share the same PCs. A device gets a temporary one on its first sign-in, good for 90 days.
- Per user CALs belong to a person in Active Directory, so one person can connect from several devices. A workgroup has no way to track them.
That last point matters for a single server you rent: unless you set up an Active Directory domain, it sits in a workgroup, so plan on per device. (Microsoft's guide to licensing session hosts goes further for deployments built with a Connection Broker: in those, a workgroup must use Per Device.)
You also get breathing room: a 120-day licensing grace period. While it runs, Windows doesn't insist on a license server; once it ends, your users need a valid CAL to start a session, so finish the licensing well before day 120. You can still reach the server yourself as an administrator by starting the client with mstsc /admin, and sort it out from there. Match the CAL version to your server too: CALs from your server's version or a later one work, and older ones don't.
RDS CALs are your purchase to make. Get them from Microsoft directly or from one of its licensing partners, then install them on the license server you run on this machine.
The server that fits
Our Windows dedicated servers come with Windows Server 2019, 2022 or 2025, with 2016 also named in that page's FAQ, and you manage them through the Windows desktop and Remote Desktop. A few things are worth knowing before you choose:
- The licence is counted in cores. Windows Server Standard is a paid licence that stays flat up to eight cores and is charged per core past them, billed to your account every month at the same price whatever term you pay.
- Not every line runs Windows. The images you can pick depend on the server line, and Windows doesn't install on any of our ARM machines. The order page shows what each line offers.
- A way back in. Every rack server or blade we offer carries an iLO, iDRAC or BMC management controller (HPE, Dell or Supermicro, depending on the machine), which opens a console in your browser after you create a console login from your dashboard. Moonshot cartridges are different: only the m510 and m710x bring their own console, and on the rest you can switch the power and nothing more.
- No traffic counting. Every server sits on an unmetered port, so a busy day of sessions doesn't bring a bandwidth bill.
A server that is already racked is ready about 30 minutes after your payment is verified; a custom build typically takes 4 to 24 hours. Choose a city near the people who will use the desktops; our data center locations list all five.
Turning it into a team desktop, step by step
Here are the Group Policy settings the steps below refer to, with their locations exactly as Windows shows them:
Computer Configuration > Administrative Templates > Windows Components >
Remote Desktop Services > Remote Desktop Session Host > Licensing
Use the specified Remote Desktop license servers (Enabled, this server's name)
Set the Remote Desktop licensing mode (Enabled, Per Device)
Computer Configuration > Administrative Templates > Windows Components >
Remote Desktop Services > Remote Desktop Session Host > Security
Require user authentication for remote connections by using Network Level Authentication (Enabled)
Computer Configuration > Windows Settings > Security Settings >
Account Policies > Account Lockout Policy
Account lockout threshold- Open Server Manager, choose Manage > Add Roles and Features, then a role-based installation. Tick Remote Desktop Services and add the two role services named Remote Desktop Licensing and Remote Desktop Session Host.
- Activate licensing: open Remote Desktop Licensing Manager (Server Manager's Tools menu, under Remote Desktop Services), pick your server and choose Action > Activate Server. The automatic option reaches the Microsoft Clearinghouse over outbound TCP 443.
- Load your CALs through Action > Install Licenses.
- Point the session host at its licences: in the Local Group Policy Editor, switch on the two Licensing settings listed above, giving this server's own name and choosing Per Device.
- Give each colleague their own standard (non-administrator) local account, then add it to the Remote Desktop Users group: in Control Panel > System, choose Remote settings, and on the Remote tab click Select Users and add each one. On later releases you can also do this under Settings > System > Remote Desktop.
Since licensing and sessions both live on this one server, Microsoft's extra workgroup credential steps don't apply to you.
Close the front door before you invite anyone
Remote Desktop listens on port 3389 unless you change it, over both TCP and UDP. In Microsoft's troubleshooting output the service is bound on 0.0.0.0 and on [::], which means it is reachable over IPv6 as well as IPv4. To see it on your own server, run netstat -anob | findstr 3389 from an elevated command prompt.
Windows lets RDP in through the UDP and TCP versions of its built-in Remote Desktop - User Mode rule, grouped as Remote Desktop. Windows Defender Firewall has no rule order: an explicit allow beats the default block, and an explicit block beats any allow. So the safe move is to narrow the built-in allow rules to the addresses your team connects from. The address list accepts IPv4 and IPv6 entries side by side:
# Elevated PowerShell. Replace the example addresses with your office or VPN addresses.
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 198.51.100.0/24, 2001:db8:20::/48
# Check the result on both rules
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Get-NetFirewallAddressFilterWhat about IPv6? As we read Microsoft's precedence rules, an IPv6 address that isn't on your list doesn't match these rules and is dropped by the default block. The catch is any other rule allowing 3389 or any port, which would let everyone back in. Open wf.msc, sort the inbound rules by local port, and disable or narrow anything else on the RDP port. If you moved RDP to another port with Microsoft's procedure, it added two rules, RDPPORTLatest-UDP-In and RDPPORTLatest-TCP-In, outside the Remote Desktop group; point Set-NetFirewallRule -DisplayName at each of them with your address list, and look for the new port number rather than 3389. If you connect over IPv6 yourself, include your prefix.
Set up your console login before you apply the fence. If you leave your own address out by mistake, the console is your route back in to fix it.
Two settings that stop password guessing
Network Level Authentication (NLA) makes people prove who they are before Windows builds a session for them. Microsoft recommends keeping it on wherever your clients support it, and the Security policy in the list above makes it compulsory.
An account lockout threshold locks an account after a set number of failed sign-ins; a value of 0 means no account ever locks, which is what Microsoft's table shows for a stand-alone server out of the box. One account is deliberately left out: the policy doesn't cover the built-in Administrator, so someone guessing passwords can keep trying that one. Protect it with a long password used nowhere else, and do your everyday admin work from a second administrator account with its own name. Microsoft's documentation for this policy puts 10 forward as a reasonable starting value, citing the Windows security baselines. It also points out the downside: someone hammering your sign-in can lock real users out deliberately, which is one more reason to fence the port first.
Better still: no public RDP port at all
Microsoft says plainly that opening a machine's Remote Desktop to the internet isn't recommended and that a VPN is preferable. Once connected to a VPN, your laptop behaves like a machine on the server's own network, so 3389 never faces the internet. You could set up WireGuard on a separate small machine as your VPN and let the Windows firewall accept only that machine's address.
If installing VPN software on every laptop is a hassle, RD Gateway is Microsoft's built-in alternative. It tunnels Remote Desktop through HTTPS (TCP 443), so after you shut 3389 to outsiders in Windows Defender Firewall, the gateway is the one thing left facing the internet, and Microsoft lists MFA and conditional access among its options. It needs the Remote Desktop Services role installed plus a TLS certificate, which you import through RD Gateway Manager's SSL Certificate tab.
Questions people ask
- Can more than two people use Remote Desktop on my server at once?
- Yes, once you add the Session Host role and license it. Without the role, Windows Server allows two connections at the same time, and only for administration. With it, every user or every device needs its own CAL.
- Which CAL type should I buy for one standalone server?
- Per device, in most cases. A server that isn't joined to an Active Directory domain is a workgroup server, and per-user licences have no way of being tracked there. If you later build a domain, per user becomes an option.
- Is the 120-day grace period a free trial of RDS?
- It is a window in which the session host works without a license server. After that, your users can't start a session without a CAL from your licensing server; you can still connect as an administrator with mstsc /admin to put licensing right. Set up licensing during that window rather than at the end of it.
- Should I just move RDP to a different port?
- You can, and Microsoft documents how: change PortNumber in the registry, then open the new port in the firewall for both TCP and UDP. Those new rules sit outside the Remote Desktop group, so fence them by name. It won't stop someone who scans every port, though. Limiting who may connect, or keeping RDP behind a VPN or RD Gateway, does far more.
- Where do I get RDS CALs?
- From Microsoft directly or from one of its licensing partners. Your Windows Server licence is billed per core on your account; the CALs are a separate purchase that you load onto the licensing role on your server.
- Can I run this on an ARM server?
- No. Windows doesn't install on our ARM machines, so pick an x86 line that offers Windows Server on the order page.