Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено…

imageНаконец-то добрались руки до того, чтобы развернуть новую ферму высоко-доступного RD Connection Broker на базе Windows Server 2012 R2. В отличие от конфигурации, которая описывалась ранее, было решено выполнить разделение ролей RDS и отказаться от использования NLB в пользу DNS Round Robin. При планировании развёртывания акцент был сделан на то, чтобы в итоге получить конфигурацию, которую можно будет считать более или менее поддерживаемой Microsoft. В результате получилась конфигурация из двух виртуальных серверов с совмещенными ролями RD Connection Broker/RD Web Access и пяти виртуальных серверов с выделенной ролью RD Session Host. А в силу того, что роли RD Connection Broker и RD Web Access не сильно требовательны к ресурсам, мы не стали создавать для них выделенные сервера, а установили эти роли на уже работающих серверах App-V 5.0 (с ролями Management Server, Publishing Server и Reporting Server, по аналогии с теми, которые были описаны в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности, только уже на базе Windows Server 2012 R2).

Сам процесс развёртывания ролей RDS прошёл достаточно гладко, однако в ходе тестирования работы новой фермы возник ряд вопросов, решение которых хоть и оказалось “на поверхности”. но всё-таки отняло некоторое время. И первый вопрос, который возник – на какие сервера должны указывать A-записи в DNS для Round Robin?

Некоторые товарищи предлагают при создании RR DNS записей использовать IP адреса серверов с выделенной ролью RD Session Host, как например здесь Step-by-Step Remote Desktop Connection Broker installation in Windows 2012 – Page 1 или здесь Creating RDS Load Balancing Farm, RD Session Host & Broker Services on WIn Server 2012 R2.

При этом специалисты, как я понимаю, из команды разработчиков Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012 для RR DNS записей предлагают использовать IP адреса серверов RD Connection Broker:

6. Assign static IP addresses to all the RD Connection Broker servers that will be a part of the Active/Active Broker deployment, and create a DNS Round Robin entry with these IP addresses.

Разумеется более приоритетным источником я считаю блог Remote Desktop Services Blog, и поэтому вношу в DNS A-записи ссылающиеся на сервера RDCB. В результате подобного рода конфигурации мы можем столкнуться с проблемой. При попытке подключения рядового пользователя к адресу RR DNS обычным способом из RDP-клиента мы получим сообщение об ошибке доступа:

image

Как я понял, это происходит потому, что клиент подключается к одному из серверов Connection Broker, и это подключение расценивается этими системами, как прямое к ним подключение. Чтобы подтвердить это предположение, можно добавить пользователя в группу доступа Remote Desktop Users на серверах Connection Broker, в результате чего подключение пройдёт успешно и мы войдём на сервер Connection Broker в режиме обычной терминальной сессии. То есть получается, что перенаправление пользователя на сервера RDSH на происходит.

В тоже самое время, если в свойствах коллекции сеансов RDS включена опция Show the session collection in RD Web Access (эта опция доступна только в случае, если коллекция имеет тип Session Remote Desktop, то есть когда в ней нет ни одного опубликованного приложения RemoteApp)… image

…то на веб-странице RD Web Access будет отображаться RDP-ярлык для подключения к этой коллекции. При подключении, как мы видим будет использоваться тоже самое имя, с которым мы не смогли подключиться обычным образом через RDP-клиент, и при этом подключение будет выполняться успешно…

image

Очевидно, что вся разница между неудачной попыткой прямого подключения через RDP-клиент и успешным подключением через ярлык в RD Web Access в возможных дополнительных параметрах, прописанных в свойствах RDP-файла опубликованного на RD Web Access. Чтобы увидеть эту разницу, достаточно сделать следующее:

1. В обычном RDP-клиенте сохраним *.rdp файл (с помощью кнопки «Сохранить как») с теми настройками, с которыми мы не смогли подключиться (получили ошибку доступа).

image

При сохранении будет создан *.rdp файл, который можно открывать и править в обычном текстовом редакторе. Далее нам нужно сравнить полученный *.rdp файл с тем, что публикуется (и успешно выполняет подключение к брокеру) на RD Web Access.

2. Чтобы получить прямой доступ к отображаемому на Web Access *.rdp файлу подключения к коллекции сеансов непосредственно с любого клиентского компьютера, можно попытаться запустить этот ярлык из браузера отличного от Internet Explorer, например Mozilla Firefox, где будет доступна возможность сохранения или открытия файла.

image 

Если же в коллекции уже есть опубликованные RemoteApp приложения, то на веб-странице Web Access значок подключения к коллекции сеансов будет отсутствовать. В таком случае можно получить *.rdp файл с подобными настройками от любого опубликованного RemoteApp-приложения. О том как это сделать и как получить доступ к таким *.rdp файлам, я писал ранее здесь — Публикуем приложения RemoteApp. Ещё один способ получения правильного *.rdp файла будет отдельно описан в следующей заметке.

3. Сравниваем полученные файлы. Основным отличием работающего *.rdp файла будет ряд строк:

...
full address:s:KOM-AD01-RDSCL.HOLDING.COM
workspace id:s:KOM-AD01-RDSCL.HOLDING.COM
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.KOM-AD01_RDSH_Se
use multimon:i:1
alternate full address:s:KOM-AD01-RDSCL.HOLDING.COM
signscope:s:Full Address,Alternate Full Address,Use Redirection Server Name,Server Port,GatewayUsageMethod,GatewayProfileUsageMethod,GatewayCredentialsSource,PromptCredentialOnce,RedirectDrives,RedirectPrinters,RedirectCOMPorts,RedirectSmartCards,RedirectClipboard,DevicesToRedirect,DrivesToRedirect,LoadBalanceInfo
signature:s:AQABAAEAAAC....

При этом ключевыми строками для возможности подключения здесь являются строки:

use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.KOM-AD01_RDSH_Se

Это легко проверить, если скопировать данные строки в обычный *.rdp файл, то у нас получится таки подключиться к ферме RDS. Однако, чтобы избежать возможных излишних предупреждений безопасности, всё-таки самым правильным вариантом будет использование rdp-файла содержащего параметры цифровой подписи (signature и signscope), то есть использовать именно тот файл, который доступен нам на веб-странице RD Web Access.

Таким образом, всё что нам нужно для успешного подключения к ферме RDS (используя в качестве записей RR в DNS адреса серверов RD Connection Broker)  – это специально сформированный *.rdp файл.

Всего комментариев: 19 Комментировать

  1. Обратная ссылка: Windows Server 2012 R2 Remote Desktop Web Access — Исчез ярлык на RDP файл для подключения к коллекции сеансов после публикации RemoteApp приложения | Блог IT-KB /

  2. Евгений /

    А с мобильного устройства из приложения Microsoft Remote Desktop получилось подключиться к rdp-сессии?

    1. Алексей Максимов / Автор записи

      Не пробовал. Моё мобильное устройство слишком старо для таких фич :)

  3. Обратная ссылка: Windows Server 2012 R2 Remote Desktop Services — Настраиваем пользовательский интерфейс на серверах RD Session Host | Блог IT-KB /

  4. Евгений /

    В чем плюс такой конфигурации в сравнении с предыдущей (http://blog.it-kb.ru/2013/09/05/remote-desktop-services-rds-rd-session-host-and-web-access-in-farm-high-availability-rd-connection-broker-in-nlb-cluster-on-windows-server-2012/) кроме поддержки Microsoft такого решения? Я не очень разбираюсь в балансировке ферм RDS, но разве такая конфигурация не вызывает сразу несколько проблем:
    1) Невозможность подключиться обратно в свою сессию после дисконнекта.
    2) Невозможность использования zero-клиентов типа thinstation (раньше у них были большие проблемы с RR DNS и «loadbalanceinfo» записью, возможно, сейчас ситуация по-лучше).
    3) Разве не будет RR DNS при малом количестве узлов неправильно балансировать подключения?
    Заранее спасибо.
    P. S. Хотел еще вопрос задать совсем не по теме. Мне не довелось поработать с WS2008: в нашей организации с 2003 перешли сразу на 2012R2. С точки зрения удобства администрирования и использования, какая из этих систем Вам ближе?

    1. Алексей Максимов / Автор записи

      1. Никогда не сталкивался с такой ситуацией. С момента публикации поста работаем с 2012R2 — полёт нормальный.
      2. Не могу по этому поводу точно сказать, так как не имею таких клиентов.
      3. см.п.1
      Вопрос удобства риторический. Технологически однозначно новая RDS выглядит привлекательней.

  5. Антон /

    Добрый день!
    Я правильно понимаю из статьи что :
    1. Две ноды с ролями RD Connection Broker/RD Web Access НЕ находятся в NLB кластере (для 443/3389 портов)? И соответственно им нужен 1 сетевой интерфейс из продуктивной сети.
    2. Запись одного DNS имени (общее для подключения клиентов) в DNS делается на два адреса IP хостов из пункта 1.
    3. Верная ли мысль : «В ранее опубликованном NLB варианте фермы из 5 хостов необходимо «разобрать» NLB на 5 хостах, оставить по 1 интерфейсу,удалить лишние роли кроме RDCH. Добавить в ферму новые два сервера из пункта 1. Удалить из фермы настройки для RDCB high availability. Имя NLB (которое фигурирует в rdp ярлыке как точка подключения) использовать для RR DNS записи для пункта 2
    Спасибо.

    1. Алексей Максимов / Автор записи

      1. NLB не используется. Об этом написано. Сколько интерфейсов нужно зависит от ваших потребностей, возможностей и фантазии.
      2. Одинаковые A-записи делаются для двух серверов с ролью RD Connection Broker.
      3. Я бы лучше сделал так:
      а) Выводим из действующей фермы с NLB 2 сервера.
      б) Собираем из выведенных серверов новую ферму c HA RDCB и DNS RR и тестируем её работу.
      в) Выводим оставшиеся серверы из старой фермы и заводим в новую.

  6. Владислав /

    Алексей, не уже ли нет другого варианта, кроме как специального RDP файла?

    1. Алексей Максимов / Автор записи

      Мне пока другие варианты неизвестны. Если у Вас появится такая информация, — не забудьте поделиться

      1. Владислав /

        Жаль. Это становится большой проблемой при переводе большого количества сотрудников на новую ферму. Алексей, на Вашей практике были такие «переезды»? Как Вы их решали?

        1. Алексей Максимов / Автор записи

          Разливали готовый RDP файл по клиентам с помощью SCCM.

          1. Владислав /

            Спасибо за Ваши статьи и комментарии! Очень полезный материал!

  7. Дмитрий /

    Добрый вечер Алексей. А если у нас используются тонкие клиенты , например типа TONK,то на тонкий клиент такой rdp файл не разольешь…

    Спасибо!

    1. Алексей Максимов / Автор записи

      Дмитрий, понятно, что в такой конфигурации универсальных решений быть не может. У меня нет под руками таких тонких клиентов, поэтому от комментариев на эту тему воздержусь. Если Вы найдёте какое-то решение своего вопроса, то не забудьте нам о нём рассказать. Возможно оно кому-то поможет.

  8. Дмитрий /

    Добрый вечер Алексей. Тут прочитал одну статейку — http://ryanmangansitblog.com/2013/03/11/connection-broker-redirection-rds-2012/
    Но что-то смысл пока до конца не уловлю.У меня есть коллекция с именем RDS_Farm-01, соответственно я вписал имя фермы (коллекции) в ключ
    DefaultTsvUrl tsv://VMResource.1.RDS_Farm-01.
    Теперь подключаясь на прямую к RDCB,брокер мне говорит, что в пуле не найдено не одного сервера.Хм..попробовал вообще создать алиас в DNS по имени фермы RDS_Farm-01 указанием на брокер.Подключился, но с двумя предупреждениями о неверных сертификатах от брокера и нужного RDSH.
    Вопрос: не могу понять, чего добивался автор статьи, если мы хотим по умолчанию использовать брокер для редиректа на узлы сеансов- то нужно добавить всего навсего в реестре самого сервера-брокера нужный ключ.Но увы не работает сходу.как говорит автор.
    Вопрос почему ? Может что-то еще надо указать..
    Спасибо! Это на фоне всего того же — не использовать специальный RDC клиент

    1. Алексей Максимов / Автор записи

      Спасибо за полезную наводку. Опубликовал новую заметку с примером использования параметра DefaultTsvUrl.

  9. Обратная ссылка: Windows Server 2012 R2 Remote Desktop Connection Broker — Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в си /

  10. AlektroNik /

    Хочу поделится интересной особенностью по поводу связки Remmina -> DNS Round Robin -> RDGW.

    Предыстория:
    Долгое время грешил на Remmina, что она не работает корректно с RD Gateway server. Натыкался на кучу инфы, что, действительно, баги такие наблюдались … все ждал и параллельно тестировал. Иногда случалось каким-то чудом подключиться через RDGW и, как на зло, каждый раз в этот момент я либо только что выключил фаервол или установил чистую Fedora 24. Грешил на мой MintLinux 18. Тут дошли руки до более глубокого изучения проблемы. С помощью tcpdump все и решилось. При подключении сначала идет куча запросов и ответов на один из IP закрепленных за DNS Round Robin именем двух RDGW серверов, а потом вдруг начинают иди запросы на второй IP и у Remmina случается разрыв шаблона судя по всему. Где-то читал что Google на своих DNS серверах то ли отказался, то ли собирается отказаться от поддержки Round Robin примерно по этим же соображениям, что, мол, Round Robin не эффективен и не предсказуем, он в чем-то прав :)

    Решение:
    Вписать один из IP адресов RDGW серверов в настройки подключения в Remmina или использовать балансировщики нагрузки. Ну либо совсем крайний случай, отказаться от второго и т. д. сервера :)

    Надеюсь кому-то эта заметка сэкономит время.

Добавить комментарий