Windows server 2019 не подключается через rdp
Обновлено: 21.11.2024
Если у вас возникли проблемы с использованием удаленного рабочего стола (RDP) на сервере Windows, вы можете исправить несколько вещей. Это руководство по устранению неполадок призвано помочь исключить некоторые из наиболее распространенных причин плохой работы.
Проблемы с подключением
Даже если у вас могут возникнуть проблемы с подключением с помощью удаленного рабочего стола Windows, вы всегда сможете войти в веб-консоль с панели управления UpCloud или с помощью подключения VNC, настройки которого указаны на вашем сервере.
После того как вы подключитесь к своему серверу любым из упомянутых выше способов, вас должен приветствовать экран блокировки Windows. Войдите на сервер с учетной записью с правами администратора, чтобы продолжить устранение неполадок.
Если соединение показывает что-то другое, кроме экрана блокировки, проверьте, отвечает ли сервер. Если он не реагирует на команды, возможно, вам придется перезапустить сервер.
Настройки удаленного рабочего стола Windows
Если вы вошли в систему и кажется, что сервер работает, но удаленный рабочий стол по-прежнему не может подключиться, убедитесь, что удаленное подключение разрешено. Самый простой способ добраться до этой опции — открыть sysdm.cpl, выполнив поиск в меню «Пуск». Затем перейдите на вкладку «Удаленное».
Удаленный рабочий стол должен разрешать подключения с других компьютеров, чтобы эта функция работала. Если ваш сервер настроен на разрешение удаленного управления с проверкой подлинности на уровне сети, убедитесь, что ваш собственный компьютер поддерживает это, или разрешите любое соединение. Дополнительную информацию об аутентификации на уровне сети можно найти на сайте Microsoft TechNet.
Оставаясь в настройках RDP, проверьте разрешенных пользователей, нажав Select Users или нажав S. Всем пользователям с правами администратора автоматически разрешается подключаться. Все обычные пользователи должны быть добавлены в этот список. Если вы пытались подключиться с учетными данными пользователя, у которого нет прав администратора, добавьте имя пользователя, под которым вы хотите подключиться, в список разрешенных пользователей.
Брандмауэр
Время от времени брандмауэр Windows может иметь некоторые ограничения, например, входящий протокол ICMP, который используется для ping-соединений, по умолчанию отключен. Откройте Брандмауэр Windows в режиме повышенной безопасности, выполнив поиск «брандмауэр» в меню «Пуск». Перейдите к списку Правила для входящих подключений и прокрутите вниз до правил Remote Desktop, нажав R.
Windows Server 2008 должен отображать два правила: Удаленный рабочий стол (TCP-In) и Удаленный рабочий стол — RemoteFX (TCP-In). Оба они в большинстве случаев будут включены, если сервер по-прежнему использует стандартный TCP-порт 3389 для RDP-соединений.
В Windows Server 2012 правила разделены между доменными и частными или общедоступными профилями, а также протоколами TCP и UDP, что преобразуется в 4 отдельных правила Remote Desktop — User Mode, все из которых обычно включен.
При желании в настройках брандмауэра вы можете включить ICMP для проверки связи. Нажмите F, чтобы найти правила под названием Общий доступ к файлам и принтерам (эхо-запрос — ICMPv4 — входящий) и v6 для обеих версий IP.
Если вы уверены, что брандмауэр Windows разрешает подключения к удаленному рабочему столу, также проверьте настройки брандмауэра для конкретного сервера на панели управления UpCloud. Если вы установили входящее правило по умолчанию для отклонения, не забудьте добавить правило, разрешающее трафик на порт, который прослушивает сервер Remoter Desktop, по умолчанию 3389. Узнайте больше о брандмауэре UpCloud в обучающих материалах.
Сетевое подключение
Проверьте подключение к Интернету на своем сервере, чтобы убедиться, что все ваши сетевые ресурсы работают должным образом. Начните пинговать с вашего сервера. Откройте командную строку и введите cmd в поиске меню «Пуск». Нажмите Enter, затем используйте команду ниже.
Если вы включили эхо-запросы от брандмауэра Windows, вы также можете попытаться пропинговать свой сервер со своего компьютера. Найдите общедоступный IP-адрес сервера в панели управления UpCloud в разделе «Сеть и общедоступная сеть».
Если подключение к Интернету не работает, проверьте конфигурацию IP-адреса в командной строке с помощью следующей команды.
В выходных данных будут перечислены все сетевые подключения ваших серверов, вы должны увидеть 3 адаптера Ethernet: частная сеть, общедоступный IPv4 и общедоступный IPv6. Убедитесь, что они совпадают с информацией о сети в сведениях о вашем сервере на вкладке «Сеть» на панели управления UpCloud.
Если вы видите различия в выходных данных ipconfig и на странице сведений о сети вашего сервера, убедитесь, что все сетевые интерфейсы настроены на автоматическое получение IP-адресов. Для этого найдите Сетевые подключения в меню "Пуск" и нажмите клавишу ВВОД, чтобы открыть его. Откройте Свойства для одного из Ethernet-адаптеров, выберите Протокол Интернета версии 6 или 4 и нажмите кнопку Свойства. под.Убедитесь, что обе круговые кнопки установлены на автоматический режим, и нажмите OK для сохранения. Таким же образом проверьте все сетевые адаптеры на сервере.
Медленное соединение
Если подключение к удаленному рабочему столу работает, но работает медленно или время от времени отключается, попробуйте обновить сетевые драйверы. Загрузите последние версии драйверов Virtio для Windows.
После загрузки ISO-файла на сервер в Windows Server 2008 для его распаковки потребуется такая программа, как 7zip. В Server 2012 вы можете просто смонтировать файл как диск.
При наличии доступных файлов откройте Диспетчер устройств, просто выполнив поиск по имени в меню "Пуск" и нажав клавишу ввода. Перейдите к разделу Сетевые адаптеры, выберите каждый адаптер по одному и запустите Обновить программное обеспечение драйвера. В мастере обновления выберите Выполнить поиск драйвера на моем компьютере, введите местоположение драйвера в поле поиска и нажмите «Далее». Обратите внимание, чтобы параметр Включить подпапки оставался выбранным.
Если вы были подключены через удаленный рабочий стол во время обновления сетевых драйверов, вы, вероятно, на мгновение отключитесь. Клиент должен иметь возможность автоматически восстанавливать соединение после успешной установки драйверов.
Конфликт портов
В некоторых случаях возможно, что другое приложение непреднамеренно использует тот же порт, что и удаленный рабочий стол. Это может вызвать проблемы с подключением или помешать удаленному рабочему столу подключиться.
Проверьте порты, используемые программами. Введите приведенную ниже команду в командной строке.
Netstat распечатает список используемых ими IP-адресов и номеров портов. Найдите строки с номером вашего порта удаленного рабочего стола (по умолчанию 3389) и проверьте идентификатор программы (PID) в конце этих строк. Один PID будет принадлежать службе RDP. Если вы видите другой PID, использующий тот же порт, они будут конфликтовать друг с другом.
Чтобы узнать, каким программам принадлежат PID, используйте следующую команду в командной строке.
Удаленный рабочий стол указан как svchost.exe TermService, любой другой PID, использующий тот же номер порта, вызывает проблемы.
Изменить номер порта RDP
Если есть конфликт портов, вы можете разрешить его, изменив порт, используемый одним из приложений. Microsoft рекомендует в идеале изменить порт, используемый любыми другими приложениями. Если это невозможно, номер порта, который прослушивает удаленный рабочий стол, можно изменить, выполнив несколько действий.
Измените номер порта, так как это также поможет снизить количество попыток вторжения путем запутывания. Это не должно быть вашим единственным методом безопасности.
Чтобы изменить номер порта, сначала нужно выбрать свободный порт, который не используется ничем другим на вашем сервере. Проверьте используемые в настоящее время порты с помощью netstat -a -o, как описано выше. Новый номер порта может быть любым от 1024 до 49151.
Добавьте выбранный вами номер порта в правила Входящего трафика брандмауэра Windows, создав новое правило. В Мастере создания правила для нового входящего трафика выберите следующее
- Тип правила: порт
- Протокол и порты: TCP, определенные локальные порты
В шагах выше
это новый порт, который вы хотите прослушивать через RDP. Убедитесь, что новое правило брандмауэра настроено правильно. После того как вы измените порт RDP, он понадобится вам, чтобы иметь возможность снова подключиться.
Номер порта для удаленного рабочего стола не предназначен для изменения, и единственный способ сделать это — изменить реестр. Мы настоятельно рекомендуем вам сделать резервную копию вашего сервера, прежде чем вносить какие-либо изменения.
Откройте редактор, выполнив поиск regedit в меню "Пуск" и нажав клавишу ввода.
Найдите следующий ключ в файловой системе реестра.
Откройте раздел реестра PortNumber для редактирования, измените отображение на Decimal, введите новый номер порта и нажмите OK, чтобы сохранить изменения. .
Чтобы изменения вступили в силу, вам потребуется перезапустить службу RDP. Снова откройте Службы, выполнив поиск в меню "Пуск" и нажав Enter, чтобы запустить программу.
В списке Службы (локальные) прокрутите вниз, найдите Служба удаленного рабочего стола и перезапустите ее. Во всплывающем окне с запросом на перезапуск других связанных служб нажмите Да, чтобы продолжить.
Вы будете отключены, если для внесения этих изменений использовали RDP. После этого просто повторно подключитесь к новому порту, указав его в поле Компьютер при подключении по протоколу RDP.
С новым портом вы должны получить бесперебойный и надежный удаленный доступ.
Получение помощи
Если вы столкнулись с более серьезными проблемами или вам нужна помощь в чем-то другом, не стесняйтесь спрашивать. Когда вы обращаетесь в службу поддержки UpCloud, постарайтесь объяснить проблему как можно лучше. Включите все шаги, которые вы уже предприняли, вместе с их результатами при устранении проблемы. Это поможет нашей службе поддержки решить вашу проблему.
Главный редактор и технический писатель UpCloud с 2015 года.Облачные энтузиасты, пишущие о серверных технологиях и программном обеспечении.
Пользователи, подключающиеся через RDP к серверу Windows 2019, не могут вернуться к работающему сеансу с открытыми приложениями
У меня есть пользователи, подключающиеся по RDP к серверу Windows 2019.
Пользователи жалуются, что не могут повторно подключиться (нажав X, чтобы закрыть сеанс RDP) и что их программы все еще работают.
Я знаю, что Windows 2019 все еще довольно новая, но я пытался найти ответы и не смог решить эту проблему.
Знает ли кто-нибудь из вас о конкретных настройках/конфигурациях RDP, которые должны быть включены или отключены для этого?
2 ответа
HI
Обычно посредник подключений к удаленному рабочему столу повторно подключает пользователя к правильному серверу узла сеансов удаленных рабочих столов и его прерванному сеансу.
1. Не могли бы вы предоставить более подробную информацию о вашей среде RDS?
1) какую роль сервера rds вы создали?
2) Сколько хостов сеансов и находятся ли они в одной коллекции?
3) Сколько коллекций вы создали в Connection Broker？
2. Эта проблема возникает только с одной коллекцией или со всеми?
3. Пробовали ли вы команду запроса сеанса, есть ли другой идентификатор сеанса при повторном подключении?
4. Есть ли какие-либо журналы событий, в которых зафиксированы некоторые подробности этой проблемы? Сначала включите средство просмотра событий журналов аналитики и отладки.
Проверить на сервере CB:
Журналы приложений и служб->Microsoft->Windows->TerminalServices->SessionBroker
Проверьте сервер SH:
Журналы приложений и служб -> Microsoft -> Windows -> TerminalServices->LocalSessionManage
Спасибо, что ответили мне.
Для уточнения: это один удаленный хост, работающий под управлением Windows 2019 Server. Несколько пользователей подключаются к нему по протоколу RDP.
Я не вижу ничего странного в журналах просмотра событий Windows в меню Windows -> Система, приложение и безопасность.
В настоящее время для решения этой проблемы можно установить время простоя равным 1 минуте. Это делается для того, чтобы, если пользователи закроют сеанс, сеанс завершится через минуту, и они смогут снова войти в систему. Конечно, это совершенно новый сеанс, и ни одно из их приложений не запущено. Это ожидаемо.
Однако я хочу отключить тайм-аут простоя и посмотреть, смогу ли я вернуть пользователей к своему предыдущему сеансу?
Не уверен, что это вообще возможно в WIndows 2019 Server.
Еще раз спасибо
Привет
Есть ли прогресс по вашему вопросу?
Привет
1. Можете ли вы ввести приведенную ниже команду powershell на сервере с проблемой w2019, а затем посмотреть, установили ли мы роль «узел сеанса удаленного рабочего стола»? выдайте w2019 или другой рядовой сервер, используя приведенную ниже команду ps ?
Get-WindowsFeature | где имя - как "rds*"
2. в общем, если мы не установим роль «узел сеанса удаленного рабочего стола» на w2019, будет только 2 одновременных активных сеанса для 2 пользователей. поэтому, если мы хотим, чтобы более 2 пользователей имели удаленный доступ w2019 одновременно, мы должны установите роль «узел сеанса удаленного рабочего стола», и нам также необходимо установить роль лицензирования удаленных рабочих столов, а затем зарегистрировать RDS-вызовы на сервере лицензирования удаленных рабочих столов. в прошлом я видел, как некоторые ИТ-друзья не устанавливали роль «узел сеанса удаленного рабочего стола» и ключ реестра «fsinglesessionperuser» в 0, что приводило к тому, что конечные пользователи не могли повторно подключиться к существующему сеансу.
Можете ли вы проверить, что значение ключа реестра "fsinglesessionperuser" в вашей проблеме равно 1? по умолчанию оно должно быть равно 1.
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\
" fsinglesessionperuser"=dword:00000001
HKEY_LOCAL_MACHINE\Software\WOW6432note\policies\Microsoft\Windows NT\Terminal Services
"fsinglesessionperuser"=dword:00000001
Стандарт Windows Server 2019. Служба удаленного рабочего стола работает, но порт 3389 не прослушивается. Та же проблема во всех экземплярах Windows Server 2019 Standard, которые у нас запущены.
Обнаружено системное событие, связанное с:
Службы удаленных рабочих столов не принимают входы в систему, поскольку программа установки запущена.
Имя журнала: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
Источник: TerminalServices-LocalSessionManager
Идентификатор события: 34
Я пытался изменить порт RDP, проверил настройки брандмауэра, убедился, что служба работает, сравнил ее с другими работающими серверами, прочитал много сообщений и вопросов и безуспешно пробовал многие вещи.
Пожалуйста, есть идеи по решению проблемы?
Вы проверили, помогает ли ответ?
Если ответ полезен, нажмите "Принять ответ" и проголосуйте за него. Спасибо.
8 ответов
Похоже, вам нужно завершить незавершенный процесс установки, который был запущен.
--пожалуйста, не забудьте принять в качестве ответа, если ответ полезен--
Я тоже так предполагал, но никаких незавершенных настроек нет. Никаких сообщений, ни уведомлений, ни приложений с отложенной настройкой не запущено. Этот сервер работает два месяца назад и полностью обновлен.Также несколько раз перезагружался, так что если какая-либо установка не выполнялась, ее сейчас нет.
Та же проблема возникает с другими 3 Windows Server 2019 Standard. Все они были установлены из образа OVF, который также содержит установку установки SQL Server, заданную при первом запуске.
Я подозреваю, что это шаблон Windows Server был подготовлен с помощью sysprep.exe и что-то не доделано.
Как я могу увидеть, есть ли незавершенные настройки?
Не так много, чтобы продолжать. За исключением любых новых подсказок, время может быть лучше потрачено на создание новой, полное исправление и перенос ролей на нее.
--пожалуйста, не забудьте принять в качестве ответа, если ответ полезен--
Проверьте, включен или отключен драйвер фильтра безопасности служб удаленных рабочих столов.
Откройте диспетчер устройств и отобразите скрытые устройства. Удалите драйвер и перезагрузите сервер, чтобы проверить, может ли проблема быть решена.
Если ответ полезен, нажмите "Принять ответ" и проголосуйте за него. Спасибо.
Спасибо за помощь.
Я пытался найти «Драйвер фильтра безопасности служб удаленных рабочих столов», но он отсутствует.
Я искал этот драйвер в Google, и люди говорят, что он должен быть в «Диспетчере устройств — Скрытые устройства — Не Plug and Play», но раздел «Не Plug and Play» не найден, и я полностью проверяю все узлы устройств без успеха.
Есть ли у вас другие идеи?
Также попробуйте проверить ниже:
Диспетчер устройств > Системные устройства > Проверьте, отсутствует ли нумератор корневой шины UMBus
Если отсутствует, выполните следующие шаги, чтобы добавить его обратно
Мы установили UMB Root Bus Enum с помощью устаревшего оборудования
Добавить оборудование с расширенными параметрами
Выберите Показать все устройства
Выберите перечисление корневой шины UMBus
Установите корневое перечисление UMBus
Если ответ полезен, нажмите "Принять ответ" и проголосуйте за него. Спасибо.
Проблемы с новым развертыванием служб удаленных рабочих столов Server 2019.
Ранее у нас было развертывание удаленного рабочего стола Windows Server 2012 R2, и оно работало нормально. Этот сервер был физическим сервером.
Я установил новый сервер, на котором работает виртуальная машина, к которой теперь я хочу, чтобы пользователи подключались через RDP. Я создал установку служб удаленных рабочих столов, и на сервере все работает нормально, и на нем установлены действительные доверенные сертификаты, указывающие на внешний пример полного доменного имени «rdp.ourdomain.com», который указывает на наш выделенный IP-адрес и соответствует имени сервера что я хочу, чтобы пользователи подключались, к которым выполняются все роли, кроме роли лицензирования, на которой находится сервер, на котором установлена виртуальная машина Hyper-V.
По какой-то причине это просто не работает. У меня не было проблем с предыдущим развертыванием, поэтому я чувствую, что при использовании виртуальной машины должны быть какие-то особые соображения или что-то в этом роде? Хотя я не могу найти документацию, в которой это упоминается.
Разбивка ситуации:
Контроллер домена 2 Server 2019: запущена роль лицензирования RDS, на нем установлена виртуальная машина RDS, а также виртуальный коммутатор, предоставляющий доступ к внешней сети.
RDS VM Server 2019: Запуск посредника подключений к удаленному рабочему столу, шлюза удаленных рабочих столов, веб-доступа к удаленным рабочим столам, узла сеансов удаленных рабочих столов с созданной коллекцией сеансов. Также установлены действующие доверенные сертификаты для внешнего полного доменного имени, совпадающего с именем сервера.
Когда я пытаюсь подключиться к удаленному рабочему столу, ничего не получается. Ничего, нада. Он пытается, а затем просто говорит, что не может оштрафовать удаленный компьютер. Я могу пропинговать IP-адрес, на который он указывает, и traceroute завершается нормально.
Есть идеи? Я что-то упустил здесь? Спасибо!!
Брайан5299
Читайте также: