В данной статье я приведу подробную пошаговую инструкцию по установке сервера терминалов (англ. terminal server), или по другому, службы удаленных рабочих столов в Windows Server 2012. В принципе, последовательность действий не сильно отличается от установки , однако есть ряд значимых отличий. Итак:
Запускаем Диспетчер серверов. Его можно запустить с ярлыка на панели задач, или же выполнив команду 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 ) для завершения работы мастера.
Теперь запустим «» (RD Licensing Diagnoser) . Сделать это можно из диспетчера серверов, выбрав в правом верхнем меню «Средства » (Tools ) — «Terminal Services » — «Средство диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) .
Здесь мы видим, что доступных лицензий пока нет, т. к. не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов.
Сервер лицензирования указывается теперь в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc .
Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:
Откроем параметры «Использовать указанные серверы лицензирования удаленных рабочих столов » (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) оставив включенным флаг «Запустить мастер установки лицензий » .
Затем выбираем необходимую вам программу лицензирования. В моем примере это «Соглашение «Enterprise Agreement «» . Жмем «Далее » (Next) .
Указываем версию продукта, тип лицензии и количество лицензий в соответствии с вашей программой лицензирования. Жмем «Далее » (Next) .
Ну и дожидаемся завершения работы мастера установки лицензий с сообщением о том, что запрошенные лицензии успешно установлены.
В диспетчере лицензирования убеждаемся, что сервер работает, а также видим общее и доступное число установленных лицензий.
Ну и наконец возвращаемся в «Средства диагностики лицензирования удаленных рабочих столов » (RD Licensing Diagnoser ) и видим, что ошибок нет, а число лицензий, доступных клиентам, соответствует тому, что мы вводили на предыдущем шаге.
На этом установка сервера терминалов в Windows Server 2012 завершена.
Для подключения к серверу терминалов можно использовать встроенный в Windows клиент .
Помогла ли Вам данная статья?
Remote Desktop Connection Broker (RD Connection Broker), ранее известный под именем Terminal Services Session Broker (TS Session Broker), — это роль сервера Windows 2008 R2, предоставляющая следующий функционал:
RD Connection Broker отслеживает все сессии пользователей в ферме терминальных серверов Windows Server 2008 R2. База данных RD Connection Broker хранит сессионную информацию, включая имена серверов RD Session Host, на которых находятся сессии пользователя, идентификатор сессии (session ID) и имя пользователя, ассоциированное с сессией. Служба RD Connection Broker использует эту информацию для перенаправления пользователя, уже имеющего активную терминальную сессию на тот сервер, на котором она запущена.
В том случае, если пользователь отключился (disconnect) от своей сессии (из-за сетевого сбоя или осознанно), все приложения, которые он запустил на сервере продолжают работать. И когда пользователь пытается вновь подключиться к ферме терминалов, Connection Broker определяет сервер, на котором уже имеется сессия пользователя и перенаправляет подключение пользователя именно туда.
Балансировка нагрузки RD Connection Broker Load Balancing, позволяет при подключении пользователя (предполагается, что у него не осталось подключений в состоянии disconnect) к ферме, перенаправить его на наименее загруженный сервер фермы (с наименьшим количеством пользовательских сессий). Чтобы более гибко управлять балансировкой нагрузки в ферме терминальных серверов, администратор может в зависимости от вычислительных мощностей серверов фермы назначить каждому из них относительный вес.
Для построения фермы терминальных серверов с балансировкой нагрузки нужны два компонента:
Сервер RD Connection Broker . Это сервер с запущенной службой Remote Desktop Connection Broker, который отслеживает сессии пользователей и осуществляет балансировку нагрузки между членами фермы RD. Существует имя сервера RD Connection Broker, с помощью которого можно отнести конкретный терминальный сервер к той или иной ферме.
Сервера RD Session Host , настроенные на использование Connection Broker. Это рядовые члены терминальной фермы. Для того, чтобы являться членом фермы под управление RD Connection Broker, терминальный сервер должен соответствовать следующим критериям:
Если роль Remote Desktop Services уже установлена:
В моем стенде 2 сервера, настроенных следующим образом:
RDS01
Для этого на сервер с установленной ролью RD Connection Broker :
На каждом из терминальных серверов RD Session Host выполните следующее:
Я выполнил соответствующую настройку на обоих серверах RDS01 и RDS02
Для балансировки нагрузки в терминальных фермах RD Session Host, можно использовать балансировку нагрузки RD Connection Broker Load Balancing совместно с функцией DNS round robin. Во втором случае, вы должны для каждого из серверов членов фермы создать DNS запись (тип A), создающую соответствие между IP адресом каждого сервера RD Session Host и DNS именем фермы.
Я опишу процедуру настройки DNS записей на контроллере домена Windows Server 2008 R2. Сразу стоит отметить, что для выполнения данной процедуры у вас должны быть права Domain Admins/ Enterprise Admins / DNS Admins.
Эти действия необходимо повторить для каждого из серверов-членов фермы RDS (в каждом случае меняться будет только ip адрес)
Проверим, что наша ферма создалась, для чего откройте Remote Desktop Services Manager. Щелкните правой кнопкой по Remote Desktop Services Manager и выберите Import from RD Connection Broker и укажите FQDN имя сервера с ролью Connection broker(в моем случае RDS01.сайт)
Теперь в дереве RD Connection Broker появится новая терминальная ферма!
Данная статья написана в рамках общего описания настройки терминальных служб в Windows server 2012. Центральная статья с описанием .
Отказоустойчивость в RDS
Давайте подумаем, из чего может складываться отказоустойчивость работы в опубликованных приложениях при использовании терминальных служб.
Отказоустойчивость серверной части можно обеспечить на двух уровнях:
Клиентское устройство , очевидно, что это должен быть тонкий клиент, на котором не хранится никакой информации, только базовые настройки подключения. Он должен уметь подключаться к терминальному серверу (серверам) по RDP протоколу и отображать на экране монитора удаленный рабочий стол или опубликованные приложения. Таких тонких клиентов сейчас на рынке очень много, от недорогих китайских (3000 руб) до дорогих брендовых на платформе Windows Embedded (до 20 000 руб). Я предлагаю использовать вот такие решения — , .
Распределение нагрузки и отказоустойчивость
. Если клиент будет подключаться напрямую к терминальному серверу (точка-точка), то в такой схеме не будет никакой отказоустойчивости. Выходит из строя сервер — работа встает. Нужно несколько терминальных серверов с одинаковым функционалом, чтобы при поломке первого клиент мог бы продолжить работу на втором, третьем и т.д. Для этого устанавливают посредник подключения к удаленными рабочим столам. В 2012 сервере (и ранее в 2008) в этой роли выступает RD connection broker – это роль, которую можно добавить через мастер добавления ролей в диспетчере сервера. Посредник подключений в первую очередь распределяет нагрузку
между терминальными серверами, отправляет пользователей на тот сервер терминалов, на котором в данный момент меньше пользователей.
Для отказоустойчивости роль посредника устанавливали на два сервера, затем объединяли их в кластер, если в Windows server 2008 Broker работал по схеме Active – Passive, т.е. один из серверов посредника, находясь в простое, ждал, пока откажет основной, то в 2012 эта схема улучшена (переработана) и работает как Active –Active кластер. Клиенты поочередно обращаются то к одному, то к другому Connection Broker (за счет работы службы DNS Round Robin), который уже указывает на терминальный сервер к которому ему следует подключаться.
Но есть одно НО
, для работы в отказоустойчивом режиме Connection Broker использует базу данных MSSQL. По логике отказоустойчивости нужно и ее дублировать, создавать кластер, а это еще больше усложнит схему.
Не забываем, про доменные службы, которые должны обеспечивать аутентификацию пользователей, DNS сервер должен разрешать имена, без этого наши терминальные службы тоже работать не будут.
В итоге, для отказоустойчивой схемы потребуется как минимум два сервера с Ролью Connection Broker, два терминальных сервера, два MSSQL сервера, два контроллера домена и два DNS сервера. Плюс два сервера, на которых будут хранениться профили пользователей. Общая папка, в которой они будут храниться, должна реплицироваться между двумя серверами.
Теперь я задам вопрос: » Стоит ли городить такой огород из разнообразных служб Microsoft? Может быть есть другой способ?»
Думаю, что есть. Не создаем кластеры из MSSQL, контроллеров доменов, DNS серверов, а используя технологии виртуализации, реплицируем виртуальные машины на другой физический сервер и не забываем делать резервное копирование. Но такая схема потребует вмешательства администратора при сбое, он должен будет удостовериться, что основные виртуальные машины вышли из строя и в ручном режиме запустить реплики.
Итак, мы хотим добиться балансировки нагрузки на наши терминальные сервера, их отказоустойчивость, или же хотим добавить к уже имеющемуся терминальному серверу второй для увеличения производительности сервиса. В моем примере я буду реализовывать следующую схему:
Как мы видим, для реализации такой схемы нам понадобится три сервера. Причем, роль Брокера можно установить на уже имеющийся у нас сервер, например, на файловый или сервер печати. Для наглядности назовем наши сервера следующим образом:
Как мы видим, имя нашего домена – domain.local. Для доступа к терминальным службам снаружи будет использоваться доменное имя domain.ru. Таким образом, в нашем DNS домена domain.local нам необходимо будет создать дополнительную зону с именем domain.ru, где мы потом создадим запись RDS.domain.ru, которая будет ссылаться на IP адрес терминальной фермы.
На закладке Digital Signature указываем сертификат, который надо предварительно запросить. Для выполнения этого шага в вашем домене должен быть центр сертификации (CA). На сервере RDS1 запустите mmc и добавьте оснастку Certificates (computer account):
Теперь на закладке Digital Signature мы можем указать наш сертификат:
Нажмем кнопку «Properties» и добавим в список пользователей, которые смогут запускать наш Калькулятор, группу rd_users.
На закладке Private Key не забудьте указать, что ключ может быть экспортирован.
После получения сертификата экспортируйте его в pfx-файл – он нам понадобится для настройки второго сервера.
Теперь указываем этот сертификат в свойствах нашего шлюза удаленных рабочих столов:
Переходим на закладку Server Farm, где добавим наш сервер RDS1 в ферму шлюзов:
Обратите внимание, что на данном этапе поле статус не обязательно должно иметь состояние «ОК».
Нажимаем на кнопку «Select» и указываем сертификат с Common Name нашей фермы – RDFarm.domain.local (он уже был установлен на сервер в пункте 1.4).
Остальные параметры не настраиваем.
Здесь же, в RD Session Host Configuration, настраиваем параметры лицензирования.
Узел сеансов удаленных рабочих столов (Remote Desktop Session Host)
Шлюз удаленных рабочих столов (Remote Desktop Gateway)
Веб-доступ к удаленным рабочим столам (Remote Desktop Web Access)
Сервер политики сети (NPS)
При установке служб ставим галочку «Require NLA», остальные настройки сконфигурим позже. Перезагружаем сервер при первом же требовании.
Укажите путь к pfx файлам, содержащим сертификаты, и импортируйте их в личные сертификаты компьютера RDS2.
3.1 Устанавливаем роль RD Connection Broker на сервер BROKER.
3.2 Добавляем сервера RDS1 и RDS2 в локальную группу Session Broker Computers на сервере BROKER.
3.3 Добавляем все наши три сервера в локальную группу TS Web Access Computers на серверах RDS1 и RDS2
3.4 На сервере BROKER добавляем наши сервера RDS1 и RDS2 в группу RD Web Access (Admin Tools > Remote Desktop Services > Remote Desktop Connection Manager > Add RD Web Access Server).
3.5 Сперва на сервере RDS1, а затем и на RDS2, заходим в Remote Desktop Services > Remote Desktop Session Host Configuration и меняем настройки RD Connection Broker:
Добавляем все наши возможные ресурсы RemoteApp: RDFarm.domain.local, RDS1.domain.local, RDS2.domain.local и RDS.domain.ru.
Включаем в балансировку только 443 и 3389 TCP порты.
3.9 Удостоверяемся, что на серверах RDS1 и RDS2, в свойствах сервера RD Gateway Manager на закладке Server Farm указаны оба наших сервера:
Вначале необходимо установить наш сертификат с Common Name «RDS.domain.ru» на ISA сервер (сделать это можно так же, как в случае с сервером RDS2, когда мы переносили на него сертификат с RDS1).
Этот раздел я не буду рассматривать слишком подробно, а обойдусь лишь наиболее важными скриншотами с настройками правила публикации и созданием WEB-прослушивателя:
Спасибо за внимание.
Remote Desktop Connection Broker (RD Connection Broker) – это функционал роли терминального сервера Windows Server. RD Connection Broker позволяет равномерно распределить нагрузку между серверам в ферме Remote Desktop (при подключении к RDS пользователя перенаправляет на наименее загруженный сервер), обеспечить доступ пользователей к VDI и RemoteApp, а также реализует возможность переподключения пользователей к своим сессиям (при подключении к новому серверу RDS, RDCB проверяет наличие незавершенной сессии на других серверах фермы, и в случае ее обнаружения новая сессия не создается, а пользователь перенаправляется в старую сессию).
В этой статье мы рассмотрим процесс настройки отказоустойчивого высоко-доступного экземпляра RD Connection Broker , обеспечивающего свой функционал при выходе из строя одного из серверов с ролью RDCB.
В отличии от реализации , Connection Broker в Windows Server 2012 обеспечивает высокую доступность в режиме Active/Active, когда каждый из серверов RDCB является активным и обрабатывает входящие запросы. Это позволяет обеспечить высокую доступность и масштабируемость RDCB в больших фермах Remote Desktop. Для хранения данных RDCB используется БД на MS SQL Server.
Примечание . В Windows Server 2008 R2 поддерживалась кластеризация службы RDCB только в режиме Active/Passive. Т.е. для фермы RD серверов поддерживался только один активный сервер Connection Broker.
Требования для внедрения отказоустойчивого RDCB
Важно . Перед началом создания отказоустойчивой конфигурации RDCB, убедитесь, что эта роль установлена только на одном из серверов.
Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и включить в домен Active Drectory.
В Active Directory создадим отдельную группу безопасности RDS Connection Brokers , в которую нужно включить все сервера RDCB.
Далее на отдельном сервере (или SQL-кластере) устанавливается SQL Server версии 2008 R2 или 2012 Standard.
На SQL сервере с помощью SQL Server Management Studio в разделе Security нужно создать новый login и предоставить доменной группе RDCB права с возможностью создания и редактирования баз данных. Также этой группе нужно предоставить полные права на каталог установки SQL.
На SQL сервере нужно создать каталог, в котором будут храниться файлы БД, например, C:\SQLDB , и предоставить этой же группе полные права на каталог.
На всех серверах с ролью RDCB необходимо установить. Его нужно скачать отдельно с сайта MS, либо запустить прямо с установочного диска (на установочном диске SQL Server 2012 он хранится в каталоге \1033_ENU_LP\x64\Setup\x64\sqlncli.msi).
Для SQL server 2008 R2 нужен SQL native client 10, для SQL Server 2012 — SQL Native client 11.
В брандмауэра SQL-сервера создадим новое правило, открывающее порт TCP 1433 для доменных машин. Сделать это можно так:
netsh advfirewall firewall add rule name = SQLSRVPort dir = in protocol = tcp action = allow localport = 1433 remoteip = localsubnet profile = DOMAIN
Следующий шаг – создание в DNS зоне A записей для реализации балансировки нагрузки (Round Robin) между серверами RD Connection Broker. Например, DNS имя нашей фермы RDCB будет RDCB_lb . Создадим две следующие A записи вида:
С помощью консоли Server Manager на первом из серверов RDCB устанавливаем роль RD Connection Broker (если еще не установлена).
После установки роли RDCB используется маленькая локальная база SQL, хранящаяся на локальном диске сервера RD Connection Broker в каталоге c:\windows\rdcbDb\ .
В этой базе хранится информация о ферме и терминальный сессиях пользователей. Так как она расположена на локальной машине, другие сервера RDCB не смогут ее использовать. Для создания HA для RDCB нужно перенести ее на выделенный SQL сервер, на котором она будет доступна другим серверам.
Для переноса БД на выделенный SQL Server нужно перейти на вкладку управления Remote Desktop Services -> Overview . Для запуска мастера создания отказоустойчивой конфигурации RD Connection Broker, щёлкнем ПКМ по изображению роли RD Connection Broker и выбираем пункт Configure High Availability . Запустившийся мастер должен создать БД на MS SQL Server и перенести в нее локальную конфигурацию.
Заполним три поля:
Для SQL 2012
:DRIVER=SQL Server Native Client 11.0;SERVER=
Затем откроем SQL Server Manager на сервере СУБД и убедимся, что была создана новая база. Переходим на вкладку Security , выберем ранее добавленную группу — > свойства, и в качестве БД по-умолчанию выбираем базу RDS. Потом отмечаем роли db_owner и public .
Для обеспечения высокой доступности на случай выхода из строя первого сервера, необходимо в текущую конфигурацию добавить второй узел Connection Broker.
Для этого щелкаем ПКМ по иконке RD Connection Broker, и выбираем пункт Add RD Connection Broker Server .
Указываем имя второго сервера, на котором нужно установить роль Connection Broker и жмем Далее.
На этом настройка High Availability конфигурации Connection Broker завершена.
Итак, мы создали высоко доступный сервис RD Connection Broker на Windows Server 2012. Вы можете протестируйте доступность RDCB, отключив один из серверов фермы RDCB. В этом сценарии точкой отказа остается SQL server. Отказоустойчивость SQL сервера можно реализовать с помощью HA SQL кластера или зеркалирования базы SQL.