Ферма rds windows server 2019

Обновлено 03.08.2020

Добрый день! Уважаемые читатели и гости 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 ферме, я бы хотел выделить пункты, которые нам потребуется выполнить.

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

Тестовый стенд с виртуальными машинами фермы Remote Desktop Services

1. Две виртуальные машины с установленной Windows Server 2019, RDCB01.root.pyatilistnik.org (ip-адрес 192.168.31.20) и RDCB02.root.pyatilistnik.org (ip-адрес 192.168.31.21)
2. Две виртуальные машины с установленной Windows Server 2016, 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 2016, но напоминаю у вас должен быть отказоустойчивый кластер SQL.

Перед тем, как мы сделаем высокодоступное подключение к ферме 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, то ставьте на все нужные хосты.

Создание пула серверов на сервере посредника подключений (RD Connection Broker)

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

Напоминаю, что делать вы это должны от имени учетной записи, у которой есть права на данные сервера и ваш брандмауэр должен пропускать данные подключения

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

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

Нажимаем «Ok».

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

Если у ваших серверов будет статус «В сети: счетчики производительности не запущены», то запустите их через правый клик

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

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

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

Стандартный тип развертывания — это лучший метод развертывания, и вы должны выбрать этот тип развертывания в производственной среде

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

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

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

Это развертывание рабочих столов на основе сеансов позволяет пользователям подключаться к коллекциям сеансов, включающим опубликованные удаленные приложения RemoteApp и рабочие столы, основанные на сеансах

Список компонентов устанавливаемых при стандартной конфигурации 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)»

Данную роль нельзя пропустить в мастере стандартной установки служб Remote Desktop Services, но она нам пригодится еще очень сильно

Последним идет пункт по установке роли на сервера к которым вы будите непосредственно подключаться, выбираем нужные сервера и инсталлируем на них роль «Узел сеансов удаленных рабочих столов (RS Session Host)». В моем примере, это два сервера rdsh01 и rdsh02.

Процесс установки ролей подразумевает, что потребуется перезагрузка сервера, для этого вам необходимо выставить галку «Автоматически перезапускать конечный сервер, если это потребуется (Restart the destination server automatically if required )» и нажать кнопку «Развернуть«

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

У вас должна произойти успешная установка службы «службы удаленных рабочих столов». Все необходимые сервера будут перезагружены.

Давайте убедимся, что все серверы получили свои роли. Для этого на сервере, где вы добавляли сервера в оснастку «Диспетчер серверов (Производили установку)», откройте оснастку и перейдите в раздел «Службы удаленных рабочих столов».

На вкладке «Общие сведения» посмотрите в разделе «Серверы развертывания», кто и какие роли себе установил.

Перейдите в раздел «Коллекции» и убедитесь, что список пуст, но зато присутствуют два ваших хоста узла сеансов удаленных рабочих столов, к котором будут подключаться конечные пользователи. Они будут иметь статус «Истина (True)», что говорит о разрешении подключаться (Режим стока выключен)

Следующим шагом мы создадим новую коллекцию для подключения к службам Remote Desktop Services High Availability на Windows Server 2019.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Скачать специальный файл RDP с RD Web хоста
2. Поправить ветку реестра на сервере с ролью RD Connection Broker

Настройка 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-файл с конфигурацией. Данный файл будет нести в себе параметры, о наименовании коллекции, при обращении к которой вы попадете на один из конечных серверов.

Напоминаю, что в моем тестовом окружении сервером веб-доступа к удаленным рабочим столам выступает брокер RDCB01.root.pyatilistnik.org

Стандартный адрес для подключения к вашему серверу RD Web, это:

https://dns имя вашего сервера с данной ролью/rdweb в моем примере https://rdcb01.root.pyatilistnik.org/rdweb

Проверить наличие данного адреса вы можете открыв диспетчер 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. Переходим в раздел:

HKLMSYSTEMCurrentControlSetControlTerminal ServerClusterSettings

Создаем тут ключ реестра с типом 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.

Не забудьте перезагрузить оба сервера, чтобы обновился их ACL с членством в группе

Установка SQL Native Client

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

Установка и настройка MS SQL 2016

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

Эта большая инструкция посвящена особенностям установки, настройки и эксплуатации фермы терминальных серверов на базе роли Remote Desktop Services (RDS) в Windows Server. Статья поможет вам развернуть службы удаленных столов на Windows Server 2022, 2019 и 2016 в домене Active Directory.

Компоненты Remote Desktop Services в Windows Server 2022/2016/2016/2012R2

В состав роли RDS в Windows Server входя следующие компоненты:

• Remote Desktop Session Host (RDSH) – узлы сеансов RDS. Основные рабочие лошадки фермы RDS, на которых работают приложения пользователей;
• Remote Desktop Connection Broker (RDCB) – посредник RDS подключений. Используется для управления фермой RDS, распределения нагрузки, обеспечивает переподключение пользователей к своим сеансам, хранит коллекции RDS и опубликованные приложения RemoteApps;
• Remote Desktop Gateway (RDGW) – обеспечивает безопасный доступ к сервисам RDS из Интернета;
• RD Web Access (RDWA) – веб интерфейс для доступа к рабочим столам, программам RemoteApp;
• Remote Desktop Licensing (RD Licensing) — служба лицензирования, управляет RDS лицензиями (CAL) пользователей.

В нашем небольшом стенде будут всего три сервера со следующим распределением ролей

• msk-rds1.winitpro.ru
  — RDSH
• msk-rds2.winitpro.ru
  – RDSH
• msk-rdsman.winitpro.ru
  – RDSH, RDWA, RDCB, RD License

Предварительные требования, которые нужно выполнить перед созданием RDS фермы:

1. Установите одинаковую версию Windows Server на все сервера, настроить их, и добавить в один домен AD;
2. Откройте консоль ADUC (
   dsa.msc
   ) и переместите все хосты с ролью RDSH в одну OU в AD. Так будет удобнее применять единые настройки через GPO;
3. Создайте в домене группу для RDSH серверов (например,
   msk-rdsh
   ) и добавьте в нее все хосты;
4. Если вы хотите использовать диски User Profile Disk (UPD) для хранения профилей пользователей RDS (или перемещаемые профили), нужно создать на файловом сервере сетевой каталог, в котором они будут хранится (желательно расположить этот каталог на отказоустойчивом файловом кластере Windows Server). Предоставьте права Full Control на этот сетевой каталог для группы
   msk-rdsh
   .

Создаем новую конфигурацию Remote Desktop Services в Windows Server

Рассмотрим, как создать и настроить RDS конфигурацию с помощью графического интерфейса Server Manager.

Откройте Server Manager и добавьте все планируемые RDS сервера в консоль. Щелкните All Server -> Add servers.

Теперь в меню Server Manager выберите Add Roles and Features -> Remote Desktop Services installation -> Standard deployment –> Session-based deployment.

Режим Quick Start используется для развертывания всех компонентов RDS на одном сервере. В RDS ферме минимум может быть один сервер, который совмещает все роли RDS (RD Session Host, RD Web Access и RD Connection broker). Но такая конфигурация не обеспечивает отказоустойчивость и балансировку нагрузки в службах удаленных рабочей столов Windows Server.

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

• RD Connection Broker –
  msk-rdsman
• RD Web Access —
  msk-rdsman
• RD Session hosts —
  msk-rdsman, msk-rds1, msk-rds2

Вы можете распределить RDS роли по серверам в любой другой конфигурации.

Поставьте галку Restart destination server automatically if required и нажмите кнопку Deploy. Дождитесь установки ролей RDS на всех серверах.

Итак, ваша ферма RDS создана.

Следующий этап установка и настройка сервера лицензирования RDS. Вы можете установить роль RD Licensing на один из серверов в вашей ферме или использовать существующий в домене сервер лицензирования RDS. Подробная инструкция по установке, настройке и активации роли RD Licensing доступа по ссылке.

Для управления вашим развертыванием RDS нужно перейти в раздел Server Manager -> Remote Desktop Services. На вкладке Overview показана текущая конфигурация RDS фермы.

Чтобы изменить настройки RDS фермы выберите Tasks -> Edit Deployment Properties в разделе Deployment Overview.

Здесь можно изменить:

• Параметры RD Gateway;
• Адрес сервер сервера лицензирования и тип пользовательских лицензий RDS CAL (per user/per device);
• Посмотреть URL адреса RD Web Access;
• Добавить SSL сертификаты для служб RDS (в инструкции мы пропустим этот пункт).

Для построения отказоустойчивой фермы Remote Desktop Services нужно обеспечить высокую доступность роли RD Connection Broker. Это достигается за счет запуска нескольких экземпляров RDCB (Active/Active) на разных серверах с общей базой данных SQL, в которой хранится конфигурация брокера подключений. Для обеспечения высокой доступности SQL базы RDCB ее можно размесить в группе высокой доступности SQL Server Always On. Ранее мы публиковали подробный гайд по настройке RDS Connection Broker с высокой доступностью.

Создаем коллекции Remote Desktop Services в Windows Server

Следующий этап настройки – создание коллекций сеансов RDS. Коллекции Remote Desktop позволяют разделить хосты в ферме RDSH на отдельные группы или создать разный набор настроек и доступных приложений Remote App для разных групп пользователей.

Перейдите в раздел Collections, выберите Edit -> Create Session Collection.

Здесь нужно задать:

1. Имя коллекции RDS:
   rds-Msk-Managers
2. Выберите какие хосты RDSH будут обслуживать пользователей коллекции (один RDSH хост может находиться в одной коллекций; не рекомендуется объединять в одну коллекцию сервера с разными версиями Windows Server);
3. На вкладке User Groups указываются группы пользователей, которым разрешено подключаться к коллекции. Уберите из групп Domain users и добавьте вашу группу (msk-Managers);
4. На вкладке User Profile Disk нужно указать, хотите ли вы использовать формат UPD для хранения профилей пользователей (Enable user profile disks). В поле Location of user profile disks укажите UNC путь к сетевому каталогу(например,
   \msk-fs01mskrds_upd
   ), в котором будут хранится профили пользователей в форматер UPD виртуальных дисков (в этом случае при входе на любой сервер коллекции RDS, пользователь будет всегда загружать свой профиль) и максимальный размер диска (20 Гб по умолчанию);
5. Нажмите Create чтобы создать новую RDS коллекцию;
6. Убедитесь, что в указанном каталоге создался UPD файл с шаблоном профиля пользователя UVHD-template.vhdx.

Чтобы задать параметры коллекции RDS, выберите ее и нажмите Tasks -> Edit Properties.

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

В разделе Session можно задать параметры переподключения/ автоматического отключения простаивающих RDP сессий (подробнее рассматривалось в статье Настройка таймаутов для RDP сессий).

На вкладке Security можно выбрать настройки безопасности (Negotiate, RDP Security level или SSL/TLS) и шифрования (Low, High, Client compatible или FIPS compliant) для сессий RDP. Здесь также можно включить/отключить Network Level Authentication для RDP.

В секции Load Balancing можно изменить веса (
Relative Weight
) RDSH хостов в вашей ферме. Если характеристики серверов (RAM, CPU) в коллекции сильно отличаются, нужно задать меньший вес для менее производительных серверов. В этом случае RDCB будет распределять сессии пользователей по серверам в зависимости от их веса.

На вкладке Client Settings можно указать, какие устройства пользователям разрешено пробрасывать в RDP сессию. Например, вы можете разрешить/запретить пробрасывать с локального компьютера пользователя в RDS сеанс принтера, сетевые диски, аудио устройства, буфер обмена.

В разделе User Profile Disks можно более тонко настроить параметры UPD профилей пользователей. Можно исключить из синхронизации определенные папки или файлы. Это позволит уменьшить размер профиля UPD в сетевом каталоге и увеличить скорость загрузки профиля (не забывайте, что он загружается по сети из сетевой папки при входе пользователя).

Настройка и эксплуатация UPD обычно гораздо проще, чем использование перемещаемых профилей или folder redirection. Один UPD профиль не может использоваться в разных коллекциях RDS.

Для уменьшения размера UPD диска пользователя можно использовать стандартный PowerShell командлет
Resize-VHD
, используемый для изменения размеров виртуальных VHDX дисков Hyper-V.

В секции HOST SERVERS коллекции RDS можно перевести любой сервер фермы в режим обслуживания RDSH (Drain Mode). Для этого щелкните по нему и выберите Do not allow new connection. В результате Connection Broker не будет отправлять новые подключения пользователей на этот сервер. В таком режиме вы можете спокойно установить обновления Windows или обновлять на сервере приложения, не затрагивая пользователей.

Здесь же можно добавить/удалить RDS Host из коллекции.

Если RDSH хост вышел из строя и не доступен, его можно корректно удалить из фермы Remote Desktop Services по этой инструкции.

Публикация RemoteApp в Remote Desktop Services

RemoteApps – это опубликованные для пользователей приложения на RDS серверах. Благодаря RemoteApp можно использовать приложения, установленные на терминальном RDSH сервере так, как будто оно запущено непосредственно на компьютере пользователя. Пользователь не видит всего рабочего стола Windows Server RDS и работает только с теми программами, которые опубликовал для него администратор. На компьютере пользователя будет отображаться только окно запущенной на RDS программы.

Если вы не создаете RemoteApp, пользователи будут работать непосредственно на собственных рабочих столах на Windows Server. Поэтому не забудьте скопировать все необходимые пользователю ярлыки приложений в папку C:UsersPublicDesktop. Файлы из этой папки будут отображаться на рабочем столе всех пользователей. Если вы устанавливаете на RDSH пакет MS Office 365, обратите внимание что Office нужно разворачивать в режиме SharedComputerLicensing.

RemoteApp приложения создаются в настройках коллекций RDS. Выберите пункт Tasks -> Publish RemoteApp Programs в секции REMOTEAPP PROGRAMS.

Windows отобразит все приложения, установленные на текущем сервере. Можете выбрать одно из них. Если вашего приложения нет в списке, но оно установлено на других хостах RDS, нажмите кнопку Add и укажите полный путь к исполняемому файлу приложения (exe, bat, cmd и т.д.).

Опубликуйте приложение RemoteApp.

Затем в настройках RemoteApp можно указать дополнительные параметры приложения.

• Нужно ли показывать опубликованное RemoteApp приложение в веб интерфейсе RD Web Access;
• Задать параметры запуска (аргументы) приложения (Command-line Parameters -> Always use the following command-line parameters);
• На вкладке User Assignment можно дополнительно ограничить каким группам пользователей разрешено запускать приложение.

Если вы хотите изменить иконку опубликованного RemoteApp, нужно открыть следующую папку на сервере с ролью RDS Connection Broker:

C:WindowsRemotePackagesCPubFarmsrds-Msk-ManagersCPubRemoteApps

Замените иконку приложения другим ico файлом.

Теперь пользователь может запустить RemoteApp приложение из RD Web Access (
https://msk-rdsman.wintpro.ru/RDWeb
) или с помощью специального RDP файла.

Для запуска опубликованного приложения RemoteApp, нужно добавить в RDP файл такие строки:

remoteapplicationmode:i:1
remoteapplicationname:s:putty
remoteapplicationprogram:s:"C:Toolsputty.exe"
disableremoteappcapscheck:i:1
alternate shell:s:rdpinit.exe

Несколько полезных мелочей для удобной эксплуатации фермы RDS:

• Для роли RDWeb можно настроить поддержку HTML5, это позволит пользователям подключаться к RDS серверам из любого браузера и ОС даже без клиента RDP;
• На веб сервере RD Web Access можно опубликовать ссылку на смену истекшего пароля пользователя (по умолчанию при включенном NLA вы не сможете аутентифицироваться на RDSH с истекшим паролем пользователя Active Directory);
• Инструкция для пользователей по смене пароля в RDP сессии;
• Администратор может использовать теневые подключения RD Session Shadow для подключения/просмотра рабочего стола сеанса пользователя на сервере RDS;
• Чтобы быстро найти, на каких RDS серверах есть сессии определенного пользователя, можно использовать PowerShell:
  Import-Module RemoteDesktop
Get-RDUserSession -ConnectionBroker msk-rdsman.winitpro.ru | where {$_.UserName -eq "a.ivanov"} | Select HostServer
• Вы можете использовать PowerShell скрипты для просмотра и анализа логов RDP подключений пользователей к серверам RDS;
• Для дополнительной защиты можно настроить двухфакторную аутентификацию (2FA) пользователей на RDS серверах Windows с помощью сторонних средств.

Настройка фермы Remote Desktop services с помощью PowerShell

Если вы четко представляете себе концепцию RDS фермы, вы можете быстро разворачивать RDS конфигурацию с помощью PowerShell.

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

Задайте имена серверов в вашей ферме RDS. В этом примере я установлю роли RDCB и RDS Licensing на отдельный сервер (в дальнейшем рекомендуется настроить отказоустойчивую конфигурацию RDCB).

$RDSH1 = "msk-rds1.winitpro.ru"
$RDSH2 = "msk-rds2.winitpro.ru"
$RDSCB = "msk-rdcb.winitpro.ru"
$RDSGW = "msk-rdsgw.winitpro.ru"
Import-Module RemoteDesktop

Установите RDS роли на сервера:

Add-WindowsFeature –ComputerName $RDSH1, $RDSH2 -Name RDS-RD-Server –IncludeManagementTools
Add-WindowsFeature –ComputerName $RDSCB -Name RDS-Connection-Broker -IncludeManagementTools
Add-WindowsFeature –ComputerName $RDSGW -Name RDS-Web-Access, RDS-Gateway –IncludeManagementTools

Перезагрузите все хосты:

Restart-Computer -ComputerName $RDSH1,$RDSH2,$RDSCB,$RDSGW

Создайте новый инстанс RDSessionDeployment:

New-RDSessionDeployment -ConnectionBroker $RDSCB -SessionHost $RDSH1,$RDSH2 –Verbose

Добавить в ферму сервера RDWA и RDGW:

Add-RDServer -Server $RDSGW -Role RDS-WEB-ACCESS -ConnectionBroker $RDSCB
Add-RDServer -Server $RDSGW -Role RDS-GATEWAY -ConnectionBroker $RDSCB -GatewayExternalFqdn "rds.winitpro.ru"

Текущее распределение RDS ролей по серверам фермы можно вывести так:

Get-RDServer -ConnectionBroker $RDSGW

Установка роли лицензирования RDS:

Add-WindowsFeature –ComputerName $RDSCB -Name RDS-Licensing, RDS-Licensing-UI

Задайте режим лицензирования PerUser:

Invoke-Command -ComputerName $RDSCB -ScriptBlock {Set-RDLicenseConfiguration -Mode PerUser -LicenseServer $RDSCB -ConnectionBroker $RDSCB}

Add-RDServer -Server $RDSCB -Role RDS-LICENSING -ConnectionBroker $RDSCB

Добавить сервер лицензирования в доменную группу с помощью Add-ADGroupMember:

Add-ADGroupMember "Terminal Server License Servers" -Members "msk-rdcb$"

Если у вас есть сертификат для RDS можно его добавить в конфигурацию фермы (можно использовать бесплатный SSL сертификат Let’s Encrypt для вашего RDS хоста):

Path = "C:psRDSCert.pfx"
$Password = ConvertTo-SecureString -String "CertPAssddr0w11-" -AsPlainText -Force
Set-RDCertificate -Role RDGateway -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDWebAccess -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDPublishing -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force
Set-RDCertificate -Role RDRedirector -ImportPath $Path -Password $Password -ConnectionBroker $RDSCB -Force

Информацию об установленных SSL сертификатах можно получить так:

Get-RDCertificate

Теперь можно создать коллекции RDS:

$CollectionName = "DEVdept"
New-RDSessionCollection –CollectionName $CollectionName –SessionHost $RDSH1,$RDSH2 –ConnectionBroker $RDSCB –CollectionDescription “Develovers”

Разрешить доступ к RDS серверам для групп:

$UserGroup [email protected]("WINITPROmsk-developers","WINITPROmsk_devops")
Set-RDSessionCollectionConfiguration -CollectionName $CollectionName -UserGroup $UserGroup

Опубликовать приложение RemoteAPP:

New-RDRemoteapp -Alias GoogleChrome -DisplayName GoogleChrome -FilePath "C:Program Files (x86)GoogleChromeApplicationchrome.exe" -ShowInWebAccess 1 -CollectionName $CollectionName -ConnectionBroker $RDSCB

В статье мы рассмотрели, как установить и настроить ферму Remote Desktop Services на базе Windows Server 2019/2022 с помощью графического интерфейса Server Manager и с помощью PowerShell. За рамками статьи осталось более подробное описание ролей RD Web Access и RD Gateway. Мы рассмотрим настройку этих ролей отдельно в следующих статьях.

Установка роли Remote Desktop Services Host (RDSH) на Windows Server 2019 в рабочей группе

В этой статье описано, как установить и настроить роль терминального сервера Remote Desktop Session Host в рабочей группе (без домена Active Directory) и без всех дополнительных ролей (Connection Broker, Remote Desktop Web Access, RDS Gateway).

Windows Server с ролью RDSH (Remote Desktop Session Host) позволяет одновременно подключаться к серверу по RDP нескольким пользователям (по умолчанию в Windows Server разрешены только 2 административных RDP подключения). Для каждого пользователя создается отдельная сессия и он получает доступ к персональному рабочему столу

Если вы планируете используете отдельный RDS сервер в рабочей группе, имейте в виду, что его функциональность ограничена. Он не может масштабироваться до полноценной RDS фермы, нельзя создавать отдельные коллекцию или RemoteApp, нет брокера, нельзя использовать User Profile Disks для профилей пользователей, отсутствуют средства централизованного управления, при проведении операций обслуживания RDP сервис будет недоступен.

Установка роли Remote Desktop Services в Windows Server 2019

Предполагаем, что вы уже установили сервер с Windows Server и выполнили базовые настройки (ip адрес, имя сервера, время/дата, установили обновления и т.д.). Теперь можно установить службу RDS.

Для этого можно использовать Server Manager или PowerShell.

Также вы можете установить нужные роли Windows Server с помощью PowerShell:

Проверьте, какие RDS роли установлены на сервере:

Настройка роли Remote Desktop Licensing, добавление RDS лицензий (CAL)

Следующий этап – настройка роли Remote Desktop Licensing, которая обеспечивает лицензирование RDP подключений пользователей к вашему RDS серверу. Вы можете установить и активировать роль Remote Desktop Licensing на данном хосте (если он у вас один), либо можете разместить роль RDLicensing на другом сервере. Один сервер с ролью RDS Licensing можете выдавать лицензии неограниченному количеству RDSH хостов.

Если вы решили использовать локальный сервер RDLicensing, активируйте сервер лицензий RDS и установите клиентские лицензии (RDS CAL) согласно гайду по ссылке.

Настройка роли Remote Desktop Session Host в рабочей группе

Если вы не нацелите ваш RDSH сервер на сервер лицензирования RDS, который может выдать пользователям лицензии, ваш сервер будет находится в триальном режиме. В этом режиме службы RDS работают в течении всего 120 дней (при каждом подключении в трее будет появляться сообщение “ Служба удаленных рабочих столов перестанет работать через xxx дней ”). После окончания grace периода ваши пользователи не смогут подключится к RDS с ошибкой:

В локальной GPO нужно настроить параметры лицензирования RDS:

Дополнительно в локальных GPO вы можете настроить лимиты (таймауты) на длительность RDP сессий и правила отключения пользователей при неактивности.

Теперь нужно создать для пользователей локальные учетные записи на RDS сервере, под которыми они будут аутентифицироваться. Можно создать пользователей с помощью оснастки lusrmgr.msc или через PowerShell:

Чтобы разрешить пользователю подключаться к серверу через службы Remote Desktop Services, нужно добавить аккаунт в локальную группу Remote Desktop Users. Добавьте пользователей вручную через консоль управления группами или через PowerShell:

При первом входе устройству пользователя выдается временная лицензия (особенности RDS Per Device лицензирования). При втором входе выдается постоянная лицензия, которая появится в консоли Remote Desktop Licensing Manager. Лицензия выдается на срок от 52 до 89 дней (случайное число).

Если у вас исчерпаны Per Device лицензии, вы можете вручную отозвать лицензии для некоторых устройств пользователей. Воспользуйтесь консоль RDSLicensing или таким PowerShell скриптом:

Если вам нужно подключиться в RDP сессию пользователя, вы можете воспользоваться режимом теневого подключения RDS (он работает на RDSH в рабочей группе).

Источник

Rds farm windows server 2019

Вопрос

I operate some 20+ VM’s with Server 2019, at the front of them there’s a pair of IIS Gateway & Connection Broker servers that manage the remote desktop services collections and the login/traffic. All fairly normal.

I’ve just added a new server into the collections, and it appeared to deploy just fine. When I login to the gateway via browser, I can see the new VM’s RDP link. However, when I download the RDP link, the server address hasn’t been populated.

None of the other links have this issue.

Все ответы

Then, new RD SH should be working. Please check above steps one by one. If problem persists, delete and remove the session host form RDS deployment and try to re-add it to check the result.

Besides, please try to using different Browser such as IE, Edge, Chrome to access RD Web Access and check the result.

If problem persists, please provide relate screenshot about the RDC window when click the VM via web access browser.

Источник

Настройка терминальной фермы RDS с RD Connection Broker

Remote Desktop Connection Broker (RD Connection Broker), ранее известный под именем Terminal Services Session Broker (TS Session Broker), — это роль сервера Windows 2008 R2, предоставляющая следующий функционал:

RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008 R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.

В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.

Балансировка нагрузки RD Connection Broker Load Balancing, позволяет при подключении пользователя (предполагается, что у него не осталось подключений в состоянии disconnect) к ферме, перенаправить его на наименее загруженный сервер фермы (с наименьшим количеством пользовательских сессий). Чтобы более гибко управлять балансировкой нагрузки в ферме терминальных серверов, администратор может в зависимости от вычислительных мощностей серверов фермы назначить каждому из них относительный вес.

Компоненты RD Connection Broker

Для построения фермы терминальных серверов с балансировкой нагрузки нужны два компонента:

Последовательность настройки терминальной фермы RD Connection Broker с балансировкой нагрузки:

Шаг 1 : Установка роли Connection Broker

Если роль Remote Desktop Services уже установлена:

В моем стенде 2 сервера, настроенных следующим образом:

Шаг 2 : Добавляем сервера RD Session Host в локальную группу Session Broker Computers.

Для этого на сервер с установленной ролью RD Connection Broker:

Шаг 3 : Включаем сервера RD Session Host в ферму RD Connection Broker, настраиваем балансировку нагрузки

На каждом из терминальных серверов RD Session Host выполните следующее:

Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02

Task 4 : Настройка DNS round robin

Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.

Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.

Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)

Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.winitpro.ru)

Теперь в дереве RD Connection Broker появится новая терминальная ферма!

Источник

Questions regarding Server 2019 RDS farm deployment using WID (without SQL)

I’ve been tasked with «fixing» our existing Remote Desktop Services farm due to compliance failures. In specific, TLS 1.0 and 1.1 vulnerabilities. The issue is if I disable these protocols on the server, they break communication with the Windows Internal Database which only supports TLS 1.0. The other issue is if I disable TLS 1.0 and require a higher version of TLS, then the RDP client on the workstations that our employee’s use to connect with (presumably at their homes) may stop working because lets face it, many people still have Windows 7 and or even Windows XP and since its their personal computers we can’t make them upgrade. But we are willing to deny access to these older EOL OS’s by requiring TLS 1.2. I would just disable TLS 1.0 and 1.1 on the current servers if it didn’t break communication with the WID database but that seems to be not possible so an upgrade to 2019 is the only real viable solution.

My current farm is as follows:

Based on the Microsoft article I found regarding issues with disabling TLS 1.0 on the server causing RDS to effectively be left broken afterwards (https://docs.microsoft.com/en-US/troubleshoot/windows-server/remote/rds-connection-broker-or-rdms-fails-caused-by-disabled-tls-10) I have concluded that the best solution would be for me to just stand up a Server 2019 RDS farm environment.

However, while that article says that upgrading the environment to 2019 is a «resolution» to the issue, it doesn’t provide any additional information about it as to how it solves the problem. So, my research has led me to believe that in Windows Server 2019, the Windows Internal Database must now support connections with TLS 1.2 but I really can’t find much info from Microsoft to confirm this 100%.

1. Is TLS 1.2 supported by the Windows Internal Database on Windows Server 2019 and if it is, is 1.2 the default?

2. If the answer to the above is yes, can RDS be deployed in a multi-server farm/cluster setup using the WID (as in without use of SQL Server or SQL Express)?

3. If the answer the to both of those is yes, can anyone point me in the direction of a «guide» to setting up an RDS farm using WID for Server 2019? All I can seem to find are detailed guides for RDS farms on 2019 using some form of SQL, which I would prefer to avoid if at all possible. I would like to basically mimic my exact current setup, just on Server 2019 with TLS 1.2 only.

Источник

Rds farm windows server 2019

Вопрос

пытаюсь настроить терминальную ферму.
есть два сервера
srv-term1:
— узел сеансов удаленных рабочих столов (RDSH)
— брокер соединений(RDCB)

srv-term2:
— узел сеансов удаленных рабочих столов (RDSH)

В основом пользуюусь данной инструкцией с сайта microsoft

Подключаюсь пользователем к term1, он попал на term3
Пытаюсь под ним же зайти еще раз с другого мееста, получаю ошибку:
«Удаленный компьютер srv-term1, попытка подключения к которому выполняется, перенаправляет вас на удаленный компьютер srv-term3. Подключение к удаленному рабочему столу не может проверить принадлежность компьютеров к одной ферме серверов узла сеансов удаленных рабочих столов. При подключении к ферме серверов узла сеансов удаленных рабочих столов необходимо использовать имя фермы, а не имя компьютера.»

Что никак не могу понять:
1. нигде во время настройки я не встречал указаний ввести имя фермы. Где его указать или посмотреть? В 2008 была консоль, там все прописывал и указвал что телефон в этой ферме.
2. много где в блогах пишут про настройку DNS RoundRobin, не пойму нужен ли он в моем случае? у меня же один брокер, а вроде как RoundRobin это как бы предоставление возможности подключаться то к оному то ко второму брокеру(н если их несколько).

Ответы

В общем работает. Спасибо за помощь товарищи.
Вот эта тема(HKLMSYSTEMCurrentControlSetControlTerminalServerClusterSettings
DefaultTsvUrl RegSZ tsv://MS Terminal Services Plugin.1.SalesSessionCollection) достаточно важная получается.

Странно, что это во многих хелпах опускается и замалчивается. Как будто это само собой разумеется)

Итого:
1. если брокер один, RR не надо
2. RDP файл надо нацеливать на брокер(или общее имя брокеров если их несколько)
3. Очень важно, либо в настройках RDP файла на клиенте, либо в реестре брокера указать в какую коллекцию отправлять клиента. Потому как без этого брокер думает что клиент хочет войти непосредственно на него самого, а не на какой либо RDSH.

Итого:
.
3. Очень важно, либо в настройках RDP файла на клиенте, либо в реестре брокера указать в какую коллекцию отправлять клиента. Потому как без этого брокер думает что клиент хочет войти непосредственно на него самого, а не на какой либо RDSH.

Дмитрий, не подскажете, ГДЕ и КАК указать в настройках RDP-файла имя коллекции с учетом указания в качестве цели именно Connection Broker’a? У меня несколько коллекций используется, но не могу найти информацию, где нужная коллекция указывается в файле подключения

2 документация часто разбросана по сети и чтоб понять что описано в фрагменте, а что не упоминалось приходится тратить дни а нередко и недели прежде чем придет осознание

3 есть вагон гайдов про настройку терминальных серверов и ферм под заголовком «step by step» где авторы уже для вас собрали все необходимое в одном месте. Вот пример, в котором в разделе 6 описана настройка брокеров. Там же в разделе 6, на одной из картинок в нач але коллега создает имя фермы в dns, после чего прописывает его в мастере. Таких гайдов можно найти много.

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

The opinion expressed by me is not an official position of Microsoft

Все ответы

Здравствуйте. Я бы не ставил брокер на терминальник, а вынес его отдельной виртуальной машиной и ещё на ней бы поставил службу лицензирования.

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

2. Вы на виртуалке с брокером ставите эту роль, дальше в нем добавляете свои машины где планируется терминалка и он сам разворачивает на них эти роли.

3. Вы создаёте на днс сервере две одинаковых А записи с айпишками терминалак и заходите по рдп этого имени.

Дальше уже брокер встраивается в ваше подключение и решает Вашу судьбу.

Здравствуйте. Я бы не ставил брокер на терминальник, а вынес его отдельной виртуальной машиной и ещё на ней бы поставил службу лицензирования.

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

2. Вы на виртуалке с брокером ставите эту роль, дальше в нем добавляете свои машины где планируется терминалка и он сам разворачивает на них эти роли.

3. Вы создаёте на днс сервере две одинаковых А записи с айпишками терминалак и заходите по рдп этого имени.

Дальше уже брокер встраивается в ваше подключение и решает Вашу судьбу.

То есть клиент приходит к rdsh, тот его отправляет к брокеру(и то если клиент пришел к rdsh через имя фермы). а дальше брокер по сути может принять решения пустить клиента ровно на тот же rdsh?

Хочется понять этот механизм, откуда подчерпали? в справке microsoft не вижу этого, возможно конечно плохо смотрю.

Брокер и rdsh на одном сервере, вопрос лицензии, не более.

Как так работает, что если я делаю две записи в dns с одиним именем, это имя сразу начинает являться именем фермы?

Практикой)) По брокеру верно, а днс запись Вам только нужна для балансировки подключений к вашим терминалкам, если допустим какая-нибудь, по какой-то причине недоступна.

Посмотрите эти темы:

То есть клиент приходит к rdsh, тот его отправляет к брокеру(и то если клиент пришел к rdsh через имя фермы). а дальше брокер по сути может принять решения пустить клиента ровно на тот же rdsh?

Хочется понять этот механизм, откуда подчерпали? в справке microsoft не вижу этого, возможно конечно плохо смотрю.

Брокер и rdsh на одном сервере, вопрос лицензии, не более.

Как так работает, что если я делаю две записи в dns с одиним именем, это имя сразу начинает являться именем фермы?

брокер к лицензиям не имеет никакого отношения

вы сервера настраивали по инструкции от 2003 сервера, или пользовали актуальной документацией?

Начиная с 2012р2 сервера настройка серверов терминалов (1 шт), а так же терминальных ферм (2 и более шт) производится через мастер, который задает сотню вопросов в том числе и имя фермы и пр. не менее важные вещи

The opinion expressed by me is not an official position of Microsoft

То есть клиент приходит к rdsh, тот его отправляет к брокеру(и то если клиент пришел к rdsh через имя фермы). а дальше брокер по сути может принять решения пустить клиента ровно на тот же rdsh?

Хочется понять этот механизм, откуда подчерпали? в справке microsoft не вижу этого, возможно конечно плохо смотрю.

Брокер и rdsh на одном сервере, вопрос лицензии, не более.

Как так работает, что если я делаю две записи в dns с одиним именем, это имя сразу начинает являться именем фермы?

брокер к лицензиям не имеет никакого отношения

вы сервера настраивали по инструкции от 2003 сервера, или пользовали актуальной документацией?

Начиная с 2012р2 сервера настройка серверов терминалов (1 шт), а так же терминальных ферм (2 и более шт) производится через мастер, который задает сотню вопросов в том числе и имя фермы и пр. не менее важные вещи

The opinion expressed by me is not an official position of Microsoft

А где вообще речь про лицензии?

На примере можете показать, где бы мастер спрашивал(просил) задать имя фермы? ну или может кусок инструкции с сайта microsoft.

Буду очень признателен за эту информацию.

По факту, делал по этой инструкции. Ни в ней, ни в реальности у меня никто не спрашивал(ни просил) указать имя фермы. Не исключаю, что я что-то пропустил, прошу помочь, покажите, что именно?

Андрей, это к кому вопрос? если ко мне,то я не знаю. Собственно в этом одна из главных проблем у меня в этой теме.

Повторюсь, я телал все настроки по этой документации https://docs.microsoft.com/ru-ru/windows-server/remote/remote-desktop-services/welcome-to-rds

Практикой)) По брокеру верно, а днс запись Вам только нужна для балансировки подключений к вашим терминалкам, если допустим какая-нибудь, по какой-то причине недоступна.

Посмотрите эти темы:

Здравствуйте. Хочу на тестовой среде развернуть терминальную ферму из двух RDS c UPD.

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

Сервера RD Session Host , настроенные на использование Connection Broker. Это рядовые члены терминальной фермы. Для того, чтобы являться членом фермы под управление RD Connection Broker, терминальный сервер должен соответствовать следующим критериям:

1. Первый сервер поднимаем RD Connection Broker . Он собственно и будет служить подключением по rdp, балансируя клиентов по RDS серверам.

2. Дальше не уверен, RD Session Host должен быть установлен на RDS серверах или отдельной виртуальной машиной, в процессе которого в него будут включены мои RDS сервера?

Подскажите пожалуйста алгоритм действий, лучший.

Источник

These days I’m trying in depth Windows Server 2019. Today I chose to pay attention to Remote Desktop Services. The goal of my lab is to deploy a RDS Farm with all components and with the new HTML5 Remote Desktop Client. Even though I’m running my lab on Windows Server 2019, you can also deploy the HTML5 client on Windows Server 2016. In this topic, I wanted to share with you the steps I followed to deploy the Windows Server 2019 RDS farm.

Requirements

To make this lab, I have deployed four virtual machines which are running Windows Server 2019:

• RDS-APP-01: RD Host Server that hosts the RemoteApp collection
• RDS-DKP-01: RD Host Server that hosts the Remote Desktop collection
• RDS-BRK-01: Hosts RD Broker and RD Licensing
• RDS-WEB-01: Hosts RD Web Access and RD Gateway

Then I have a public certificate for RD Web Access and RD Gateway role:

I have also a private certificate for RD Broker publishing and RD Broker connection. To create this certificate, I duplicated the Workstation Authentication ADCS template as described in this topic.

I have register both certificates in PFX (with private key) and in cer (just the public certificate).

Finally, I have two DNS zone:

• SeromIT.local: Active Directory forest zone

• SeromIT.com: splitted zone: hosted by local domain controllers and by public provider. I use this zone to connect from Internet. In this zone I have created two registrations:

  • Apps.SeromIT.com: leading to RDS-WEB-01 (CNAME)
  • RDS-GW.SeromIT.com: leading to RDS-BRK-01 (CNAME) for the gateway

RDS farm deployment

To deploy the RDS farm, I use only PowerShell. In this way I can reproduce the deployment for other customers. First of all, I run a Remote Desktop deployment to configure a RD Web Access, a RD Broker and a RD Host Server:

New-RDSessionDeployment -ConnectionBroker RDS-BRK-01.SeromIT.local `
                        -SessionHost RDS-DKP-01.SeromIT.local `
                        -WebAccessServer RDS-WEB-01.SeromIT.local

Then I run a PowerShell cmdlet to add another RD Host Server, a RD Licensing and a RD Gateway role.

Add-RDServer -Server RDS-APP-01.SeromIT.local `
             -Role RDS-RD-SERVER `
             -ConnectionBroker RDS-BRK-01.SeromIT.local

Add-RDServer -Server RDS-BRK-01.SeromIT.local `
             -Role RDS-Licensing `
             -ConnectionBroker RDS-BRK-01.SeromIT.local

Add-RDServer -Server RDS-WEB-01.SeromIT.local `
             -Role RDS-Gateway `
             -ConnectionBroker RDS-BRK-01.SeromIT.local `
             -GatewayExternalFqdn RDS-GW.SeromIT.com

Once these commands are run, the role deployment is finished:

Now we can configure the certificates.

Certificate configuration

To configure each certificate, I use again PowerShell. Remember, I have store both certificates in PFX in C:tempRDS of my broker server.

$Password = Read-Host -AsSecureString
$Password = Read-Host -AsSecureString
Set-RDCertificate -Role RDGateway `
                  -ImportPath C:tempRDSwildcard_SeromIT_com.pfx `
                  -Password $Password `
                  -ConnectionBroker RDS-BRK-01.SeromIT.local `
                  -Force

Set-RDCertificate -Role RDWebAccess `
                  -ImportPath C:tempRDSwildcard_SeromIT_com.pfx `
                  -Password $Password `
                  -ConnectionBroker RDS-BRK-01.SeromIT.local `
                  -Force

Set-RDCertificate -Role RDPublishing `
                  -ImportPath C:tempRDSBroker.pfx `
                  -Password $Password `
                  -ConnectionBroker RDS-BRK-01.SeromIT.local `
                  -Force

Set-RDCertificate -Role RDRedirector `
                  -ImportPath C:tempRDSBroker.pfx `
                  -Password $Password `
                  -ConnectionBroker RDS-BRK-01.SeromIT.local `
                  -Force

Once these commands are executed, the certificate are installed for each role:

Collection creation

Now I create a collection to add resources inside the RD Web Access portal:

New-RDSessionCollection -CollectionName Desktop `
                        -CollectionDescription "Desktop Publication" `
                        -SessionHost RDS-DKP-01.SeromIT.local `
                        -ConnectionBroker RDS-BRK-01.SeromIT.local

Then from Server Manager, you can configure settings of this collection:

Enable HTML 5 Remote Desktop client

In this lab, I don’t want to use the legacy portal. I’d like to use the super cool new HTML5 RD client. To enable this client, I connect to the server hosting RD Web Access role and I run the following cmdlet:

Install-Module -Name PowerShellGet -Force -Confirm:$False

After, close and open again a PowerShell window. Then execute this command:

Install-Module -Name RDWebClientManagement -Confirm:$False

Then copy the RD Broker certificate in cer format into the RD Web Access server and run the following cmdlets:

Import-RDWebClientBrokerCert c:tempbroker.cer

Install-RDWebClientPackage
Publish-RDWebClientPackage -Type Production -Latest

Now you can connect to the RD Web client by using the following URL: https:///RDWeb/WebClient/Index.html. In my example, I connect to https://apps.SeromIT.com/RDWeb/WebClient/Index.html.

Conclusion

I like the RD Web client for several reasons. First, you can connect to a RDS session from a HTML5 ready web browser. You don’t need anymore a compatible RD client and you can connect from several devices such as Mac, a Linux device or maybe a tablet or smartphone. Secondly, the HTML5 client doesn’t require settings for SSO like we did with the legacy portal. The deployment is easier as before. And finally I found this client more user friendly than the legacy portal. The only thing missing is the ability to enable the HTML5 client by a single click or PowerShell cmdlet, or to enable it by default.

Установка службы удаленных рабочих столов (RDS) на Windows Server 2019 состоит из многих шагов, но в действительности это очень просто. Из статьи вы узнаете о том, как установить эту службу в доменной среде, которая требует наличия двух серверов.

Предварительные условия

Перед началом установки RDS необходимо убедиться, что выполняются два требования,  а именно:

• все серверы подключены к домену;
• есть по крайней мере два доступных сервера.

Необходимо, чтобы было именно два сервера, так как для роли RD Licensing, согласно лучшим практикам Microsoft, требуется отдельный сервер. В данной инструкции мы будем использовать для этой роли контроллер домена, что не вполне соответствует лучшим практикам, но мы делаем это, чтобы упростить демонстрационную установку.

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

Для начала мы добавим к основному RDS-серверу следующие роли:

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

Пошаговая установка

1. В диспетчере сервера на основном RDS-сервере, на котором выполняется установка, откройте Add Roles and Features Wizard (мастер добавления ролей и компонентов) и выберите Remote Desktop Services installation(установку службы удаленных рабочих столов).

2. Для этой инструкции мы используем опцию Quick Start (Быстрый старт), но если вам требуется больше контроля над процессом установки, вы можете выбрать Standard Deployment (Стандартную установку), которая позволяет редактировать большее количество настроек.

3. Далее мы выбираем Session-based desktop deployment (Установка рабочих столов на основе сеансов), так как это стандартная модель подключения к удаленным приложениям и удаленным рабочим столам, используемая в большинстве установок RDS.

4. В разделе Server Selection (Выбор сервера), выберите сервер, на который мы устанавливаем RDS.

5. Чтобы начать установку, выберите Restart the destination server automatically if required (Автоматический перезапуск конечного сервера в случае необходимости) и кликните на Deploy (Установить).

6. Проверьте, что все роли успешно установлены перед тем, как переходить к следующим шагам.

Добавление дополнительного сервера

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

1. Чтобы добавить дополнительный сервер, кликните правой кнопкой мыши на All Servers (Все серверы), выберите Add Servers (Добавление серверов), а затем выберите нужный сервер в Active Directory.

2. Перейдите на экран Remote Desktop Services (Службы удаленных рабочих столов) и кликните на зеленом плюсе над RD Licensing (Лицензирование удаленных рабочих столов).

3. Откроется окно Add RD Licensing Servers (Добавление серверов лицензирования удаленных рабочих столов), в котором вы сможете выбрать дополнительный сервер для роли RD Licensing.

4. Кликните на Add (Добавление), чтобы установить роль на дополнительный сервер.

5. Убедитесь, что установка завершена и зеленый плюс над RD Licensing заменен на соответствующий значок.

Добавление роли RD Gateway Role

Теперь нам нужно добавить RD Gateway Role (роль службы шлюза удаленных рабочих столов) к основному RDS-серверу.

1. На экране Remote Desktop Services (Службы удаленных рабочих столов) кликните на зеленом плюсе над RD Gateway (Шлюз удаленных рабочих столов).
2. Выберите основной RDS-сервер для установки этой роли.

3. Присвойте самоподписанному SSL-сертификату полное доменное имя.

4. Кликните Next и потом Add, чтобы установить роль на основной RDS-сервер.

Настройка параметров установки

Теперь, когда все роли установлены, можно перейти к настройке параметров установки.

1. Откройте экран Remote Desktop Services и в выпадающем списке Tasks (Задания) кликните на Edit Deployment Properties (Редактирование параметров установки).

2. На экране RD Gateway оставьте настройки по умолчанию и кликните на пункте меню RD Licensing.

3. Выберите Per User (По количеству пользователей) на экране RD Licensing. Вы можете выбрать любую из двух опций, но в целях обучения мы выбираем Per User.

4. Обратите внимание на URL на экране RD Web Access (Веб-доступ к удаленным рабочим столам). Позже мы будем его использовать для доступа к установленным приложениям.

5. В целях тестирования можно оставить сертификаты как Not Configured (Не сконфигурированные) и нажать OK, чтобы сохранить параметры установки. 

Если вы хотите сконфигурировать сертификат, вам придется делать это для каждой службы роли по отдельности.

Верификация службы удаленных рабочих столов

По умолчанию после установки создается QuickSessionCollection, куда входят Calculator, WordPad и Paint в качестве удаленных приложений. Мы можем использовать это для тестирования установки RDP.

1. Для тестирования IIS перейдите по ссылке, представленной на экране RD Web Access, или используйте https://localhost/rdweb/, если вы находитесь на RDP-сервере.

2. Подключитесь к сеансу IIS RDS с помощью доменной учетной записи.

3. Запустите удаленное соединение: то, которое вы сконфигурировали, или удаленное приложение по умолчанию.

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

Для установки и настройки роли RemoteApp, имеем подготовленный сервер с операционной системой Windows Server 2019, на котором будем производить нижеописанные действия.

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

На первом этапе установим службы Удаленных рабочих столов, для этого в окне Диспетчер серверов выбираем Добавить роли и компоненты.

Обращаем внимание перед установкой роли на предупреждение → далее.

Устанавливаем чекбокс Установка служб удаленных рабочих столов → далее.

Устанавливаем чекбокс Cтандартное развертывание → далее.

Устанавливаем чекбокс Развертывание рабочих столов на основе сеансов → далее.

Выбираем сервер, на который будут установлены службы роли посредника → далее.

Устанавливаем чекбокс Установить службы роли веб-доступа к удаленным рабочим столам на сервере посредника подключений к удаленному рабочему столу → далее.

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

Устанавливаем чекбокс Автоматически перезапускать конечный сервер, если это потребуется → развернуть.

Закрываем установку после завершения и перезагружаем сервер.

Создание коллекции сеансов

Заходим в диспетчер серверов → Службы удаленных рабочих столов → Создание коллекции сеансов.

Нажимаем далее → Указываем имя коллекции → Выбираем наш сервер → Выбираем группу пользователей для доступа к коллекции → Снимаем чекбокс с включить диски профилей пользователей → Нажимаем создать → закрыть.

Выбираем нашу коллекцию и нажимаем публикация удаленных приложений RemoteApp.

Выбираем из списка приложения, которые необходимо опубликовать, нажимаем далее → опубликовать → закрыть.

Проверка публикации RemoteApp

Переходим в браузере по адресу https://localhost/rdweb и выбираем приложение.

После сохранения файла RDP, можем заходить в него под пользователем.

Нужна помощь? Наша компания может оказать помощь в реализации ИТ-задач, для этого напишите в чат. Также мы предоставляем готовый сервер с RemoteApp-приложениями, например, с различными конфигурациями 1С.