RDP 5.2 thin clients won't connect to Windows server 2008

Posted on 2009-12-22
Medium Priority
Last Modified: 2012-05-08
I have installed a new server onto a site using their existing Wyse thin clients, which run RDP 5.2. The clients have connected without issue for a full day & a half, until I installed the termianl server CAL's onto the terminal server. Once that occured, any client that logged off & tried to log back on could not connect.
I am certain that the issue is the TS is not issuing Device CAL's to the thin clients as they are not running RDP 6.0 or greater. The one PC running XP is issued a license, as is the second server & another thin client running Embeded XP.
I have seen an article claiming that a registry edit will fix this.....

If you are using Ws08 SP2 just specify the bellow key and restart termservice will allow the connection.

Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM
Registry entry: Use512LenPropCert
Data type: REG_DWORD
Value: 0 or 1

Can anyone confirm that this will work & if the value is meant to be 0 or 1?
Question by:JazIT
  • 2
  • 2
LVL 33

Accepted Solution

NJComputerNetworks earned 2000 total points
ID: 26104301
one method to solve this problem is to use PER USER Cals... PER USER cals are tracked by Windows 2008 but are NOT enforced.  In this way, you will never get errors on the client machines...

Source:  (attached)
LVL 33

Expert Comment

ID: 26104347
The registry key you list is regarding the encryption level of the TS client and server.  If you think this is your problem (not really a licensing problem then), you can change the encyption level of your TS server so that your clients are compatible...  here's how:

source: http://technet.microsoft.com/en-us/library/cc775148(WS.10).aspx

Change the RDP encryption level on the terminal server
To resolve this issue, change the RDP encryption level on the terminal server to a level that is supported by the version of Remote Desktop Connection that is running on the client computer.

By default, Terminal Services connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Terminal Services client do not support this high level of encryption. If your network contains such legacy clients, you can set the encryption level of the connection to send and receive data at the highest encryption level supported by the client.

To perform this procedure, you must have membership in the local Administrators group, or you must have been delegated the appropriate authority.

To change the RDP encryption level:

On the terminal server, open Terminal Services Configuration. To open Terminal Services Configuration, click Start, point to Administrative Tools, point to Terminal Services, and then click Terminal Services Configuration.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
Under Connections, right-click the connection (for example, RDP-Tcp), and then click Properties.
On the General tab, change the value of Encyption level to a level that is appropriate for the version of Remote Desktop Connection that is running on the client computer. For more information about encryption levels, see "Configure Server Authentication and Encryption Levels" in the Terminal Services Configuration Help in the Windows Server 2008 Technical Library (http://go.microsoft.com/fwlink/?LinkId=101637).
When you change the encryption level, the new encryption level takes effect the next time a user logs on. If you require multiple levels of encryption on one terminal server, install multiple network adapters and configure each adapter separately.

Note:  You can also change the RDP encryption level on the terminal server by using Group Policy.

To set the RDP encryption level for the terminal server by using Group Policy, enable the Set client connection encryption level Group Policy setting. This Group Policy setting is located in Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security. Note that the Group Policy setting will take precedence over the setting configured in Terminal Services Configuration.
To configure the terminal server to use FIPS as the encryption level by using Group Policy, enable the System cryptography: Use FIPS compliant algorithms for encryption, hashing and signing Group Policy setting. This Group Policy setting is located in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Note that this Group Policy setting will take precedence over the setting configured in Terminal Services Configuration and takes precedence over the Set client connection encryption level policy setting.
To configure the Group Policy setting in Active Directory Domain Services (AD DS), use the Group Policy Management Console (GPMC). To configure the Group Policy setting locally on a terminal server, use the Local Group Policy Editor. For more information about configuring Group Policy settings, see either the Local Group Policy Editor Help (http://go.microsoft.com/fwlink/?LinkId=101633) or the GPMC Help (http://go.microsoft.com/fwlink/?LinkId=101634) in the Windows Server 2008 Technical Library.

Author Comment

ID: 26108334
Thanks' - The encryption level is already set to "Client Compatible"
I have added the registy key value & am awaiting staff to test that it works.
The clients are Wyse S10 & are diskless & classless. The only error reads that the Profile could not be accessed & for this reason I think that changing the license CAL's type will not make a difference.
What I don't understand is the fact that the clients connected just fine when the temp licenses were being issued. I actually had one of these clients connecting for over a week as I was configuring the server's.
This means that the server must accept RDP 5.2 connections and that they are being denied since installing the CAL's.
I will keep you updated.

Author Comment

ID: 26109210
OK. The registry entry change has not worked, I have changed the encryption method from client compatible to low, rebooted the server & still the Wyse clients fail to connect.

The solution was to change the licensing mode from Device CAL's to User CAL's.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Scenario:  You do full backups to a internal hard drive in either product (SBS or Server 2008).  All goes well for a very long time.  One day, backups begin to fail with a message that the disk is full.  Your disk contains many, many more backups th…
For anyone that has accidentally used newSID with Server 2008 R2 (like I did) and hasn't been able to get the server running again because you were unlucky (as I was) and had no backups - I was able to get things working by doing a Registry Hive rec…
This tutorial will give a short introduction and overview of Backup Exec 2012 and how to navigate and perform basic functions. Click on the Backup Exec button in the upper left corner. From here, are global settings for the application such as conne…
This tutorial will show how to configure a new Backup Exec 2012 server and move an existing database to that server with the use of the BEUtility. Install Backup Exec 2012 on the new server and apply all of the latest hotfixes and service packs. The…
Suggested Courses

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question