Столкнулся со странным сообщением “
Произошла внутренняя ошибка
/
An internal error has occurred
” при RDP подключении к недавно развернутому серверу RDSH на Windows Server 2012 R2 из Windows 10. Буквально вчера RDP подключение к серверу работало нормально, но после установки и настройки RemotApp приложений и перезагрузки сервера, я не могу удаленно подключиться к его рабочему столу. Служба Remote Desktop Services судя по всему работает, так как пароль пользователя при подключении запрашивается.
Как я понял, сообщение RDP консоли “Произошла внутренняя ошибка” может появляться в различных случаях и иметь совершенно различные причины, связанные как с сервером Remote Desktop, так и с клиентом. В этой статье я постарался собрать все варианты решения и сценарий, который помог мне.
Изучив логи RDP подключений на удаленном RDS сервере, я не увидел никаких особенных ошибок. В журнале Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational видно, что RDP сессия создается:
The server accepted a new TCP connection from client 10.10.1.60:64379.
Connection RDP-Tcp#3 created
Но потом без какой-либо ошибки RDP сеанс завершается:
The server has terminated main RDP connection with the client.
The disconnect reason is 0
Проверьте состояние службу Remote Desktop Services на удаленном сервере и перезапустите ее. Вы можете удаленно перезапустить службу через консоль Services.msc (Connect to another computer), но гораздо проще проверить состояние службы и перезапустить ее через PowerShell:
(Get-Service TermService -ComputerName msk-ts1).status
Служба запушена (Running), перезапустим ее:
Get-Service TermService -ComputerName msk-ts1| Restart-Service –force –verbose
Но проблему это не решило.
Какие еще варианты решения проблемы мне удалось найти в сети:
- Если у вас на удаленном сервере установлен КриптоПРО, он может быть источником проблем с rdp подключением. Попробуйте отключить проверку контрольных целостности файлов (проверки контрольных сумм) в КриптоПро через реестр. Перейдите в ветку реестра
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\CProIntegrityи измените значение параметра CheckMode на 0. Перезагрузите сервер. - Если в журнале событий TerminalServices-RemoteConnectionManager вы встретите событие с EventID 1057 (The RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on SSL connections), перейдите в каталог
C:\ProgramData\Microsoft\Crypto\RSA, переименуйте папку Machinekeys в Machinekeys_bak и перезапустите службу TermService. - Также нашел информацию, что RDP проблема “Произошла внутренняя ошибка” встречалась в Windows 10 1809, если на удаленном компьютере включена политика Configure H.264/AVC hardware encoding for Remote Desktop connections (находится в секции GPO: Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Remote Session Environment). Для решения этой проблемы достаточно отключить UDP протокол для RDP, создав в ветке реестра
HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\ClientпараметрfClientDisableUDPсо значением 1. - В комментариях Ivan оставил очень полезный фикс.
Проблема с ошибкой RDP может быть в наличии некоего счетчика учитывающего максимальное количество подключений в Windows.
В десктопных версиях Windows — 100, в Windows Server -3000. Для сброса счетчика достаточно перезагрузить компьютер, или просто увеличить лимит через реестр:
REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server" /v MaxOutstandingConnections /t REG_DWORD /d 65536
Ни один из рассмотренных выше сценариев не был применим в моем случае. Я совершенно случайно обнаружил, что с других компьютеров нет проблем с подключением к этому RDS серверу. Значить проблема только с моим компьютером, а не с сервером.
Я очистил историю RDP подключений в ветке
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
и сбросил кэш RDP в каталоге
C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\Cache
(перед удалением закройте все запущенные сеансы mstsc.exe):
del "C:\Users\%Username%\AppData\Local\Microsoft\Terminal Server Client\cache"
После этого перезагрузил свой компьютер, и ошибка RDP подключения исчезла!
Редко пишу комменты, но тут не удержался, т.к. даже на таком профессиональном сайте как этот, начали появляться статьи уровня юных читателей «кулл хацкер»… Безобразие… Не несите ерунду.
Все, что Вы тут понаписали, не поможет и со временем ошибка появится, Вас в данном случае просто спасла перезагрузка, которая сбрасывает хитрый счетчик, который в свою очередь подсчитывает не очень корректные заходы\выходы и при достижении определенных значений блокирует RDP-сервис, считая, что на него осуществляется сетевая атака, так происходит например при некачественном WiFi на стороне клиента.
Этой «проблеме» уже несколько лет, я посвятил ее решению кучу времени и на данный момент работает только это (10000 хватает надолго и точно до очередной плановой перезагрузки, например при обновлении):
A temporary workaround for this issue is to increase the maximum outstanding connections limit. On client SKUs it is 100 by default, while on server SKUs it is 3000. The following DWORD registry key controls this value:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\
DWORD: MaxOutstandingConnections
VALUE: 10000
Всем успехов.
Естественно это надо делать не на RDS-сервере, а на компьютере, к котрому надо подключаться.
Спасибо за критику 🙂
Хотелось бы увидеть какие симптомы при вашем решении были в логах клиента/сервера. Возможно я что-то пропустил и вы ткнете меня в нужные события.
В том-то и дело, что у меня в логах тишина. В сети нашел несколько вариантов, которые помогали людям, решил оставить их здесь. Но как, я понял симптомы у всех разные.
По этому у меня есть сомения по поводу универсального решения.
Не за что.
Симптом всегда один, сообщение с красным крестом, которое Вы написали: «Произошла внутренняя ошибка/ An internal error has occurred», если коннектиться напрямую, если же через RDS, ошибка «маскируется» стандартным сообщение о недоступности узла. В логах где-то поглубже тоже вроде появляются мессаги, раскрывающие смысл, описанный мной выше и типа сервис поэтому отключается. Где точно не помню, т.к. для себя я уже закрыл эту проблему. В каждую систему Win10 по умолчанию вбиваю это в реестр (кое в каких доменах даже кажется через политики прописал) и больше не парюсь.
Ну а Вы можете конечно и дальше сомневаться и писать красивые статьи\исследования на эту тему.
В сети же как и Вы молодые исследователи готовы сутками изобретать велосипеды и мазать вилами по воде.
Иван, критикуете?! предлагайте! Покажите свою профессиональную статью по этой ошибки, с полным разбором. А то «В логах где-то поглубже… Где точно не помню..» чувствуется не ответ профессионала, а «Мамкиного хакера».
А тут просто льется желчь неудачника «Ну а Вы можете конечно и дальше сомневаться и писать красивые статьи\исследования на эту тему.»
дык он и предложил увеличить до 10000 вместо 3000
вот же его предложение:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\
DWORD: MaxOutstandingConnections
VALUE: 10000
Вы б добавили решение Ivan в статью. Помогло, и повезло что вообще комментарии читать пошел. Ivan — спасибо.
Принято!
Спасибо Вам, в момент написания коммента Вы меня очень выручили!!!
Вот соглашусь с Иваном, краткое содержание статьи «бяда, я загуглил, нашел вот это, хер знает».
Это не статья профессионала с разбором что и почему произошло на низком уровне.
Ivan, это не решение проблемы, а всего лишь обходной путь. Применять его без разбора всем компам, я бы не стал.
Hexen05, дословно конечно Вы правы, т.к. само по себе это не решение технической проблемы, для себя я имел ввиду приемлемое решение проблемы периодической остановки производственного процесса в ожидании реального решения, т.к. есть официальные мануалы,теоретические выкладки, возможности бесконечных исследований в песочницах на самом низком уровне, красивые статьи сертифицированных специалистов, а есть реальная жизнь, в которой приходится принимать решения, чем-то жертвовать, где-то брать ответственность, для того чтобы твоя компания, в которой реально учитывают деньги и время, продолжала работать. Ну а статья выше уж точно не про это.
Была такая же проблема, почему то перестал подключаться к одному RDS серверу с ошибкой An internal error has occurred. Перезагрузил клиента и все решилось.
Может и не нужны такие сложности 🙂
Тоже получил такую прелесть на клиенте «Произошла внутренняя ошибка». И как оказалось «дело было не в бабине» а банально слетела активация винды на клиенте, переактивировал винду, ребутнул ноут и вуаля «я тоже мамкин хакер», Всем удачи и побед.
Всем привет!
У меня ошибка «Произошла внутренняя ошибка» проявляется если я пробую переподключится на отдельностоящий RDS-сервер с другого клиента.
Т.е. если я просто закрыл сеанс и пробую переподключится с другого ПК — ошибка
Если я завершаю сеанс — с того же ПК все ОК.
На самом RDS-сервере не нашел где убирается такая «привязка»
у меня тоже окно при подключении но в логах на сервере вот что
Код ошибки, возвращенный модулем шифрования: 0x8009030D
Проблему с сертификатом не решил, а решил отключением проверки подлинности на уровне сети.
спасибо за статью.
мне помогла наводка на ключ из статьи
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\Servers
Там перечень ip_адресов на которые заходил по RDP, в моём случае 4.
Так вот, на трёх из них ИМЯКОМПА/ПОЛЬЗОВАТЕЛЬ те которые я вводил и «запомнил»,
а один, именно тот, который проблемный (внутр.ошибка) почему то имел
MicrosoftAccount\Administrator
и комп не так называется и имя не админа.
Когда и после чего слететели мои имя/юзер хз.
Поменял в реестре на своё ИМЯКОМПА/ЮЗЕР.
Тут же ошибка исчезла (без ребута)
У меня недавно появилась такая ошибка при работе через клиент Shrew VPN при подключении к рабочему офису, при этом с другими офисами проблем с RDP через Shrew VPN нет.
С рабочим офисом при использовании Cisco VPN или смене клиентского провайдера на мобильный интернет ошибки нет.
Вот не знаю куда копать, чтобы RPD заработал через клиентского провайдера и через Shrew VPN. Подскажите?
Может быть что-то на Cisco ASA надо смотреть и обратиться за помощью к сетевикам?
Проблема решилась, но решение неясно.
В Shrew VPN для каждого профиля VPN можно изменить MTU, по умолчанию — 1380. Изменил на 1300 — подключиться по RDP получилось.
В Cisco VPN Clien MTU по умолчанию установлен на 1300, но при сменить его на 1500 — то тоже работает RDP, и после этого заработало и в Shrew VPN со значениями MTU по умолчанию так и с 1500.
Спасибо большое! Помог третий вариант с созданием параметра fClientDisableUDP.
А нет, на следующий день ошибка вернулась. Помог метод, который очень высокомерно описал Ivan в самом первом комментарии. Если вкраце, то нужно запустить командную строку от имени администратора, вставить эту строку и нажать enter:
REG ADD «HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server» /v MaxOutstandingConnections /t REG_DWORD /d 65536
Мне помогло это
reg add «HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server» /v Enabled /t REG_DWORD /d 1 /f
reg add «HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server» /v Enabled /t REG_DWORD /d 1 /f
reg add «HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server» /v Enabled /t REG_DWORD /d 1 /f
Была отключена служба настройка сервера удаленных рабочих столов
столкнулся с этой ошибкой. Хостер мне выдал такую инструкцию
Нажмите на кнопку «Пуск» и наведите на значок «Windows PowerShell»
справа-сверху. Кликните по нему правой кнопкой мыши и нажмите «Запуск от имени
администратора»
Сначала:
— Проверьте версию net framework командой:
Get-ItemProperty «HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full»
Если версия меньше 4.7.2 скачайте новую версию [1]по ссылке.
Далее, введите эти команды последовательно:
— [Net.ServicePointManager]::SecurityProtocol =
[Net.SecurityProtocolType]::Tls, [Net.SecurityProtocolType]::Tls11,
[Net.SecurityProtocolType]::Tls12
— Install-Module -Name StopBruteforce
— После завершения установки, введите еще одну команду:
Stop-Bruteforce
Если проблема вернется со временем, повторите ввод команды «Stop-Bruteforce»
или используйте команду «Protect-FromBruteforce», если у вас статический IP
адрес, это окончательно решит проблему.
Вроде работает. Иногда, правда, ошибка снова вылезает, но при повторном включении «Подключение к удаленному серверу», всё включается
Нашли решение такой же проблемы здесь:
https://docs.microsoft.com/en-us/answers/questions/108219/can-not-rdp-to-2012-r2-standard-server-after-septe.html
В русской версии WS2016: «Требовать использования специального уровня безопасности для удаленных подключений по протоколу RDP» — Включена — RDP
Помог второй пункт
Помог сброс кеша
Помог снос КриптоПРО. Просто отключение CheckMode -> 0 не помогало, но за наводку — спасибо!
Не фига не понял
Столкнулся с этой ошибкой. Не подключалось с одного клиента. «Я посвятил ее решению кучу времени» )
В моем случае проблема на клиенте — Крипто Про 4 + новые обновления windows. Дополнительно в журнале регистрировалось событие «произошла неустранимая ошибка при создании учетных данных client tls»
Решилось удалением Крипто Про 4, установкой последней 5.
P.S. К автору и профессионалам комментаторам: указывайте, где изменения вносить (на сервере/ на клиенте).
Второй раз поймал такую ошибку при подключении по RDP к Windows Server 2016 и Windows 7, которые находятся в одной сети за одним роутером, при том подключение по RDP в другой офис с моего ПК в другом городе, все ок.
НО с других ПК через интернет, в том же городе где и «проблемный» офис все ок!
Ни одно решение из перечисленных в статье не помогло, ситуация явно указывает, что проблема либо на моем ПК с которого подключаюсь, либо в сетке(роутере) «проблемного» офиса, через анидески и подобное туда все подключается.
Проблема самоустраняется через некоторое время…
Проблема следующая, есть windows server 2022 поднят RDP с локальной сети все заходят все хорошо. Есть сервер windows server 2022 на нем поднят VPN сервер с RDP коннектится к серверу VPN удаленные пользователи тоже коннектятся к серверу VPN при подключении к RDP некоторые пользователи заходят без проблем у некоторых черный экран и вылазит ошибка 0х10b. Причем с одного и того же удаленного компа под одним пользователем пускает под другим нет.
При использовании VPN такое может проявляться из-за использования UDP для RDP сессии. попробуйте запретить исопльзовать UDP для rdp на проблемном клиенте. Если проблема у всех — то на сервере:
https://winitpro.ru/index.php/2023/04/18/zavisaet-rdp-sessiya-udp-transport/
Возникла такая же проблема, после недавнего применения Security Update на удаленных серверах Windows Server 2016, 2019 Data Centre (октябрьское обновление KB5044293 (сборка ОС 14393.7428)
Отлетела возможность подключения ко всем физическим и виртуальным серверам как через RDP, так и через менеджеры гипервизора, вдобавок еще улетела БД — перестали запускаться сервисы MSSQL. Перенастройка гипервизора, перезапуск служб и самих серверов, изменение реестра не помогли.
Кое как смог подключится к серверам через RDP, отключив проверку подлинности уровня сети (NLA) в RDP через скрипты powershell
Прочесал журналы событий, увидел следующие ошибки:
1. При попытке подключения через RDP в журнале Microsoft-Windows-RemoteDesktopServices-RdpCoreTS
a) RDPClient_SSL: An error was encountered when transitioning from TsSslStateCollectingCreds to TsSslStateDisconnecting in response to TsSslEventInitializeFailed (error code 0x80004005)
b) RDP_TCP: An error was encountered when transitioning from StatePreparingX224CC in response to Event_ERROR_SendingX224CC (error code 0x0).
2. В журнале System — a fatal error occurred while creating a tls client credential. the internal error state is 10010
В общем все указывало на проблемы с протоколами шифрования. Попробовал вручную и через Powershell править значения в Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols , перезагрузился.
Нифига, как вилами по воде. В конце концов помогла одна прога, которая тоже правит значения TLS, но через GUI и делает это корректно, как оказалось — IIS Crypto GUI. Скачал, запустил, поставил галочки для TLS 1.1, TLS 1.2 и TLS 1.3 (client/server) и перезагрузился. Проблема решилась.
После посмотрел, что он сделал со значениями в реестре — он перевел значения в формат hex — ffffffff вместо 1 (аналогичные друг-другу, как я понял)
Надеюсь, кому-то поможет.