Публикация кластера терминальных серверов на базе Windows 2012 R2 – обсуждение на форуме

Настраиваем СЕТЬ

На каждом серваке должно быть по 2 сетевухи:

Public

– имеет нормальный серверны айпи, с ДНСом, шлюзом. Все как обычно.

Cluster

       – отдельная подсеть, в которой только айпи и маска. Больше ничего. В ДНС тоже регистрацию снять галочку. Нужно для работы службы Failover Cluster

При этом нужно, чтобы на каждом серваке в приоритете ПАБЛИК сетевуха была выше, чем КЛАСТЕР. Делается просто

При этом сетевуха ПАБЛИК, как уже говорилось имеет стандартные сетевые настройки обычной сетевухи сервера со всеми службами и т.д.

А сетевуха КЛАСТЕР выглядит примерно так

не забыть отключить на ней регистрацию ДНС

С сетевухами все.

Настраиваем РОЛИ

Теперь устанавливаем роли на КАЖДОМ сервере.

Если есть в сети венда младше ВИСТЫ – ставим галочку БЕЗ НЛА. Коли таких нету – ставим ТРЕБОВАТЬ НЛА. Так как у меня икспи нету – НЛА оставил ТРЕБОВАТЬ

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

Настраиваем Failover Clustering (фичи)

Добавляем нужную нам ФИЧУ на  все сервера

После того как фичи добавлены – собираем наш кластер

В мастере добавляем наши все три сервера.

На шаге определения имени задаем ему

RDPCluster,

и даем ему общий айпи (нужно учитывать, что это не то имя и не тот айпи, к которому будут подключатся пользователи). Айпи даем обычный, серверный.

После того, как кластер создался – получаем экземпляр, который будет работать при наличии 2 из 3 голов. Т.е. если один сервер падает – не беда. Упадет 2 из 3 – беда. Называется Node majority.

Лично у меня кластер с первого раза не создался. Ошибка в параметрах безопасности и все такое. Это обычно потому, что не может мастер в домене создать обьект кластера. Вообще, экземпляр кластера виден в домене как обычный компьютер (с именем RDPCluster).

НАСТРОЙКА СЕРТИФИКАТОВ

При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен 

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

Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.

При создании запроса на сертификат необходимо использовать политику применения — Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)

Если в перспективе на ваших терминальных серверах вы планируете использование технологии RemoteApp с использованием цифровой подписи распространяемых RDP-файлов, то возможно вам резонно будет в запрос включить так же и политику применения  — Подписывание кода (1.3.6.1.5.5.7.3.3)

Также при создании запроса на сертификат нужно учесть то, что создаваемый сертификат желательно иметь с альтернативными именами объекта – Subject Alternative Name (SAN). В противном случае при подключении клиенты могут получать предупреждение безопасности RDP клиента о том, что имя которое мы используем для подключения не совпадает с именем сервера на который его перенаправляет RD Connection Broker

Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.

certutil -getreg PolicyEditFlags

Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:

certutil -setreg policyEditFlags EDITF_ATTRIBUTESUBJECTALTNAME2net stop certsvcnet start certsvc

Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например RequestPolicy.inf

Содержимое этого файла в нашем примере выглядит так:

[Version]
Signature=»$Windows NT$»
[NewRequest]
Subject = «CN=TS.domain.local»;
Exportable = TRUE; Private key is exportable
KeyLength = 2048
KeySpec = 1; Key Exchange – Required for encryption
KeyUsage = 0xA0; Digital Signature, Key Encipherment
MachineKeySet = TRUE
ProviderName = «Microsoft RSA SChannel Cryptographic Provider»
RequestType = PKCS10
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.3 ; Code signing
[RequestAttributes]
SAN=”dns=TS.domain.local&dns=TS01.domain.local&dns=TS02.domain.local&dns=TS03.domain.local&dns=TS&dns=TS01&dns=TS02&dns=TS03″

при этом по поводу шаблона — нужно сделать дубликат шаблона «Веб
Сервер», переименовать его в что-то типа «шаблон терминалок» и
подкрутить его, назначив права всем нодам кластера в разделе СЕКЬЮРИТИ
на read, enroll, autoenroll. а также добавить в разделе Extention —
Application policies добавить Code sighning.

С помощью встроенной в ОС утилиты CertReq.exe создадим файл запроса на основе файла параметров:

cd /d C:TempCertReq –New RequestPolicy.inf RequestFile.req

Далее, на основании полученного файла запроса RequestFile.req в локальном центре сертификации можно получить сертификат. В нашем случае для отправки запроса и получения сертификата будет использоваться веб-узел локального изолированного ЦС Active Directory Certificate Services.

Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:Request a certificate > advanced certificate request > Submit a
certificate request by using a base-64-encoded CMC or PKCS #10 file, or
submit a renewal request by using a base-64-encoded PKCS #7 file.

и скопируем содержимое сгенерированного ранее запроса из файла RequestFile.req

После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:

View the status of a pending certificate request 

Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b

Устанавливаем в систему полученный сертификат командой:

CertReq -accept certnew.p7b

После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС

Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.

В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат

В окне выбора сертификатов выбираем соответствующий сертификат… После этого сохраняем настройки свойств подключения.

Теперь нам нужно установить этот же сертификат на другие два сервера – TS02 и TS03. Для этого в консоли управления сертификатами на сервере TS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.

В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key

На странице Export File Format выбран один возможный вариант формата выгрузки — Personal Information Exchange – PKCS #12 (.PFX)

Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах TS02 и TS03. Далее указываем имя файла в который будет экспортирован сертификат

Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата

В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом. Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.

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

После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.

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

В конечном результате описанных действий подключение клиентов должно работать без предупреждений безопасности.

Настройка 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

Постановка задачи

Необходимо организовать высоко доступную ферму RDS (Remote Desktop Services), где в качестве брокеров подключения будут выступать операционные системы с Windows Server 2021. В качестве хостов подключений, на которых будут работать конечные пользователи требуется иметь операционную систему Windows Server 2021.

Развернуть сервер лицензирования, раздающий лицензии на пользователя или устройства. Чем хорошо использовать в качестве посредников подключений именно Windows Server 2021, все просто, когда большинство клиентского программного обеспечения станет поддерживаться данной ОС, можно будет легко вывести из эксплуатации сервера с W2021 и заменить их на более новые.

Предварительные настройки

1. Так как RD Connection Broker использует SQL Server в отказоустойчивой схеме, то сервер RD Connection Broker должен иметь полные привилегии доступа к SQL Server. Создадим в AD группу RDCB Servers, включим в нее наши RD Connection Broker серверы, а после дадим этой группе все привилегии доступа в разделе Security сервера SQL, используя SQL Server Management Studio.

2. Так же изменим параметры Windows Firewall на нашем SQL сервере, что бы он пропускал входящие подключения. Откроем окно командной строки или PowerShell и введем следующее: netsh advfirewall firewall add rule name = SQLPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN.

3. Создадим заранее папку для базы данных. Это может быть как локальная папка, так и расшаренная где либо еще. В нашем случае это будет локальная папка C:Base на сервере SQL.

Публикация кластера терминальных серверов на базе windows 2021 r2 – обсуждение на форуме

Создание группы безопасности для rd connection broker

Следующим шагом нам необходимо в Active Directory создать группу безопасности в которую мы поместим наши сервера с ролью RD Connection Broker. Необходимо, это для того, чтобы мы этой группе безопасности назначили необходимые права на нашем SQL сервере.

Открываем оснастку ADUC и создаем в нужном вам расположении группу безопасности RD-Connection-Broker. Я выставлю область действия группы (Локальная в домене).

Добавим в группу RD-Connection-Broker два сервера с ролью посредника подключений к удаленным рабочим столам. В моем случае, это RDCB01 и RDCB02.

Создание коллекции для отказоустойчивой терминальной фермы

Следующим шагом идет создание коллекции или коллекций, к ресурсам которых будут подключаться пользователи. Коллекция Remote Desktop Services — это некое объединение серверов RDSH, RD Web под определенные задачи, отделы и другие варианта разграничения.

Приведу пример, у вас есть отдел продаж, есть отдел разработчиков 1С. Логично предположить, что пользователям из отдела продаж не нужны всякие программные продукты для разработчиков, а разработчикам не нужен специфический софт, который установлен у отдела продаж.

Отсюда следует, что будет создано две коллекции, и каждая из них будет иметь на борту, только свои определенные сервера «Службы удаленных рабочих столов», со своим набором программного обеспечения, а доступ к коллекциям будет осуществляться исключительно по группам безопасности Active Directory.

Так, что подытожим, коллекции RDS призваны решать две задачи:

• Они позволяют нам разделять RD Session Hosts на отдельные фермы
• Второе, что они делают, это позволяют администраторам организовывать ресурсы, по отделам или другим критериям

Для создания новой коллекции сеансов службы удаленных рабочих столов, выберите раздел «Коллекции» и нажмите кнопку «Задачи — Создать коллекцию сеансов«

Придумываем любое имя для вашей коллекции, в моем примере это root-collection

Теперь вам необходимо определиться какие серверы с ролью узлов сеансов (RDSH) вам нужно включить в коллекцию, у меня это RDSH01 и RDSH02

Указываем каким пользователям или группам разрешен доступ к данной терминальной ферме, я удалю группу «Пользователи домена» и добавлю другую.

У меня получился вот такой список доступа, потом его так же можно изменить.

Я снимаю галку «Включить диски профилей пользователей» так как не планирую использовать UDP диски.

Смотрим сводную информацию по создаваемой коллекции и нажимаем «Создать».

Дожидаемся создания коллекции службы удаленных рабочих столов.

В общем списке у вас будет ваша коллекция.

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

Создание пула серверов на сервере посредника подключений (rd connection broker)

Пул серверов, это удобное объединение серверов в общий список для быстрого управления и развертывания на них ролей и компонентов. Все манипуляции производятся из единой консоли управления «Диспетчер серверов». Откройте оснастку «Диспетчер серверов» раздел «Все серверы». Щелкните по нему правым кликом и нажмите «Добавление серверов».

На вкладке Active Directory вам необходимо указать в каком домене вы будите производить поиск, в поле «Имя (Общие)» находим нужные вам сервера.

Выбираем нужные сервера и переносим их в раздел «Выбрано».

В итоге в вашей оснастке «Диспетчер серверов» вы увидите все добавленные хосты. которые будут участниками Remote Desktop Services High Availability на Windows Server 2021.

В результате все должно быть в статусе «В сети».

Стандартная установка rds фермы в windows server 2021

Перед тем, как мы сделаем высокодоступное подключение к ферме Remote Desktop Services, нам необходимо произвести установку стандартной конфигурации служб удаленных рабочих столов, включающей в себя:

• Установку посредника подключений (RD Connection Broker) на сервер RDCB01.root.pyatilistnik.org
• Установка роли удаленного подключения (RD Session Host) на сервера RDHC01.root.pyatilistnik.org и RDCH02.root.pyatilistnik.org
• Установка роли RD Web на сервера RDHC01.root.pyatilistnik.org или RDCH02.root.pyatilistnik.org, если планируете использовать RemoteApp, то ставьте на все нужные хосты.

Стандартное развертывание службы удаленных рабочих столов

Перед тем как создавать высоко доступную ферму RDS, вы должны произвести базовую инсталляцию, а именно нам необходимо установить три роли на текущие сервера, для этого в правом верхнем углу выберите пункт «Управление — Добавить роли и компоненты«.

В мастере добавления ролей выберите пункт «Установка служб удаленных рабочих столов (Remote Desktop Services Installation)» и нажимаем далее.

Выбираем первый пункт «Стандартное развертывание (Standard Deployment)» — данный тип развертывания позволяет устанавливать роли Remote Desktop Services на нескольких серверах одновременно.

Выбираем второй пункт «Развертывание рабочих столов на основе сеансов (Session-based desktop deployment)»

Список компонентов устанавливаемых при стандартной конфигурации RDS фермы. Тут будет установлен:

• Посредник подключений к удаленным рабочим столам (Connection Broker)
• Веб-доступ к удаленным рабочим столам
• Узел сеансов удаленных рабочих столов

На следующем шаге вам нужно выбрать и перенести в правую область сервер, который будет нести на себе роль «Посредник подключений к удаленным рабочим столам (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 2021.

Тестовый стенд с виртуальными машинами фермы remote desktop services

1. Две виртуальные машины с установленной Windows Server 2021, RDCB01.root.pyatilistnik.org (ip-адрес 192.168.31.20) и RDCB02.root.pyatilistnik.org (ip-адрес 192.168.31.21)
2. Две виртуальные машины с установленной Windows Server 2021, RDHC01.root.pyatilistnik.org
3. (ip-адрес 192.168.31.22) и RDSH02.root.pyatilistnik.org (ip-адрес 192.168.31.23)
4. Виртуальная машина SQL01.root.pyatilistnik.org с установленной MS SQL 2021, но напоминаю у вас должен быть отказоустойчивый кластер SQL.

Требования по развертыванию rd connection broker high availability

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

1. Наличие двух серверов или виртуальных машин с Windows Server 2021, на которые мы будем устанавливать роли посредников подключений (RD Connection Broker)
2. Создание группы безопасности Active Directory, в которую необходимо поместить сервера RD Connection Broker
3. Установка MS SQL 2021 и выше, для базы Connection Broker, лучше в режиме Always On.
4. Предоставление группы безопасности с серверами RD Connection Broker, прав на создание баз данных
5. Установка на сервера посредников подключений SQL Server Native Client, если SQL 2021, то Client Tools Connectivity
6. Создание записи в DNS, которое будет использоваться в качестве имени RDS фермы, с помощью механизма DNS round robin.
7. Настройка алиаса в cliconfg.exe для SQL базы и упрощенного переноса в случае необходимости
8. Подготовка одного или более сервера с Windows Server 2021 для установки роли Remote Desctop Session Host и RD Web
9. Выпуск SSL сертификата безопасности
10. Создание и настройка коллекции на RDS ферме
11. Установка и настройка сервера лицензирования терминальных сессий
12. Дополнительные правки реестра для подключений через стандартное приложение «Подключение к удаленному рабочему столу»

Установка и настройка ms sql 2021

Следующим подготовительным требованием идет установка общей базы для наших брокеров, в моем примере это будет MS SQL 2021 Standard. Сам процесс инсталляции я подробно разбирал, так что так же советую посмотреть мою статью. Еще я вам советую делать всегда вашу базу данных отказоустойчивой, в режиме Always On.