In short
Remote Desktop Services (RDS), formerly known as Terminal Server, is the Microsoft role that lets several users run desktops and applications in separate sessions on the same Windows Server. It is for companies that want to deliver accounting, ERP or branch applications centrally. CybUp installs Session Host, Connection Broker, Gateway, Web Access and the licence server, configures RDS CALs and secures access with MFA.
Which roles make up an RDS deployment?
An RDS deployment is made up of several roles, which share one server in small environments and run on separate servers in larger ones. According to Microsoft’s RDS overview, RD Session Host runs sessions and RemoteApp programs; RD Connection Broker distributes sessions and reconnects users to their existing session; RD Web Access provides a web portal listing the apps each user is allowed to use; RD Gateway wraps RDP traffic in HTTPS (TCP 443) for secure external access; and RD Licensing issues and tracks CALs.
Picture a 35-person distribution company: 20 users at head office and 15 across two branches all use the same ERP program. Rather than installing it on every PC, a typical design publishes it as a RemoteApp on two Session Host servers, updates it in one place and gives branch users access through RD Gateway. Users see the ERP window as if it were running on their own computer, while the data never leaves the server at head office.
- RD Session Host: sessions and RemoteApp programs
- RD Connection Broker: load balancing and session reconnection
- RD Web Access: portal for applications and desktops
- RD Gateway: external access over HTTPS 443
- RD Licensing: issuing and tracking RDS CALs
Per-user or per-device RDS CALs: which should you buy?
If each user has their own computer and some connect from more than one device, per-user CALs are the right fit; if several people share the same computers across shifts, per-device CALs work better. Microsoft’s RDS CAL page sets out the differences between the two models clearly.
Some of those differences matter in practice. Per-user CALs are assigned in Active Directory and cannot be tracked in a workgroup. The licence server does not technically enforce per-user CALs, so holding enough of them is the administrator’s responsibility. With per-device CALs, a temporary licence valid for 90 days is issued on first connection, permanent licences are renewed after a random period of between 52 and 89 days, and no more than 20 per cent can be revoked.
“When you use the per user model, licensing isn't enforced, and each user is granted a license to connect to a session host from any number of devices.”
Why do RDS licensing errors happen?
The error we see most often is users suddenly being unable to connect, months after installation. The usual cause is the end of the licensing grace period: according to Microsoft, RDS allows a 120-day grace period without a licence server, after which a client must obtain a valid CAL from a licence server before it can sign in. If the licence server was never installed, never activated, or the Session Host was never told which licence server to use, the problem surfaces on exactly that day.
The second common problem is a licensing mode mismatch: the deployment is set to per-user mode but per-device CALs are installed on the server, or the other way round. The third is a version mismatch. According to Microsoft’s compatibility table, a CAL can only be used to connect to Session Hosts of its own version or earlier; Windows Server 2022 CALs, for instance, are not valid for connecting to a Windows Server 2025 Session Host. CALs must also be installed on a licence server running the same or a newer version. For anyone planning a Windows Server 2016 migration, this has a direct effect on the budget.
“There's a licensing grace period of 120 days during which no license server is required. Once the grace period ends, clients must have a valid RDS CAL issued by a license server before they can sign in a remote session.”
How do you secure remote access with RD Gateway and MFA?
Opening the RDP port (3389) straight to the internet leaves the server facing constant password-guessing attacks, so we provide external access through RD Gateway with multi-factor authentication (MFA). RD Gateway uses port 443 only, needs a valid TLS certificate, and controls who can connect to which server through connection (RD CAP) and resource (RD RAP) authorisation policies.
For MFA, we connect RD Gateway to Microsoft Entra multifactor authentication using Microsoft’s NPS extension. According to Microsoft’s documentation, the extension has to be installed on a separate NPS server, not on the RD Gateway server itself. Users must have registered either phone call or approve/deny notifications in the Authenticator app as their method, because the RD Gateway sign-in has nowhere to type a verification code and SMS does not work. The RADIUS timeout also needs raising from the default 3 seconds to 30–60 seconds; otherwise the connection drops before the user has time to approve.
As an alternative to the gateway, some companies prefer users to connect over a VPN first and then use RDP. We compare the two approaches for your environment. What matters is that RDP is never left directly exposed to the internet.
How do you keep an RDS server responsive for users?
Session Host performance comes down to per-user resource planning and profile management. We measure memory per user based on the applications they run, and size the number of Session Hosts to the concurrent users at the busiest hour. We keep profiles and documents off the server’s system disk and install printer drivers in a controlled way, because one incompatible printer driver can affect every session.
Before installation, we test that the application behaves correctly in a multi-user session; some older programs write their settings to the machine instead of the user profile, so one person’s change affects everyone. We roll updates out across Session Hosts in stages and, during maintenance, use Connection Broker to send users to the other server. If the scope is larger and people need desktops of their own, we also look at virtual desktop infrastructure (VDI).
What you receive
- RDS design based on user and application analysis
- Session Host, Connection Broker, Web Access and Gateway installation
- Activated licence server with CALs installed in the correct mode
- RD Gateway TLS certificate, RD CAP/RAP policies and MFA integration
- RemoteApp publishing, profile and printer configuration
- Documentation covering licensing status, roles and access paths
How we work
- 1
Discovery
We review user numbers, applications, where people connect from and your existing licences.
- 2
Design
We decide on the role layout, number of servers, CAL model and access method.
- 3
Installation
We install the RDS roles, activate the licence server and install the CALs.
- 4
Secure access
We configure RD Gateway, the certificate and MFA, and close RDP to external access.
- 5
Testing and handover
We test the applications with multiple users, move users across and hand over the documentation.
Frequently asked questions
Do you offer hosted remote desktops or server rental?
No. We do not rent out servers or desktops. We build RDS on your own servers or in a cloud subscription opened in your name.
Users suddenly cannot connect to RDS. What could be wrong?
The most common cause is the 120-day licensing grace period running out. We check that the licence server is installed and activated, and that the Session Host points to the right licence server and uses the right licensing mode.
Should we buy per-user or per-device CALs?
Per-user CALs usually suit companies where everyone has their own device; per-device CALs suit computers shared by several people across shifts. Per-user CALs cannot be tracked in a workgroup.
Can we use older RDS CALs on a new server?
No. A CAL is valid only for Session Hosts of its own version or earlier. Windows Server 2022 CALs, for example, cannot be used with a Windows Server 2025 Session Host.
How much does an RDS deployment cost?
We give you a written quote after reviewing user numbers, applications and your existing licences; the review is free. RDS CALs are shown as a separate line.
Do we need an extra licence for RD Gateway MFA?
MFA through the NPS extension requires a Microsoft Entra multifactor authentication licence, and your on-premises AD must be synchronised with Entra ID. We check whether your current Microsoft 365 subscription covers this.
Do you set up RDS remotely?
Yes, we deploy RDS remotely anywhere in Türkiye, and work on site in Istanbul when needed.
Will users be affected during installation?
The new RDS environment is built alongside your current setup. After testing, we move users across in groups, out of hours.