TS CAL token storage on client devices with no local storage

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?

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:

Name: DoNotReplicateToAllServers
Data: 1

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

To understand how these work, we went to Claudio Rodrigues, the original developer of the server-based computing software bought by 2X, and now the guy behind TSfactory.com.

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.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Very interesting!
For me there is one question left: Why isn´t it possible to put a TS-CAL back into pool when it was used only one time and the workstation from which the CAL was drawn never connect again.
By design, TS device CALs are tied to the device forever, so technically/legally speaking, if you use a device once, then by Microsoft's definition it should keep that CAL forever.

Now in the real world, devices fail, die, are re-formatted, etc. To mitigate this, a device CAL is automatically returned to the pool (by the license server) after a random period of 52-89 days if it's not renewed by the device. (i.e. the device blows up.)

Of course this only applies to device CALs. A 2003 Terminal Server operating in "per user" CAL mode doesn't do any of this.

How then are "per user" CALs returned to the pool if that user account in Active Directory is deleted?  Does it use the same method as device CALs?

Isn't there something to say about the fact that you can write 10's of thousands of words about TS Licensing and people still say "huh"?  Maybe Microsoft should look into that :)
I hope this isn't too dumb a question, but what is considered diskless? Most XPe thin clients use the Enhanced Write Filter so I am guessing this applies to them. But what about CE devices or something like Wyse OS (aka Blazer)? They technically all have "local storage," just not much of it...
Maybe you should read the tens of thousands of words that I wrote, because I've covered the answer to your question in [link=http:
Per user CALs are completely different. Please read the articles I've listed here, or do a site search for per user CALs for the full story. Today's article only refers to device CALs.

No this is a good question.. Cause you're right.. A lot of the thin clients and stuff can store the TS CAL token in the NVRAM (Which is why MS allows them to work).

In this article, I used the terms "diskless clients" and "clients with no local storage" interchangeably. However, that's technically wrong on my part. "Clients with no local storage" is more correct.

So that said, what is a client with no local storage? This could be a device that downloads and boots from an image on the network. Or one that boots from one of those knoppix or PXES burned CDs that "restores" itself to the factory default settings with every boot. Or this could be something like an Ardence PC. Or even a Linux or some other thin client where the vendor chose not to implement the local token storage.

But you raise a good point of distinction... many thin client devices are able to store the TS CAL token locally.

Hi Brian,
Nice information!, i will add this article to the Ardence presentation for BriForum 07 Chicago.
So when using Ardence in a Desktop environment with standard images (some call it public vDisks) and connecting to RDP-only Terminal Servers it's not an offical support configuration TS-CAL wise ..?!.
"He said that the official RDP specification from Microsoft requires that client devices have a local storage capability,"
Do you know if Ardence has tweaked this ?.
With regards,
Ruben Spruijt
What would happen if you streamed Windows XP Professional to your Wyse terminals using Wyse Streaming Manager? Would a new TS CAL be issued every time you boot your terminal? (assume you don’t use the option that saves terminal information to a network share)
This sounds a silly question but how does the presentation server / License server know that the device is diskless in order to use this alternative method to store the license.
Also if I remeber correctly the client is issues a temporary license on first connection and is only issues a "real" tscal on the second connection.
This short Citrix article explains what is happening with my Mac, a PowerPC G4, when I try to connect to the Citrix Metaframe server.


I have two questions regarding the following  background information which I think may contain the answer to my problem.

(1) Since Macintosh does not have registry keys, how would I change the permissions that exist in a comparable file as HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\MSLicensing"?

(2) Which of the numerous files in my Citrix ICA client folder would be the "token" mentioned in the article "TS CAL token storage on client devices with no local storage" at

I've tried the first two 'resolutions' using the ICA Citrix Client Editor using our external Citrix IP but  but I still get the "Connection to server IP ( failed. Error: 51

The third resolution has a link to "Check the Event Viewer for 1004 error messages CTX564283 - Troubleshooting 1003 and 1004 Terminal Server Licensing Errors"

The only reference to Macintosh in this link is:

"Note: If using a NON Native Windows Client (Macintosh, Linux, or a Thin Terminal) without a local registry, the above permissions (outlined in Issue 1) must be verified on the following registry key:


These are the permissions “outlined in Issue 1”:

1. Open the Registry Editor (Regedt32.exe).

2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSLicensing.

3. Highlight this key, select Security on the toolbar, and select Permissions.

4. Click the Advan
You can ignore my previous email (and my apologies to everyone for the inadvertent multiple posts.)  I figured it out the solution.

All I had to do was delete my Citrix ICA Client folder to get rid of the used “token” or license key.  Next time I logged on to Citrix, the license server recognized my machine as  new and issued me a new license key.  

Thanks for your very helpful article:  
TS CAL token storage on client devices with no local storage

I am Accessing TS applications via Linux machine. I have use 2X Application Server to publish applications. where i can see TSCAL Licensing information on Linux Client.

I too am connecting to Win 2000 & 2003 servers from a Linux PC (Ubuntu 7.10). For some reason the linux pc was granted a temp license from just one of the servers. Unfortunately that temp license has expired and I can no longer connect to that single server (Win 2000 SP4). I haven't had any success in finding either the ICA or RDP folders mentioned in the article.