If you would like to read the other parts of this article series please go to:
- Troubleshooting Terminal Server Licensing Issues (Part 1)
- Troubleshooting Terminal Server Licensing Issues (Part 2)
- Troubleshooting Terminal Server Licensing Issues (Part 3)
In parts one through three of this four-part series, we looked at the issues commonly seen (or not-so-commonly seen) on the server side. In this final segment, we’ll delve into some common client-related problems and solutions. Topics in this discussion will include:
- An in-depth look at the MSLicensing registry key
- Using the TSCTST resource kit utility for decoding client CALs
- Popular event IDs and corrupt CAL issues
- Transferring CALs from one client to another
- Some notes on thin-client devices
Client-Related Issues
There are few client-related issues that can occur because of licensing issues. However, any good troubleshooting methodology should include certain steps to eliminate the obvious.
When attempting a connection to a terminal server, regardless of the method (RDP client, web connection, etc.) the client should see the logon splash screen. If this isn’t observed, then the issue probably isn’t licensing-related and is more likely a connectivity issue. Temporary CALs are issued upon first connection, but permanent CALs are not issued until the client successfully logs on; however, in both cases a logon splash screen is observed.
Check basic connectivity to the server via PING or by initiating a TELNET session to TCP port 3389 (the default terminal services listening port) by typing the following at a command prompt on the client:
telnet a.b.c.d 3389
where a.b.c.d = the IP address or FQDN of the terminal server in question.
The MSLicensing Registry Key
Every Windows client maintains their terminal server CAL information in the registry under the following key:
HKLM\Software\Microsoft\MSLicensing
The MSLicensing key contains two sub-keys used to store both unique client-specific information and any license certificates obtained from license servers.
\HardwareID
\Store
HardwareID stores a random 20-bit binary identifier specific to the client machine and is generated automatically by Windows. This ID uniquely identifies the machine to the license server. When a client is allocated a terminal services CAL from the license server, this HardwareID is recorded in the licensing database to associate the client with the CAL. This entry is made when clients are allocated both temporary CALs and permanent licenses.
Store is used to store the terminal services CAL allocated from the license server. Entries are contained in sub key named License00x, where X is a numerical ID beginning with 0. Each License00x entry contains a separate CAL.
The License00x entry contains four binary components that comprise a terminal services CAL certificate:
- ClientLicense
- CompanyName
- LicenseScope
- ProductID
The information in these keys can be viewed by leveraging the TSCTST utility, discussed next.
TSCTST Utility
The Windows Server 2003 Resource Kit includes a utility called TSCTST that can be used to decode this information in the client’s registry. Simply executing TSCTST.EXE from a command prompt on a client will output the most relevant information from the CAL, but using the /a argument (tsctst /a) will yield an advanced view of the CAL data, as seen in Figure 3.
Figure 3: TSCTST
TSCTST can provide a lot of information about the CALs contained on a client machine. From the sample above, you can see four key pieces of information:
- The client Hardware ID embedded in the certificate (HWID) – This information must match the client’s HardwareID registry entry.
- The issuing license server name, domain, client machine name and user ID – The Issuer is the license server that issued the license. Check that this license server is still active on the network. Also verify that the Issued to machine information matches the NetBIOS name of the client machine.
- The license type – The type of CAL is also listed. The License ID can have one of several options:
- A02-5.00-S – Windows 2000 TS temporary or permanent CAL.
- A02-5.02-S – Windows server 2003 TS temporary or permanent CAL.
- A02-5.00-EX – Windows 2000 TS CAL from the “Built-in” pool.
Whether the license is a temporary or permanent CAL is determined by the second red-highlighted criteria.
- The issue date and expiration date – Check the expiration date to see if the CAL has already expired.
Many client-related CAL issues may be corrected by simply deleting the MSLicensing registry key. By deleting this key, the client will generate a new hardware ID and will, in effect, become a new client as far as Terminal Server Licensing is concerned. The terminal server will see a new HardwareID as a new, unique client and will allocate a new CAL on the client’s behalf.
It’s important to note that although this would seem to cause your licenses to be consumed prematurely, it won’t. Remember that CALs are leased for a limited amount of time. By deleting the HardwareID on the client, the client is effectively removed from the environment and a new one is instantiated by the creation of a new HardwareID (automatically be Windows). The lease CAL will be placed back in the pool through normal attrition. For more information on the allocation process check out the section titled “Transferring a CAL from One Machine to Another” later in this article.
Another important note is that the MSLicensing registry key is not used when the terminal server to which the client is connecting is in per-user mode, so deleting the HardwareID will have no effect. In the case of per-user mode terminal servers, license checking and allocation is not enforced.
If you find that the MSLicensing key is not being created automatically and you have verified that your terminal servers are in per-device mode, check the permissions on the MSLicensing registry entry. The creation of the MSLicensing key is handled by the SYSTEM account; however through the process, the logged on user is granted full control over the key itself. If you have modified either the HKLM\Software key or the HKLM\Software\Microsoft sub-key permissions, be sure the SYSTEM account is still granted FULL CONTROL to that key and all sub keys. Otherwise the creation of MSLicensing will fail and the client will be unable to connect. You may also try granting Authenticated Users FULL CONTROL to the MSLicensing key and its sub-keys, although this typically isn’t necessary.
Popular Event IDs and Corrupt CALs
Many of the following event IDs were mentioned in either parts one, two or three of this series; however many are related to potential problems on the client side. Some of the more popular event log entries are as follows:
|
Event ID |
Source |
Description |
|
1000 |
TermService |
Unable to acquire a license for user <user>, domain <domain> |
|
1003 |
TermService |
The terminal service client <clientname> has provided an invalid license. |
|
1004 |
TermService |
The terminal server cannot issue a client license. |
|
1011 |
TermService |
The terminal services client <clientname> has been disconnected because its temporary license has expired. |
Event ID 1003 is typically logged when the client presents an invalid or corrupt license to the license server. However, event IDs 1000, 1004 and 1011 may also be logged whenever there is a problem with the MSLicensing registry key on the client (corrupt key, invalid permissions, etc.).
As mentioned before, most of these issues can be corrected by simply deleting the MSLicensing registry key. Upon next connection to a terminal server (in per-device mode), Windows will automatically regenerate the MSLicensing key with a new random HardwareID.
Transferring a CAL from One Machine to Another
One question that commonly arises is the issue of transferring a terminal services CAL from one client to another when that client has either suffered a hardware failure or has been retired permanently, but is currently consuming a license token from the pool.
Unfortunately, CALs cannot be “transferred” from one client to another. The resolution comes from the built-in license attrition mechanism in the Windows Terminal Server Licensing service. When license are allocated to a client, they are stamped with an expiration date of no more than 89 days from the date of issue. However, license servers can issue an unlimited number of temporary CALs, which are good for up to 90 days. The fact that there is a one day difference is not by accident.
Let’s say that a client is issued the last permanent CAL in the license pool on June 1st and is stamped with an expiration date of August 28th (89 days). Later that same day, the client suffers a fatal hardware error and is taken offline permanently. A new client is placed online that day and is issued a temporary CAL, which is good for 90 days and will expire on August 29th. Each day that the client connects to the terminal server, it will attempt to upgrade the temporary CAL to a permanent one, but will be unable to do so because no permanent CALs are available. On August 28th (the 89th day) the permanent CAL from the failed client will be returned to the pool and will be issued to the new client the next time it connects, before the expiration date of August 29th.
If you find yourself in a situation where the temporary CAL is about to expire and no permanent CALs will be available before the expiration date, you may find deleting the MSLicensing registry key on the client reconnecting to be a temporary solution. The client will generate a new HardwareID and appear to be a brand new client. This will allow the computer to be issued another temporary CAL, something that is typically not possible. However, this is not a workaround to circumvent Microsoft’s licensing requirements and should be used as a last resort. Under normal circumstances, the 1-day overlap should be sufficient to keep all clients connected in your environment, provided you are tracking license usage and requirements adequately.
Thin Client Device Issues
Thin client devices are unique in that they either run a proprietary OS or a specialized version of Windows. If you find you are having licensing-related issues with a thin client device, try updating the firmware on the device to the latest version available from the vendor. Certain updates to the Windows Server side of communications may cause problems with thin clients due to security changes. You might also try re-flashing the firmware if you suspect a corruption issue.
On Windows-based terminals, you might try deleting the MSLicensing registry key, the same way you would if the client were a Windows-based PC.
Finally, if your terminal servers are still running a pre-SP1 version of Windows Server 2003, there is a known issue with thin-client connectivity that has been corrected in a hotfix. This issue is also observed by the following event log entry on the terminal server:
|
Event ID |
Source |
Description |
|
1004 |
TermService |
The terminal server cannot issue a client license. |
The hotfix has since been superseded by Windows Server 2003 SP1, but may still be obtained through Microsoft Product Support Services (PSS). See Microsoft KB article Q884570 for more information.
Final Thoughts
Over the course of this four-part series, you have been exposed to a lot of information and possible resolutions to common licensing issues. However, the more important aspect is to gain an understanding of how the licensing process works and the “rules” involved from a functional standpoint. Understanding how the process functions will definitely aid in more effective troubleshooting.
Always consult the Windows Event Logs for possible clues as to where the problem may lie. A few resources I commonly use to quickly find possible causes is, of course, Google, but also the Microsoft Knowledgebase and a great web site called EventID.net (www.eventid.net). This site was originally created by folks in the community and has become an invaluable wealth of information.
I also would urge you to check out Microsoft’s whitepaper on licensing titled “Windows Server 2003 Terminal Server Licensing”, available on Microsoft’s web site. I have also written several articles on this site around Terminal Server licensing you may find helpful so feel free to check those out as well.
If you would like to read the other parts of this article series please go to:
