Link to home
Start Free TrialLog in
Avatar of JazIT
JazIT

asked on

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

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?
ASKER CERTIFIED SOLUTION
Avatar of NJComputerNetworks
NJComputerNetworks
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.
Avatar of JazIT
JazIT

ASKER

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.
Avatar of JazIT

ASKER

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.