Microsoft RDS licensing demystified

This article discusses Microsoft RDS licensing demystified. It attempts to explain all available Microsoft RDS licensing modes and when to use each mode, based on your scenario. Microsoft RDS licensing is required on any Windows Server where the RDS server role has been deployed for remote user access to the server. This can also be the case in VDI solutions in which a third party product, for example Citrix Virtual Apps and Desktops, may install Windows Server RDS server role for its operations.


Love it or hate it, Remote Desktop Licensing (RD Licensing) remains a core responsibility for IT admins to maintain operational efficiency and legal compliance for any given Remote Desktop infrastructure. For many years however this subject matter has remained a source of misinterpretation amongst both customers and Microsoft engineers alike, fuelling the publication of misguided information that only further detracts from understanding the true underlying mechanics at work.

With the helpful collaboration of our Escalation Engineers and the Product Group, this article aims to throw light on RD Licensing in a way that helps an organisation make informed decisions on how best to configure a Remote Desktop environment in the most cost effective and resilient way possible.

Before progressing any further, bear in mind that the information provided here applies specifically to Remote Desktop Services; i.e. Server 2008 R2 and above. RD Licensing (previously Terminal Services) has undergone many iterations of changes since its original inception back in NT4, much of which is no longer relevant to the current supported editions of Windows Server.

Per Device vs. Per User

Let’s start with some basics.  RD Licensing is primarily deployed in one of two flavours; Per Device or Per User. Per Device is used to allocate a Client Access License (CAL) to each client device accessing an RD deployment, including VDI infrastructure. Per User licensing is used to allocate a CAL to each user connecting to an RD deployment (where an Active Directory infrastructure exists). A single RDSH can only accommodate one mode of licensing at a time.

 One of the first and most significant decisions an IT admin is faced with when setting up a Remote Desktop infrastructure is which mode they should use. Keeping things simple; licenses cost money, so choosing the model that has the least financial impact will often answer this question for you. I.e. which is less; the number of users connecting to an RD deployment or the number of client devices? This becomes particularly relevant in situations where one user may log onto multiple client machines, or multiple users share a single client device for example.

That said, there are a number of distinctions between these two licensing modes that may also play a part in this decision process that System Administrators should also be aware of:

 Per DevicePer User 
CALs are physically assigned to each client device, marked within the registryCALs are assigned to a user’s properties within Active Directory (where a Server 2008 AD infrastructure exists)
 CALs are tracked and enforced CALs can be tracked but not strictly enforced.
 CALs can be tracked regardless of AD membership CALs cannot be tracked within a workgroup
 Up to 20% of CALs can be revoked on demand CALs cannot be revoked
 Temporary CALs assigned on first logon are valid for 90 daysTemporary CALs are not assigned 
 Full CALs remain valid for 52-89 days at randomCALs are valid for 60 days before renewal 
 CALs cannot be over allocatedCALs can be over allocated (in breach of the End User License Agreement) 
 An offline License Server issuing Per Device CALs can (under specific conditions) prevent users logging into an RD deployment An offline License Server issuing Per User CALs will not prevent users from logging on

Notice the last entry in the above table; this is often overlooked within large mission critical production environments with only one active License Server, presenting itself as a single point of failure (addressed later).

One of the biggest differences between Per Device and Per User licensing lies around tracking and enforcement. Whilst both modes can be tracked to provide CAL reporting, only Per Device is strictly enforced. This is to say that even if a Per User CAL isn’t available, a user won’t be prevented from connecting and you will see an error reported within Event Viewer (typically Event ID 21). Be aware however that running in Per User mode with more connections than installed CALs is in breach of the End User License Agreement (EULA), to which all customers are legally bound.

A feature often overlooked within RD Licensing is the ability to revoke on demand up to 20% of your Per Device CALs within RD Licensing Manager. This can be useful if a full CAL has been assigned to a device that has since been decommissioned, and you want to reallocate this to a new client prior to the 52-89 day automatic expiry. Where Per User licensing is not strictly enforced, this functionality is only available for Per Device CALs. 

Other licensing modes

While a large majority of customers will opt for Per Device or Per User mode licensing, it is worth mentioning two other modes which are also available; External Connector and a Services Provider License Agreement (SPLA).

An External Connector allows multiple external users (those not part of your company) to connect to a specific Remote Desktop Server. A separate connector is required for each individual server, including RD Gateway if these users connect over a WAN.  Whilst not widely documented; note that there is no option within the GUI to configure an External Connector license. Instead, administrators must simply configure each applicable RD Session Host to Per User mode. Whilst Event IDs may be recorded denoting a lack of available licenses (where nothing is actually installed), this is expected behaviour and is not considered a breach of EULA.

Finally, hosting providers and independent service vendors (ISVs) who host and provide access to an RDS environment are able to leverage an SPLA license, though these also remain uncommon. More details can be found in the full Microsoft Technet article available at: