Назад | Перейти на главную страницу

Ферма серверов удаленных рабочих столов перестает работать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ИЗМЕНИТЬ после комментария: Похоже, что основные обвиняемые обновления KB3002657, KB3035017 либо не были установлены, либо были установлены за несколько дней до начала проблемы на соответствующих серверах (клиенты, серверы RDP, брокер, контроллеры домена), но я все равно попробую их удалить .. .

ОБНОВИТЬ Дополнительная информация:

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

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

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

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

Von 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.

Венн Sie eine Verbindung mit einem bestimmten Fammitglied herstellen möchten, um es zu verwalten, geben Sie "mstsc.exe / admin" an der Eingabeaufforderung ein.

Чтобы выяснить, не виновато ли какое-то недавнее обновление на стороне Cleint, я начал с новой коробки 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.

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

  • Тонны обновлений Windows

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

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

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

  1. создать A-RR в зоне DNS для <domain> для <farmname.domain> указывает на каждый из ваших хостов сеанса на ферме
  2. настроить доверенные сертификаты для каждого <sessionhost.domain> с Альтернативное имя субъекта из <farmname.domain> и установите / включите их для служб RD на каждом из ваших хостов сеанса
  3. настроить GPO, настроив все узлы сеанса в качестве участников фермы для <farmname> в <connectionbroker.domain> (все настройки в Административные шаблоны / Компоненты Windows / Службы удаленного рабочего стола / Узел сеанса удаленного рабочего стола / Посредник подключений к удаленному рабочему столу):
  4. настроить GPO, чтобы назначить компьютерную учетную запись вашего брокера подключений в качестве члена Distributed COM Users (built-in)
  5. перезагрузите узлы сеанса, чтобы убедиться, что все политики применяются и действуют
  6. проверить подключение клиента к <farmname.domain>

Удачи!