Windows Server 2008 R2: how to return access to old terminal clients (RDP5) after raising the license server?

Question

Iron

Good day, %username%!

Introduction

The server has a recently installed MS Windows Server 2008 R2 OS - before that, the server was controlled by Windows 2003 R2 OS.
Terminal clients connect to the server. On clients, in addition to the main functionality, i.e. KVM - and COM ports with connected barcode scanners.
Immediately after installing the server, the role of the license server was not raised, and there was a message that there were so many days left before the end of such a period, while for most customers the transition from MS WS 2003 went more or less unnoticed, and the problems that arose were solved.
Now, when installing the license role, the network level protection checkbox was not set, and was not set initially, and was not set after the problem was detected.

Now the picture is

— desktop clients running MS Windows XP SP3 32bit RUS and MS Windows 7 SP1 RUS 32/64bit have no problems: they connect normally, without errors, work normally with barcode scanners connected to COM ports
— RDP5 clients, such as desktop computers based on MS Windows 2000 and thin clients (terminals) HP t5530 with Windows CE 5 firmware do not work due to a security reason - the connection is not even established, and there is no prompt to enter a password

What was done

- if you reflash the HP t5530 thin client with Windows CE 6 firmware, KVM has RDP communication, but not the barcode scanner connected via the COM port, and the application apparently does not even see the forwarding of this COM port, although declaratively the firmware allows you to set the appropriate checkboxes for enabling the COM port and the checkboxes for forwarding serial ports via RDP; In fairness, it should be noted that this problem with Windows CE 6 firmware was still there while the server was running under Windows 2003 R2
- if you copy a new version of the RDP client (files mstsc.exe and mstscax.dll), from Windows XP SP3, on which the updated client, to a machine running Windows 2000, then this client does not even start: it says that the EXE file being launched is not a Win32 application

During brainstorming and further research, the following solutions were proposed

- find a solution to the problem on the Internet; why it doesn’t fit: any of the found options offered as a solution to the problem, firstly, is not a 100% guaranteed solution for all cases, which the comments show, and secondly, does not explain the essence of the problem, i.e. does not allow her to comprehend; and it is inexpedient to check all solutions of the AnyKey WAY style
- rearrange the server from scratch in order to return access, because canceling the elevation of the role of licenses is not possible; the brute force method, taking into account the workload of the turnover, it may take two days; then it will be necessary to think what to do next; it will not be possible to rearrange forever, tk. according to our calculations, only three times are enough, after which the server will stop working completely
- temporarily transfer users to another server that does not have a problem, and think what to do with this server - this will have to be done, and in the near future, because production server
- flash HP t5530 thin clients with Windows CE 6 firmware from HP t5550 thin client; there is a possibility that this option will work, because on the website of the manufacturer, the firmware versions of both models are mixed, plus a third model is shown - HP t5540, so there is a suspicion that the line is the same, and the firmware is interchangeable; the HP t5550 model with Windows CE 6 firmware has no problems either with RDP connection in general, or with the COM port in particular - it has been tested in practice - and there is confidence that the problem is software, i.e. does not depend on iron; the only thing that confuses is that the firmware for the HP t5550, even if it is compatible at the level of hardware drivers, may refuse to work with the HP t5530 due to lack of RAM, the latter has only 128 MB on board; certainly,
- generate firmware based on GNU / Linux, for example Thinstation; I spent the whole evening tinkering with version 2.2.2i, and in the configuration with booting from a disk device, on which the configuration file is located, and with a static IP address, it didn’t want to work, it doesn’t see the thinstation.conf.user configuration file; perhaps a bug of a specific version, tk. a few years ago (in 2008) when using an older version, i.e. Thinstation 2.2.1, and some other GNU/Linux build tool, i.e. Slackware, (look at backups) everything went like clockwork; the search engine told me that I'm not the only one with the problem, and playing with the STORAGE_PATH and STORAGE_CONFIGx variables in the thinstation.conf.buildtime file is futile; perhaps it will be possible to work in this direction again, starting with a step back; such a solution should be suitable not only for the HP t5530 thin client, but it is possible to install it on old desktop computers instead of Windows 2000, while loading will be faster, because. there is no slowing down antivirus, and if there is some local work, then it is quite possible to transfer it to the terminal server; I know that the freerdp package version 0.8.2 works with COM ports OK (I tried it in a desktop configuration in Debian 6.0, I took the packages themselves from snapshots or one of the previous versions of Ubuntu), it remains only to find out if RDP 6 communication will be possible; when playing with version 2.2.1 in 2008, I didn’t get around to using the freerdp package - I played with rdesktop, which has a known problem of incompatibility with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... in this case, the download will be faster, because. there is no slowing down antivirus, and if there is some local work, then it is quite possible to transfer it to the terminal server; I know that the freerdp package version 0.8.2 works with COM ports OK (I tried it in a desktop configuration in Debian 6.0, I took the packages themselves from snapshots or one of the previous versions of Ubuntu), it remains only to find out if RDP 6 communication will be possible; when playing with version 2.2.1 in 2008, I didn’t get around to using the freerdp package - I played with rdesktop, which has a known problem of incompatibility with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... in this case, the download will be faster, because. there is no slowing down antivirus, and if there is some local work, then it is quite possible to transfer it to the terminal server; I know that the freerdp package version 0.8.2 works with COM ports OK (I tried it in a desktop configuration in Debian 6.0, I took the packages themselves from snapshots or one of the previous versions of Ubuntu), it remains only to find out if RDP 6 communication will be possible; when playing with version 2.2.1 in 2008, I didn’t get around to using the freerdp package - I played with rdesktop, which has a known problem of incompatibility with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... 2 works with COM ports OK (I tried it in a desktop configuration in Debian 6.0, I took the packages themselves from snapshots or one of the previous versions of Ubuntu), it remains only to find out if the connection will be via RDP 6 protocol; when playing with version 2.2.1 in 2008, I didn’t get around to using the freerdp package - I played with rdesktop, which has a known problem of incompatibility with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... 2 works with COM ports OK (I tried it in a desktop configuration in Debian 6.0, I took the packages themselves from snapshots or one of the previous versions of Ubuntu), it remains only to find out if the connection will be via RDP 6 protocol; when playing with version 2.2.1 in 2008, I didn’t get around to using the freerdp package - I played with rdesktop, which has a known problem of incompatibility with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... which has a known incompatibility issue with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ... which has a known incompatibility issue with COM port forwarding; I just want to check it all, Linux Way was asked to work out for me personally, so I am eager, eager to fight ...
- contact Microsoft technical support; we have no such experience, except for perhaps very rare routine problems - with the activation of Windows XP flying off, which was at one time; but perhaps we should start somewhere?

UPD: added the "old iron" tag, added "Old iron" to the hub

Answer 1

Maybe I'll ask a stupid question, but still: Have you looked in the properties of the Terminal Server system on the remote access tab, in the Remote Desktop section, the radio button Allow connections from computers with any version of Remote Desktop should be selected?
PS The first time I accidentally poked in to clarify the question, instead of writing an answer, I'm sorry.

Answer 2

Here is a similar situation: x220.minasi.com/forum/topic.asp?TOPIC_ID=30026 in the third post is the answer.
Check that the registry key is:
HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\UserAuthentication = 0