Remote Desktop Services 2019

A production RDS deployment is built from five roles. Session Host runs the user sessions and the published apps. Connection Broker load-balances incoming sessions across multiple Session Hosts and handles session reconnection when a user returns to an existing disconnected session. Web Access publishes the RemoteApp and Desktop Connection portal. Gateway provides the SSL-tunnelled entry point from the public internet so that the RDP protocol does not need to be exposed directly. Licensing tracks CAL allocation and issues per-user or per-device CALs to clients. The Connection Broker and Licensing roles can be highly available; Session Host scales horizontally by adding hosts.

RDS CALs come in two flavours. Per-user CALs are assigned to named users in Active Directory and follow the user across any device they use to connect — the right choice when users connect from multiple devices (laptop, phone, home PC). Per-device CALs are issued to the specific device that connects — the right choice for shared workstations like training rooms, kiosks, or shop-floor terminals where many users sit at the same device through the day. Mixing both modes is allowed; the Licensing service hands out the right CAL type based on the connection. Per-user CALs are technically a 'temporary issued' licence that should reconcile against Active Directory, but in practice many estates do not perform that reconciliation and so over-deploy per-user CALs — a common audit finding.

Critically, every RDS user or device also needs a base Windows Server 2019 CAL. The RDS CAL grants access to the RDS-specific session-hosting feature; the base CAL grants access to Windows Server itself. Missing base CALs underneath valid RDS CALs is the second most common RDS audit finding, after under-licensed per-device deployments. For Microsoft 365 estates, the base Server CAL needs to be procured separately from the M365 user subscription — M365 does not include Windows Server CALs.

Windows Server 2019 (and therefore RDS 2019) is in extended support through 9 January 2029. Security-only updates continue, but no new features and no protocol enhancements ship. RDS on Windows Server 2025 is the supported on-prem continuation; in-place upgrade from 2019 to 2025 is supported, and existing RDS CALs hold downgrade rights covering older session hosts but cannot be used against newer session hosts without an upgrade. For estates that want to leave on-prem RDS entirely, Azure Virtual Desktop (multi-session Windows 11 Enterprise hosted in Azure) is the cloud destination, with per-user licensing bundled into Microsoft 365 E3/E5 and pay-as-you-go compute. Windows 365 (per-user Cloud PCs) is the simpler alternative for shops that want a one-Cloud-PC-per-user model without managing session hosts at all.

The most common architectural mistake is running Session Host on the same Windows Server instance as the domain controller or the SQL database — Microsoft has been explicit for years that Session Host must run on a dedicated VM. The most common licensing mistake is operating in the 120-day grace period that the RDS Licensing service grants before requiring an installed CAL pack; once that window closes, sessions stop connecting and the licensing team has a fire to fight. Audit findings cluster around missing base Server CALs, under-counted per-device CALs (shared workstations counted as one device when several physical devices share the same hostname through KMS reissue), and per-user CALs deployed against more named users than purchased.