Недавно, после очередного обновления сервера терминалов на базе Windows Server 2003, клиенты из удаленного офиса, подключающиеся к нему с помощью стандартного Подключения к удаленному рабочему столу, стали получать ошибку «Ошибка расшифровки на сервере. Удаленное подключение было отключено.» примерно каждые пять минут. На сервере же, стала появляться ошибка TermDD 50.
Тип события: Ошибка
Источник события: TermDD
Категория события: Отсутствует
Код события: 50
Дата: 12.01.2011
Время: 15:47:02
Пользователь: Н/Д
Компьютер: TS01
Описание:
Компонент "DATA ENCRYPTION" RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента
Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp".
Данные:
0000: 00 20 04 00 02 00 52 00 . ....R.
0008: 00 00 00 00 32 00 0a c0 ....2..À
0010: 00 00 00 00 32 00 0a c0 ....2..À
0018: 00 00 00 00 00 00 00 00 ........
0020: 00 00 00 00 00 00 00 00 ........
0028: 92 01 00 00 ’...
Сначала я грешил на VPN-туннель, через который пользователи подключались к серверу, но потом выяснилось, что и некоторые пользователи в локальной сети получали точно такое же сообщение.
Погуглив, нашел несколько вариантов решения проблемы:
1. Encryption levels defined on the RDP-TCP connection (or ICA, if appropriate), are set too high for the client to successfully negotiate. For example, a client set to Low encryption would be unable to connect to a server with High (or now, FIPS compliant) encryption levels defined. Additionally, XP and XP SP1 clients are currently unable to connect at all if «FIPS compliant» encryption level is set (article in progress on this issue).
To check this, open Terminal Services Configuration (tscc.msc) on the Terminal Server, select the RDP-Tcp connection, select properties, and view the Encryption settings on the General tab. Verify that this is set to Client Compatible, or low, and retest the connection (if needed).
Начал с него, как с самого простого 🙂 Поставил низкий уровень шифрования, перезагрузил сервер — ошибка, к сожалению, не пропала.
Пришлось переходить ко второму варианту:
2. Another frequent cause of these problems stems from issues with some registry values in the TermService\Parameters registry key. To this end, could you export the following key: HKLM\System\CurrentControlSet\Services\TermServices\Parameters
After doing this, delete the Certificate, X509 Certificate, and X509 Certificate ID values, and restart the Terminal Server. These values should be regenerated on reboot (but keep the Exported values just in case). This is documented in M323497. The X509 Certificate and X509 Certificate ID values have also been known to cause this problem, so delete them as well. Also see M329896. In 9 out of 10 cases this resolves the issue.
Удалил значения указанных ключей, предварительно сделав бекап этой ветки реестра, перезагрузился.
Почему-то значение ключа Certificate не создалось автоматически — не беда, добавил старое из бекапа 😉
После еще одной перезагрузки пользователи успешно подключились к серверу и уже сутки не жалуются. Ошибка TermDD 50 больше не появляется.
Ниже приведу третий вариант решения проблемы, хотя мне он и не понадобился 🙂
3. The third possibility is that some software you are installing is overwriting some of the files needed for the protocol stream. Schannel.dll, rsaenh.dll, and several others are involved in this process.