Why Can’t Legacy Thin Clients Connect to RDS on Server 2012?

At BBL Systems, we use Remote Desktop Services extensively. Our sister company runs our point-of-sale system from a 2003 Server via Remote Desktop. They have around 50 users who access it via thin clients, Windows 7, and Windows 8. It’s a great solution as it centralizes the management of the IT infrastructure to one server. All of our software is installed on one machine, the server. The thin clients are commodity items, if one fails it can be swapped out within minutes. It makes managing 50 users in a 3 story building easy.

We also rent our point-of-sale system via Remote Desktop. Customers can sign up and pay monthly to use the software. We host these customers on a dedicated 2008 Server that they access via the internet, again via Remote Desktop.

Most of our larger customers also use Remote Desktop to run our software. They set up a dedicated server in-house and deploy thin clients or PC’s for their employees.

Our Plan

Now, our in-house 2003 Server was beginning to show it’s age, so we planned to upgrade the hardware to a newer 64-bit dual quad-core server with 32gb of RAM. We also took the opportunity to upgrade to Server 2012.

In case you don’t know, Remote Desktop requires a client access license (CAL) for each user or device that will access the server. For Server 2012, they’re not cheap. They’re never cheap for the current server O/S. You can pick up 2003 or 2008 CALS for a good price, but not 2012 CALS.

Our plan was to set up the server for production use, test it for a few weeks, then deploy it and run it for a few more weeks. Once we were sure it was running well, we’d activate the license server and install the RDS CALS. If there was a problem with Server 2012, we would just use 2008 instead, as we have experience with that for our hosted customers.

We did have a problem with older thin clients connecting, and had to uncheck the “Allow connections only from computers running Remote Desktop with Network Level Authentication (recommended)” located on the Remote tab of System Properties, and on Server Manager\Remote Desktop Services\Collections[servername]\Properties of the collection->Tasks->Edit Properties. This allowed the older thin clients to connect.

Other than that, everything went according to plan, Server 2012 performed perfectly and our new server was much more responsive than the older one.

We activated the license server on a Thursday and installed the CALS.

The Problem

On Saturday morning a user said they were getting an error message when they tried to connect to the server:

Remote Desktop disconnected because of a security error. The client cannot to the remote computer. verify you are logged on the network and try connecting again

The server was also logging the following error:

A fatal alert was generated and sent to the remote endpoint. This may result in termination of the connection. The TLS protocol defined fatal error code is 10. The Windows SChannel error state is 10.

We had some other users try disconnecting and re-connecting, and they got the same error. However, I was successfully connected to the server via RDP, as was my co-worker. Very odd. We thought it might be related to the activation of the license server, so we de-activated it. No change, the clients couldn’t connect.

We cataloged which users were having problems. All the users who could not connect were using thin clients. However, not all thin clients got the error. A few thin clients could connect. Additionally, Windows 7 and 8 could connect, as could an XP test machine we had laying around.

We suspected that the version of RDP on the client dictated whether or not it can connect. The older thin clients were using RDP 5.x, whereas Windows XP SP3 uses RDP 6.x, and Windows 7 uses RDP 7 or RDP 8, depending on whether it’s been upgraded. Windows 8 uses RDP 8. If this was the case, why did it work during our test period, and then fail when we activated the license server?

We couldn’t find an authoritative answer from Microsoft as to exactly what version(s) of RDP are supported to connect to RDS under Server 2012. There were some forum posts on MSDN from people with similar problems, with some registry key changes that worked for them, but these fixes didn’t work for us.

The Answer

We had to get a definitive answer, so we opened a support call with Microsoft. The tech first told us to work with the thin client vendors to solve the problem. However, we really wanted to get an answer to the RDP version question. She checked and confirmed that:

Only RDP 6 and later is supported with Server 2012.
RDP 5.x clients CANNOT connect, except as follows:
RDP 5.x clients CAN connect if no license server is activated. In this case, Server 2012 RDS does not issue any license to the client, and allows the client to connect at a low encryption level, 512 bits. However, when a RDS license server is activated, a higher level of encryption is required (2048 bits) and RDP 5.x cannot support this level of encryption. Therefore, the RDP 5.x client can no longer connect.

This explained the problem, and the misleading results during our test. I put the answer on ServerFault as well.

The Solution

Up to this point, we were running a mix of old and new thin clients. Some ran Win CE 5, others ran XP embedded, still others used WTOS, which is a freebsd based O/S for Dell/Wyse Winterms. All of the problem units were running RDP 5.x. Most of them are discontinued units at this point. We put them into production in 2006, and they’d been working reliably and silently ever since.

We decided to upgrade all our thin clients to modern HP units with embedded Windows 7 with RDP 8. If these units last 6+ years as well, we’ll be in good shape.