Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено…
Наконец-то добрались руки до того, чтобы развернуть новую ферму высоко-доступного 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-клиента мы получим сообщение об ошибке доступа:
Как я понял, это происходит потому, что клиент подключается к одному из серверов Connection Broker, и это подключение расценивается этими системами, как прямое к ним подключение. Чтобы подтвердить это предположение, можно добавить пользователя в группу доступа Remote Desktop Users на серверах Connection Broker, в результате чего подключение пройдёт успешно и мы войдём на сервер Connection Broker в режиме обычной терминальной сессии. То есть получается, что перенаправление пользователя на сервера RDSH на происходит.
В тоже самое время, если в свойствах коллекции сеансов RDS включена опция Show the session collection in RD Web Access (эта опция доступна только в случае, если коллекция имеет тип Session Remote Desktop, то есть когда в ней нет ни одного опубликованного приложения RemoteApp)… 
…то на веб-странице RD Web Access будет отображаться RDP-ярлык для подключения к этой коллекции. При подключении, как мы видим будет использоваться тоже самое имя, с которым мы не смогли подключиться обычным образом через RDP-клиент, и при этом подключение будет выполняться успешно…
Очевидно, что вся разница между неудачной попыткой прямого подключения через RDP-клиент и успешным подключением через ярлык в RD Web Access в возможных дополнительных параметрах, прописанных в свойствах RDP-файла опубликованного на RD Web Access. Чтобы увидеть эту разницу, достаточно сделать следующее:
1. В обычном RDP-клиенте сохраним *.rdp файл (с помощью кнопки «Сохранить как») с теми настройками, с которыми мы не смогли подключиться (получили ошибку доступа).
При сохранении будет создан *.rdp файл, который можно открывать и править в обычном текстовом редакторе. Далее нам нужно сравнить полученный *.rdp файл с тем, что публикуется (и успешно выполняет подключение к брокеру) на RD Web Access.
2. Чтобы получить прямой доступ к отображаемому на Web Access *.rdp файлу подключения к коллекции сеансов непосредственно с любого клиентского компьютера, можно попытаться запустить этот ярлык из браузера отличного от Internet Explorer, например Mozilla Firefox, где будет доступна возможность сохранения или открытия файла.
Если же в коллекции уже есть опубликованные RemoteApp приложения, то на веб-странице Web Access значок подключения к коллекции сеансов будет отсутствовать. В таком случае можно получить *.rdp файл с подобными настройками от любого опубликованного RemoteApp-приложения. О том как это сделать и как получить доступ к таким *.rdp файлам, я писал ранее здесь — Публикуем приложения RemoteApp . Ещё один способ получения правильного *.rdp файла будет отдельно описан в следующей заметке.
3. Сравниваем полученные файлы. Основным отличием работающего *.rdp файла будет ряд строк:
При этом ключевыми строками для возможности подключения здесь являются строки:
Это легко проверить, если скопировать данные строки в обычный *.rdp файл, то у нас получится таки подключиться к ферме RDS. Однако, чтобы избежать возможных излишних предупреждений безопасности, всё-таки самым правильным вариантом будет использование rdp-файла содержащего параметры цифровой подписи (signature и signscope), то есть использовать именно тот файл, который доступен нам на веб-странице RD Web Access.
Таким образом, всё что нам нужно для успешного подключения к ферме RDS (используя в качестве записей RR в DNS адреса серверов RD Connection Broker) – это специально сформированный *.rdp файл.
Remote Desktop Services 2012 Connection Broker с высокой доступностью
Remote Desktop Connection Broker (RD Connection Broker) – это функционал роли терминального сервера Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между серверам в ферме Remote Desktop (при подключении к RDS пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователей к VDI и RemoteApp, а также реализует возможность переподключения пользователей к своим сессиям (при подключении к новому серверу RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и в случае ее обнаружения новая сессия не создается, а пользователь перенаправляется в старую сессию).
В этой статье мы рассмотрим процесс настройки отказоустойчивого высоко-доступного экземпляра RD Connection Broker, обеспечивающего свой функционал при выходе из строя одного из серверов с ролью RDCB.
В отличии от реализации RDCB в предыдущих версиях Windows Server, Connection Broker в Windows Server 2012 обеспечивает высокую доступность в режиме Active/Active, когда каждый из серверов RDCB является активным и обрабатывает входящие запросы. Это позволяет обеспечить высокую доступность и масштабируемость RDCB в больших фермах Remote Desktop. Для хранения данных RDCB используется БД на MS SQL Server.
Требования для внедрения отказоустойчивого RDCB
- Как минимум 2 сервера с ролью RDCB (под ОС Windows Server 2012 / 2012 R2)
- SQL Server ( редакция SQL server 2008 R2 Standard или выше) c минимум 4 Гб RAM
- Наличие установленного SQL Server Native Client
- Полные права серверов RD Connection Broker на БД SQL и каталог установки SQL
- Минимум один сервер с ролью Remote Desktop Session Host в ферме
- Разрешенные исключения для портов SQL server в фаерволе Windows
Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и включить в домен Active Drectory.
- RDCB1.domain.ru — 172.25.104.71
- RDCB2.domain.ru — 172.25.104.171
В Active Directory создадим отдельную группу безопасности RDS Connection Brokers, в которую нужно включить все сервера RDCB.
Далее на отдельном сервере (или SQL-кластере) устанавливается SQL Server версии 2008 R2 или 2012 Standard.
На SQL сервере с помощью SQL Server Management Studio в разделе Security нужно создать новый login и предоставить доменной группе RDCB права с возможностью создания и редактирования баз данных. Также этой группе нужно предоставить полные права на каталог установки SQL.
На SQL сервере нужно создать каталог, в котором будут храниться файлы БД, например, C:\SQLDB, и предоставить этой же группе полные права на каталог.
На всех серверах с ролью RDCB необходимо установить SQL Server Native Client. Его нужно скачать отдельно с сайта MS, либо запустить прямо с установочного диска (на установочном диске SQL Server 2012 он хранится в каталоге \1033_ENU_LP\x64\Setup\x64\sqlncli.msi).
Для SQL server 2008 R2 нужен SQL native client 10, для SQL Server 2012 — SQL Native client 11.
В брандмауэра SQL-сервера создадим новое правило, открывающее порт TCP 1433 для доменных машин. Сделать это можно так:
netsh advfirewall firewall add rule name = SQLSRVPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN
Следующий шаг – создание в DNS зоне A записей для реализации балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Например, DNS имя нашей фермы RDCB будет RDCB_lb. Создадим две следующие A записи вида:
- A RDCB_lb.domain.ru 172.25.104.71 (ip адрес RDCB1)
- A RDCB_lb.domain.ru 172.25.104.171 (ip адрес RDCB2)
С помощью консоли Server Manager на первом из серверов RDCB устанавливаем роль RD Connection Broker (если еще не установлена).
После установки роли RDCB используется маленькая локальная база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге c:\windows\rdcbDb\.
В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.
Для переноса БД на выделенный SQL Server нужно перейти на вкладку управления Remote Desktop Services -> Overview. Для запуска мастера создания отказоустойчивой конфигурации RD Connection Broker, щёлкнем ПКМ по изображению роли RD Connection Broker и выбираем пункт Configure High Availability. Запустившийся мастер должен создать БД на MS SQL Server и перенести в нее локальную конфигурацию.
- Database Connection String – строка подключения с базе на SQL сервере.Для SQL 2008 R2: DRIVER=SQL Server Native Client 10.0;SERVER= ;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=
Для SQL 2012 :DRIVER=SQL Server Native Client 11.0;SERVER= ;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=
Затем откроем SQL Server Manager на сервере СУБД и убедимся, что была создана новая база. Переходим на вкладку Security, выберем ранее добавленную группу — > свойства, и в качестве БД по-умолчанию выбираем базу RDS. Потом отмечаем роли db_owner и public.
Для обеспечения высокой доступности на случай выхода из строя первого сервера, необходимо в текущую конфигурацию добавить второй узел Connection Broker.
Для этого щелкаем ПКМ по иконке RD Connection Broker, и выбираем пункт Add RD Connection Broker Server.
Указываем имя второго сервера, на котором нужно установить роль Connection Broker и жмем Далее.
На этом настройка High Availability конфигурации Connection Broker завершена.
Итак, мы создали высоко доступный сервис RD Connection Broker на Windows Server 2012. Вы можете протестируйте доступность RDCB, отключив один из серверов фермы RDCB. В этом сценарии точкой отказа остается SQL server. Отказоустойчивость SQL сервера можно реализовать с помощью HA SQL кластера или зеркалирования базы SQL.