Не удается подключиться к удаленному компьютеру по RDP
Не удается подключиться к удаленному компьютеру по RDP
Добрый день уважаемые читатели и гости блога, сегодня столкнулся с такой ситуацией, при попытке подключиться к серверу терминалов на 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 установлено, то попробуйте его удалить, проверить возможность подключения и снова поставить.
Скачать KB3011780 https://www.microsoft.com/ru-ru/download/details.aspx?id=44966
Скачиваете и производите обновление, это похоже на шаги описанные в проблеме, где windows 7 не находит обновления, мы так же устанавливали автономные версии.
Понижение требования к уровню шифрования
Не самое правильное решение, так как уменьшает уровень защиты и шифрования трафика, но может быть палочкой-выручалочкой в некоторых ситуациях. В настройках сервера терминалов снизить уровень «безопасности/уровень шифрования». Для этого заходите в «Пуск > Администрирование > Удаленный рабочий стол > Конфигурация узла сеансов удаленного рабочего стола», выбираете «Настройка для сервер», далее вкладка «Общие» и два пункта:
- Уровень безопасности > Уровень безопасности RDP
- Уровень шифрования > Низкий
Все теперь повторите подключение и повторите попытку зайти по RDP, ошибка должна исчезнуть, но поищите возможность все же обновиться.
Не удается подключиться к удаленному рабочему столу windows server 2008 r2
Сообщения: 14
Благодарности: 0
Да и еще: Если вместо ip использовать имя сервера, то по telnet проходит подключение к порту 3389, но через RDP не подключается по имени. На самом сервере делал telnet localhost 3389 и тоже все ок. И вывод команды netstat -an:
C:\Users\Администратор>netstat -an
Имя Локальный адрес Внешний адрес Состояние
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:3389 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5985 0.0.0.0:0 LISTENING
TCP 0.0.0.0:8092 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49154 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49155 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49156 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49157 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49158 0.0.0.0:0 LISTENING
TCP 127.0.0.1:49268 127.0.0.1:49269 ESTABLISHED
TCP 127.0.0.1:49269 127.0.0.1:49268 ESTABLISHED
TCP 192.168.1.2:139 0.0.0.0:0 LISTENING
TCP 192.168.1.2:3389 188.127.239.132:80 SYN_RECEIVED
TCP [::]:135 [::]:0 LISTENING
TCP [::]:445 [::]:0 LISTENING
TCP [::]:3389 [::]:0 LISTENING
TCP [::]:5985 [::]:0 LISTENING
TCP [::]:8092 [::]:0 LISTENING
TCP [::]:47001 [::]:0 LISTENING
TCP [::]:49152 [::]:0 LISTENING
TCP [::]:49153 [::]:0 LISTENING
TCP [::]:49154 [::]:0 LISTENING
TCP [::]:49155 [::]:0 LISTENING
TCP [::]:49156 [::]:0 LISTENING
TCP [::]:49157 [::]:0 LISTENING
TCP [::]:49158 [::]:0 LISTENING
TCP [::1]:3389 [::1]:49323 CLOSE_WAIT
TCP [::1]:49323 [::1]:3389 FIN_WAIT_2
TCP [fe80::5d39:9e7d:7e2a:1e36%11]:3389 [fe80::c01f:1604:f78:db38%11]:7375
ESTABLISHED
UDP 0.0.0.0:500 *:*
UDP 0.0.0.0:4500 *:*
UDP 0.0.0.0:5355 *:*
UDP 192.168.1.2:137 *:*
UDP 192.168.1.2:138 *:*
UDP [::]:500 *:*
UDP [::]:4500 *:*
UDP [::]:5355 *:*
Не удается подключиться к удаленному рабочему столу windows server 2008 r2
Вопрос
У меня такая проблема: после апгрейда Windows 2008 R2 с версии Standard на Enterprise при помощи DISM компьютер перестал принимать подключения по RDP. В сервисах служба Remote Desktop Services запущена и ошибок не выдает, но в статистике netstat нет записи с номером порта 3389 вообще! Windows Firewall отключен. Ветка реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\ полностью совпадает с аналогичной на работоспособном сервере. Подскажите пожалуйста, в чем может быть причина?
Ответы
Так что — никто не поможет.
Всем спасибо за участие! Проблема снята. Видимо все-таки при апгрейде при помощи DISM как-то некорректно отрабатывается замена ключа Windows, т.к. после очередного проделывания операций:
1. Запуск командной строки
6. Перезагрузка сервера
все заработало нормально! Т.е. оперативная память видна полностью и RDP работает так, как нужно!
Все ответы
Это я посчитал совершенно ненужным указывать как само собой разумеющееся. 🙂 Эта галка установлена! И даже программа MSRA работает! Но порта, «слушаещего» 3389 по-прежнему нет.
Это я посчитал совершенно ненужным указывать как само собой разумеющееся. 🙂
смущает именно то, что не слушает порт. попробуйте убрать, рестартануть сервер и снова поставить: чудеса.
Ммм. Событий с кодом 1035/1036 в журналах нет? Других событий от TSRCM? Команда qwinsta что выдаёт?
Событий 1035/1036 нет. Порт в реестре прописан правильно: 3389. Результат выполнения QWINSTA:
C:\Users\. >qwinsta
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
>console . 4 Active
C:\Users\. >qwinsta /mode
SESSIONNAME STATE DEVICE TYPE BAUD PARITY DATA STOP
services Disc none 1
>console Active none 1
C:\Users\. >qwinsta /flow
SESSIONNAME STATE DEVICE TYPE FLOW CONTROL
services Disc
>console Active
C:\Users\. >qwinsta /counter
SESSIONNAME USERNAME ID STATE TYPE DEVICE
services 0 Disc
>console . 4 Active
Total sessions created: 5
Total sessions disconnected: 3
Total sessions reconnected: 0
Интересно. Попробуйте вот этот вариант пока. Фиг с ним, что там 2003 сервер, проблема такая же.
Была аналогичная ситуация с MS Windows 2008
Примечательно что проблема возникала без event ’ов в журнале
Т.к сервис работал НО, принимал запросы только по FQDN имени (игнорировал по ip и name) .
Помогло два варианта:
1 Переустановить службу терминалов
2 Изменить ожидающий порт, затем вернуть его назад.
If you wake up in a different time, in a different place, could you wake up as a different person?
Была аналогичная ситуация с MS Windows 2008
Примечательно что проблема возникала без event ’ов в журнале
Т.к сервис работал НО, принимал запросы только по FQDN имени (игнорировал по ip и name) .
Помогло два варианта:
1 Переустановить службу терминалов
2 Изменить ожидающий порт, затем вернуть его назад.
If you wake up in a different time, in a different place, could you wake up as a different person?
К сожалению тоже не про мой вариант. Сделал как там рекомендуют — не помогло. По-прежнему сервис запущен, но в статистике портов ничего:
C:\Users\. >netstat -aon
Proto Local Address Foreign Address State PID
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING 688
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:475 0.0.0.0:0 LISTENING 207712
TCP 0.0.0.0:1540 0.0.0.0:0 LISTENING 207408
TCP 0.0.0.0:1541 0.0.0.0:0 LISTENING 160192
TCP 0.0.0.0:1560 0.0.0.0:0 LISTENING 160192
TCP 0.0.0.0:1561 0.0.0.0:0 LISTENING 207408
TCP 0.0.0.0:1562 0.0.0.0:0 LISTENING 206340
TCP 0.0.0.0:1563 0.0.0.0:0 LISTENING 206340
TCP 0.0.0.0:1564 0.0.0.0:0 LISTENING 207464
TCP 0.0.0.0:1565 0.0.0.0:0 LISTENING 207464
TCP 0.0.0.0:1566 0.0.0.0:0 LISTENING 207264
TCP 0.0.0.0:1567 0.0.0.0:0 LISTENING 207264
TCP 0.0.0.0:2301 0.0.0.0:0 LISTENING 2348
TCP 0.0.0.0:2381 0.0.0.0:0 LISTENING 2348
TCP 0.0.0.0:5633 0.0.0.0:0 LISTENING 4240
TCP 0.0.0.0:6101 0.0.0.0:0 LISTENING 5148
TCP 0.0.0.0:6106 0.0.0.0:0 LISTENING 4256
TCP 0.0.0.0:10000 0.0.0.0:0 LISTENING 2356
TCP 0.0.0.0:22350 0.0.0.0:0 LISTENING 1228
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 4
TCP 0.0.0.0:49152 0.0.0.0:0 LISTENING 408
TCP 0.0.0.0:49153 0.0.0.0:0 LISTENING 788
TCP 0.0.0.0:49162 0.0.0.0:0 LISTENING 836
TCP 0.0.0.0:49164 0.0.0.0:0 LISTENING 504
TCP 0.0.0.0:49252 0.0.0.0:0 LISTENING 496
TCP 0.0.0.0:49255 0.0.0.0:0 LISTENING 5256
TCP 0.0.0.0:61603 0.0.0.0:0 LISTENING 1516
Попробуйте вот такой вариант решения вашей проблемы:
- вам нужна утилита DevCon(для W2K8 R2 ее можно найти в Windows Driver Kit (WDK) http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=11800 )
- теперь выполните devcon.exe -r install %windir%\inf\machine.inf root\rdpdr(при этом все соединения буду отключены и сервер уйдет в перезагрузку)
Ну и после загрузки поглядеть на результат netstat -na. Надеюсь это решит проблему.
Не помогает! Пишет следующее:
Proto Local Address Foreign Address State
TCP 0.0.0.0:135 0.0.0.0:0 LISTENING
TCP 0.0.0.0:445 0.0.0.0:0 LISTENING
TCP 0.0.0.0:475 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1540 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1541 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1560 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1561 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1562 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1563 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1564 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1565 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1566 0.0.0.0:0 LISTENING
TCP 0.0.0.0:1567 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2301 0.0.0.0:0 LISTENING
TCP 0.0.0.0:2381 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5633 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6101 0.0.0.0:0 LISTENING
TCP 0.0.0.0:6106 0.0.0.0:0 LISTENING
TCP 0.0.0.0:10000 0.0.0.0:0 LISTENING
TCP 0.0.0.0:22350 0.0.0.0:0 LISTENING
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49157 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49158 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49163 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49185 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49263 0.0.0.0:0 LISTENING
TCP 0.0.0.0:49268 0.0.0.0:0 LISTENING
TCP 0.0.0.0:61603 0.0.0.0:0 LISTENING
Кстати, еще только что обратил внимание на еще один «косяк» системы после апгрейда: