If you would like to read the other articles in this series please go to:
- Troubleshooting Terminal Server Licensing Issues (Part 1)
- Troubleshooting Terminal Server Licensing Issues (Part 3)
In part one of this four-part series, we looked at the most popular licensing-related issues pertaining to license server availability. In this segment, as well as in part three we’ll examine some additional common server-related issues and conclude with client-side common issues in part four.
No Licenses Available on License Servers
Another common issue is simply running out of licenses. This is most often due to inadequately planning for the proper number of connections to the farm.
Available licenses can be observed in the Terminal Server Licensing program, so that’s the first place to look. The different pools, or types, of licenses will be displayed along with the total number of licenses in each pool, the number allocated and how many remain. If you double-click on a particular pool, more details will be displayed including the machine name to which it was issued, when it was issued and when the CAL expires.
Two event IDs common when the license server can be reached but is out of licenses include:
|
Event ID |
Source |
Description |
|
1000 |
TermService |
Unable to acquire a license for user <user>, domain <domain> |
|
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 IDs 1000 and 1004 have been mentioned previously; however event ID 1011 may be logged if the client has a temporary CAL and it has expired. If this occurrs, then licensing counts are not sufficient to handle the actual number of connections. To resolve this, purchase and add more device CALs.
Using LSREPORT
LSREPORT, another great utility in the resource kit, can display detailed information about the issue status of the CALs in the licensing database. The following command line arguments can be used with LSREPORT:
/F filename
Output file name
/D [start] [end]
Only licenses from start to end
/T
Only temporary licenses
/W
Include HardwareID in report
serverlist
List of license servers
Usage: LSREPORT /W /F c:\report.txt server1 server2
Figure 2: LSREPORT
In some circumstances, it’s possible that a client may lease more than one CAL thereby prematurely consuming all the CALs in the database, as seen in the above example. This is typical when the MSLicensing key has been deleted on the client. In most cases, a new client can connect using a temporary CAL until the allocated (but unused) CAL is returned to the pool through normal attrition. More detailed information on the MSLicensing key will be covered in part four.
Mixed-Licensing Environments
There is a known issue with the licensing service in Windows Server 2003 that affects mixed-licensing environments – those that have both Windows 2000 and Windows Server 2003 license servers. Normally, Windows 2000 license servers would detect when per-device CALs were available on Windows Server 2003-based license servers so they can forward unfulfilled requests to those license servers. However, a bug in the Windows Server 2003 version of LServer.exe prevents this from occurring. This could lead to a failure to accept the connection and may appear to be intermittent. Typically, the following circumstances accompany this issue:
- Your environment consists of a mix of both Windows 2000 and Windows Server 2003 license servers.
- The Windows 2000 Server-based license servers have no available permanent CALs.
- The Windows Server 2003-based license servers do have available permanent CALs.
- The connecting client is running an older version of Windows, such as Microsoft Windows 98.
This issue has been fixed in Windows Server 2003 SP2, but a hotfix is available from Microsoft to address the problem on Windows Server 2003 SP1 and earlier; more details are available in Microsoft KB Q911288. Contact Microsoft Product Support Services to obtain the hotfix.
Terminal Servers in the Wrong Licensing Mode
This is another common issue. It used to be much more popular before Windows Server 2003 SP1 as there was a bug in the Add/Remove programs process. If you added a Windows component at any time after installing Terminal Services, the registry value PolicyAcOn would get set to an invalid value of 0 and would cause the server to revert to per-device mode. This issue was corrected in SP1.
The two modes still seem to confuse a lot of people. Windows Server 2003 Terminal Servers can be in one of two licensing modes – either-per user or per-device. The choice pertains to whom or what leases the CAL, or more importantly, which CALs were purchased. Per-device CALs are leased to machines or devices, while per-user CALs are allocated to named users.
Per-device CALs are explicitly leased to clients and are recorded in the license server’s database. Upon first connection, clients are given a temporary access license, which is good for 90 days. The second time the client connects, and on each subsequent connection until successful, the terminal server will attempt to upgrade the temporary CAL to a permanent one. Permanent CALs are leased for a limited amount of time (up to 89 days) and do expire.
Per-user CALs are not leased as there is currently no tracking mechanism available to tie a terminal services CAL to a user account. Therefore, terminal servers in per-user mode only check for license server availability, but never actually lease a CAL to the user. If the terminal server can contact the license server, it simply accepts the connection.
The important point here is the licensing mode that is in effect is determined by the terminal server, not the license server or the CALs installed. If you are licensing Terminal Services in per-user mode (allocating CALs per named user), then be sure you are in the appropriate mode, and have verified this is set correctly on all terminal servers in your environment. This can be adjusted in the Terminal Services Configuration program from Administrative Tools at any time and does not require a reboot or a restart of services.
Common symptoms of an incorrect licensing mode are event log entries for event ID 1000 or 1004 (described earlier), or the sudden inability for clients to connect. If you see this on only one terminal server out of the farm, then definitely check the licensing mode on the misbehaving box. You can also automate the process of checking or setting this value by creating a script to query the value in the following registry key:
HKLM\System\CurrentControlSet\Control\TerminalServer\Licensing Core\PolicyAcOn
The two valid entries are 2 for per-device mode and 4 for per-user mode. A value of 0 indicates that this was set as a result of the pre-SP1 bug noted earlier.
Large Licensing Database Issues
Although uncommon, some terminal server licensing databases may become large. If the database reaches around 80MB or more, there may be problems with the licensing service. This issue is usually accompanied by the following event in the Windows event log:
|
Event ID |
Source |
Description |
|
43 |
TermServLicensing |
Work Manager error Can’t Startup work scheduler, Error code -1072167891 |
There is a known issue with licensing databases that are larger than 80MB in size. The licensing service uses a Microsoft Jet-based database engine, and the transactions involved in a large database can consume a lot of memory. If a transaction hangs or runs for an extended period of time (for instance, it can’t complete because the disk is full), this can cause Jet to consume the entire Version Store, crashing the service.
In case you are wondering, the Version Store is used in Jet-based databases as an in-memory “cache” used to hold pending transactions until they can be written to disk.
Microsoft included a new registry key in Windows Server 2003 to be able to tweak the default memory resources associated with the Version Store in Jet transactions. If you find you have a large database and are seeing event ID 43, locate the following key in the registry on the license server:
HKLM\System\CurrentControlSet\Services\TermServLicensing\Parameters
Add a new Value called MaxVerPages (REG_DWORD) with a value data of 1024 (decimal).
Most likely, you will not see this issue except in extremely large terminal server deployments of several hundred nodes. For more information on this issue, check out Microsoft KB article Q310122.
Final Thoughts
Whenever problems arise with connectivity, always check the event logs as they may contain valuable information. I also make it a point to perform basic connectivity tests to be sure the terminal servers can contact the license server, and leverage the tools at your disposal.
In part three, we’ll review some of the more-obscure issues seen in terminal server licensing from the server side, and part four will cover issues from the client’s perspective.
If you would like to read the other articles in this series please go to:
