rds ферма что это
Rds ферма что это
Доброго времени суток, многоуважаемые инженеры, системные администраторы и просто начинающие пользователи. Рад вас вновь приветствовать на страницах IT блога Pyatilistnik.org. Если вы мой постоянный читатель, то вы заметили, что я очень часто и много пишу про терминальные сервера и RDS фермы. Сегодня я хочу вам показать, как производится управление RDS фермой Windows Server 2012 и Windows Server 16. Я на сто процентов уверен, что данная информация будет вам полезна, так как я часто видел опытных администраторов, кто не знал как это делается, в виду старых знаний и стереотипов, о данной технологии.
Описание ситуации
Пришел один администратор к нам на работу, пришла заявка, что нужно было для обслуживания вывести из RDS фермы один из узлов подключения, посидев некоторое время и потыкав диспетчер серверов, он не смог выполнить данную задачу, потому что у него было понимание работы терминального сервера, но не фермы.
В чем отличие фермы от терминала
Если посмотреть организацию удаленного доступа в Windows Server 2008 R2, то там схема была простой, где-то в сети устанавливался сервер лицензирования удаленных рабочих столов, а уже на нужно из серверов, куда планировалось подключение, ставилась роль «Службы удаленных рабочих столов». Ему назначались лицензии и пользователь подключался.
Если посмотреть концепцию Windows Server 2012 R2 и старше, то выглядит это уже вот так, есть некое виртуальное имя к которому все подключаются, есть серверная роль «Посредник подключения (RD Connection Broker)«, он берет на себя роль распределения нагрузки и количество сеансов пользователей, на сервера удаленного подключения «RD Session Host«, где уже работаю пользователи. Вся эта конструкция объединяется в некий пул. называемый RDS фермой, где легко создать отказоустойчивость на уровне посредников подключения и легко обслуживать хосты конечного подключения.
Схема управления RDS фермой
Тот сотрудник не совсем понимая схему и видя ее впервые, наивно подумал, что все управление Remote Desktop Services фермой осуществляется через посредника подключения (Connection Broker). Он попытался к нему подключиться, но его послали с формулировкой «Удаленный компьютер «имя», попытка подключения к которому выполняется, перенаправляет вас на удаленный компьютер «имя», он то и не знал, что для подключения к нужному хосту фермы нужно использовать специальные ключи.
Далее показав ему, как происходит подключение к посреднику, он попытался отыскать оснастку управления, так как в Windows Server 2008 R2, была именно такая реализация работы, но он там ничего не нашел. Он подглядел у меня, что я управляю RDS, через «Диспетчер серверов». Он его открывает и у него там то же ничего не оказалось, в итоге он побился часок и попросил ему показать. Чтобы знающих людей стало больше и грамотность системных инженеров была больше я вам написал небольшую инструкцию. Не подумайте, что я надменно отнесся к своему коллеге, я просто так же был однажды в на его месте и понимал, что это просто отсутствие опыта, что не смертельно.
Собираем консоль управления RDS фермой
Для управления настройками Remote Desktop Services вам потребуется клиентская операционная система Windows 8.1 или Windows 10, либо это могут быть Windows Server 2012 R2 и выше. Там нам потребуется оснастка «Диспетчер серверов».
Если вы знаете всех участников RDS фермы, то это хорошо, вы немного себе выиграете времени, если нет, то придется слегка пописать команды и помучить DNS-сервер.
Откройте командную строку или запустите PowerShell оболочку. Предположим у вас виртуальное имя для подключения к удаленному рабочему столу TERM. Тут у вас два варианта:
И та и другая выдали вам ip-адреса, в которое разрешается ваше виртуальное имя RDS фермы. В моем примере их два. Эти адреса принадлежат посредникам по подключению (Connection Broker), делаем так же запрос:
Стрелками я выделил полученные DNS имена, самое главное мы получили.
Теперь открывает оснастку «Диспетчер серверов» от имени той учетной записи у которой есть права на администрирование RDS фермы. В открывшейся оснастке выберите пункт «Добавить другие серверы для управления»
У вас откроется окно «Добавление серверов», перейдите на вкладку DNS и в поисковой строке укажите нужное имя брокера и нажмите кнопку с изображением лупы. У вас будет осуществлен поиск по базе Active Directory, если такой сервер есть, то он будет отображен в списке. Переносим его в поле выбрано.
Точно так же поступаем и с остальными посредниками подключений к Remote Desktop Services ферме.
У вас начнется процесс добавление в вашу оснастку дополнительных серверов. Когда закончится добавление, то вы увидите, что у вас появились серверные роли, в нашем случае «Службы удаленных рабочих столов» и обратите внимание на иконку «Все серверы», тут стало их уже два.
Переходим в роль «Службы удаленных рабочих столов», в итоге у вас отобразится список всех участников RDS фермы, и для ее управления вам нужно их всех добавить в данных пул серверов.
В итоге у меня добавились все мои хосты подключения и сервера лицензирования. Как видите стало 20 серверов.
Переходим в «Службы удаленных рабочих столов», в этот раз у вас уже откроется полноценное управление коллекциями RDS. Вы увидите схему работы, вам будет представлен список всех ваших серверов и кто за какую роль отвечает. Переходим в саму коллекцию.
Попав в коллекцию удаленных рабочих столов, у вас будет несколько областей:
Так же для удобства администрирования серверов, я вам советую создавать отдельные группы по нужным вам признакам и управлять ими, но об этом уже в другой раз. Либо же вы можете создать группу серверов в Remote Desktop Connection Manager.
Rds ферма что это
Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В прошлый раз мы с вами разобрали ситуацию, когда ваш жесткий диск виделся в формате RAW и не позволял получить доступ к данным, мы это благополучно решили. Сегодня мы рассмотрим задачу установки отказоустойчивой терминальной фермы Remote Desktop Services, где посредники подключений (RD Connection Broker) работают в режиме высокой доступности (High Availability) и все это дело будет работать на Windows Server 2019 в связке с хостами подключений (RDSH) на базе Windows Server 2016. Давно хотелось у себя на сайте иметь такую инструкцию, тем более что давно стояла задача перехода с W2012R2.
Постановка задачи
Необходимо организовать высоко доступную ферму RDS (Remote Desktop Services), где в качестве брокеров подключения будут выступать операционные системы с Windows Server 2019. В качестве хостов подключений, на которых будут работать конечные пользователи требуется иметь операционную систему Windows Server 2016. Развернуть сервер лицензирования, раздающий лицензии на пользователя или устройства. Чем хорошо использовать в качестве посредников подключений именно Windows Server 2019, все просто, когда большинство клиентского программного обеспечения станет поддерживаться данной ОС, можно будет легко вывести из эксплуатации сервера с W2016 и заменить их на более новые.
Требования по развертыванию RD Connection Broker High Availability
Прежде, чем мы начнем к поэтапному приготовлению к установке вашей отказоустойчивой RDS ферме, я бы хотел выделить пункты, которые нам потребуется выполнить.
Тестовый стенд с виртуальными машинами фермы Remote Desktop Services
Стандартная установка RDS фермы в Windows Server 2019
Перед тем, как мы сделаем высокодоступное подключение к ферме Remote Desktop Services, нам необходимо произвести установку стандартной конфигурации служб удаленных рабочих столов, включающей в себя:
Создание пула серверов на сервере посредника подключений (RD Connection Broker)
Пул серверов, это удобное объединение серверов в общий список для быстрого управления и развертывания на них ролей и компонентов. Все манипуляции производятся из единой консоли управления «Диспетчер серверов». Откройте оснастку «Диспетчер серверов» раздел «Все серверы». Щелкните по нему правым кликом и нажмите «Добавление серверов».
На вкладке Active Directory вам необходимо указать в каком домене вы будите производить поиск, в поле «Имя (Общие)» находим нужные вам сервера.
Выбираем нужные сервера и переносим их в раздел «Выбрано».
В итоге в вашей оснастке «Диспетчер серверов» вы увидите все добавленные хосты. которые будут участниками Remote Desktop Services High Availability на Windows Server 2019.
В результате все должно быть в статусе «В сети».
Стандартное развертывание службы удаленных рабочих столов
В мастере добавления ролей выберите пункт «Установка служб удаленных рабочих столов (Remote Desktop Services Installation)» и нажимаем далее.
Выбираем второй пункт «Развертывание рабочих столов на основе сеансов (Session-based desktop deployment)»
Список компонентов устанавливаемых при стандартной конфигурации RDS фермы. Тут будет установлен:
На следующем шаге вам нужно выбрать и перенести в правую область сервер, который будет нести на себе роль «Посредник подключений к удаленным рабочим столам (RD Connection Broker)». В моем примете, это первый сервер RDCB01.root.pyatilistnik.org.
Далее у нас идет выбор сервера для установки роли «Веб-доступ к удаленным рабочим столам (RD Web Access)», так как я пока не планирую использовать веб доступ RemoteApp, а настрою это потом, то я воспользуюсь галкой «Установить службу веб-доступа к удаленным рабочим столам на сервере посреднике подключений к удаленному рабочему столу (Install the RD Web Access role service on the RD Connection Broker server)»
Последним идет пункт по установке роли на сервера к которым вы будите непосредственно подключаться, выбираем нужные сервера и инсталлируем на них роль «Узел сеансов удаленных рабочих столов (RS Session Host)». В моем примере, это два сервера rdsh01 и rdsh02.
Процесс установки ролей подразумевает, что потребуется перезагрузка сервера, для этого вам необходимо выставить галку «Автоматически перезапускать конечный сервер, если это потребуется (Restart the destination server automatically if required )» и нажать кнопку «Развернуть«
Начинается процесс установки службы удаленных рабочих столов, может занимать несколько минут.
У вас должна произойти успешная установка службы «службы удаленных рабочих столов». Все необходимые сервера будут перезагружены.
Давайте убедимся, что все серверы получили свои роли. Для этого на сервере, где вы добавляли сервера в оснастку «Диспетчер серверов (Производили установку)», откройте оснастку и перейдите в раздел «Службы удаленных рабочих столов».
На вкладке «Общие сведения» посмотрите в разделе «Серверы развертывания», кто и какие роли себе установил.
Перейдите в раздел «Коллекции» и убедитесь, что список пуст, но зато присутствуют два ваших хоста узла сеансов удаленных рабочих столов, к котором будут подключаться конечные пользователи. Они будут иметь статус «Истина (True)», что говорит о разрешении подключаться (Режим стока выключен)
Следующим шагом мы создадим новую коллекцию для подключения к службам Remote Desktop Services High Availability на Windows Server 2019.
Создание коллекции для отказоустойчивой терминальной фермы
Так, что подытожим, коллекции RDS призваны решать две задачи:
Придумываем любое имя для вашей коллекции, в моем примере это root-collection
Теперь вам необходимо определиться какие серверы с ролью узлов сеансов (RDSH) вам нужно включить в коллекцию, у меня это RDSH01 и RDSH02
Указываем каким пользователям или группам разрешен доступ к данной терминальной ферме, я удалю группу «Пользователи домена» и добавлю другую.
У меня получился вот такой список доступа, потом его так же можно изменить.
Я снимаю галку «Включить диски профилей пользователей» так как не планирую использовать UDP диски.
Смотрим сводную информацию по создаваемой коллекции и нажимаем «Создать».
Дожидаемся создания коллекции службы удаленных рабочих столов.
В общем списке у вас будет ваша коллекция.
Про описание свойств коллекции RDS я уже писал пост, можете к нему обратиться. Теперь у системного администратора, кто первый раз развернул стандартную установку службы удаленных рабочих столов возникает вопрос, как ему подключиться к новой коллекции и это правильный вопрос, так как если вы сейчас попытаетесь подключиться брокеру, то вас не перекинет на хост из коллекции, вы просто попадете на сам RDCB хост. Чтобы это поправить нам нужно сделать две вещи:
Настройка RD Connection Broker для подключений к ферме RDS
Как я писал выше в текущей конфигурации посредник подключений к удаленным рабочим столам вас не будет перебрасывать в коллекцию, он просто будет подключаться к брокеру по RDP, ниже мы это поправим.
Для подключения к ферме Remote Desktop Services в отказоустойчивой конфигурации создают две записи DNS и направляют их на сервера с ролью RD Connection Broker, кто-то балансирует иначе, но мы в данном окружении воспользуемся именно DNS и механизмом перебора Round Robin. Откройте оснастку и создайте A-запись с нужным именем вашей RDS фермы у меня это будет DNS имя «terminal«.
Я пока создам одну A-запись с таким именем и в качестве IP-адреса укажу адрес моего первого сервера с ролью RD Connection Broker.
В запись terminal.root.pyatilistnik.org успешно создана.
Проверяем ее через утилиту PING
Теперь, чтобы наш сервер посредник подключений к удаленным рабочим столам перебрасывал нас на RDSH сервера, нам необходимо подключиться к RD Web серверу и скачать RDP-файл с конфигурацией. Данный файл будет нести в себе параметры, о наименовании коллекции, при обращении к которой вы попадете на один из конечных серверов.
Стандартный адрес для подключения к вашему серверу RD Web, это:
Проверить наличие данного адреса вы можете открыв диспетчер IIS.
У вас должна открыться вот такая страница с авторизацией.
Теперь нам нужно получить значение loadbalanceinfo из свойств вашей коллекции, оно будет прописано в реестре брокеров. Для этого выполним публикацию приложения RemoteApp. Переходим в коллекцию службы удаленных рабочих столов и находим раздел «Удаленные приложения RemoteApp«. Нажимаем на задачи и произведем публикацию удаленного приложения RemoteApp.
Выберите для примера обычный калькулятор
Нажимаем «Опубликовать«.
Дожидаемся публикации приложения в коллекции Remote Desktop Services.
Далее вы переходите в веб интерфейс RDWEb и авторизуетесь, у вас будет доступно приложение калькулятор. Щелкните по нему и у вас будет запущено скачивание RDP пакета.
Теперь полученный файл RDP нужно открыть через блокнот.
Вам нужно найти строку loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.root-collection, она то нам и нужна для прописывания ее в реестре сервера несущего роль посредника подключений к удаленным рабочим столам (Connection Broker).
Переходим на сервер с ролью RD COnnection Broker и открываем реестр Windows. Переходим в раздел:
Создаем тут ключ реестра с типом REG_SZ (Строковый) и именем DefaultTsvUrl. В качестве содержимого вставляем tsv://MS Terminal Services Plugin.1.root-collection
Перезагрузите на всякий случай ваш брокер. Пробуем теперь произвести подключение по имени terminal.root.pyatilistnik.org.
Как видите нам ответил rdcb01.root.pyatilistnik.org
Но как и было задумано посредник подключений к удаленным рабочим столам перекину нас на конечный хост с ролью RDSH. Я для теста сделал три подключения, все отлично работает. Можно сказать, что мы успешно установили и настроили стандартную Remote Desktop Services ферму на базе Windows Server 2019. Теперь можно превращать ее в высоко доступную, о чем и пойдет речь ниже.
Создание группы безопасности для RD Connection Broker
Следующим шагом нам необходимо в Active Directory создать группу безопасности в которую мы поместим наши сервера с ролью RD Connection Broker. Необходимо, это для того, чтобы мы этой группе безопасности назначили необходимые права на нашем SQL сервере.
Открываем оснастку ADUC и создаем в нужном вам расположении группу безопасности RD-Connection-Broker. Я выставлю область действия группы (Локальная в домене).
Добавим в группу RD-Connection-Broker два сервера с ролью посредника подключений к удаленным рабочим столам. В моем случае, это RDCB01 и RDCB02.
Установка SQL Native Client
Следующим шагом вам необходимо на обоих серверах с ролью RD Connection Broker установить бесплатного клиента SQL Native Client, это необходимое требование. Где скачать SQL Native Client и как его установить я подробно рассказывал, на этом я останавливаться не буду, посмотрите по ссылке.
Установка и настройка MS SQL 2016
Следующим подготовительным требованием идет установка общей базы для наших брокеров, в моем примере это будет MS SQL 2016 Standard. Сам процесс инсталляции я подробно разбирал, так что так же советую посмотреть мою статью. Еще я вам советую делать всегда вашу базу данных отказоустойчивой, в режиме Always On.
Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).
Описание задачи
Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.
По информации доступной из блога TechNet Blogs > Mark Ghazai’s Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.
Среда исполнения
Три виртуальных сервера на базе Windows Server 2008 R2 Enterprise EN. Корпоративная редакция ОС потребуется нам из-за необходимости использования средств Windows Failover Clustering.
Каждый из серверов имеет по два сетевых интерфейса.
Создаваемый в процессе описания кластерный экземпляр Windows Failover Clustering будет иметь имя KOM-AD01-RDSCL.
Кластеризованный экземпляр службы RD Connection Broker будет иметь имя KOM-AD01-RDCB
С точки зрения сетевого взаимодействия, упрощённая схема отказоустойчивой фермы RDS в нашем случае будет выглядеть так:
Настраиваем сетевые параметры
Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 – Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.
Выполним описанные ниже настройки на каждом из трёх серверов.
Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).
NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.
Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.
В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:
В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.
Здесь же, по кнопке Advanced откроем окно дополнительных настроек
В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS
Как было сказано ранее, указанные настройки сетевых интерфейсов нужно сделать по аналогии согласно нашей схемы на всех трёх серверах.
Устанавливаем роль Remote Desktop Services
На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles
В открывшемся окне мастера выбираем роль Remote Desktop Services
Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker
На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication
Значение этой настройки, как и всех других в этом мастере можно будет в изменить позже в любое время после установки роли с помощью оснасток управления RDS
На шаге выбора групп добавим заранее созданную доменную группу безопасности, в которую будут включаться пользователи имеющие потребность в доступе к ресурсам расположенным на серверах создаваемой фермы RDS. После установки роли на сервере будет создана специальная локальная группа безопасности Remote Desktop Users в которую и будут включены выбранные нами на этом шаге группы
На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под Desktop Experience понимается установка дополнительных пользовательских компонент в составе:
В многопользовательской среде должен быть взят за правило принцип необходимого минимума приложений и поэтому, следуя этому принципу мы не будем устанавливать этот «винегрет».
Далее, после окончания процесса установки роли RDS потребуется перезагрузка сервера. После перезагрузки сервера войдём в систему и дождёмся автоматического открытия окна мастера добавления ролей, который должен будет сообщить нам об успешном окончании процесса.
В открывшемся окне мастера добавления возможностей выбираем Failover Clustering
Создаём кластер
На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster
В открывшемся мастере создания кластера добавляем все три сервера которые мы планируем включить в будущий кластер
На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.
В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.
Настраиваем кластерные ресурсы
После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.
Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application
В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker
Обратите внимание на то, что в официальной документации есть информация об ограничениях в ситуации когда вы хотите создать кластеризованный экземпляр службы RD Connection Broker в уже существующем кластере и при этом в этом кластере есть настроенные ранее службы типа Generic Service.
На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker
На этапе создания службы в кластере в домене также будет создана дополнительная учетная запись и будет произведена регистрация имени в DNS
После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.
Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети.
Включаем сервера в ферму RD Connection Broker
На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.
Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажимаем кнопку Change Settings.
В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name по рекомендации оставим схожим с именем кластерного экземпляра.
Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.
Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…
… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker
После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host
Уже на этом этапе можно попробовать работу нашей фермы в действии подключившись RDP клиентом на адрес фермы. При отключении пользовательского сеанса и повторном подключении RDCB должен направлять нас в уже существующую сессию.
Настраиваем сертификаты серверов RDSH фермы RDCB
При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен
Если открыть свойства этого сертификата мы увидим что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным.
Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.
Также при создании запроса на сертификат нужно учесть то, что создаваемый сертификат желательно иметь с альтернативными именами объекта – Subject Alternative Name (SAN). В противном случае при подключении клиенты могут получать предупреждение безопасности RDP клиента о том, что имя которое мы используем для подключения не совпадает с именем сервера на который его перенаправляет RD Connection Broker
Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.
Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.
Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:
Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:
Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf
Содержимое этого файла в нашем примере выглядит так:
Signature = «$Windows NT$»
Exportable = TRUE; Private key is exportable
KeySpec = 1; Key Exchange – Required for encryption
KeyUsage = 0xA0; Digital Signature, Key Encipherment
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
OID = 1.3.6.1.5.5.7.3.1 ; Server Authentication
OID = 1.3.6.1.5.5.7.3.3 ; Code signing
С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:
Далее, на основании полученного файла запроса RequestFile.req в локальном центре сертификации можно получить сертификат. В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального изолированного ЦС Active Directory Certificate Services. Действия по запросу и получению сертификата нужно выполнять непосредственно с одного из тех серверов для которых будем создавать этот сертификат. В нашем примере мы выполним запрос и получения сертификата с сервера KOM-AD01-RDS01
Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:
и скопируем содержимое сгенерированного ранее запроса из файла RequestFile.req
После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:
View the status of a pending certificate request
Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b
Устанавливаем в систему полученный сертификат командой:
После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС
Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.
В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат
В окне выбора сертификатов выбираем соответствующий сертификат…
После этого сохраняем настройки свойств подключения
Теперь нам нужно установить этот же сертификат на другие два сервера – KOM-AD01-RDS02 и KOM-AD01-RDS03. Для этого в консоли управления сертификатами на сервере KOM-AD01-RDS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.
В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key
Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03
Далее указываем имя файла в который будет экспортирован сертификат
Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата
В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом
Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.
На следующем шаге будет предложено выбрать хранилище сертификатов в которое производится импорт. Оставим значение Personal
После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.
По завершении всех манипуляций с сертификатами желательно не забыть удалить все временные копии экспортированного сертификата с закрытым ключом.
В конечном результате описанных действий подключение клиентов должно работать без предупреждений безопасности.