Understanding Terminal Server/Citrix Licensing Models
Licensing models have changed from version to version for both the OS and the Citrix version. This can lead to confusion sometimes when doing fast upgrades or migrations of the Terminal Server/Citrix server. Sometimes even a change on other servers can have an impact on your SBC environment. The wrong choice made months ago, can lead to a complete farm shutdown in a worst case scenario.
Support for NT4 TSE and Metaframe 1.8 has dropped, so I will focus on Windows 2000 and 2003 Terminal Services, and on Citrix XP, MPS 3.0 and CPS 4.0.
Terminal Server Licensing
When setting up a RDP connection to a Terminal Server, the Terminal Server (called TS from now on) will connect to a TS License Server (called TSLS from now on), to fetch a TS CAL (client application license) to be consumed by that client machine. That CAL is ticked off as used in the TSLS database, and also stored on the client machine in the registry. This type of licensing is a named license, so you need one for every client that will connect.
With the introduction of Windows 2000, Microsoft wanted to use TS to promote upgrades to the new Windows 2000 professional, and later to Windows XP professional. Therefore they programmed the TSLS to recognize such a client OS, and grant it a free TS CAL (most people said that those client OS’s had a “built-in CAL”, but that’s not fully true. They were just recognized, and granted a free one).
If the Windows 2000 TS was running in a workgroup environment, the TSLS service could run on any of the TS servers. Once the TS’s had joined a domain, the TSLS HAD to reside on a Windows 2000 Domain Controller.
At a later stage, when Windows 2003 were introduced, this changed a little. If the TS’s remained on Windows 2000, the same principle applied to the DCs. Those could be either Windows 2000 or Windows 2003 and could run the TSLS (They still handed out the free cals if the TS’s were Windows 2000).
If however the TS itself was also Windows 2003, then the DC HAD to be Windows 2003 also, if it needed to run the TSLS service. Existing 2000 CALs were NOT usable on 2003 server, so you needed to buy new TS CALs, when upgrading your TS’s to Windows 2003! The good news with Windows 2003 was that the TSLS could also be one of the Windows 2003 TS’s, while still being in a domain environment.
With so much creativity of where the TSLS may reside, the automatic discovery process of the TS to find a TSLS could get confusing. You can set a registry key on the TS to hardcode the server where the TSLS resides.
For Windows 2000 TS that is:
For Windows 2003 TS that is:
For those of you who script TS/Citrix installations; notice that the key has changed between Windows 2000 and Windows 2003. The Windows 2000 key does NOT work in Windows 2003, and vice versa.
Windows 2003 has a TS license model of “Per Device” and “Per USER”. By default it is set as “Per Device”. Above and below mentioned issues will easier arise on a “Per Device” setting, than on a “Per User” setting, as the “Per User” setting does not do ANY validation if the connection request is valid. Changing the system to “Per User” may be a quick fix for your problems, but could be completely illegal if you do not have the licenses purchased this way.
A full explanation of this new Windows 2003 TS model can be found here.
On the client side
Like I wrote above, when the TSLS is running Windows 2000, the client OS Windows 2000 and XP Professional get a free TS CAL assigned (That means XP Home, Media Centre Edition and Tablet PC edition does NOT get a free TS CAL assigned, and you need to buy one for those clients).
The assigned TS CAL is stored on the client machine in key: (the x can be a variable number)
As you see, this key is a HKLM key, and regular users do not have write access to this key be default.
This is one of the most asked questions on the forums, regarding license problems: As soon as users have write access to that key, connection problems are gone. (Dial-up or network errors are prevented…) A Citrix document on this behavior can be found here.
Sometimes this key is the temporary TS CAL (the 90 day version) and cannot get overwritten correctly by a permanent one. Deleting the LICENSE00x key and logon again, usually fixes those issues. I have also seen that specific key get corrupted in general, and that was also fixed by removing that key, and get a new fresh one assigned.
If your client is Windows XP pro and you get a security error, when connecting to a Windows 2000 TS, make sure to check out this article.
Take the above advice with you during the implementation of a SBC environment. That will prevent panic escalations once the 90 day temporary TS CALs start expiring and you as a consultant or implementer have left the site.
At some point you may end up contacting Microsoft Clearing House - (888) 571-2048 - to fix issues on re-activating TS CALs etc. Keep in mind, that the clearing house has been created to protect Microsoft’s licensing model, but is not part of their standard support chargeability model. Calling the Clearing House to fix issues is usually a free exercise.
Citrix licensing uses a so called “concurrent licensing” model. The Citrix licenses are more expensive, but you need less of them. Size your needed licenses by the maximum number of concurrent users on the farm you expect (As from MPS 3.0 and higher, this can even be calculated cross farm). So if you have a farm of 100 users, of which 50% is concurrent, you would need 100 TS CALs, and 50 Citrix connection licenses.
Keep in mind, that Citrix has created session sharing to consume fewer resources on a server, but this same session sharing is needed to make sure only 1 Citrix license is consumed. If the mechanism does not work correctly, you will see more then 1 license in use by 1 user. The following article will help you stabilize session sharing so you don’t use unneeded licenses.
In Citrix XP, the licenses are stored in the farm’s data store, so licensing was set per farm. If you wanted to create an extra farm, you needed to install a new license model per farm (for those who need to use a test farm using Citrix XP, make sure to check out this article).
In Citrix MPS 3.0, they created a stand alone license service, which could be installed on any server you wanted to. That created the opportunity to go cross-farm on your licensing, and for bigger farms, this was the major reason for upgrading from XP to MPS 3.0.
For those of you who migrate from XP to MPS3 or higher, keep the following in mind: Citrix has purchased that licensing technology from a company that was also a bit UNIX-minded. Therefore the mechanism that asks you for the hostname to setup Citrix license server is Case Sensitive (Which is usually no problem on Windows servers). When you open up the computer properties of that new License Server to get the hostname, Windows night not show you the Case Sensitive name of that server. Always retrieve the hostname of that server by using the command line via the command “hostname” and use that output to register your server name in mycitrix to get the license file.
Mixed mode RDP/ICA
It is mentioned in the admin guide, but still a lot of people get surprised by it; until Citrix XP you could setup a so called mixed server for smaller environments to save some money. Internal people would use RDP sessions, and external people could use a Citrix session.
In MPS 3.0 and higher, Citrix added the functionality of starting a RDP session via their web interface technology. Together with that, they decided that functionality entitled them to charge a Citrix connection license for using a RDP session (Even if the web interface was not used). Basically it’s more convenient to use ICA for every user, since it costs the same.
When upgrading smaller Citrix XP customers to a new version, check out if they use mixed mode, and prepare the customer for an additional investment if needed.
Citrix client types
Citrix has a variety of client types to use. Most popular are the full, the agent and the web client. In the newest version, CPS 4.0, the java client capabilities have grown tremendously compared to older Citrix versions.
If you are going to use this java client as the only way for clients to connect to your farm because of the convenience of zero footprint on the client side, keep the following in mind; the java client does not directly communicate with the underlying OS. Therefore it cannot see if the OS is Windows 2000 or XP professional, and cannot get the free TS CAL assigned if the TS server is Windows 2000. Therefore the java client will ALWAYS consume a full TS CAL.
In this article I have tried to explain common issues regarding licensing on Terminal Server and Citrix. The tips and experiences mentioned should help you during migrations, and to give some extra thought on a planned architecture, regarding the pitfalls I described. Hopefully the above advice will bring you a stable farm, and/or help you understand and fix future license issues more quickly.