После установки пакета Windows 2000 Security Rollup 1 (SRP1) клиенты служб терминалов, возможно, не смогут подключиться к серверу этих служб. Такая проблема может также возникнуть при подключении к серверу служб терминалов с использованием веб-подключения к удаленному рабочему столу на компьютере с операционной системой Windows XP Professional. При этом в журнале системных событий регистрируется событие с кодом 50.
Тип: Ошибка
Источник: TermDD
Код (ID): 50
Описание:
Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Причина:
Возможное состояние состязания между библиотеками динамической компоновки (DLL) Icaapi.dll и Rdpwsx.dll может стать причиной отсутствия синхронизации закрытого ключа сертификата на сервере служб терминалов.
Решение
1. Откройте редактор реестра.
2. Найдите и выделите раздел реестра
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermService\Parameters
3. Удалите в этом разделе следующие параметры:
* Certificate
* X509 Certificate
* X509 Certificate ID
4. Закройте редактор реестра и перезагрузите сервер.
Оригинал и доплонительные ссылки: http://support.microsoft.com/kb/323497/ru
Недавно, после очередного обновления сервера терминалов на базе 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.
Запись опубликована в рубрике IT с метками terminal, windows. Добавьте в закладки постоянную ссылку.
- Remove From My Forums
-
Общие обсуждения
-
Добрый день. В компании развернуто несколько серверов под управлением Windows 2008, Windows 2008 R2.
Структура стандартная — AD, DNS, DHCP, Службы терминалов.
ПОд R2 я могу подключиться к удаленной терминальной сессии пользователя через диспетчера службы терминалов, а в 2008.. ошибка подключения.
В логе: Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента
Перелапатил уже все что только можно, решения не нашел. Что посоветуете?
-
Перемещено
Kathy Sun
20 апреля 2012 г. 9:29
merge forums (От:Windows Server 2008) -
Изменен тип
Petko KrushevMicrosoft contingent staff
27 марта 2013 г. 15:01
Давность и отсуствие действий
-
Перемещено
Все ответы
-
Та же ерунда. перелопатил пол-гугла ничего вменяемого не нашел, кроме того, что вроде как понял, что это из-за разницы в протоколе шифрования твоего и клиента.
Практическими методами понял следующее, что начинает у меня подключаться только если использую хрюшный клиент 6.1, для этого у себя на семерке запускаю ХР-моде и в нем родного клиента, с него в общем подключается!
Гугл советует поиграть методами шифрования через политики, но у меня этот номер не вышел, хотя возможно просто политики не применились или ещё что, я более подробно не смотрел.
Резюме.. Кривой способ подключения найден.
Если кто подскажет человечий, так же буду благодарен!
-
Если ли здесь гуру которые могли бы помочь в данном вопросе? Народ, что посоветуете?
-
Всем добрый день!
Столкнулся с такой же проблемой. В организации 2 терминальных сервера Windows 2008 Enterprise. Пока в роли клиентов терминального сервере выступали станции под Windows XP Pro SP3 — все было нормально, подключение к удаленному сеансу пользователей проходило
без ошибок. После того, как в роли клиентов выступили станции Windows 7 Pro (x64) SP1 — при подключении к сеансу пользователя его отрубает, удаленное управление не происходит… Также было испробовано множество вариантов решения из интернета — безрезультатно…
Одна надежда на помощь специалистов Microsoft… -
Проблема все еще актуальна… В предложенной Вами ветке решения не нашел…
-
А может быть тупо дело в настройке терминал сервера? Там что-то было из серии «проверка на уровне сети». При этой настройке повышались требования по безопасности. Например ХРюшных старых клиентов не пускало. Какая версия RDP клиента у вас на клиентских
машинах 5я или 6я ? -
Добрый день, Тимур!
Настройки сервера:
-Уровень безопасности RDP
-Уровень шифрования совместимый с клиентским (пробовал ставить низкий — не помого)
Версия на клиентах Windows XP SP3 — 6.1.7600.16722
Версия на клиентах Windows 7 x64 SP1 — 6.1.7601.17514
Кстати, попробовал сделать удаленное управление от ХР-шного клиента на 7-й — получилось… Странно все это…
-
Проблема один в один как у
AlexSKG. При неудачной попытке удаленного управление пользователя выбивает.Решения не нашел. Помогите пожалуйста. -
В моем случае это решилось отключением алгоритмов сжатия RDP протокола, если конечно у вас это настроено. Проверьте — Политика «локальный компьютер» / конфигурация компьютера / административные шаблоны
/ компоненты windows / службы терминалов / сервер терминалов / среда удаленных сеансов / задание алгоритма сжатия для данных RDPДа, и не лишним будет будет в ветке безопасность установить уровень шифрования для клиентских подключений — совместимый с клиентским
-
Изменено
Ant_Tech
3 декабря 2014 г. 6:49
так надо
-
Изменено
Используем «gpedit.msc» для решения поднадоедливой проблемы.
Раньше я уже упоминал аналогичную Error id 50 источника TermDD но на Windows XP. В этот раз проблема появляется после завершения удаленного управления другим сеансом на Windows server 2008 R2. Наблюдаем сообщение «Этот сеанс будет отключен из-за ошибки протокола. Попробуйте повторить попытку подключения к удаленному компьютеру» и отвалившийся терминал. В журнале фиксируется событие:
Тип: Ошибка
Источник: TermDD
Код (ID): 50
Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Решаем:
«Локальная политика безопасности» gpedit.msc -> Котфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Среда удаленных сеансов. Выбираем параметр «Задание алгоритма сжатия данных RDP«. И указываем ему значение «Не использовать алгоритм сжатия RDP«. Применяем обновленную политику gpupdate /force или перегружаем для надежности.
Чуть больше читаем на сайте поддержки Microsoft: http://support.microsoft.com/kb/976110/ru
Недавно, после очередного обновления сервера терминалов на базе 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. Добавьте в закладки постоянную ссылку.
Добрый день!
В организации имеется 2 сервера терминалов на MS Windows 2008 Server Enterprise 32 bit SP2. Рабочие станции в основном Windows XP Pro SP3 32bit, но часть компьютеров (админские) под управлением Windows 7 Профессиональная SP1 64bit. По характеру работы
иногда требуется подключиться к терминальному сеансу пользователя через «удаленное управление» для осуществления помощи.
Проблема заключается в следующем: при попытке Удаленного управления терминальным сеансом от клиента, подключившегося с Windows 7, сессия пользователя, к которому происходило подключение, отключается с предупреждением «Сеанс подключения к удаленному рабочему
столу завершен. Возможно, подключение было завешено администратором сети. Повторите попытку подключения или обратитесь за помощью в службу технической поддержки.» В это же время на сервере возникает ошибка TermDD
Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента
Версия на клиентах Windows XP SP3 — 6.1.7600.16722
Версия на клиентах Windows 7 x64 SP1 — 6.1.7601.17514
Было замечено, что играет роль только версия клиента, от которого идет попытка удаленного управления. Т.е. удаленное управление от клиенты Windows XP на Windows 7 происходит без ошибок.
Для решения данной проблемы было безрезультатно испробовано множество вариантов из различных форумов…
Заранее благодарен за любую помощь…
-
Перемещено
21 апреля 2012 г. 12:45
merge forums (От:Windows Server 2008) -
Изменен тип
Petko KrushevMicrosoft contingent staff
27 марта 2013 г. 14:47
Давность и отсуствие действий
После установки пакета Windows 2000 Security Rollup 1 (SRP1) клиенты служб терминалов, возможно, не смогут подключиться к серверу этих служб. Такая проблема может также возникнуть при подключении к серверу служб терминалов с использованием веб-подключения к удаленному рабочему столу на компьютере с операционной системой Windows XP Professional. При этом в журнале системных событий регистрируется событие с кодом 50.
Тип: Ошибка
Источник: TermDD
Код (ID): 50
Описание:
Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Причина:
Возможное состояние состязания между библиотеками динамической компоновки (DLL) Icaapi.dll и Rdpwsx.dll может стать причиной отсутствия синхронизации закрытого ключа сертификата на сервере служб терминалов.
Решение
1. Откройте редактор реестра.
2. Найдите и выделите раздел реестра
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServiceParameters
3. Удалите в этом разделе следующие параметры:
* Certificate
* X509 Certificate
* X509 Certificate ID
4. Закройте редактор реестра и перезагрузите сервер.
Оригинал и доплонительные ссылки: http://support.microsoft.com/kb/323497/ru
Недавно, после очередного обновления сервера терминалов на базе 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. Добавьте в закладки постоянную ссылку.
Hello everybody,
I am trying to remote desktop connect to a pc running Windows 10 Pro trough a VPN. The VPN is an IPSec one, and the vpn clients I am using are both the one provided by Android 8 and the Remote Desktop client provided by Windows 7. In both cases the rdp connection
starts but then immediately crashes and I get the following error message:
«Your session ended because of a data encryption error. If this keeps happening, ask your admin or tech support for help. Error code: 0x407»
I have read carefully solutions provided in this thread:
https://social.technet.microsoft.com/Forums/lync/en-US/1fe7892c-36c3-479a-8e51-cd7f94ea2e87/quotbecause-of-an-error-in-data-encryption-this-session-will-endquot?forum=winserverTS
but none of the solutions provided there apply to my case.
First of all, I haven’t the values
- Certificate
- X509 Certificate
- X509 Certificate ID
under the subkey HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServiceParameters
Then, the pc I am trying to connect to is using a wireless connection (Intel AC 9560) and not a wired one, so I couldn’t find he property IPv4
Large Send Offload in its advanced configuration. I tried disabling ARP offload for WoWLAN and NS offload for WoWLAN, but with no luck.
I can’t also use the trick of uninstalling the Link-Layer Topology (Mapper I/O Driver and Responder) protocols, as well as
the QoS Packet Scheduler service on client machine, since I am using an Android tablet mainly as client, even if this fix worked for a Windows pc client, it would be of practically no use for me.
I am not using Sonicwall or Cisco vpn client, so the solutions related to these products don’t work for me (I don’t have the Citrix DNE LightWeight Filter service in the network adaptor).
The only thing that apparently seems to solve this issue, is to go to sharing properties of the wireless card and
to check «Allow other network users to connect through this computer’s internet connection». But this works for a limited random period of time after enabling this feature, then the error comes back again.
Can anybody help me to solve this issue?
- Edited by
Thursday, January 17, 2019 6:11 PM
Hello everybody,
I am trying to remote desktop connect to a pc running Windows 10 Pro trough a VPN. The VPN is an IPSec one, and the vpn clients I am using are both the one provided by Android 8 and the Remote Desktop client provided by Windows 7. In both cases the rdp connection
starts but then immediately crashes and I get the following error message:
«Your session ended because of a data encryption error. If this keeps happening, ask your admin or tech support for help. Error code: 0x407»
I have read carefully solutions provided in this thread:
https://social.technet.microsoft.com/Forums/lync/en-US/1fe7892c-36c3-479a-8e51-cd7f94ea2e87/quotbecause-of-an-error-in-data-encryption-this-session-will-endquot?forum=winserverTS
but none of the solutions provided there apply to my case.
First of all, I haven’t the values
- Certificate
- X509 Certificate
- X509 Certificate ID
under the subkey HKEY_LOCAL_MACHINESystemCurrentControlSetServicesTermServiceParameters
Then, the pc I am trying to connect to is using a wireless connection (Intel AC 9560) and not a wired one, so I couldn’t find he property IPv4
Large Send Offload in its advanced configuration. I tried disabling ARP offload for WoWLAN and NS offload for WoWLAN, but with no luck.
I can’t also use the trick of uninstalling the Link-Layer Topology (Mapper I/O Driver and Responder) protocols, as well as
the QoS Packet Scheduler service on client machine, since I am using an Android tablet mainly as client, even if this fix worked for a Windows pc client, it would be of practically no use for me.
I am not using Sonicwall or Cisco vpn client, so the solutions related to these products don’t work for me (I don’t have the Citrix DNE LightWeight Filter service in the network adaptor).
The only thing that apparently seems to solve this issue, is to go to sharing properties of the wireless card and
to check «Allow other network users to connect through this computer’s internet connection». But this works for a limited random period of time after enabling this feature, then the error comes back again.
Can anybody help me to solve this issue?
- Edited by
Thursday, January 17, 2019 6:11 PM
Этот сеанс будет прекращен из-за ошибки шифрования данных
На Windows 11 при подключении к рабочему серверу по RDP через VPN сегодня словил ошибку:
Этот сеанс будет прекращен из-за ошибки шифрования данных. Попробуйте подключиться заново к удаленному компьютеру.
This session will be terminated due to a data encryption error. Try reconnecting to the remote computer.
После повторного соединения снова выскочила ошибка и соединение RDP завершилось. И так каждые 5-10 минут.
Источник проблем
Погуглил вопрос и вычитал много странного. В первую нужно определить источник проблемы: сервер или клиент. Я параллельно подключился к домашнему серверу по RDP и вскоре получил ту же самую ошибку. Одновременно отвалилось и рабочее подключение и подключение к домашнему серверу. Значит, дело именно в клиенте, т.е. в моём компьютере.
Проверка при подключении к домашнему серверу исключила из источников проблем сеть провайдера, роутер и возможные потери данных, ибо сервер у меня в той же домашней сети что и рабочий ноутбук.
Переключил на ноуте проводную сеть на Wi-Fi и получил ту же ошибку: патчкорд не при чём, сетевая карта тоже.
Решение
Перезагрузил ноутбук, помогло. Вероятно, что-то пошло не так в ОС или работающих службах.
Окончательно вылечил так:
Лечим Windows 11 Pro
Альтернативные решения
Определяем источник проблем: сервер или клиент.
Перезагружаем сервер/клиент. Если не помогает перезагрузка, то устанавливаем последние обновления Windows. На клиенте обновляем клиент RDP до последней версии.
Если обновление не помогло, то пробуем в настройках сетевой карты отключить параметр Large Send Offload (проводное соединение).
Для старых версий Windows есть рекомендации от поддержки Microsoft — перейти к ветке реестра:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTermServiceParameters
и удалить там ключи «Certificate», «X509 Certificate», «X509 Certificate ID». Предварительно сделайте резервную копию ветки реестра.
Следующий шаг — провести проверку на вирусы, посмотреть, нет ли каких лишних параметров в настройках сетевой карты.
Ещё один вариант решения — обновление драйвера сетевой карты, замена сетевой карты.
Похожие материалы
Настройка зеркалирования в Microsoft SQL Server 2014
Олег
- 31 января 2018
- Подробнее о Настройка зеркалирования в Microsoft SQL Server 2014
Зеркалирование или mirroring в MS SQL Server 2014 всё ещё есть. Это очень полезное решение для повышения доступности базы данных. Если ваш сервер упал, посыпались винты, сгорел ЦОД, то возможность быстро переключиться на резервный сервер, не занимаясь восстановлением сервера или БД из бэкапа, экономит кучу времени, денег и нервов. Однако, не следует рассматривать зеркалирование как замену резервному копированию, так как оно не спасает от случайного удаления данных.
Почитать
Утро пятницы началось с жалоб некоторых пользователей на невозможность подключится к удаленному рабочему столу Windows Server 2008 R2 и Windows Server 2012 R2.
Произошла ошибка при проверке подлинности. Указанная функция не поддерживается.
Причиной ошибки может быть исправление шифрования CredSSP. Дополнительные сведения см. статье https://go.microsoft.com/fwlink/?linkid=866660
Причиной отказа в подключении послужило обновление безопасности Windows, закрывающее уязвимости в протоколе CredSSP (бюллетень CVE-2018-0886), в результате чего клиентам запрещалось подключаться к удаленным RDP серверам с непропатченой версией CredSSP. Таким образом, клиентские машины, установившие майские обновления остались не при делах.
Есть несколько путей решения проблемы. Наиболее правильным я считаю всё-таки установку обновления для закрытия уязвимости CredSSP на сервере, однако такое решение может выйти боком в некоторых случаях. Приведу простой пример когда не стоит гнаться за обновлениями.
В сети имеются компьютеры на старой версии Mac OS X (10.7.5), для которых не существует свежей версии RDP-клиента и после такого обновления теряется возможность работы с сервером. Вопрос безопасности соединения мобильных пользователей в таком случае решается VPN туннелем.
Так что, для начала рассмотрим вариант, позволяющий убрать уведомление безопасности и блокировку подключения с установленным обновлением безопасности без обновления самого сервера. Удаление самого обновления, конечно решает проблему, но неужели вы будете заниматься этим постоянно?
Отключение уведомления об ошибке шифрования CreedSSP на клиенте
Можно пойти двумя путями — внести изменения через редактор локальных групповых политик (не прокатит в редакциях Windows Home), либо напрямую в реестр с помощью командной строки. Второй способ более быстрый и универсальный — в командной строке, запущенной от имени администратора, выполним:
REG ADD HKLMSOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemCredSSPParameters /v AllowEncryptionOracle /t REG_DWORD /d 2
Если же вам удобнее использовать редактор локальных групповых политик, то запустив редактор gpedit.msc, переходим в раздел:
Конфигурация компьютера -> Административные шаблоны -> Система -> Передача учетных данных
(Computer Configuration -> Administrative Templates -> System -> Credentials Delegation)
Открываем параметр с именем «Исправление уязвимости шифрующего оракула» (Encryption Oracle Remediation), и нажимаем «Включено» («Enabled»). Уровень защиты ставим как «Оставить уязвимость» (Vulnerable).
Обновить политики на компьютере можно командой, после чего подключение по RDP должно заработать:
gpupdate /force
Установка обновления для исправления шифрования CreedSSP на сервере
Установить отсутствующие обновления безопасности на сервере можно через службу Windows Update или вручную. Чтобы не тянуть кучу лишнего, вот прямые ссылки на обновления для разных версий Windows Server:
- Windows Server 2012 R2 / Windows 8: KB4103715
- Windows Server 2008 R2 / Windows 7: KB4103712
- Windows Server 2016 / Windows 10 1607: KB4103723
Учтите, что после установки обновления сервер уйдет в перезагрузку.
Подписывайтесь на канал
Яндекс.Дзен
и узнавайте первыми о новых материалах, опубликованных на сайте.
Используем «gpedit.msc» для решения поднадоедливой проблемы.
Раньше я уже упоминал аналогичную Error id 50 источника TermDD но на Windows XP. В этот раз проблема появляется после завершения удаленного управления другим сеансом на Windows server 2008 R2. Наблюдаем сообщение «Этот сеанс будет отключен из-за ошибки протокола. Попробуйте повторить попытку подключения к удаленному компьютеру» и отвалившийся терминал. В журнале фиксируется событие:
Тип: Ошибка
Источник: TermDD
Код (ID): 50
Компонент «DATA ENCRYPTION» RDP-протокола обнаружил ошибку в потоке протокола и отключил этого клиента.
Решаем:
«Локальная политика безопасности» gpedit.msc -> Котфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Среда удаленных сеансов. Выбираем параметр «Задание алгоритма сжатия данных RDP«. И указываем ему значение «Не использовать алгоритм сжатия RDP«. Применяем обновленную политику gpupdate /force или перегружаем для надежности.
Чуть больше читаем на сайте поддержки Microsoft: http://support.microsoft.com/kb/976110/ru