Столкнулись с проблемой. Windows 2008 Server R2 Standart.
Сервер используется для терминального доступа по RDP из вне.
На сервере поднята служба удаленных рабочих столов.
Компонент RDP версии 7.1.
Уровень безопасности — Согласование
Уровень шифрования — Совместимый с клиентским
В некоторые моменты времени в логе «События управления»
появляются ошибки вида «Уровень безопасности сервера терминалов обнаружил ошибку в потоке протокола и отключил
этот клиент. IP-адрес клиента: XXX.XX.XX.XXX.«
и «Компонент
X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента«
Источник события TermDD
Далее доступ с этого IP по RDP невозможен в течение, примерно 2х суток.
Telnet на 3389 в этот период с блокированного IP не проходит.
С других IP подключения проходят.
Можете подсказать, как лечится данная проблема?
Перерыли весь интернет, ничего конкретного по данной проблеме не обнаружили.
Может быть есть средство, хотя-бы для разблокировки IP вручную?
Изменение уровней безопасности в настройках протокола RDP не влияет на наличие проблемы.
Диагностика лицензирования ошибок не выдает (режим лицензирования установлен — для пользователя)
- Remove From My Forums
-
Question
-
I did quite a bit of online research prior to asking my own question, but none of the solutions I’ve found online really pertain to the issue we’re experiencing.
We have 2 Windows 7 Pro PCs in the office. They are accessed via RDP from within the same network/location. The systems that are accessing these 2 PCs are an XP Pro machine and a Mac. The clients stay connected for randomly lengths of time
(no longer than 1 hour) before the session goes black and disconnects them randomly. When the disconnect occurs, it’s not due to inactivity. The user has to wait several minutes before they are able to reconnect.
On the Windows 7 PCs, Event Viewer gives:Event ID: 50 The RDP protocol component X.224 detected an error in the protocol stream and has disconnected the client.
Event ID: 56 The Terminal Server security layer detected an error in the protocol stream and has disconnected the client.I’ve seen suggestions of checking registry keys and a lot of suggestions regarding Windows Server and Terminal Server, but they don’t apply to our situation. Please let me know if more information is required. Thank you!
Answers
-
Hi,
Do you enable the
IEEE 802.1x authentication?Regarding the issue, I suggest updating the network adapter driver manually on Windows 7 PCs. Also update the router’s driver and firmware.
If the issue persists, you could disable the TCP Offload. To do this,
a.
Run the following commands on both the client and the server to disable NIC offloading.netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
b.
Modify the following registry key to disable netDMA on the client and the server.HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersEnableTCPA
Note: If this registry entry does not exist, right-click Parameters, point to New, click DWORD Value, type EnableTCPA, and then press ENTER.
Value: 0
You can also refer to the following KB to troubleshoot the issue. Hope it helps.
http://support.microsoft.com/kb/2477023
Best Regards,
Niki
Please remember to click «Mark as Answer» on the post that helps you, and to click «Unmark as Answer» if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
-
Marked as answer by
Friday, May 20, 2011 2:30 PM
-
Marked as answer by
Обновлено 16.06.2017
Добрый день уважаемые читатели и гости блога, сегодня столкнулся с такой ситуацией, при попытке подключиться к серверу терминалов на Windows Server 2008 R2 я получил ошибку «Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера.» после ввода логина и пароля, что говорит как минимум о том, что порт доступен, давайте смотреть как можно решить данную проблему и восстановить доступ.
Причины ошибки «Повторите попытку подключения»
В прошлый раз мы с вами победили ошибку с синим экраном dpc watchdog violation, победим и эту, но для начала нужно понять причину всего этого действия. Вот как выглядит данная проблема:
Как я и писал выше, появляется она после ввода корректного логина и пароля.
- Вся эта канитель началась еще с 2014 года, после обновлений KB2992611 и последующих. В момент установки данных обновлений ужесточился уровень безопасности и шифрования.
- Вторая возможная причина, это наличие программ КриптоПро или VipNet, у меня был именно второй вариант
- Другие сторонние программные обеспечения по шифрованию.
Если вы посмотрите логи Windows, то сможете обнаружить вот такие системные предупреждения:
- возникло следующее неустранимое предупреждение: 36888. Внутренне состояние ошибки: 1250
- Компонент X.224 RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Как решить ошибку с RDP подключением
Существует несколько методов решения ошибки «Не удается подключиться к удаленному компьютеру. Повторите попытку подключения. Если проблема повторится, обратитесь к владельцу удаленного компьютера.» что вы должны сделать:
- Удалить необходимые обновления Windows
- Удаление или обновление «Крипто ПРО» и VipNet
- Понижение требования к уровню шифрования
- Установка дополнительных обновлений
Удаление или обновление ПО
Начинаю я с этого метода, так как он самый правильный и с точки удобства и с точки безопасности. Если вам данное ПО не нужно, то советую его удалить его и провести очистку системы от мусора, если же программы нужны, то рассмотрите вариант их обновления на свежие версии в которых уже таких проблем нет. В моем случае это не получилось сделать, так как мне была необходима старая версия VipNet.
Удаления обновления KB2992611
Следующим методом я вам посоветую установка новых обновлений, которые это решают, могу посоветовать KB3018238 (оно идет теперь вместе с KB2992611) и KB3011780, с ходом времени, данные обновления могут перекрываться уже более новыми, так, что следите за ними на официальном сайте Microsoft. Если KB2992611 установлено, то попробуйте его удалить, проверить возможность подключения и снова поставить.
Скачать KB2992611 https://www.microsoft.com/ru-ru/download/details.aspx?id=44618
Скачать KB3011780 https://www.microsoft.com/ru-ru/download/details.aspx?id=44966
Скачиваете и производите обновление, это похоже на шаги описанные в проблеме, где windows 7 не находит обновления, мы так же устанавливали автономные версии.
Понижение требования к уровню шифрования
Не самое правильное решение, так как уменьшает уровень защиты и шифрования трафика, но может быть палочкой-выручалочкой в некоторых ситуациях. В настройках сервера терминалов снизить уровень «безопасности/уровень шифрования». Для этого заходите в «Пуск > Администрирование > Удаленный рабочий стол > Конфигурация узла сеансов удаленного рабочего стола», выбираете «Настройка для сервер», далее вкладка «Общие» и два пункта:
- Уровень безопасности > Уровень безопасности RDP
- Уровень шифрования > Низкий
Все теперь повторите подключение и повторите попытку зайти по RDP, ошибка должна исчезнуть, но поищите возможность все же обновиться.
Недавно, после очередного обновления сервера терминалов на базе 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 TermServiceParameters registry key. To this end, could you export the following key: HKLMSystemCurrentControlSetServicesTermServicesParameters
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.
Запись опубликована в рубрике IT с метками terminal, windows. Добавьте в закладки постоянную ссылку.