Ever since Microsoft decided to start enforcing Terminal Server Client Access License (TS CAL) usage in Windows 2000 Server, we administrators have been trying to figure out exactly how the whole system works. (Why did Microsoft choose to single out TS for license enforcement? Seven years later, we’re still the only MS server product that does this. But I digress..)
I’ve written tens of thousands of words over the years about Microsoft TS CALs (a good primer is can be found here). By now everyone is familiar with the basic concept: A client device logs into a terminal server. The terminal server contacts a TS Licensing server. A TS CAL license token is physically transferred from the license server to the client device (by way of the terminal server).
The key here is that a license token is physically installed to the client device. For Windows-based clients, the TS CAL token is installed into the registry. For non-Windows clients, the token is copied into the folder that contains the client software (either RDP or ICA, depending on the connection type).
But what happens when the client device has no local storage? How does the TS License server “know” that a particular client already has a TS CAL if that device is not capable of storing its CAL?
For the past seven years, I was under the impression that the TS License server kept track of these licenses on its own via some combination of MAC address or client name or something.
In my class a few weeks ago, one of the students asked for clarification about exactly how the TS License server tracked that information. So I posted the question to a private MVP newsgroup monitored by the Microsoft TS product group in Redmond. Before Microsoft was able to answer, other MVPs posted answers saying it was things like MAC address, GUID, etc.
It turns out that they were wrong. And I was wrong. In fact, everyone was wrong.
How Microsoft deals with client devices with no local storage
The answer I got from Rob Leitman at Microsoft surprised me. He said that the official RDP specification from Microsoft requires that client devices have a local storage capability, and that the TS License server does not track CALs in this way for clients without any local storage.
Wow! That was news to me. This was easy enough to understand, except for the fact that I know that Citrix Presentation Server is able to work with clients without any local storage, and seeing how Citrix and Microsoft are friends, I doubt that Citrix is breaking the Microsoft license agreement.
How Citrix deals with client devices with no local storage
Therefore I headed over to Citrix to find out how they handled things. I posted my question to the product group via a CTP forum. Citrix’s Pedro Llaguno filled me in on how they handle it. He said:
Presentation Server provides non-Windows clients and client devices that have no local storage with the ability to connect to a Presentation server even though the client devices cannot store the TS CAL token locally. The TS CAL token is stored and managed on the Presentation server. The registry location that the Presentation server uses to store TS CALs is:
NOTE: you may notice that the "_xx" is the fifth byte of the client device hardware ID (MAC address). The client device hardware ID is based on system specific hardware information and random data which is unique to that client device. Essentially, when the client must present the token, the Presentation Server opens the bucket to locate the correct license. These licenses are then loaded into the data store and replicated through IMA event notification to all other Presentation Servers.
Cool! Since this information is stored in the data store and replicated to all Presentation Servers via IMA, one client connecting to multiple Presentation Servers will still only consume a single license.
Pedro also pointed out that Hotfix Rollup Pack 1 for Presentation Server 4.0 contains a feature enhancement that’s relevant here. Before HRP01, all TS CAL tokens for client devices without local storage were replicated to all other servers in the farm. This could be a problem in large environments because all servers would end up with all TS CAL token information for every diskless client. HRP01 adds support for the following registry key:
You can add this key to servers that serve sessions to diskless ICA client devices. If present, this key prevents those Presentation Servers from replicating their TS CAL token information to other servers in the farm. This is useful in situations where only a few servers in your farm serve sessions to diskless clients. (i.e. when you’re using a “desktop tier” in an ICA pass-through scenario).
How Linux and the open source clients deal with client devices with no local storage
Claudio said that since Linux-based Thin Clients usually use RDesktop, which was developed without the RDP specs, what happens really depends on the manufacturer. For example, PXE-based solutions grab the stored information about the TS CAL token from a server and present that to RDesktop software after Linux loads but before RDesktop is called. If you have no TS CAL token and the terminal server sends you one, the Linux OS could simply get it and save it somewhere on the network. The weird thing is that this is completely up to the vendor to implement, so depending on the vendor this may or may not be implemented. (And if it is, it may be different from vendor to vendor).
As a fun aside, in the older builds of RDesktop, you could pass a switch to pretend you were coming from a Windows 2000 Professional box, This meant that when connecting to a Windows 2000 terminal server, a TS CAL was not used. Of course 2003 changed that, and when people realized this was not legal they removed that functionality from RDesktop.