Remote Desktop Licensing Demystified
Overview
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 Device | Per User |
| CALs are physically assigned to each client device, marked within the registry | CALs 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 days | Temporary CALs are not assigned |
| Full CALs remain valid for 52-89 days at random | CALs are valid for 60 days before renewal |
| CALs cannot be over allocated | CALs 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.
RD Licensing infrastructure setup
Once a licensing model has been decided it is then possible to start designing and deploying an RDS infrastructure, which will include at least one RD Licensing Server. As these are typically lightweight roles it is not uncommon to virtualise the licensing server; though it is recommended to install this as a dedicated role. In-line with best practise guidelines, administrators should ensure at least two license servers are available to avoid single point of failure; though this is only truly impactful to end users in Per Device mode. (In Per User, you will see event log errors – but connections will still be permitted).
The type of licensing mode chosen will also have an impact on how best to install CALs across RD License Servers. For Per Device mode, it is recommended that CALs are split 50:50 across each License Server, whereas for Per User it may be beneficial for accurate CAL tracking to install a majority (if not all) licenses on the primary RD License Server. As Per User CALs are tracked but not strictly enforced, an RDSH server will not defer to a secondary RD License Server if the primary listed server has no remaining CALs. Instead, any reporting will show an over-allocation of licenses – and the customers need to ensure that they have enough CALs. As Per Device CALs are enforced however, it is recommended to split CALs 50:50 so that if a primary server does run out of CALs, the next specified server within RDSH Configuration Manager will be contacted for a valid CAL in order to allow a connection.
The list of RD License Servers to use is commonly configured within the RDSH Configuration Manager, whereby the servers are contacted top-down in the order specified. This is written to the registry of the RDS Host under HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers, though best practise guidelines recommend configuring all licensing settings including license servers and licensing mode via Group Policy to ensure complete consistency across the RDS infrastructure. For the perfectionists amongst you, allocating odd and even number servers to separate OUs, with reversed preferences set for the list of RD License Servers in each will ensure an even allocation of CALs from each server resulting in neater reports and easier tracking.
Whilst this behaviour may seem strange to some, it is the direct result of the deprecation of a feature known as CAL forwarding in previous versions of Windows Server Terminal Services that leveraged an auto-discovery mechanism to locate known license servers using an LDAP query in Active Directory. Over time, this auto-discovery mechanism often proved a high generator of support calls and a bug bare for many customers troubleshooting licensing issues and as such, has now been deprecated in favour of a specified list that an RDSH server pings directly.
Grace periods
Once the RD License Server role is installed, administrators have 120 days to activate the license server with the Clearing House. During this time, users can connect to RDSH servers without any CALs being assigned. Contrary to popular belief, the RDSH servers themselves do not have any grace period; only the RD License Servers. Furthermore; if using Per Device mode, only after a second successful logon will a full CAL actually be assigned (preventing DoS attacks).
Temporary CALs that are initially assigned from an unlimited pool are valid for 90 days (per Device only). As such – it is possible for users to legally connect to an RDSH server without any CAL for up to a maximum of 210 days after the RD Licensing role has been installed.
CAL assignment process
In an effort to outline all possible eventualities when attempting to connect to an RDSH server, the following Visio diagram provides a high level overview of this process:
CAL reporting
Whilst RD Licensing Manager contains basic functionality for tracking Per User CAL allocation within an Active Directory domain, the RDS Product Group have also published some useful scripts for both cross-domain Per User reporting and Per Device mode. Full details for each are available via http://technet.microsoft.com/en-us/library/hh553161(v=ws.10).aspx and can prove useful for an organisation to understand their compliance status and forecast for future scalability where required.
Troubleshooting tips
RD Licensing has historically proven a pain point for many customers, and yet whilst the deprecation of CAL forwarding has simplified things greatly, having a deeper understanding of the mechanics at work is never a bad thing. Usually a license server outage may not have an appreciable impact on end users (especially if Per User); but there are certain situations that may lead to denied connections; specifically when using Per Device CALs that require renewal or upgrade.
If an RD Licensing Server issuing Per Device CALs does go down and there is no immediate backup; the quickest way to prevent any denied connections is to temporarily switch the licensing mode on each RDSH server to Per User. As this mode of licensing is not strictly enforced, users will never be denied a connection. Whilst this restricts administrators from accurate CAL tracking, it may provide some needed breathing space to address the underlying issue. The administrator needs to ensure that there are enough CALs installed to cover all users connecting into the environment in order to be in compliance with the EULA.
For issues with Per Device CAL distribution when the RD License Servers are online and operational, the most efficient course of action will normally be to delete the MSLicensing registry entry (after backing up) from any affected client devices, which is located under HKLM\SOFTWARE\Microsoft\MSLicensing. Two successful subsequent logons to an RDSH server should recreate and populate this hive on the client device with a new CAL; which can be verified within RD Licensing Manager.
Additional information
So there it is, as simple as that. For those that wish to dive deeper down the rabbit hole and explore some additional capabilities of RD Licensing not covered in this post the following links provide a great source of reference material:
- Understanding Remote Desktop Licensing
- Managing Remote Desktop Services Client Access Licenses (RDS CALs)
The Remote Desktop Services Resource Kits also continue to prove valuable resources to any IT administrators responsible for the design, implementation and/or support of an RDS environment.