Невозможно проверить, принадлежат ли компьютеры одной ферме хост-серверов

Обновлено: 21.11.2024

Параметры групповой политики сервера соединений RDS позволяют пользователям устанавливать политики для сервера соединений.

Используйте этот параметр политики, чтобы указать, должен ли узел RDS присоединяться к ферме на сервере соединений, установленном на узле RDS. Сервер соединений на узле RDS отслеживает сеансы пользователей и позволяет пользователю повторно подключиться к существующему сеансу в ферме RDS с балансировкой нагрузки. Чтобы участвовать в сервере подключений на узле RDS, на узле RDS должна быть установлена служба роли узла сеансов удаленных рабочих столов.

Если этот параметр политики включен, узел RDS присоединяется к ферме, указанной в параметре «Настроить имя фермы посредника подключений к удаленному рабочему столу». Ферма существует на сервере соединений, указанном в параметре политики «Настроить имя сервера посредника подключений к удаленному рабочему столу».

Если вы отключите этот параметр политики, хост RDS не будет присоединяться к ферме на сервере соединений, и отслеживание сеансов пользователей не будет выполняться. Если этот параметр отключен, вы не сможете использовать средство настройки узла сеансов удаленных рабочих столов или поставщик WMI служб терминалов для присоединения узла RDS к серверу подключений.

Если параметр политики не настроен, он не указывается на уровне групповой политики. В этом случае можно настроить узел RDS для присоединения к серверу соединений на узле RDS с помощью средства настройки узла сеансов удаленных рабочих столов или поставщика WMI служб терминалов.

Если вы включите этот параметр, вы также должны включить параметры политики «Настроить имя фермы посредника подключений к удаленному рабочему столу» и «Настроить имя сервера посредника подключений к удаленному рабочему столу» или настроить эти параметры с помощью средства настройки узла сеансов удаленного рабочего стола или Поставщик WMI служб терминалов.
Для Windows Server 2008 этот параметр политики поддерживается как минимум в Windows Server 2008 Standard.

Используйте этот параметр политики, чтобы указать имя фермы для присоединения к серверу соединений для хоста RDS. Сервер соединений использует имя фермы, чтобы определить, какие узлы RDS находятся в одной ферме RDS. Поэтому необходимо использовать одно и то же имя фермы для всех узлов RDS в одной ферме с балансировкой нагрузки. Имя фермы не обязательно должно соответствовать имени в доменных службах Active Directory.

Если вы укажете новое имя фермы, новая ферма будет создана на сервере соединений для хоста RDS. Если вы укажете имя существующей фермы, узел RDS присоединяется к этой ферме на сервере соединений на узле RDS.

Если вы включите этот параметр политики, вы должны указать имя фермы на сервере соединений для хоста RDS.

Если вы отключите или не настроите этот параметр политики, имя фермы не будет указано в групповой политике. В этом случае вы можете настроить имя фермы с помощью средства настройки узла сеансов удаленных рабочих столов или поставщика WMI служб терминалов.

Примечание. Для Windows Server 2008 этот параметр политики поддерживается как минимум в Windows Server 2008 Standard. Этот параметр не действует, если параметры «Присоединиться к посреднику подключений к удаленному рабочему столу» и «Настроить имя сервера посредника подключений к удаленному рабочему столу» не включены и не настроены с помощью групповой политики, средства настройки узла сеансов удаленных рабочих столов или поставщика WMI служб терминалов.< /p>

Используйте этот параметр политики, чтобы указать метод перенаправления, который будет использоваться при повторном подключении клиентского устройства к существующему сеансу служб удаленных рабочих столов в ферме RDS с балансировкой нагрузки. Этот параметр применяется к узлу RDS, настроенному на использование сервера соединений на узле RDS, а не к серверу соединений на удаленном рабочем столе.

Если вы включите этот параметр политики, клиент служб удаленных рабочих столов запрашивает сервер соединений на узле RDS и перенаправляется на существующий сеанс, используя IP-адрес узла RDS, на котором существует сеанс. Чтобы использовать этот метод перенаправления, клиентские компьютеры должны иметь возможность напрямую подключаться по IP-адресу к узлу RDS в ферме.

Если вы отключите этот параметр политики, IP-адрес узла RDS не будет отправляться клиенту. Вместо этого IP-адрес встроен в токен. Когда клиент повторно подключается к балансировщику нагрузки, маркер маршрутизации используется для перенаправления клиента в существующий сеанс на правильном узле RDS в ферме. Отключайте этот параметр только в том случае, если ваше решение для балансировки сетевой нагрузки поддерживает использование маркеров маршрутизации сервера подключений узла RDS и вы не хотите, чтобы клиенты напрямую подключались по IP-адресу к узлу RDS в ферме с балансировкой нагрузки.

Если этот параметр политики не настроен, используется параметр «Использовать перенаправление IP-адресов» в средстве настройки узла сеансов удаленных рабочих столов. По умолчанию этот параметр в средстве настройки узла сеансов удаленных рабочих столов включен.

Примечание. Для Windows Server 2008 этот параметр политики поддерживается как минимум в Windows Server 2008 Standard.

Используйте этот параметр политики, чтобы указать сервер соединений, который узел RDS использует для отслеживания и перенаправления сеансов пользователей для фермы RDS с балансировкой нагрузки. На указанном узле RDS должна быть запущена служба сервера соединений. Все хосты RDS в ферме с балансировкой нагрузки должны использовать один и тот же сервер соединений.

Если вы включите этот параметр политики, вы должны указать сервер соединений для хоста RDS, используя его имя хоста, IP-адрес или полное доменное имя. Если вы укажете недопустимое имя или IP-адрес для сервера соединений, в средстве просмотра событий на узле RDS будет зарегистрировано сообщение об ошибке.

Если вы отключите или не настроите этот параметр политики, вы сможете настроить имя или IP-адрес сервера подключений узла RDS с помощью средства настройки узла сеансов удаленных рабочих столов или поставщика WMI служб терминалов.

Для Windows Server 2008 этот параметр политики поддерживается в Windows Server 2008 Standard.
Этот параметр политики не действует, если не включен параметр политики «Присоединиться к посреднику подключений к удаленному рабочему столу» или узел RDS не настроен для присоединения к серверу подключений на узле RDS с помощью средства настройки узла сеансов удаленных рабочих столов или WMI служб терминалов. провайдер.
Чтобы быть активным участником сеанса с включенным сервером соединений на ферме RDS, учетная запись компьютера для каждого узла RDS в ферме должна быть членом локальной группы «Компьютеры каталога сеансов» на сервере соединений для узла RDS. .

Используйте этот параметр политики, чтобы указать, следует ли использовать функцию балансировки нагрузки на сервере соединений на узле RDS для балансировки нагрузки между серверами в ферме RDS.

Если этот параметр политики включен, сервер соединений на узле RDS перенаправляет пользователей, у которых нет существующего сеанса, на узел RDS в ферме с наименьшим количеством сеансов. Поведение перенаправления для пользователей с существующими сеансами не затрагивается. Если сервер настроен на использование сервера соединений на узле RDS, пользователи, у которых есть существующий сеанс, перенаправляются на узел RDS, на котором существует их сеанс.

Если вы отключите этот параметр политики, пользователи, у которых нет существующего сеанса, будут входить на первый хост RDS, к которому они подключаются.

Если вы не настроите этот параметр политики, вы можете настроить узел RDS для участия в балансировке нагрузки сервера подключений для узла RDS с помощью средства настройки узла сеансов удаленных рабочих столов или поставщика WMI служб терминалов.

Примечание. Если этот параметр политики включен, необходимо также включить параметры политики «Присоединиться к посреднику подключений к удаленному рабочему столу», «Настроить имя фермы посредника подключений к удаленному рабочему столу» и «Настроить имя сервера посредника подключений к удаленному рабочему столу».

Приветствую. Я пытаюсь настроить RDP-ферму, используя посредничество сеансов на основе tcp/ip. Все работало до тех пор, пока я не попробовал кое-что причудливое, чтобы приспособить rDesktop для Linux, что, по-видимому, совершенно не работает для фарм-серверов RDP.

В любом случае. Моя установка такова: две машины 2008 R2, на обоих установлена роль служб удаленных рабочих столов, на одном установлен брокер сеансов, оба сервера в локальной группе «Компьютеры брокера сеансов» на брокере сеансов. Лицензирование установлено, включено и не вызывает проблем.

Эти машины представляют собой два физических компьютера HP Proliant, каждый с двумя сетевыми адаптерами. Сетевые адаптеры для брокера сеансов объединены в один виртуальный интерфейс, конфигурация TCP/IP которого считается правильной. На втором компьютере, членском сервере фермы, изначально также были объединены сетевые карты, и все работало (конечно, с клиентов Windows и Mac. Не с rdesktop).

Чтобы попытаться приспособить пользователей rdesktop, группа сетевых адаптеров на рядовом сервере была нарушена, каждому интерфейсу был присвоен собственный IP-адрес, а IP-адрес второго сетевого адаптера был исключен из набора IP-адресов в «Сеансе удаленного рабочего стола». Broker» в свойствах рядового сервера. Вот где все становится забавным.

Мы внезапно заметили, что сеансы, пытающиеся перенаправить на рядовой сервер, завершатся сбоем с сообщением об ошибке:

[Этот компьютер не может подключиться к удаленному компьютеру.]

Удаленный компьютер broker.domain.edu, к которому вы пытаетесь подключиться, перенаправляет вас на удаленный компьютер-член. домен.edu. Подключение к удаленному рабочему столу не может проверить, принадлежат ли два удаленных компьютера одной ферме. Это может произойти, если в вашей сети есть другой компьютер с тем же именем, что и компьютер, к которому вы пытаетесь подключиться.

(И, конечно, вездесущая ирония) Обратитесь за помощью к вашему сетевому администратору.

Когда я повторно объединил сетевые карты, эта проблема исчезла для всех, кроме моего коллеги, который при попытке авторизации в ферме с использованием своей учетной записи su (член локальных администраторов на обоих устройствах) продолжал получить сообщение об ошибке.

Однако также возникла новая, другая проблема: при первоначальной попытке аутентификации в качестве домена\пользователя мы получаем «Неверное имя пользователя или пароль». Затем сервер запросил полностью.квалифицированный.ad\user, для которого сработала аутентификация.

Это заставило меня заподозрить NetBIOS, но, похоже, там все в порядке; Я могу разрешать записи DFS с одним именем, другие хосты Windows в сети и т. д.

ТАК… есть идеи? Если я забыл какую-то деталь, дайте мне знать, и я предоставлю ее. Это очень раздражает.

У меня есть ферма RDS (RDS-FARM), работающая в центре обработки данных Server 2016. У меня есть один посредник соединений (RDSCB) и два хоста сеансов (RDS02, RDS03). Первоначально ферма была настроена с узлами сеансов с именами RDS01 и RDS02. RDS01 столкнулся с проблемами на прошлой неделе, мы предложили мне создать новый узел сеанса RDS (RDS03) и добавить его в мою существующую ферму. Затем я удалил RDS01 из фермы. 98% моих внутренних сотрудников получают доступ к ферме через тонкие клиентские компьютеры — они могут без проблем подключаться к ферме и балансировать нагрузку. Небольшое количество сотрудников получает доступ к ферме с помощью подключения к удаленному рабочему столу с настольного компьютера или ноутбука. Для тех, кто осуществляет доступ через настольный компьютер или ноутбук, они получают следующую ошибку при подключении к имени фермы (RDS-FARM) или IP. «Подключение к удаленному рабочему столу не может подключиться к удаленному компьютеру. Удаленный компьютер RDS-FARM, к которому вы пытаетесь подключиться, перенаправляет вас на другой удаленный компьютер с именем RDS03. Подключение к удаленному рабочему столу не может проверить, принадлежат ли компьютеры одному и тому же хост-серверу сеансов удаленных рабочих столов. ферме. При подключении к ферме хост-серверов сеансов удаленных рабочих столов необходимо использовать имя фермы, а не имя компьютера. Если вы используете подключение RDP, предоставленное вам администратором, обратитесь к администратору за помощью. Если вы хотите подключиться конкретному члену фермы для его администрирования, введите «mstsc/admin» в командной строке». Я дважды и трижды проверил все свои конфигурации на ферме и считаю их правильными. Я также проверил права удаленного доступа на сервере и клиентах. Странно то, что все тонкие клиенты могут без проблем подключаться к ферме и распределять нагрузку между моими двумя SH. Мне просто нужно выяснить, почему компьютеры, подключающиеся к удаленному рабочему столу, не могут этого сделать. Я нашел других пользователей в Интернете, у которых возникла проблема, но решения нет.

Лорен7060

Ранее хорошо функционирующая ферма серверов удаленных рабочих столов перестала работать два дня назад. Настройка выглядит следующим образом:

DNS разрешает "myfarm.mydomain.local" в IP-адреса всех серверов, входящих в ферму.
Все серверы-члены фермы настроены как члены фермы "myfarm" на брокере MYBROKER
Все члены фермы являются членами локальной группы брокеров сеансов в MYBROKER.
Клиенты настроены на подключение к "myfarm"

(Все вовлеченные серверы являются виртуальными ящиками Windows2008R2). Внезапно люди начали получать следующую ошибку (в переводе с немецкого) и не могли подключиться.

Невозможно подключиться к серверу терминалов.

Ферма серверов терминалов "myfarm", к которой вы пытаетесь подключиться, перенаправляет вас на сервер "farmmemberX.mydomain.local". Удаленный рабочий стол не может проверить, принадлежит ли этот сервер к той же ферме серверов. Это может произойти, если в вашей сети есть сервер с тем же именем, что и ферма серверов. «Невозможно проверить, принадлежат ли оба удаленных компьютера к одной и той же ферме серверов удаленных рабочих столов. Вы должны использовать имя фермы, а не имя компьютера, если хотите установить соединение с фермой серверов удаленных рабочих столов.

Обратитесь к сетевому администратору за поддержкой, если вы используете соединение RDP, подготовленное администратору.

Если вы хотите подключиться к определенному члену фермы, используйте "mstsc /admin"

Иногда также казалось, что они были просто отклонены, как если бы они ввели неправильные учетные данные (а это не так, большинство сохранили свои учетные данные)

Вопрос 1. Можете ли вы объяснить, что за этим стоит, в частности, по поводу «не удалось проверить»: как происходит эта проверка, если она работает? В конце концов, перенаправление даже не было бы предпринято, если бы оно не было инициировано брокером.

Что мы пробовали: иногда помогала заменить имя, к которому подключается клиент, на другое (например, мы добавляли имя "foo" в DNS, которое разрешалось в те же IP-адреса, и пользователи подключались к "foo"), но это было далеко не последовательно.

Позже мы заметили, что всегда одни и те же несколько серверов появлялись как "farmmemberX" в приведенном выше сообщении об ошибке. Мы экспериментально удалили их из фермы (у самих участников и в DNS) и, таким образом, смогли сократить сломанную ферму из восьми серверов до работающей фермы из двух серверов.Поскольку этого было бы недостаточно, чтобы снизить нагрузку на пользователя, я хотел клонировать один из них; для этого я сначала выключил его, а затем перезапустил - с этого момента он стал таким же плохим, как и остальные шесть серверов. Очевидно, перезапуск серверов RDP был фатальным. Судя по логам, этот конкретный сервер не перезагружался около двух месяцев. Таким образом, практически любое изменение, сделанное за последние два месяца, может иметь значение. Среди них

Мы добавили наш первый сервер AD Win2012 в нашу структуру AD Win2003
Я помню, что было несколько случаев проблем с безопасностью, связанных с IE10/SSL/TLS, которые требовали ручного вмешательства (regedit и т. д.), но я все еще пытаюсь вспомнить, что это могло быть.
Много обновлений Windows
Мне пришли в голову такие вещи, как недействительные сертификаты, но я не нашел ничего подобного

Вопрос 2. Может ли одна из этих причин вызвать эту проблему?

В настоящее время мы полностью отказались от фермы серверов, т. е. у нас есть только "балансировка нагрузки для бедняков" с помощью циклического перебора DNS (и нам, конечно, особенно не хватает функции повторного подключения к предыдущему сеансу)

Основной вопрос. Как мне снова привести ферму в рабочее состояние?

РЕДАКТИРОВАТЬ: я должен был упомянуть, что нескольким клиентам повезло, и у них не было проблем с фермой RDP: те, кто все еще работал под управлением Windows XP и ее старого клиента RDP.

РЕДАКТИРОВАТЬ после комментария: похоже, что основные обновления KB3002657, KB3035017 либо не были установлены, либо были установлены за несколько дней до возникновения проблемы на соответствующих серверах (клиентах, RDP-серверах, брокере, контроллеры домена), но я все равно попробую их удалить .

ОБНОВЛЕНИЕ Еще немного информации:

Я улучшил регистрацию событий в брокере. Согласно этому журналу, все в порядке (без предупреждений), и перенаправление сеанса завершается нормально. Просто по истечении тайм-аута soe целевая сессия удаляется. Я пробовал (не удалось) быстрое подключение, и в этом случае брокер даже зарегистрировал попытку повторного использования существующего сеанса.
Если для целевого RDP-сервера установлено значение "RDP-Sercurity" вместо "согласование", перенаправление работает (за исключением ожидаемых раздражающих сообщений об ошибках для клиента)
Я попробовал совершенно новую ферму (то есть другого брокера с другими хостами), и проблема может быть воспроизведена и в этой системе. Это может свидетельствовать о том, что проблема на стороне клиента.

ОБНОВИТЬ информацию, запрашиваемую в комментариях

Если я устанавливаю безопасность на «TLS 1.0» (вместо «согласования») на хостах RDP, проблема сохраняется. Если я выберу «RDP», ферма работает, но каждый должен дважды вводить свой пароль. В ситуации с ошибкой по какой-то причине я теперь часто просто получаю «Не удалось установить соединение с указанными учетными данными» вместо исходной ошибки. Это сопровождается событием ошибки входа в систему 4625 со статусом 0xc000006d, подстатусом 0. Прежде чем вы спросите: все контроллеры домена имеют свои часы в хорошей синхронизации; в реестре не настроены параметры совместимости с LanMan.

Сертификаты в настройках клиента хоста RDP, которые работали, были выданы все еще заслуживающим доверия внутренним ЦС (доверенным для всех в соответствии с GPO) и действительны в течение как минимум четырех месяцев в будущем. Для тестирования я изменил их на «автоматические» сертификаты и обратно, но безуспешно.

Исходный текст сообщения об ошибке на немецком языке выглядит следующим образом:

Фон Remotedesktopverbindung kann keine Verbindung mit dem Remotecomputer hergestellt werden.

Vom Remotecomputer "FARMNAME", mit dem Sie eine Verbindung herstellen möchten, werden Sie zum Remotecomputer "FARMMEMBER.DOMAIN" umgeleitet. Es kann nicht überprüft werden, ob diebeiden Remotecomputer zur gleichen Remotedesktop-Sitzungshostserverfarm gehören. Sie müssen den Farmnamen, nicht den COMputernamen, verwenden, wenn Sie eine Verbindung mit einer Remotedesktop-Sitzungshostserverfarm herstellen möchten.

Wenden Sie sich an den Netzwerkadministrator, um Unterstützung zu erhalten, wenn Sie eine RDP-Verbindung verwenden. die vom Administrator bereitgestellt wurde.

Возможно, если вы укажете, что у вас есть права доступа, а вы их проверили, geben Sie "mstsc.exe /admin" и Eingabeaufforderung ein.

Чтобы выяснить, не виновато ли какое-то недавнее обновление на стороне клиента, я начал с новой коробки Windows 7 и проверял ее после каждой пачки обновлений. Кажется, введение первого клиента лучше, чем XP, уже сейчас вызывает проблемы, но первые такие версии клиентов выдают другое сообщение об ошибке (не то, чтобы это имело смысл):

Die Verbindung kann nicht hergestellt werden, da es sich bei dem erreichten Remotecomputer nicht um den angegebenen Computer handelt. Dies kann durch einen veralteten Eintrag im DNS-Cache verursacht werden. Verwenden Sie statt des Namens die IP-Adresse es Computers.

@ojovirtual, я не думаю, что это та же самая проблема, поскольку он говорит, что это перенаправление фермы и что без брокера все более или менее функционально.

Проверяли ли вы журналы событий рассматриваемых серверов (RDSH и RDCB)? Они могут дать дополнительные намеки на корень проблемы. Кроме того, не рассматривали ли вы возможность настройки другого брокера подключений и повторной сборки фермы?

@the-wabbit ничего интересного в журналах событий RDSH / RDCB app / sys, за исключением, возможно, события 4501 от Terminal Serve Licensing (но мы уже решили эту проблему, и она начала происходить некоторое время назад). - Сегодня я добавил роль брокера на другой сервер и пересобрал с ней фарм без каких-либо изменений

Не зная подробностей здесь, типичная причина того, что вещи, которые не были затронуты, перестают работать, — это истечение срока действия сертификатов. Я полагаю, что современные версии RDC используют сертификаты сервера для проверки подлинности, и их может потребоваться обновить?

2 ответа 2

Кажется, здесь довольно сложно найти иголку в стоге сена, но я считаю, что это где-то ошибка конфигурации. После этого вы должны получить рабочую базовую конфигурацию:

создайте A-RR в зоне DNS для указания на каждый из ваших хостов сеансов в ферме
настройте доверенные сертификаты для каждого с альтернативным именем субъекта и установите/включите их для служб удаленных рабочих столов на каждом из ваших узлов сеансов
настройте объект групповой политики, настроив все узлы сеансов в качестве членов фермы по адресу (все настройки в Административные шаблоны/Компоненты Windows/Службы удаленных рабочих столов/Узел сеансов удаленных рабочих столов/Посредник подключений к удаленному рабочему столу):
настройте объект групповой политики, чтобы назначить учетную запись компьютера вашего брокера подключений в качестве члена распределенных пользователей COM (встроено)
перезагрузите узлы сеансов, чтобы убедиться, что все политики применены и действуют
проверить подключение клиента к

Спасибо за все предложения, но ни одно из них не подходит. Я понятия не имею, почему возникла наблюдаемая и описанная схема неисправности (и временное развитие неисправности), но виновник скрыт в том, что я описал как

Это KB3002567. Обновление, которое вскоре после его выпуска стало известно как «ломающее RDP» — или фактически ломающее все. По иронии судьбы, быстрое исследование после первого столкновения с нашими проблемами уже выявило это (по крайней мере, проблемы RDP, поскольку это то, что мы искали в Google), поэтому мы пометили KB3002567 (и несколько других подозрительных) для удаления на нашем WSUS ( см. мое оптимистическое замечание на этот счет в ОП) и в остальном замороженная синхронизация обновлений на данный момент. Чего мы не заметили, так это того, что версия этого обновления для Windows Server 2003 не считает себя удаляемой. Таким образом, хотя во время тестового обновления мы заметили, как патч был успешно удален, например. с сервера Win2008, мы думали, что удаление произошло успешно и на наших серверах AD (Win 2003) за ночь (поскольку они ни о чем не просили обновления на следующий день). Поскольку проблема осталась, мы предположили, что проблема не в обновлении (и действительно, rdp не был полностью сломан — нам удалось обойти проблему за счет удобства пользователя). С другой стороны, версия Win 2012 была автоматически удалена. Как следствие, от того, какой сервер использовался для аутентификации, зависело, работал или не работал RDP. Мы ошибочно пришли к выводу, что перезагрузка сервера привела к появлению ранее «установленной» проблемы, хотя на самом деле перезагрузка просто произошла для переключения приоритетов сервера аутентификации. Мы также ошибочно пришли к выводу, что наши тесты миграции AD были причиной проблем, понизили и удалили сервер 2012, а затем начали искать любые проблемы, которые могли возникнуть при игре с AD. Поскольку интенсивность проблемы в любом случае неуклонно возрастала, мы не были слишком подозрительны, когда заметили, что сбой часто превращался в сбой всегда в тот же день, когда мы избавились от сервера AD 2012 (хотя связь очевидна задним числом).

Когда наш поиск продолжал выдавать одни и те же бесполезные предложения (проверьте, что разница во времени между серверами составляет менее 5 минут - проверьте, это всего лишь доли секунды; проверьте, что все соответствующие членства в группах установлены - это действительно становится скучно при выполнении это во второй раз; проверьте записи DNS - в DNS действительно мало что могло быть неправильно замечено; проверьте, что KB3002567 не установлен - эй, наш WSUS позаботился об этом, не так ли?) мы начали рвать на себе волосы. Когда затем появился еще один намек на KB3002567, мы, наконец, просмотрели список установленных обновлений на нашем сервере Win2003 AD (черт возьми, это действительно стало проще с современными ОС), чтобы неожиданно найти его установленным. Удалите вручную, перезагрузите, все сразу счастливы!

В этой статье мы рассмотрим основные методы диагностики проблем с подключением к удаленному рабочему столу. Например, при попытке установить соединение с удаленным сервером с помощью встроенного в Windows клиента mstsc.exe (Подключение к удаленному рабочему столу) появляется сообщение «Инициирование удаленного подключения…», после чего пользователь получает сообщение об ошибке:

Удаленный рабочий стол не может найти компьютер %RDPHostName%. Это может означать, что %RDPHostName% не принадлежит указанной сети. Проверьте имя компьютера и домен, к которому вы пытаетесь подключиться.

Как исправить ошибку: удаленный рабочий стол не может найти компьютер в Windows?

В большинстве случаев эта ошибка означает наличие проблем с вашими DNS-серверами (или DNS-записями на них), из-за которых ваш компьютер не может разрешить указанное имя хоста.

Прежде всего убедитесь, что вы указали правильное имя удаленного хоста RDP в поле "Компьютер".

Попробуйте подключиться к RDP-серверу по IP-адресу, а не по DNS-имени. Если подключение RDP по IP-адресу установлено правильно, значит, проблема связана с DNS.

В настройках вашего компьютера с ОС Windows указаны неверные IP-адреса DNS-серверов;
На вашем компьютере файл hosts содержит неправильные записи для имен хостов RDP;
Ваши DNS-серверы недоступны (доступ заблокирован брандмауэром или сервер не работает);
В зоне DNS для вашего узла RDP нет записи DNS, или запись указывает на неправильный IP-адрес.

Попробуйте выяснить, знает ли ваш DNS-сервер полное доменное имя RDP-сервера, к которому вы подключаетесь (%RDPHostName%). Откройте командную строку с повышенными привилегиями и выполните команду:

Убедитесь, что команда вернула IP-адрес удаленного сервера, например:

Если команда вернула неправильную запись, попробуйте очистить кеш DNS (ipconfig/flushdns) на клиенте и снова попытаться разрешить имя хоста RDP.

Если команда nslookup возвращает ошибку «Время ожидания запроса DNS истекло», это означает, что ваш DNS-сервер недоступен (не в сети, заблокирован брандмауэром) или в настройках вашего сетевого подключения указан неверный DNS-сервер.

Проверьте предпочтительный и альтернативный IP-адреса DNS-серверов, указанные в настройках сетевого подключения. Вы можете получить адреса локальных DNS-серверов с помощью следующей команды PowerShell:

Если вы назначили адреса DNS-серверов вручную, проверьте их правильность у администратора сети. Если параметры DNS-сервера назначаются автоматически DHCP-сервером (Windows Server DHCP или Cisco DHCP-сервером), убедитесь, что они соответствуют вашей инфраструктуре. В последнем случае вы можете обновить настройки IP с помощью команды ipconfig:

Если приведенный выше совет не помог, убедитесь, что исходящий трафик клиента DNS разрешен в брандмауэре. Если вы используете брандмауэр Защитника Windows в режиме повышенной безопасности, вы можете добавить правила брандмауэра, чтобы принимать любой входящий трафик через порт 53 (как UDP, так и TCP).

Подсказка. Или просто сбросьте настройки брандмауэра Windows до состояния по умолчанию.

Если команда Nslookup по-прежнему возвращает недопустимую запись, откройте локальный файл hosts с помощью команды:

Если в файле нет записей для вашего RDP-сервера, вы можете попробовать добавить их вручную (таким образом вы сможете обойти неверные записи, возвращаемые вашим DNS-сервером). Вам необходимо добавить строку в файл hosts в следующем формате:

Вы можете использовать следующий пакетный скрипт, чтобы добавить новые записи в ваш хост-файл. Просто замените значения в скрипте IP-адресами и полными доменными именами ваших хостов RDP или серверов RDS:

Если проблема решена, это означает, что ваш DNS-сервер настроен неправильно. Вам необходимо проверить записи на нем или сообщить о проблеме администратору DNS.

Если вы являетесь членом группы безопасности домена администраторов DNS, вы можете проверить записи DNS с помощью оснастки mmc диспетчера DNS (dnsmgmt.msc).

Подключитесь к DNS-серверу (обычно это ближайший контроллер домена), разверните зону DNS и найдите запись A или CNAME вашего хоста RDP. Убедитесь, что он имеет правильный IP-адрес.

Если в зоне DNS много записей, вы можете использовать меню Вид > Фильтр, чтобы быстро найти нужные записи DNS.

Далее проверьте доступность сервера RDP с помощью команды ping:

Затем следует проверить, доступен ли RDP-порт 3389 (TCP) на сервере с клиента (это порт для RDP-подключения по умолчанию). Самый простой способ проверить доступность порта — использовать команду PowerShell:

Если команда вернула значение TcpTestSucceeded: False, это означает, что служба RDP на удаленном компьютере отключена (можно попробовать удаленно включить удаленный рабочий стол) или соединение заблокировано брандмауэром на удаленном компьютере. клиент, сервер или сетевые маршрутизаторы.

Если ваш брандмауэр Защитника Windows с повышенной безопасностью настроен на блокировку исходящих подключений, вам необходимо разрешить исходящие подключения RDP к указанному компьютеру по его IP-адресу. Вы можете создать новое правило в Защитнике Windows с помощью PowerShell:

Вы также можете разрешить исходящие подключения RDP к любому компьютеру:

Несколько советов, как проверить, не удается ли подключиться к RDP-серверу:

Попробуйте обновить версию вашего RPD-клиента (особенно если вы используете Windows XP, Windows 7 или 8.1);
Попробуйте использовать альтернативный RDP-клиент (RDCMan);
Временно отключите антивирус и брандмауэр на стороне клиента и сервера и проверьте соединение RDP;
Если вы подключаетесь из клиента Windows XP и на сервере включена NLA (проверка подлинности на уровне сети), то на стороне клиента XP вы можете включить поддержку NLA только через реестр;
Удаленное подключение невозможно, если учетная запись пользователя, под которой вы подключаетесь, не имеет пароля.

Проверьте настройки на хосте удаленного рабочего стола

Если ничего не помогает, нужно проверить настройки на удаленном хосте Windows, к которому вы подключаетесь по RDP. Откройте консоль PowerShell от имени администратора.

Проверьте IP-адрес и имя (FQDN) удаленного компьютера с помощью команды:

Убедитесь, что вы ввели правильный IP-адрес или имя хоста для подключения к этому компьютеру в окне клиента RDP.

Проверьте, использует ли компьютер профиль частной или доменной сети. Вы можете получить текущий профиль подключения следующим образом:

Если для параметра NetworkCategory задан профиль общедоступной сети, это может ограничить возможность подключения по протоколу RDP. Измените тип сетевого профиля на частный:

Проверьте, включен ли RDP на компьютере:

Если для параметра реестра fDenyTSConnections установлено значение 1, RDP отключен. Измените значение на 0.

Проверьте, запущены ли на компьютере следующие службы:

Службы удаленных рабочих столов (TermService).
Перенаправитель портов пользовательского режима служб удаленных рабочих столов (UmRdpService).

Если службы не запущены, измените порядок их запуска и перезагрузите компьютер:

Убедитесь, что служба RDP принимает подключения через TCP-порт 3389 по умолчанию:

Теперь проверьте, прослушивает ли служба RDP порт 3389:

Также проверьте, прослушивается ли этот порт службой TermService процесса svchost.exe (необходимо указать PID процесса с помощью команды netstat):

Теперь запустите команду:

Проверьте, содержит ли список rdp-tcp (прослушиватель протокола удаленного рабочего стола) со статусом прослушивания.

Удаленный рабочий стол не может найти компьютер через шлюз RDWeb

В некоторых случаях вы можете получить сообщение об ошибке «Удаленный рабочий стол не может найти компьютер» при попытке создать удаленное подключение RDP или запустить приложение RemoteApp, размещенное на шлюзе удаленных рабочих столов. Вы можете увидеть следующую ошибку после успешной аутентификации на шлюзе RDWEB:

RemoteApp отключен — удаленный рабочий стол не может найти полное доменное имя компьютера.

Чтобы решить эту проблему, откройте консоль управления IIS на сервере RD Web Access. Перейдите в раздел Сайты > Веб-сайт по умолчанию > RDWeb > Страницы. Откройте раздел Параметры приложения и в параметре DefaultTSGateway укажите внешнее DNS-имя вашего сервера RD Gateway.

Теперь обновите страницу RDWeb и попробуйте снова установить соединение RDP.

Мне нравится технология и разработка веб-сайтов. С 2012 года я веду несколько собственных веб-сайтов и делюсь полезным контентом по гаджетам, администрированию ПК и продвижению веб-сайтов.

Читайте также: