
Keep in mind that the new database will not have any of your CALs installed you will need to contact the Microsoft Clearinghouse to recover them. Of course, there is no better protection against corruption than a good backup however if you find yourself with a corrupt database you can recreate a new (empty) database pretty easily. Other ways corruption can occur is incorrect shutdown of the server or a licensing service crash, or a hardware related issue such as a problematic RAID controller or faulty cache. In parts one and two of this four-part series, we discussed the more common server-related licensing issues. In this segment, I’ll cover some of the more less-common issues with terminal server licensing, including:Īlthough rare, it is possible for the licensing database to become corrupt. Symptoms of a corrupt database include not being able to start the licensing service, failure of the service to stay running, or possibly the inability of terminal servers to lease CALs (although this last one is most likely due to some other underlying issue).Ĭorruption can occur for a number of reasons, but the most popular is making the mistake of placing the licensing database on a compressed drive. The drive compression could cause a write-delay, thereby corrupting the database. Per Microsoft, Jet-based databases should not be located on compressed drives. See Microsoft KB Q318116 for more information. Troubleshooting Terminal Server Licensing Issues (Part 2).Troubleshooting Terminal Server Licensing Issues (Part 1).If you would like to read the previous articles in this series please go to: Please use slmgr.If you would like to be notified when Michael Burle releases the next article in this series please sign up to the Real time article update newsletter. Microsoft (R) Windows Script Host Version 5.8Ĭopyright (C) Microsoft Corporation. Reports the following: C:\temp\pstools>cscript %windir%\system32\slmgr.vbs /dlv Minimum = 112.86ms, Maxiumum = 113.43ms, Average = 113.12msĪnd the cscript %windir%\system32\slmgr.vbs /dlv

Sent = 4, Received = 4, Lost = 0 (0% loss), I tested the psping and everything seems to be OK: I found that someone else has encountered the same problem:
