8/10/2019 RD Licensing Demystified How It Works - TechNet Articles - United States (English) - TechNet Wiki

1/2

30/11/2014 RD Licensing Demystified how it Works - TechNet Articles - United States (English) - TechNet Wiki

http://social.technet.microsoft.com/wiki/contents/articles/21180.rd-licensing-demystified-how-it-works.aspx 1/2

RD Licensing Demystified how it WorksTable of Contents

OverviewLove 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 RemoteDesktop infrastructure. For many years however this subject matter has remained a source of misinterpretation amongst both customers and Microsoft engineers alike, fuelling thepublication 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 informeddecisions 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 . RDLicensing previously Terminal Services has undergone many iterations of changes since its original inception back in NT4, much of which is no longer relevant to thecurrent supported editions of Windows Server.

Per Device vs. Per UserLets 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 eachclient 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 ActiveDirectory 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 RDdeployment 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 singleclient 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 awareof:

Per Device Per User

CALs are physically assigned to each client device, marked within the registry CALs are assigned to a users properties within Active Directory (where a Server 2008AD 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 5289 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 userslogging into an RD deployment

An offline License Server is suing Per User CALs will not prevent users fromlogging 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 asingle 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 thateven if a Per User CAL isnt available, a user wont 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 moreconnections 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 hasbeen assigned to a device that has since been decommissioned, and you want to reallocate this to a new client prior to the 5289 day automatic expiry. Where Per User licensing isnot strictly enforced, this functionality is only available for Per Device CALs.

Other licensing modesWhile 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 aServices 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 eachindividual 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 ExternalConnector 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 availablelicenses (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 alsoremain uncommon.

RD Licensing infrastructure setupOnce 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 aretypically lightweight roles it is not uncommon to virtualise the licensing server; though it is recommended to install this as a dedicated role. Inline 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 PerUser, 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:50across 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

Overview

Per Device vs. Per User

RD Licensing infrastructure setup

Grace periods

CAL reporting

Troubleshooting tips

Additional information

http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-http://-/?-

8/10/2019 RD Licensing Demystified How It Works - TechNet Articles - United States (English) - TechNet Wiki

2/2

30/11/2014 RD Licensing Demystified how it Works - TechNet Articles - United States (English) - TechNet Wiki

http://social.technet.microsoft.com/wiki/contents/articles/21180.rd-licensing-demystified-how-it-works.aspx 2/2

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 reportingwill show an overallocation 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 CALs50: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 topdown in the order specified. This iswritten to the registry of the RDS Host under HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers , though best practise guidelines recommendconfiguring all licensing settings including license servers and licensing mode via Group Policy to ensure complete consistency across the RDS infrastructure. For the perfectionistsamongst 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 CALsfrom 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 ServerTerminal Services that leveraged an autodiscovery mechanism to locate known license servers using an LDAP query in Active Directory. Over time, this autodiscoverymechanism often proved a high generator of support calls and a bug bare for many customers troubleshooting licensing issues and as such, has now been deprecatedin favour of a specified list that an RDSH server pings directly.

Grace periodsOnce 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 serverswithout 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 PerDevice 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 serverwithout any CAL for up to a maximum of 210 days after the RD Licensing role has been installed.

CAL assignment processIn 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 reportingWhilst RD Licensing Manager contains basic functionality for tracking Per User CAL allocation within an Active Directory domain, the RDS Product Group have also published someuseful scripts for both crossdomain Per User reporting and Per Device mode. Full details for each are available via http://technet.microsoft.com/enus/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 tipsRD 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 understandingof 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 certainsituations 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 thelicensing 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 fromaccurate 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 tocover 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 MSLicensingregistry entry (after backing up) from any affected client devices, which is located under HKLM\SOFTWARE\Microsoft\MSLicensing. Two successful subsequent logons to an RDSHserver should recreate and populate this hive on the client device with a new CAL; which can be verified within RD Licensing Manager.

Additional informationSo 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 RDSenvironment.

http://technet.microsoft.com/en-us/library/dd759163.aspxhttp://social.technet.microsoft.com/wiki/cfs-file.ashx/__key/communityserver-wikis-components-files/00-00-00-00-05/8867.RD_5F00_licensing_5F00_flowchart.PNGhttp://technet.microsoft.com/en-us/library/hh553161(v=ws.10).aspxhttp://technet.microsoft.com/en-us/library/cc772298.aspx