Настройка rds windows server 2012 r2

Сегодня мы объясним, чем развертывание RDS Session Host на Windows Server 2012 R2 отличается от более ранних версий Windows Server и расскажем о доступных опциях развертывания. Remote Desktop Services на Windows Server значительно усовершенствовались за последнее время, но остается, тем не менее, много непонятного по причине множества вовлеченных в процесс компонентов. RD Session Host-ы выполняют всю грязную работу, обслуживая терминальные сессии пользователей. Однако даже при самом примитивном сценарии обязательно использование RD Connection Broker (посредника подключений к удаленному рабочему столу). Еще до того, как вы запланируете развертывание служб удаленного рабочего стола, стоит ознакомиться с его ролью.

RD Connection Broker

Когда сеанс удаленного рабочего стола отключается, приложения в сеансе пользователя продолжают работать. Для отслеживания сеансов пользователей RD Connection Broker (Посредник подключений удаленного рабочего стола) хранит такую информацию, как название хост-сервера сеансов удаленных рабочих столов, где проходит каждая сессия, состояние сессии и ее идентификатор, а также информация о подключенных пользователях в каждой сессии. Эта информация используется для подключения пользователей к существующим сеансам на серверах RD Session Host (терминальные сервера Windows). При создании новой сессии RD Connection Broker-ы также играют свою роль путем подключения пользователей к серверам RD Session Host по мере загрузки.

Начиная с Windows Server 2012, посредники подключений к удаленному рабочему столу не только хранят данные о пользовательских сессиях, но и информацию о конфигурации. Посредник подключений к удаленным рабочим столам использует внутреннюю базу данных Windows для сохранения сессии и информации о конфигурации, кроме случаев, когда установлен режим высокой доступности (HA), где используется сервер SQL 2008 R2 (или более поздняя версия).

Посредник подключений к удаленному рабочему столу требует домен Active Directory, но не может быть установлен на контроллере домена (DC). Можно развернуть службы удаленного рабочего стола в рабочей группе с помощью установки роли сервера, хотя при этом теряется возможность централизованного управления, пульты управления и функционал удаленных приложений Remoteapp.

Централизованная публикация приложений

В Windows Server 2012 также введен концепт коллекций (collections). В Windows Server 2008 R2 требовалось, чтобы системные администраторы публиковали приложения для каждого RD Session Host в индивидуальном порядке. Теперь посредник подключений к удаленному рабочему столу хранит информацию о конфигурации.

Опции развертывания: быстрая и стандартная

Ключ к пониманию того, как развернуть RDS на Windows Server 2012 R2 в понимании того, что недостаточно установки роли RD Session Host. Диспетчер серверов обеспечивает специальный режим развертывания для установки RDS, таким образом все необходимые компоненты установлены в нужных местах, чтобы делает развертывание простым и быстрым.

Службы удаленного рабочего стола на Windows Server 2012 R2

В мастере добавления ролей и компонентов (Add Roles and Features Wizard) в диспетчере серверов есть специальная опция установки, установка служб удаленных рабочих столов (Remote Desktop Services installation), которую необходимо выбрать при развертывании служб удаленных рабочих столов. Формулировка при этом варианте немного смущает, но опция позволяет устанавливать хосты сеансов удаленных рабочих столов без развертывания полной инфраструктуры виртуальных ПК (virtual desktop infrastructure — VDI).

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

Стандартное развертывание позволяет установить RD Connection Broker, RD Session Host и RD Web Access на одном сервере или на нескольких серверах, что является наиболее вероятным сценарием развертывания в производственной среде. Посредник подключений к удаленному рабочему столу включает внутреннюю базу данных Windows, RD Session Host и RD Web Access roles. Все это является обязательным, но RD Gateway играет факультативную роль. RD Web Access предоставляет пользователям доступ к RemoteApps или рабочим столам из меню «Пуск» или с веб-портала. Если вы хотите использовать RDS больше, чем в течение 120-дневного пробного периода, вам потребуется дополнительно устанавливать роль лицензирования удаленных рабочих столов.

Консоли управления

Все необходимые консоли управления можно найти в диспетчере серверов на сервере, где установлен посредник подключений к удаленным рабочим столам, за исключением RD Gateway и RD Licensing.

Установка служб удаленного рабочего стола на Windows Server 2012 R2

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

Стандартное развертывание — это модель развертывания по умолчанию, и даже при том условии, что для демонстрации будут установлены три роли сервера на один сервер, это не лучшее решение. Внутренняя база данных Windows устанавливается как часть процесса для поддержки роли посредника подключений к удаленному рабочему столу, также как и некоторые компоненты IIS для RD Web Access, которые обеспечивают доступ к RemoteApps или рабочим столам из меню «Пуск» или с веб-портала.

Лицензирование

При желании использовать развернутые службы удаленного рабочего стола более чем в течение 120-дневного тестового периода необходимо установить роль RD Licensing, добавить лицензию, зарегистрировать сервер лицензирования с Active Directory, а затем добавить RD Licensing в RDS-инфраструктуру. RD Licensing устанавливается также, как любая другая роль, поэтому нет необходимости использовать специальную опцию развертывания в диспетчере серверов.

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

Серверы, которые вы планируете использовать в своем RDS-развертывании, должны быть добавлены в Пул Серверов (Server Pool) в диспетчере серверов перед началом процесса. Вам потребуется домен Active Directory domain и аккаунт, у которого есть разрешение на установку ролей сервера на выбранный сервер (серверы). Дополнительно может быть установлена роль посредника подключений к удаленному рабочему столу на контроллер домена.

• Откройте Диспетчер серверов;
• Выберите «Добавить роли и компоненты» в меню управления;
• В Мастере добавления ролей и компонентов нажмите «Далее» на экране «Перед началом установки» (Before You Begin).
• На экране «Выберите тип установки» выберите «Установка служб удаленного рабочего стола» и нажмите «Далее»;
• На экране «Выберите тип развертывания» выберите «Стандартное» и нажмите «Далее».

Стандартное или быстрое развертывание

• На экране «Выберите сценарий развертывания» выберите развертывание серверов сеансов (Session-based desktop deployment) и нажмите «Далее».
• На экране обзора служб ролей (Review role services) отметьте службы ролей для установки и нажмите «Далее».

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

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

Выберите сервер из пула серверов

• На экране определения сервера RD Web Access повторите предыдущий шаг, чтобы добавить сервер в Selected, или поставьте галочку в «Установить службу роли RD Web Access на сервер посредника подключений к удаленному рабочему столу» (Install the RD Web Access role service on the RD Connection Broker server), если вы хотите установить эту роль на тот же сервер, что и посредника подключений к удаленному рабочему столу. Нажмите «Далее». continue.
• На экране определения серверов RD Session Host выберите один или более серверов из пула серверов, кликнув дважды или с помощью выбора мышью и нажатия на стрелку в центре диалогового окна.
• На экране подтверждения нажмите «Перезапустить сервер автоматически, если необходимо» (Restart the destination server automatically if required) и нажмите «Развернуть».
• Когда 3 роли сервера будут установлены, нажмите «Закрыть» на экране хода развертывания (View progress).

Ход развертывания

Теперь необходимо залогиниться на сервере, где установлена роль посредника подключений к удаленному рабочему столу, открыть Диспетчер серверов и нажать «Службы удаленного рабочего стола» (Remote Desktop Services) в списке опций слева, чтобы увидеть информацию по вашему

RDS-развертыванию

.

Дашборд служб удаленного рабочего стола в Диспетчере серверов

БЫСТРОЕ РАЗВЁРТЫВАНИЕ В ДОМЕНЕ

Перед тем, как начать установку RDS на сервер необходимо ознакомиться с существующей инфраструктурой сети. В данном случае, это тестовая сеть, состоящая из контроллера домена DC1 со статическим адресом 172.16.7.1/24, сервера на который будут установлены службы  RDS — RAPP, с адресом 172.16.7.2/24 и рабочих станций WS101, WS102, WS103, получающих IP-адреса по DHCP. Все компьютеры сети подключены к домену domain.local

На сервере RAPP необходимо открыть Диспетчер серверов. Для этого можно нажать на соответствующую иконку на панели задач или выполнить команду servermanager.exe В окне диспетчера выбираем Управление —Добавить роли и компоненты, после чего откроется окно мастера добавления ролей и компонентов. В первом его окне предлагается ознакомиться с основными требованиями к серверам, на которые будут устанавливаться роли. Также здесь можно установить галочку, которая позволит пропускать эту информацию при добавлении новых компонентов и ролей. При частой установке бывает полезно её установить. Прочитав информацию нажимаем Далее.

В следующем окне предлагается выбрать тип установки. Отмечаем пунктУстановка служб удалённых рабочих столов.

Так как мы производим установку всех служб RDS на один сервер, то целесообразно в следующем окне мастера выбрать Быстрый запуск.

Далее выбираем сценарий развертывания RDS. Нас интересует создание среды удалённых рабочих столов на основе сеансов. Поэтому выбираем соответствующую опцию и жмём Далее.

В следующем окне мастера предлагается выбрать сервер, на котором будут развернуты службы RDS. В нашем случае это сервер RAPP.domain.local. После того, как выбор сделан, жмём Далее.

После выбора сервера мы увидим окно с подтверждением выбранных служб и именем сервера, на который будут установлены эти службы. Тут же необходимо согласиться с тем, что сервер будет перезагружен, поставив соответствующую галочку и нажать кнопку Развернуть, после чего откроется окно в котором будет отображен процесс развёртывания ролей RDS. В процессе выполнения установки сервер будет перезагружен. После перезагрузки сервера, необходимо зайти под той же учётной записью, под которой был начат процесс установки (в данном случае это domaindcadmin) и спустя некоторое время откроется окно мастера и развёртывание возобновится автоматически.

После завершения установки, мастер отрапортует о состоянии всех служб и сообщит ссылку для организации веб-доступа к удалённым рабочим столам.

Когда мастер завершит развёртывание RDS, можно будет посмотреть какие роли установлены. Для этого заходим в диспетчер серверов и выбираем в левой панели пункт Службы удалённых рабочих столов. На вкладке Общие сведения мы можем увидеть, что сервер RAPP в данном развёртывании будет выступать в роли посредника подключений к удалённому рабочему столу, узла сеансов удалённых рабочих столов и узла веб-доступа к удалённым рабочим столам.

Так же мы видим, что кроме этих служб была установлена коллекция QuickSessionCollection в которую входят несколько стандартных приложений RemoteApp, а именно Paint, WordPad и Калькулятор.

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

Проверим работу веб-доступа к удалённым приложениям. Для этого перейдем по ссылке, которую мы получили в процессе работы мастера установки ролей и компонентов —  https://rapp.domain.local/rdweb

Как видим, подключение удалось. Это значит, что все роли служб удалённых рабочих столов настроены корректно и могут обслуживать клиентов. Единственное что осталось сделать, перед тем как давать доступ для клиентов — это установить службу лицензирования, но об этом далее в этой статье.

Следует помнить, что в доменной среде пользователей не обязательно добавлять в группу «Пользователи удалённого рабочего стола» т.к. при развёртывании RDS в эту группу автоматически добавляется группа «Пользователи домена».

Стандартное развёртывание

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

Теперь рассмотрим случай посложнее и поинтереснее — необходимо развернуть службы удалённых рабочих столов таким образом, чтобы посредник подключений к удалённому рабочему столу, узел веб-доступа и узлы сеансов располагались на разных серверах. Таким образом, ферма серверов RDS будет располагаться на четырёх серверах:

• RDCB — сервер, выступающий в роли посредника подключений. Имеет адрес 172.16.7.2/24
• RDWH — сервер, выступающий в роли узла веб-доступа к службе удалённых рабочих столов. Его адрес — 172.16.7.3/24
• RDSH1, RDSH2 — серверы, выступающие в роли узлов сеансов. Имеют адреса, соответственно 172.16.7.4/24 и 172.16.7.5/24

Компьютеры WS101, WS102, WS103 — это рабочие станции, с которых осуществляется доступ к ресурсам серверов RDS. Их сетевые интерфейсы конфигурируются с помощью протокола DHCP.

Прежде чем приступать непосредственно к развёртыванию служб RDS, необходимо выполнить некоторый минимум подготовительный действий. А именно, на сервере, с которого будем проводить установку, откроем Диспетчер серверов и добавим в него все необходимые нам сервера. В данном случае в диспетчер серверов на RDCB добавим сервера RDWH, RDSH1 и RDSH2. Сделать это можно зайдя в пункт Управление и выбрав там опцию Добавление серверов.

После того, как все необходимые для развёртывания серверы добавлены, можно приступить непосредственно к установке служб удалённых рабочих столов. Следует отметить, что сама процедура во многом схожа с процедурой рассмотренной ранее, поэтому некоторые шаги мастера добавления ролей и компонентов будут повторяться. Итак, запустим сам мастер. Это можно сделать, выбрав пункт Управление — Добавить роли и компоненты. На первом шаге мастера предлагается выбрать тип установки. Нам необходимо развернуть службы

RDS, поэтому отмечаем Установка служб удалённых рабочих столов и жмём Далее.
Далее мастер предложит варианты развёртывания RDS. Нас интересуетстандартное развёртывание. Выбираем соответствующий пункт и жмём Далее.

В следующем окне мастера выбираем пункт Развёртывание рабочих столов на основе сеансов.

Далее мастер отобразит окно, которое вкратце ознакомит нас со всеми службами ролей RDS и сообщит от имени какого пользователя будет производиться процедура установки.

На трёх последующих вкладках следует указать серверы, на которые будут установлены соответствующие роли. В нашем случае роль посредника подключений установим на сервер RDCB, роль узла веб-доступа — на сервер с именем RDWH, роли узлов сеансов — на серверы RDSH1 и RDSH2.

После указания всех серверов на предыдущих шагах, мастер отобразит окно подтверждения сделанного выбора, в котором можно убедиться, что роли будут установлены на правильные серверы. Так же здесь необходимо установить галочку Автоматически перезапускать конечный сервер, если это потребуется. Т.к. на сервере, с которого будет производиться развёртывание, не будет установлена роль узла удалённых рабочих столов, то он перезагружаться не будет, а вот остальные серверы выполнят перезагрузку в автоматическом режиме. Как мне кажется, это очень удобно и правильно организовано.

После завершения установки, в консоли управления удалёнными рабочими столами, на вкладке Общие сведения можно увидеть схему развёртывания и список серверов, на которые установлены различные роли RDS.

Проверить работоспособность развёрнутой конфигурации можно зайдя на страницу веб-доступа (https://rdwh.domain.local/rdweb) с одной из рабочих станций.

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

СЕРВЕР ЛИЦЕНЗИРОВАНИЯ

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

Для этого, запустим Диспетчер серверов, если он не запущен, и перейдём вконсоль управления удалёнными рабочими столами, кликнув на соответственную ссылку слева. Для запуска необходимого мастера кликнем на зелёную кнопку с плюсом и подписью Лицензирование удалённых рабочих столов на панели Обзор развёртывания.

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

После того, как выбор сделан, необходимо подтвердить его правильность, нажав на кнопку Добавить

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

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

К этим же свойствам можно получить доступ и после завершения установки. Для этого нужно на панели Обзор развёртывания выбрать пункт Свойства, а затем Изменить развёртывание.

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

Далее мы можем развернуть удаленные приложения RemoteApp на этом RDS

Join @AdmNtsRu on Telegram

Обновлено 17.11.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. Вы еще не знакомы с Windows Server 2012R2? Мне вот уже «посчастливилось» настраивать на нем терминальный сервер. Честно говоря, совершенно не понятно зачем было пихать новый ленточный интерфейс в сервер — логика Microsoft последнее время не поддается объяснению.

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

Однако всё оказалось решаемо, пусть и с некоторыми дополнительными действиями, о которых узнал c technet.microsoft.com. Данный метод позволит вам производить более двух RDP подключений одновременно на ваш сервер, чтобы более рационально использовать его ресурсы.

Настраиваем роль терминального сервера на WinServer 2012 без поднятия домена

Принципиальных отличий в установке Windows Server 2012 от Windows Server 2008 R2 нет, потому этот этап пропустим. Хочу подсветить, что операционная система прекрасно ставится с флешки, на которую был записан образ (давно уже не использую CD/DVD — медленно и нудно). Перейдем непосредственно к установке роли RDS на сервере.

• 1️⃣ Для этого запустим Диспетчер серверов (Server Manager), и перейдем в поле Локальный сервер (Local Server)

• 2️⃣ Далее запускаем мастер добавления ролей и компонентов, где выбираем тип установки «Установка ролей или компонентов (Role-based or feature-based installation)«.

• 3️⃣ Выбираем сервер из пула, если их несколько, то удобно их добавить, чтобы процедуру проводить один раз для всех.

• 4️⃣ Выставляем галку «Службы удаленных рабочих столов«

• 5️⃣ Производить установку всех компонент роли RDS можно сразу, но на Technet, для лучшего понимания процесса, советуют разделить этот процесс на два этапа. Последуем этому совету и мы. Первой установим компоненту «Лицензирование удаленных рабочих столов (Remote Desktop Licensing)»

• 6️⃣ Подтверждаем добавление компонентов, для терминального стола на Windows Server 2012 R2.

• 7️⃣ Проверяем сводную информацию, и если все верно, то нажимаем кнопку «Установить«. Обратите внимание, что есть возможность экспортировать параметры конфигурации в XML файл, для автоматизации.

• 8️⃣ После завершения процесса, запускаем Диспетчер лицензирования удаленных рабочих столов (RD Licensing Manager), в котором активируем наш сервер лицензий и устанавливаем пакет терминальных лицензий (например: Windows Server 2012 — RDS Per User CAL, 5 шт.).

• 9️⃣ Активация происходит, через правый клик.

Никаких новшеств здесь нет, а потому описывать подробно данный процесс не стану (возможно раскрою тему в одной из будущих статей — жду ваших предложений и комментариев).

Весь процесс активации и установки пакета лицензий на себя берет мастер, наша задача правильно выбрать программу лицензирования, тип лицензий, количество и т.д. Вторым этапом устанавливаем компоненту «Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)«.

После установки этой компоненты у нас появится «Средство диагностики лицензирования удаленных рабочих столов (RD Licensing Diagnoser)«, которое сообщит нам ошибку об отсутствии сервера, раздающего терминальные лицензии (скриншота с ошибкой к сожалению не сделал, приведен уже работающий вариант сервера).

Стоит заметить, что в оснастке отсутствуют инструменты управления, которые были в Windows Server 2008 R2, т.е. возможности добавления сервера лицензий нет.

Настраиваем локальные политики для серверов находящихся в рабочей группе

Осталось самое интересное. Исправить данную ситуация не сложно — достаточно настроить всего две локальные политики. В строке терминала пишем gpedit.msc и изменяем соответствующие ключи.

Англоязычный вариант:

Установка компонента — Remote Desktop Web Access

Если, в качестве клиента требуется использовать браузер, устанавливаем дополнительную компоненту Remote Desktop Web Access. Тут вообще все просто, нужно лишь разрешить мастеру добавить то, что он хочет, в частности IIS. После окончания установки, на клиентской машине в браузере сервер должен ответить и показать страницу Remote Web Access.

Обратиться к серверу терминалов через браузер можно по адресу https://ip/rdweb

Описание задачи: Настраиваем терминальный сервер Windows 2012 R2 для возможности предоставления вычислительных ресурсов пользователям.

Шаг 1 — Настройка роли терминального сервера на windows 2012 R2

Авторизуйтесь в ОС под локальной учетной записью администратора и запустите Диспетчер серверов (Server Manager).

Запускаем мастер добавления ролей и компонентов, где выбираем тип установки «Установка ролей или компонентов»:

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В нашем случае это локальный сервер. Нажимаем «Далее».

Отмечаем роль «Службы удаленных рабочих столов» в списке ролей и жмем «Далее».

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее».

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

Также устанавливаем «Узел сеансов удаленных рабочих столов». Отметив необходимы службы ролей, нажимаем «Далее».

Все параметры установки роли определены. Жмем «Далее».

На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется, нажимаем «Да» в появившемся окне и нажимаем «Установить» для запуска установки службы.

Если все прошло хорошо, после перезагрузки увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» для завершения работы мастера.

Шаг 2 — Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов». Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства»— «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов».

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду «gpedit.msc» в пункте меню Пуск — Выполнить.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:
«Конфигурация компьютера» — «Административные шаблоны» — «Компоненты Windows» — «Службы удаленных рабочих столов» — «Узел сеансов удаленных рабочих столов» — «Лицензирование»
Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов», кликнув 2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено». Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В нашем случае сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК».

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов». Также устанавливаем переключатель в «Включено» и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта — «На пользователя» или «На устройство».

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК».

Изменив вышеперечисленные политики, закрываем редактор.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов». Найти его можно в диспетчере серверов, вкладка «Средства»— «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов».

Здесь найдем наш сервер лицензирования, со статусом «Не активирован». Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер».

Запустится Мастер активации сервера. Жмем «Далее» на первой странице мастера. Затем выбираем метод подключения «Авто» и жмем «Далее».

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее»
Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее»
Сервер лицензирования активирован.

Шаг 3 — Установка лицензий на сервер лицензирования службы удаленных рабочих столов

Теперь произведем установку лицензии на сервер лицензирования службы удаленных рабочих столов. Для этого нажимаем в окне «Лицензирования удаленных рабочих столов» на активированный сервер лицензирования и выбираем пункт «Установить лицензии».

Нажимаем «Далее» на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement». Жмем «Далее».

Вводим номер соглашения и нажимаем «Далее».

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее».

Ждем завершения работы мастера установки лицензий с сообщением о том, что запрошенные лицензии успешно установлены. Жмем «Готово».

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

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

На этом настройка сервера терминалов в Windows Server 2012 завершена.

Шаг 4 — Подключение к серверу терминалов

Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».

Есть вопросы? Можете написать в чат для связи с нашим специалистом.

Win server 2012 r2 настройка сервера терминалов

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. Вы еще не знакомы с Windows Server 2012R2? Мне вот уже «посчастливилось» настраивать на нем терминальный сервер. Честно говоря, совершенно не понятно зачем было пихать новый ленточный интерфейс в сервер — логика Microsoft последнее время не поддается объяснению.

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

Однако всё оказалось решаемо, пусть и с некоторыми дополнительными действиями, о которых узнал c technet.microsoft.com. Данный метод позволит вам производить более двух RDP подключений одновременно на ваш сервер, чтобы более рационально использовать его ресурсы.

Настраиваем роль терминального сервера на WinServer 2012 без поднятия домена

Принципиальных отличий в установке Windows Server 2012 от Windows Server 2008 R2 нет, потому этот этап пропустим. Хочу подсветить, что операционная система прекрасно ставится с флешки, на которую был записан образ (давно уже не использую CD/DVD — медленно и нудно). Перейдем непосредственно к установке роли RDS на сервере.

• 1️⃣ Для этого запустим Диспетчер серверов (Server Manager), и перейдем в поле Локальный сервер (Local Server)

Как установить и настроить терминальный сервер на Windows Server 2012R2-01

• 2️⃣ Далее запускаем мастер добавления ролей и компонентов, где выбираем тип установки «Установка ролей или компонентов (Role-based or feature-based installation)«.

Как установить и настроить терминальный сервер на Windows Server 2012R2-02

• 3️⃣ Выбираем сервер из пула, если их несколько, то удобно их добавить, чтобы процедуру проводить один раз для всех.

Как установить и настроить терминальный сервер на Windows Server 2012R2-03

• 4️⃣ Выставляем галку «Службы удаленных рабочих столов«

Как установить и настроить терминальный сервер на Windows Server 2012R2-04

• 5️⃣ Производить установку всех компонент роли RDS можно сразу, но на Technet, для лучшего понимания процесса, советуют разделить этот процесс на два этапа. Последуем этому совету и мы. Первой установим компоненту «Лицензирование удаленных рабочих столов (Remote Desktop Licensing)»

Как установить и настроить терминальный сервер на Windows Server 2012R2-05

• 6️⃣ Подтверждаем добавление компонентов, для терминального стола на Windows Server 2012 R2.

Как установить и настроить терминальный сервер на Windows Server 2012R2-06

• 7️⃣ Проверяем сводную информацию, и если все верно, то нажимаем кнопку «Установить«. Обратите внимание, что есть возможность экспортировать параметры конфигурации в XML файл, для автоматизации.

Как установить и настроить терминальный сервер на Windows Server 2012R2-07

• 8️⃣ После завершения процесса, запускаем Диспетчер лицензирования удаленных рабочих столов (RD Licensing Manager), в котором активируем наш сервер лицензий и устанавливаем пакет терминальных лицензий (например: Windows Server 2012 — RDS Per User CAL, 5 шт.).

Как установить и настроить терминальный сервер на Windows Server 2012R2-08

• 9️⃣ Активация происходит, через правый клик.

Как установить и настроить терминальный сервер на Windows Server 2012R2-09

Никаких новшеств здесь нет, а потому описывать подробно данный процесс не стану (возможно раскрою тему в одной из будущих статей — жду ваших предложений и комментариев).

Весь процесс активации и установки пакета лицензий на себя берет мастер, наша задача правильно выбрать программу лицензирования, тип лицензий, количество и т.д. Вторым этапом устанавливаем компоненту «Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)«.

После установки этой компоненты у нас появится «Средство диагностики лицензирования удаленных рабочих столов (RD Licensing Diagnoser)«, которое сообщит нам ошибку об отсутствии сервера, раздающего терминальные лицензии (скриншота с ошибкой к сожалению не сделал, приведен уже работающий вариант сервера).

Стоит заметить, что в оснастке отсутствуют инструменты управления, которые были в Windows Server 2008 R2, т.е. возможности добавления сервера лицензий нет.

Как установить и настроить терминальный сервер на Windows Server 2012R2-10

Настраиваем локальные политики для серверов находящихся в рабочей группе

Осталось самое интересное. Исправить данную ситуация не сложно — достаточно настроить всего две локальные политики. В строке терминала пишем gpedit.msc и изменяем соответствующие ключи.

Англоязычный вариант:

Установка компонента — Remote Desktop Web Access

Если, в качестве клиента требуется использовать браузер, устанавливаем дополнительную компоненту Remote Desktop Web Access. Тут вообще все просто, нужно лишь разрешить мастеру добавить то, что он хочет, в частности IIS. После окончания установки, на клиентской машине в браузере сервер должен ответить и показать страницу Remote Web Access.

Обратиться к серверу терминалов через браузер можно по адресу https://ip/rdweb

Популярные Похожие записи:

7 Responses to Как установить и настроить терминальный сервер на Windows Server 2012R2

Неплохо, работали с виндовс сервер. Перешли на Thinstuff из-за высокой цены майрософта(курс доллара и санкции заметно прибавили цену MS Server). Неплохой аналог, стабильно работает, проблем не возникло.

Очередной раз, сделал все по рекомендации.
Но, лицензии не раздаются на пользователя, пускает на терминальный сервер, потому что еще остался бесплатный период 120 дней (осталось 110).
Попутно вопрос — если активируешь терминальный сервер, то и отключается бесплатный период, а он не отключился и диспетчере лицензий видно 10 активированных лицензий.
Но не выдаются.
Что делать?

Опишите вашу структуру, есть ли Ad, если да то в группы добавили и все через политики прописали на клиентской машине, чтобы сервер виделся?

Добрый день. Сделал все по инструкции, а больше 2-х удаленных столов не хочет пускать? Что еще нужно добавить? Помогите пожалуйста.

Источник

Установка сервера терминалов в Windows Server 2012 R2

Оглавление

1. Что понадобится
2. Установка службы удаленных рабочих столов
3. Определение сервера лицензирования для службы удаленных рабочих столов
4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов
5. Подключение к серверу терминалов

1. Что понадобится

1. Компьютер (сервер) с установленной на нем Windows Server 2012 и права администратора на данном сервере.
2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования.
   (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера: 6565792, 5296992, 3325596, 4965437, 4526017)
3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

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

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть» (Open) написать имя команды и нажать «ОК» ).

В меню, в верхнем правом углу, выбираем «Управление» (Manage) — «Добавить роли и компоненты» (Add Roles and Features) .

Запустится «Мастер добавления ролей и компонентов» (Add Roles and Features Wizard). Нажимаем «Далее» (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов» (Role-based or features-based installation) и снова жмем «Далее» (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее» (Next) .

Отмечаем роль «Службы удаленных рабочих столов» (Remote Desktop Services) в списке ролей и жмем «Далее» (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее» (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее» (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов» (Remote Desktop Licensing) (также соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» (Add Features) в появившемся мастере) и «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» (Add Features) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее» (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется» (Restart the destination server automatically if required), подтвердим выбор нажав «Да» (Yes) в появившемся окне и нажмем «Установить» (Install) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» (Close) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser). Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства» (Tools) — «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

• «Конфигурация компьютера» (Computer Configuration)
  • «Административные шаблоны» (Administrative Templates)
    • «Компоненты Windows» (Windows Components)
      • «Службы удаленных рабочих столов» (Remote Desktop Services)
        • «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host)
          • «Лицензирование» (Licensing)

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов» (Use the specified Remote Desktop license servers), кликнув 2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено» (Enabled). Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК» .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов» (Set the Remote licensing mode) . Также устанавливаем переключатель в «Включено» (Enabled) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

Для того, чтобы разобраться чем отличаются эти режимы, рассмотрим простой пример. Предположим, у Вас есть 5 лицензий. При режиме «На устройство» вы можете создать неограниченное число пользователей на сервере, которые смогут подключаться через удаленный рабочий стол только с 5 компьютеров, на которых установлены эти лицензии. Если выбрать режим «На пользователя», то зайти на сервер смогут только 5 выбранных пользователей, независимо с какого устройства они подключаются.

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК» .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser)

и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов» (RD Licensing Manager). Найти его можно в диспетчере серверов, вкладка «Средства» (Tools) — «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов» (Remote Desktop Licensing Manager) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован» (Not Activated). Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер» (Activate Server) .

Запустится Мастер активации сервера. Жмем «Далее» (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто» (Automatic connection) по умолчанию) и жмем «Далее» (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее» (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее» (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее» (Next) оставив включенным флаг «Запустить мастер установки лицензий» .

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

Нажимаем «Далее» (Next) на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement«». Жмем «Далее» (Next) .

Вводим номер соглашения и нажимаем «Далее» (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее» (Next) .

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

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».

Источник

В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки сервера терминалов в Windows Server 2008 R2, однако есть ряд значимых отличий. Итак:

Оглавление

1. Что понадобится
2. Установка службы удаленных рабочих столов
3. Определение сервера лицензирования для службы удаленных рабочих столов
4. Установка лицензий на сервер лицензирования службы удаленных рабочих столов
5. Подключение к серверу терминалов

1. Что понадобится

1. Компьютер (сервер) с установленной на нем  Windows Server 2012 (об установки этой ОС, я писал здесь) и права администратора на данном сервере.
2. Действительная клиентская лицензия сервера терминалов, приобретенная по одной из существующих программ лицензирования. (В данной статье я буду использовать найденный в интернете номер соглашения, по программе Enterprise Agriment. На момент написания статьи рабочими были номера:  6565792, 5296992, 3325596, 4965437, 4526017.)
3. Доступ к сети Internet для активации сервера лицензирования и установки лицензий (возможна также активация и по телефону).

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

Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду servermanager.exe (Для этого необходимо нажать комбинацию клавиш Win + R, в появившемся окне в поле «Открыть» (Open) написать имя команды и нажать «ОК» ).

В меню, в верхнем правом углу, выбираем «Управление» (Manage) — «Добавить роли и компоненты» (Add Roles and Features) .

Запустится «Мастер добавления ролей и компонентов» (Add Roles and Features Wizard). Нажимаем «Далее» (Next) на начальной странице.

Оставляем переключатель на «Установка ролей и компонентов» (Role-based or features-based installation) и снова жмем «Далее» (Next) .

Выбираем тот сервер из пула серверов, на который будет установлена служба терминалов. В моем примере это данный локальный сервер. Нажимаем «Далее» (Next) .

Отмечаем роль «Службы удаленных рабочих столов» (Remote Desktop Services) в списке ролей и жмем «Далее» (Next) .

Компоненты оставляем в том виде, в котором они есть. Ничего не отмечая жмем «Далее» (Next) .

Читаем описание службы удаленных рабочих столов и нажимаем «Далее» (Next) .

Теперь необходимо выбрать устанавливаемые службы ролей. Как минимум нам пригодится «Лицензирование удаленных рабочих столов» (Remote Desktop Licensing) (также соглашаемся на установку дополнительных компонент нажав  на «Добавить компоненты» (Add Features) в появившемся мастере)

и «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host) (опять соглашаемся на установку дополнительных компонент нажав на «Добавить компоненты» (Add Features) в открывшемся окне). Отметив необходимы службы ролей, нажимаем «Далее» (Next) .

Все параметры установки роли определены. На последней странице установим флаг «Автоматический перезапуск конечного сервера, если требуется» (Restart the destination server automatically if required) , подтвердим выбор нажав «Да» (Yes) в появившемся окне и нажмем «Установить» (Install) для запуска установки службы.

Если все прошло хорошо, после перезагрузки, увидим сообщение об успешной установке всех выбранных служб и компонент. Нажимаем «Закрыть» (Close) для завершения работы мастера.

3. Определение сервера лицензирования для службы удаленных рабочих столов

Теперь запустим «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства» (Tools) — «Terminal Services» — «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) .

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

Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc.

Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

• «Конфигурация компьютера» (Computer Configuration)
  • «Административные шаблоны» (Administrative Templates)
    • «Компоненты Windows» (Windows Components)
      • «Службы удаленных рабочих столов» (Remote Desktop Services)
        • «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host)
          • «Лицензирование» (Licensing)

Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов» (Use the specified Remote Desktop license servers) , кликнув  2 раза по соответствующей строке.

В окне редактирования параметров политики, переставим переключатель в «Включено» (Enabled) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем «ОК» .

Далее меняем параметры политики «Задать режим лицензирования удаленных рабочих столов» (Set the Remote licensing mode) . Также устанавливаем переключатель в «Включено» (Enabled) и указываем режим лицензирования для сервера узла сеансов удаленных рабочих столов. Возможны 2 варианта:

• «На пользователя» (Per User)
• «На устройство» (Per Device)

Для того, чтобы разобраться чем отличаются эти режимы, рассмотрим простой пример. Предположим, у Вас есть 5 лицензий. При режиме «На устройство» вы можете создать неограниченное число пользователей на сервере, которые смогут подключаться через удаленный рабочий стол только с 5 компьютеров, на которых установлены эти лицензии. Если выбрать режим «На пользователя», то зайти на сервер смогут только 5 выбранных пользователей, независимо с какого устройства они подключаются.

Выбираем тот режим, который наиболее подходит для ваших нужд и нажимаем «ОК» .

Изменив вышеперечисленные политики, закрываем редактор.

Возвращаемся в оснастку «Средство диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим новую ошибку, указывающую на то, что сервер лицензирования указан, но не включен.

Для запуска сервера лицензирования переходим в «Диспетчер лицензирования удаленных рабочих столов» (RD Licensing Manager) . Найти его можно в диспетчере серверов, вкладка «Средства» (Tools) — «Terminal Services» — «Диспетчер лицензирования удаленных рабочих столов» (Remote Desktop Licensing Manager) .

Здесь найдем наш сервер лицензирования, со статусом «Не активирован» (Not Activated) . Для активации кликаем по нему правой кнопкой мыши и в контекстном меню выбираем «Активировать сервер» (Activate Server) .

Запустится Мастер активации сервера. Жмем «Далее» (Next) на первой странице мастера.

Затем выбираем метод подключения («Авто» (Automatic connection) по умолчанию) и жмем «Далее» (Next) .

Вводим сведения об организации (эти поля обязательны для заполнения) после чего жмем «Далее» (Next) .

Вводим дополнительные сведения об организации (необязательно) и снова нажимаем «Далее» (Next) .

Сервер лицензирования активирован. Теперь следует установить лицензии. Для этого нажимаем «Далее» (Next) оставив включенным флаг «Запустить мастер установки лицензий» .

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

Нажимаем «Далее» (Next) на начальной странице Мастера установки лицензий.

Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement«» . Жмем «Далее» (Next) .

Вводим номер соглашения и нажимаем «Далее» (Next) .

Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее» (Next) .

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

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

Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов» (RD Licensing Diagnoser) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.

На этом установка сервера терминалов в Windows Server 2012 завершена.

5. Подключение к серверу терминалов

Для подключения к серверу терминалов можно использовать встроенный в Windows клиент «Подключение к удаленному рабочему столу».

Эта большая инструкция посвящена особенностям установки, настройки и эксплуатации фермы терминальных серверов на базе роли 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 Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
— Среда исполнения
— Подготавливаем виртуальные сервера
— Создаём кластер NLB
— Подготавливаем SQL Server
— Устанавливаем роли Remote Desktop Services
— Создаём высоко-доступный RD Connection Broker
— Добавляем сервера в высоко-доступный RD Connection Broker
— Добавляем на сервера роль RD Web Access
— Создаём коллекцию сеансов – Session Collection
— Настраиваем цифровые сертификаты
— Настраиваем веб-узлы RD Web Access
— Настраиваем Roaming User Profiles и Folder Redirection
— Публикуем приложения RemoteApp
— Устанавливаем языковой пакет
— Настраиваем перенаправление печати

Среда исполнения

В рассматриваемом примере мы будем строить ферму RDCB из 5 виртуальных серверов одинаковой конфигурации на базе Hyper-V из Windows Server 2012 Datacenter EN. На всех виртуальных серверах устанавливается Windows Server 2012 Standard EN.

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

Серверам присвоены имена – KOM-AD01-RDS21 , KOM-AD01-RDS22 , KOM-AD01-RDS23 , KOM-AD01-RDS24 , KOM-AD01-RDS25

Создаваемый в процессе описания высоко-доступный экземпляр RD Connection Broker а также NLB-кластер RD Web Access будут использовать общее виртуальное имя KOM-AD01-RDSNLB.

База данных высоко-доступного экземпляра RDCB будет расположена на отдельном кластере SQL Server c именем KOM-SQLCL 

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

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

Итак, у каждого виртуального сервера создадим по 2 сетевых адаптера. Назовём их условно на каждом сервере таким образом, чтобы было понятно за что отвечает этот интерфейс — NIC1 (Management) и NIC2 (NLB Cluster).

При создании второго сетевого адаптера NIC2, который будет использоваться для построения NLB в свойствах виртуальной машины Hyper-V необходимо разрешить спуфинг МАС адресов (Enable spoofing of MAC addresses)

Согласно нашей схемы, выделим и распределим статические IP адреса на серверах следующим образом:

Имя сервера	Настройки IP NIC1	Настройки IP NIC2 (NLB Cluster)
KOM-AD01-RDS21	IP 10.160.0.151/24	IP 10.160.0.141/24
KOM-AD01-RDS22	IP 10.160.0.152/24	IP 10.160.0.142/24
KOM-AD01-RDS23	IP 10.160.0.153/24	IP 10.160.0.143/24
KOM-AD01-RDS24	IP 10.160.0.154/24	IP 10.160.0.144/24
KOM-AD01-RDS25	IP 10.160.0.155/24	IP 10.160.0.145/24

На всех интерфейсах используются одинаковые настройки адреса шлюза по умолчанию -10.160.0.254 и адресов DNS — 10.160.0.253, 10.160.1.253. Причина использования именно такой сетевой конфигурации для построения NLB на базе Windows Server 2012 была ранее изложена в заметке App-V 5 for RDS — Разворачиваем инфраструктуру повышенной доступности

Интерфейс NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера), а NIC2 (для которого включён спуфинг MAC адресов) будет участником NLB кластера. Выполним настройку сетевых интерфейсов на каждом из серверов согласно вышеприведённой таблицы на примере сервера KOM-AD01-RDS21

Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).

NIC1 должен иметь приоритет над NIC2.

В свойствах сетевого подключения, которое будет использоваться для подключения к NLB кластеру (NIC2) можно отключить все компоненты, за исключением TCP/IPv4 и Client for Microsoft Networks:

В свойствах компонента TCP/IPv4 зададим настройки согласно приведённой ранее таблицы и по кнопке Advanced откроем окно дополнительных настроек

В окне дополнительных настроек TCP/IP на закладке DNS отключим механизм регистрации в DNS:

Интерфейс NIC1 настроим согласно вышеприведённой таблицы аналогичным образом, за исключением того, что на нём может быть включена опция регистрации в DNS и обязательно должны быть включены компоненты TCP/IPv4 , Client for Microsoft Networks и File and Printer Sharing for Microsoft Networks

После того как описанным способом настроены сетевые интерфейсы на всех серверах, зарегистрируем их имена в доменной зоне прямого просмотра DNS (если запрещена динамическая регистрация в DNS и/или отключена опция регистрации в свойствах интерфейсов NIC1). Для пакетной регистрации A-записей в DNS можно воспользоваться скриптом описанным в заметке DNS – Пакетное создание А-записей с помощью WMI и Powershell 

Дополнительно сразу же создаём статическую А-запись для будущего NLB кластера.

RD Connection Broker использует для хранения БД сессий общий экземпляр SQL Server, поэтому все сервера RDCB должны иметь «на борту» клиентские компоненты SQL Server, а также привилегии доступа к SQL Server. Настройку доступа к SQL Server выполним позже, а пока установим на каждый сервер, где планируется развертывание RD Connection Broker, свежую версию пакета Microsoft SQL Server 2012 Native Client (в нашем случае установка нужна на всех пяти виртуальных серверах). Скачать его можно со страницы загрузки Microsoft SQL Server 2012 SP1 Feature Pack (файл sqlncli.msi)

После установки клиента SQL Server создадим на каждом сервере SQL-Alias, который будем в дальнейшем использовать для подключения серверов RDCB к серверу SQL Server. Этого конечно можно и не делать, но это может оказаться полезным (даст нам дополнительную гибкость) в случае необходимости переноса БД на другой SQL-сервер или даже экземпляр. Запустим встроенную в ОС утилиту SQL Server Client Network Utility (C:windowssystem32cliconfg.exe) и добавим два новых алиаса – с коротким именем сервера и FQDN

Фактически созданные SQL-алиасы в интерфейсе утилиты были записаны в ключ реестра HKLMSOFTWAREMicrosoftMSSQLServerClientConnectTo

Теперь нужно проверить созданные нами SQL-алиасы. Для этого создадим пустой файл Universal Data Link с расширением *.udl и запустим его. На закладке Connection укажем SQL-алиас, выберем режим аутентификации Use Windows NT Integrated security и нажмём кнопку Test Connection

Если мы всё сделали правильно, то получим положительный результат подключения. При этом перечень всех активных БД на новом SQL сервере будет доступен в выпадающем списке Select the database on the server. Таким образом проверим алиас созданный как по NetBIOS имени так и по FQDN.

***

Далее, с помощью PowerShell установим на каждый сервер исполняемые компоненты NLB

Import-Module "ServerManager" 
Add-WindowsFeature "NLB" -IncludeManagementTools

Создаём кластер NLB

На первом виртуальном сервере (KOM-AD01-RDS21) открываем консоль Network Load Balancing Manager (nlbmgr.exe). Выбираем пункт меню Cluster > New Cluster

Вводим имя первого узла, который хотим добавить в NLB, кнопкой Connect подключаемся к нему, и получив с него набор доступных интерфейсов, выбираем тот который хотим сделать участником кластера:

На странице параметров хоста (Host Parameters) оставляем настройки по умолчанию:

В следующем окне мастера создания кластера добавляем IP адрес NLB кластера, на который мы ранее в DNS зарегистрировали А-запись.

Далее указываем FQDN кластера NLB (по той самой A-записи), а также режим его работы. Режим работы кластера – режим одноадресной рассылки – Unicast.

На странице правил портов (Port rules) удаляем имеющееся по умолчанию правило и добавляем необходимые нам правила. При добавлении правила портов убираем флажок All и указываем конкретный интерфейс NLB и диапазон портов, который хотим добавить в кластер NLB.

В общей сложности, в нашем примере балансировке в NLB кластере мы будем подвергать следующие порты:

TCP 443 – для подключения клиентов к RD Web Access;
TCP/UDP 3389 – для подключения клиентов к RD Connection Broker/Session Host;

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

Далее, переходим на имя NLB кластера и пунктом меню Add Host to Cluster вызываем мастер добавления второго и последующих серверов в кластер.

В конечном итоге после добавления (по аналогии с первым узлом) всех серверов мы получим работоспособный Windows NLB кластер

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

Подготавливаем SQL Server

Создадим в AD группу безопасности, например KOM-AD01-RDS-Connection-Broker-Computers, и включим в нее учетные записи наших виртуальных серверов.

После этого подключимся к экземпляру SQL Server на котором будет размещаться БД RDCB (в нашем случае это отдельный кластер SQL Server из двух серверов), создадим новый SQL Login с привязкой к указанной доменной группе. При создании SQL-логина ему будет присвоена серверная роль SQL Server – public, которая даст право подключаться к экземпляру SQL Server. Включим ещё одну серверную роль – dbcreator. Эта роль понадобится нам лишь на время первоначальной инициализации БД RDCB для того, чтобы учетная запись сервера, на котором мы будем запускать процесс создания отказоустойчивого RDCB, смогла выполнить операцию создания новой БД.

Дополнительно на SQL сервере создадим каталог для файлов базы данных RDCB. В нашем случае это будет каталог U:SQLData_SQL01_RDCB на кластерном диске SQL сервера.

Устанавливаем роли Remote Desktop Services

Так как консоль Server Manager в Windows Server 2012 поддерживает групповую настройку сразу нескольких серверов, перед тем как разворачивать на наши виртуальные сервера роли RDS, объединим их в логическую группу. На любом из виртуальных серверов, например на KOM-AD01-RDS21, откроем консоль Server Manager и выберем пункт меню Manage > Create Server Group

добавим пять наших виртуальных серверов в группу и дадим ей название, например RDS-FARM.

После этого выберем пункт меню Manage > Add Roles and Features Wizard

В открывшемся мастере добавления ролей выберем режим установки служб RDS — Remote Desktop Services installation

 

  Тип развёртывания — Standard deployment

Сценарий развертывания выбираем Session-based desktop deployment, так как планируется развертывание серверов сеансов, а не серверов инфраструктуры VDI 

На этапе выбора ролей RDS нас предупредят о том, что будет выполняться развертывание сразу трёх ролей —  RD Connection Broker, RD Session Host, RD Web Access, не оставляя при этом нам никакого выбора…

На этапе выбора серверов для роли RD Connection Broker выбираем один сервер, ибо мастер не даст нам выбрать более одного сервера. Так как всю первоначальную настройку мы выполняем на сервере KOM-AD01-RDS21, то соответственно и выберем его для этой роли…

На этапе выбора серверов для роли RD Web Access включим опцию Install the RD Web Access role on the RD Connection Broker server для того чтобы эта роль была установлена на тот же сервер, который был выбран для роли RDCB. Выбирать какой-то другой сервер в нашей ситуации особого смысла нет, да и потом мастер опять таки не даст нам выбрать для установки этой роли более чем один сервер…

На этапе выбора серверов для роли RD Session Host мы сможем выбрать все сервера…

 
На странице подтверждения мы видим предупреждение, что серверы могут быть перезагружены после установки роли RD Session Host. Включим опцию автоматической перезагрузки серверов — Restart the destination server automatically if required и запустим процесс развёртывания..

В процессе установки ролей первым будет автоматически перезагружен сервер, с которого мы запустили весь этот процесс, поэтому мы отвалимся от его консоли. Пугаться не надо… После того, как система поднимется из перезагрузки, снова залогинимся и запустим консоль Server Manager, где через несколько секунд автоматически запустится мастер развертывания ролей RDS и мы сможем убедиться в том, что процесс развертывания успешно прошёл до конца на всех серверах.

В нашем примере мастер сообщил о том, что на двух серверах из пяти не удалось установить службу RDSH, хотя последующая проверка этих серверов свидетельствовала об обратном. В системном журнале Applications and Services Logs > Microsoft > Windows > ServerManager-DeploymentProvider > Operational было зарегистрировано событие говорящее об успешной установке компонент…

Ну и соответственно PS-запрос состояния компонент RDS показывал что роль RDSH установлена..

В любом случае если Server Manager упорно будет говорить вам о том, что роль RD Session Host не установлена на каких-то серверах, то для того чтобы заставить её «прокашляться», можно повторить процедуру установки через мастер добавления ролей RDS на вкладке управления службами Remote Desktop Services > Overview

Создаём высоко-доступный RD Connection Broker

После окончания процесса установки ролей в консоли Server Manager и перейдём на вкладку управления службами Remote Desktop Services > Overview, чтобы приступить к созданию отказоустойчивой конфигурации RD Connection Broker.

На схеме инфраструктуры RDS выберем изображение роли RD Connection Broker и правой кнопкой мыши вызовем меню, в котором выберем пункт Configure High Availability.

Запустится мастер создания высоко-доступного экземпляра RDCB, где нас предупредят о необходимых условиях, которые мы уже предварительно выполнили, за исключением последнего пункта, который предполагает создание в DNS A-записей c одинаковым FQDN именем RDCB и IP адресами всех серверов (для работы механизма Round Robin). Откажемся от концепции использования DNS Round Robin для получения клиентами имени точки подключения к ферме RDCB. Вместо этого мы будем использовать имя созданного ранее NLB кластера.

На следующем шаге мастера Configure High Availability заполняем значения трёх полей:

Database connection string – строка подключения к БД SQL Server. Значение должно иметь вид: DRIVER=SQL Server Native Client 11.0 (10.50 для SQL Server 2008 R2);SERVER=<FQDN-Имя или SQL-Alias сервера SQL Server>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<Имя БД>

В нашем случае это значение будет иметь следующий вид:

DRIVER=SQL Server Native Client 11.0;SERVER=KOM-AD01-SQL-RDCB.holding.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDS_ConnectionBroker

Folder to store database files — путь ранее подготовленного каталога U:SQLData_SQL01_RDCB на кластерном диске SQL сервера. В этом каталоге будут размещены файл данных и лога транзакций SQL Server при создании БД RDCB.

DNS round robin name – имя точки подключения клиентов. Как я уже сказал, здесь предполагается ввод значения FQDN-имени созданного в DNS с несколькими A-записями. В нашем примере, в качестве такого имени, мы будем использовать имя созданного ранее NLB кластера – KOM-AD01-RDSNLB.holding.com

Далее мы получим предупреждение о том, что указанное нами имя DNS RR имеет отличный IP адрес от того, для которого выполняется установка HA RDCB. Мы идём на этот шаг намеренно и поэтому соглашаемся…

Дожидаемся успешного окончания процесса конфигурирования высокой доступности.

В ходе этого процесса на SQL-сервере будет создана БД высоко-доступного экземпляра RDCB.

***

Переключимся на наш SQL Server с только что созданной БД и выполним пару настроек…

В обязательном порядке для SQL-логина, который мы создавали на подготовительном этапе (KOM-AD01-RDS-Connection-Broker-Computers), нужно дать роль db_owner для созданной базы RDS_ConnectionBroker

Помимо этого, для данного SQL-логина можно отключить добавленную ранее серверную роль dbcreator, так как БД уже создана и больше данная привилегия этому SQL-логину не потребуется.

Если резервное копирование баз данных SQL Server выполняется такими инструментами как например SC 2012 DPM, то при желании мы можем поменять модель восстановления созданной БД (Recovery Model) c Full на Simple.

***

Вернёмся на наш сервер KOM-AD01-RDS21 и обратим внимание на то, что в консоли Server Manager в схеме инфраструктуры RDS статус роли RDCB поменялся на High Availability Mode

Теперь для того чтобы задуманная нами связка NLB + RDCB работала так как нужно, нам необходимо до-установить роль RD Connection Broker на оставшиеся четыре сервера.

Добавляем сервера в высоко-доступный RD Connection Broker

Добавление серверов к высоко-доступной конфигурации RDCB делается через то же самое контекстное меню в схеме развертывания RDS на странице Overview.

В открывшемся мастере добавляем следующий сервер (мастер также не даст добавить более одного сервера)

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

Аналогичным образом мы по одному серверу должны добавить роль HA RDCB на все оставшиеся сервера, те. KOM-AD01-RDS23, KOM-AD01-RDS24 и KOM-AD01-RDS25.

Добавляем на сервера роль RD Web Access

Так как мы хотим иметь отказоустойчивую конфигурацию роли RD Web Access, нам нужно до-установить эту роль на оставшиеся четыре сервера (на KOM-AD01-RDS21 эта роль уже установлена). Делаем это в уже знакомом нам месте через мастер добавления ролей

Здесь уже мы сможем выбрать сразу все серверы и выполнить установку роли RDWA оптом…

Создаём коллекцию сеансов – Session Collection

Все наши сервера с ролью RD Session Host мы должны объединить в логическую единицу – коллекцию сеансов (Session Collection). Делаем это в оснастке Server Manager на вкладке Remote Desktop Services > Collections выбрав задачу Create Session Collection в таблице перечисления коллекций.

В открывшемся мастере создания коллекции зададим имя коллекции и при желании описание

Затем выбираем все сервера, которые хотим сделать членами коллекции…

Далее мы должны определить доменную группу безопасности которой будет разрешено подключаться к коллекции сеансов. Убираем выбранную по умолчанию группу доступа Domain Users и добавляем специально созданную группу доступа, в нашем случае KOM-AD01-RDS-AllUsers, ограничив тем самым круг пользователей которые смогут подключаться к серверам коллекции.

На следующем шаге определяемся с тем, хотим ли мы использовать новую технологию Windows Server 2012 – User profile disks (UPD), которая, как я понял, предлагается в качестве альтернативы механизму перемещаемых профилей — Roaming User Profiles. Новая технология подразумевает централизованное хранение файлов пользователя в отдельных VHD дисках, которые располагаются где-то на выделенном файловом ресурсе. В силу того, что на данный момент нет уверенности в стабильности работы данного механизма из-за полученной информации в обсуждении Windows Server 2012 RDS — [User Profile Disk] VS [Roaming Profiles + Folder Redirection] я решил пока не использовать данный функционал и поэтому он не будет рассмотрен в данной заметке.

А пока не будут разрешены имеющиеся на данный момент проблемы с UPD будем использовать связку технологий Roaming User Profiles и Folder Redirection, настройка которых рассматривалась ранее в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки 

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

Настраиваем цифровые сертификаты

При попытке подключения к ферме RD Connection Broker по FQDN-имени кластера NLB клиенты могут получать предупреждение безопасности, говорящее о том, что нет доверия сертификату того сервера сеансов, на который он был перенаправлен. Если открыть свойства этого сертификата, мы увидим, что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным. Чтобы избежать таких предупреждений нам нужно создать для развёртывания RDS сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС. Этот сертификат после создания мы развернём на всех серверах фермы.

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

Client Authentication (1.3.6.1.5.5.7.3.2)
Server Authentication (1.3.6.1.5.5.7.3.1)

Хотя в нашей ситуации альтернативные имена в сертификате Subject Alternative Name (SAN) иметь вовсе необязательно, я всё-таки рассмотрю вариант создания именно такого сертификата, то есть чтобы помимо имени NLB кластера в сертификате содержались имена отдельных серверов.

Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. О том как это сделать можно прочитать в заметке Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker

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

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

[Version]
Signature="$Windows NT$"

[NewRequest] 
Subject = "CN=KOM-AD01-RDSNLB.holding.com" ; 
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.2 ; Client Authentication 
  
[RequestAttributes] 
SAN  = "dns=KOM-AD01-RDSNLB.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS21.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS22.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS23.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS24.holding.com&" 
_continue_ = "dns=KOM-AD01-RDS25.holding.com&" 
_continue_ = "dns=KOM-AD01-RDSNLB&" 
_continue_ = "dns=KOM-AD01-RDS21&" 
_continue_ = "dns=KOM-AD01-RDS22&" 
_continue_ = "dns=KOM-AD01-RDS23&" 
_continue_ = "dns=KOM-AD01-RDS24&" 
_continue_ = "dns=KOM-AD01-RDS25&"

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

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

Выполнять эту команду надо локально на сервере RDS. В нашем случае команда выполняется на сервере KOM-AD01-RDS21. После выполнения команды откроем консоль управления локальными сертификатами (mmc.exe > Add/Remove snap-in > Certificates > Add > Computer account) для хранилища Local Computer и убедимся в появлении ожидающего запроса в разделе Certificate Enrollment Request

Полученный файл запроса RequestFile.req добавляем в локальный центр сертификации через консоль управления Certification Authority (certsrv.msc) (All Tasks > Submit new request)

Затем в этой же консоли в разделе Pending Requests проверяем наш добавленный запрос и разрешаем выдачу сертификата по нему (Выбираем запрос > All Tasks > Issue )

Переходим в раздел выданных сертификатов — Issued Certificates, находим сертификат, открываем его свойства и на закладке Details вызываем мастер экспорта сертификата (Copy to File)

В открывшемся мастере выбираем формат экспорта DER X.509 и сохраняем файл например с именем NLBCert.cer

Скопируем полученный файл NLBCert.cer на сервер RDS, где мы создавали запрос на сертификат (KOM-AD01-RDS21) и вернёмся в консоль управления локальными сертификатами этого сервера. Выберем хранилище Personal > Certificates и вызовем мастер импорта сертификатов (All Tasks > Import)

В мастере импорта автоматически будет выбрано хранилище Local Machine

Далее выберем импортируемый файл сертификата NLBCert.cer и укажем раздел хранилища PersonalRegistry. Чтобы этот раздел был доступен для выбора, нужно включить опцию Show physical stores.

После того как импорт сертификата выполнен, убеждаемся что он появился в соответствующем хранилище и с ним связан его закрытый ключ (присутствует значок ключика на иконке). При этом в разделе Certificate Enrollment Request информация о запросе должна исчезнуть.

Далее выбираем установленный сертификат и вызываем мастер экспорта (All Task > Export). В мастере экспорта выбираем опцию экспорта закрытого ключа при экспорте сертификата – Yes, export the private key

В качестве формата экспорта используем единственно возможный и нужный нам формат .PFX

Далее задаем пароль (он потребуется нам в дальнейшем для назначения этого сертификата в развёртывании RDS)

После того как сертификат экспортирован, переходим в консоль Server ManagerRemote Desktop ServicesOverview и на схеме развёртывания в списке задач выбираем пункт редактирования развёртывания (TASKS > Edit Deployment Properties)

На вкладке Certificates используем кнопку Select existing cerificates для того чтобы назначить сделанный нами сертификат для той или иной роли RDS…

В окне выбора сертификата определяем, что мы хотим использовать файл PFX полученный нами ранее и задаём пароль с которым этот сертификат был экспортирован. Хотя опция Allow the certificate to be added to the Trusted Root CA нам по сути не нужна, так как созданный нами сертификат сделан в ЦС, которому предположительно все наши сервера уже доверяют, её всё таки придётся отметить, так как если она не отмечена, кнопка OK недоступна…

После закрытия этого окна по ОК, мы увидим что в таблице статус сертификата изменился на Ready to apply..Нажмём кнопку Apply и через несколько секунд наш сертификат будет назначен роли соответствующей RDS. Описанным методом мы выполним привязку сертификатов ко всем развёрнутым у нас ролям и в конечном итоге получим примерно следующий вид:

Назначенные нами сертификаты будут автоматически установлены на все сервера, которые участвуют в нашем RDS развёртывании.

Настраиваем веб-узлы RD Web Access

По умолчанию при обращении в стартовой веб-странице RDWA от пользователя в явном виде требуется ввод учетной записи и пароля. Если мы используем RDWA для доменных пользователей внутри локальной сети, то для удобства нам нужно будет задействовать механизм прозрачного входа Single sign-on (SSO) при обращении к веб-узлу RDWA. Для этого на каждом сервере с установленной ролью RDWA в оснастке IIS Manager откроем свойства веб-приложения RDWeb > Pages выберем в разделе настроек пункт Authentication…выключим анонимную аутентификацию (Anonymous Authentication), аутентификацию на основе формы (Forms Authentication) и включим Windows Authentication:

***

После входа на веб-страницу RDWA можно обнаружить уже знакомый нам по предыдущей версии опцию I am using a private computer that complies with my organization’s security policy (в русском варианте — Я использую личный компьютер, соответствующий политике безопасности моей организации).

Ранее, в заметке RDS Web Access – Опция «Я использую личный компьютер…», я писал о том, как выставить эту опцию во включенное состояние по умолчанию, чтобы избежать повторного запроса аутентификации при подключении к опубликованным приложениям RemoteApp в Windows Server 2008 R2. Это рецепт работает и для Windows Server 2012.

***

Верхняя часть страниц RDWA по умолчанию оформлена в виде заголовочной надписи Work Resources и изображения размером 48*48 пикселей.

Для того чтобы заменить заголовочную надпись можно использовать командлет PowerShell (один раз для всей коллекции серверов):

Set-RDWorkspace -Name "Приложения RemoteApp" -ConnectionBroker KOM-AD01-RDS21.holding.com

 

Для того чтобы заменить имеющееся изображение на другое, например с корпоративной символикой, можно внести корректировки в файл %windir%WebRDWebPagesSite.xsl – найти секцию с комментарием «Replaceable Company Logo Image«…

… и заменить ссылку на файл изображения, указав собственный файл размещённый в соответствующем подкаталоге %windir%WebRDWebPagesimages

В результате мы получим примерно следующий вид верхней части страниц RDWA:

Настраиваем Roaming User Profiles и Folder Redirection

Так как пользователи нашей фермы RDS от сеанса к сеансу могут попадать на разные сервера, нам необходимо обеспечить идентичность пользовательской среды на всех этих серверах. Для этого мы будем использовать механизмы перемещаемых профилей (Roaming User Profiles ) и перенаправления папок (Folder Redirection). Для настройки этих механизмов настраиваем групповую политику применяемую к серверам нашей фермы RDS. Здесь мы не будем рассматривать эту процедуру, так как она уже была ранее описана мной в заметке Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки

Публикуем приложения RemoteApp

Чтобы опубликовать в ферме RDS приложения RemoteApp переходим в консоль Server Manager в раздел Remote Desktop Services > Collections > выбираем нашу коллекцию KOM-AD01-RDSH-COLL и публикуем необходимые приложения в окне REMOTEAPP PROGRAMS. В меню задач выбираем пункт публикации TASKS > Publish RemoteApp Programs

Для примера опубликуем два простых приложения Calculator и WordPad

 
Опубликованные приложения доступны клиентам нашей фермы RDS двумя основными способами – через веб-интерфейс RD Web Access и через непосредственную доставку ярлыков запуска на клиентские компьютеры. С первым способом, полагаю, всё итак понятно, рассмотрим второй. Для того чтобы ярлыки опубликованных приложений RemoteApp стали доступны на клиенте с Windows 7/8, нужно выполнить подписку на узел RDWA в Панели управления (апплет Подключения к удаленным рабочим столам и приложениям RemoteApp). Щелкнув по ссылке Доступ к удалённым приложениям RemoteApp и рабочим столам мы вызовем мастер подключения, где в адресной строке укажем URL RDWA в формате http://KOM-AD01-RDSNLB.holding.com/RDWeb/Feed/WebFeed.aspx

В примерах описанных в окне подключения можно заметить вариант с указанием адреса, похожего на адрес электронной почты —  alexeyo@contoso.com. На самом деле такой метод указания адреса не столько имеет отношение к электронной почте, сколько относится к методу автоматического обнаружения сервера публикации RemoteApp с помощью специальных записей в зоне прямого просмотра DNS. То есть мастеру подключения важно лишь то, что указано после символа @ – имя зоны DNS. До символа @ можно написать любую ерунду. Например, в нашем примере в DNS используется зона holding.com и в качестве адреса мы можем указать например blablabla@holding.com

В зоне DNS соответственно при использовании такого метода должна быть создана специальная запись формата TXT c именем _msradc и текстовым значением в формате https://rds.domain.com/rdweb/feed 
Соответственно в нашем примере запись будет иметь следующий вид:

После того как запись создана, проверим то, что DNS сервер возвращает нам значение этой записи с помощью утилиты nslookup в режиме set querytype=TXT и если всё в порядке, то теперь в качестве адреса подключения можем указать соответствующее значение

При этом из DNS будет возвращён URL-адрес подключения…

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

При этом в меню “Пуск” для Windows 7 и в стартовом экране для Windows 8 в отдельной группе появятся ярлыки на запуск приложений RemoteApp

Если вам потребуется каким-то альтернативным способом распространять ярлыки на приложения RemoteApp, то их можно будет найти на клиентской машине подключённой вышеописанным способом к точке публикации RDWA в каталоге
%APPDATA%MicrosoftWorkspaces{GUID}Resource

Нововведением Windows 8 стал ещё один способ подключения клиентов к точке публикации – с помощью групповых политик (GPO). За это отвечает параметр
Specify default connection URL в разделе User Configuration/Policies/Administrative Templates/Windows Components/Remote Desktop Services/RemoteApp and Desktop Connections. Для настройки клиентов нужно включить этот параметр и указать значение URL-адреса подключения в формате:
https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx

Как я уже сказал, этот параметр поможет нам настроить только клиентов Windows 8, но если у вас есть сильное желание раздать через GPO настройку и для клиентов Windows 7 – читайте статью Concurrency Blog — How to deliver RemoteApps from Windows Server 2012 RDS. Метод заключается в применении на клиентских машинах PowerShell скрипта Configure RemoteApp and Desktop Connection on Windows 7 Clients с передачей ему в виде параметра файла настроек в следующем формате:

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<workspace name="Enterprise Remote Access" xmlns="http://schemas.microsoft.com/ts/2008/09/tswcx" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<defaultFeed url="https://KOM-AD01-RDSNLB.holding.com/rdweb/Feed/webfeed.aspx" />
</workspace>

Устанавливаем языковой пакет

Так как в нашем примере на серверах фермы RDS используется англоязычная система, нам потребуется установка языкового пакета для локализации интерфейса пользователя. Чтобы получить файлы русского языкового пакета распаковываем образ содержащий все языковые пакеты для Windows Server 2012 RTM SW_DVD5_NTRL_Win_Svr_Language_Pack_2012_64Bit_MultiLang_FPP_VL_OEM_X18-27741.ISO

Извлекаем файл langpacksru-rulp.cab из состава образа и вызываем на сервере RDS мастер установки языковых пакетов командой lpksetup

Помимо этого установку языкового пакета можно выполнить командой:

Dism /online /Add-Package /PackagePath:"C:DistributivesWS2012RTMLanguagePacklp.cab"

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

Далее открываем апплет панели управления Control Panel > Region (intl.cpl) , проверяем и при необходимости настраиваем параметры на родной язык на закладках Formats и Locations , а затем на закладке Administrative нажимаем Copy settings, чтобы скопировать языковые предпочтения текущего пользователя для всех пользователей которые будут первый раз входить в эту систему.

Убедимся что у текущего пользователя установлены такие настройки, которые мы хотим иметь у всех пользователей сервера RDS и включим галочку New user accounts

Не рекомендую использовать опцию копирования русских настроек в системный профиль (галка Welcome screen and system accounts), так как это в перспективе может привести к невменяемой работе некоторых “буржуйских” программ, проблемы в которых возникают чаще всего из-за знака разделителя целой и дробной части.

Настраиваем перенаправление печати

Для того чтобы пользователи служб удалённых рабочих столов смогли выполнять печать на перенаправленные с их клиентских мест устройств печати, выполним ряд нехитрых манипуляций.
Установим на сервера RDS консоль управления службой печати – Print Management, например с помощью PowerShell:

Add-WindowsFeature RSAT-Print-Services

Если есть сильное желание управлять службой печати на всех серверах например с рабочей станции Администратора, то для того, чтобы можно было удалённо подключаться к службе печати, на серверах необходимо включить параметр групповой политики Allow Print Spooler to accept client connections в разделе Computer ConfigurationPoliciesAdministrative TemplatesPrinters. После применения политики на серверах нужно перезапустить службу очереди печати — Print Spooler.
На мой взгляд использовать локально установленную на серверах консоль – более предпочтительно.

После установки открываем консоль, добавляем в неё наши сервера, и в свойствах сервера печати для каждого сервера выполняем необходимые изменения настроек, например на закладке Advanced отключаем включённые по умолчанию оповещения сетевых и локальных принтеров…

К слову об использовании именно локальной консоли…эти две опции недоступны для изменения (попросту не видны) если вы подключаетесь консолью удалённо.

На закладке Drivers добавляем драйвера принтеров, которые используются для печати на клиентских компьютерах. Драйвера принтеров нужно добавлять исходя из принципа разумного минимума. Например вместо того чтобы для принтеров Hewlett-Packard добавлять несколько драйверов для конкретных моделей лучше добавить один универсальный драйвер HP Universal Print Driver (UPD), в случае если принтеры поддерживают работу на данном драйвере. В нашем примере используется текущая версия (на момент написания этой заметки) UPD совместимая с Windows Server 2012 — 5.6.5.15717. Разумеется добавлять драйвера производителей оборудования вообще имеет резон только в том случае если тесты показывают, что принтер не выполняет поставленные задачи печати на драйвере Remote Desktop Easy Print.

В конфигурации по умолчанию для принтеров перенаправляемых с пользовательских компьютеров система будет использовать драйвер Remote Desktop Easy Print. Если мы загружаем на сервера RDS драйвера производителей принтеров, как например тот же HP UPD, то возможно нам стоит переопределить такое поведение, то есть, чтобы приоритетным для использования считался драйвер вендора железки, а уж если его не удалось найти – использовать RD Easy Print. Задаётся это параметром групповой политики Use Remote Desktop Easy Print printer driver first = Disabled в разделе Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemote Desktop Session HostPrinter Redirection

После применения GPO в пользовательской терминальной сессии проверяем какой драйвер был назначен для перенаправленного принтера…

На этом, в целом, можно считать, что мы выполнили основные этапы создания и настройки отказоустойчивой фермы RD Connection Broker на базе Windows Server 2012. В отдельной следующей заметке мы рассмотрим пример настройки пользовательского интерфейса на сервера RD Session Host.

Полезные ссылки по теме:

Remote Desktop Services Blog — RD Connection Broker High Availability in Windows Server 2012
VirtualizationAdmin.com — Taking a closer look at RD Connection Broker High Availability in Windows Server 2012
TechNet Articles  —  RD Connection Broker HA – SQL Permissions
Freek Berson Blog — RD Connection Broker HA and the RDP properties on the client
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 1)
Blog Working Hard In IT — Reflections on Getting Windows Network Load Balancing To Work (Part 2)