Данная статья написана в рамках общего описания настройки терминальных служб в Windows server 2012. Центральная статья с описанием .

Отказоустойчивость в RDS

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

Отказоустойчивость серверной части можно обеспечить на двух уровнях:

• аппаратный — когда выход из строя физического сервера не ведет к долгому простою терминального сервера. Это легко осуществимо при использовании платформы виртуализации от любого производителя , Citrix, Microsoft, у них у всех есть технология высокой доступности HA (High Availability)
• программный — когда выходит из строя операционная система (Windows server 2008 или 2012) и администратору приходится восстанавливать данные из резервной копии с неизбежной потерей информации. Чтобы пережить программные сбои нужно настраивать кластеры, дублирующие серверы и не забывать о резервном копировании.

Клиентское устройство , очевидно, что это должен быть тонкий клиент, на котором не хранится никакой информации, только базовые настройки подключения. Он должен уметь подключаться к терминальному серверу (серверам) по 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 серверов, а используя технологии виртуализации, реплицируем виртуальные машины на другой физический сервер и не забываем делать резервное копирование. Но такая схема потребует вмешательства администратора при сбое, он должен будет удостовериться, что основные виртуальные машины вышли из строя и в ручном режиме запустить реплики.

Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения

Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker , то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active .
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server , а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin .

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

Четыре виртуальных сервера на базе Windows Server 2012 Standard EN . Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.

Визуально схема будет выглядеть так:

В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host , так и Remote Desktop Connection Broker .
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).

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

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

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

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

5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.

6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group , добавим оба сервера в группу и дадим ей название RDS .

Создание отказоустойчивой фермы Remote Desktop Connection Broker

1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation .

2. Оставьте опцию Standard deployment , так как мы будем делать развертывание на несколько серверов.

3. Выберем Session-based desktop deployment , так как в данной конфигурации мы не рассматриваем ферму VDI.

4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access . Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.

5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker .

6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker . Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.

7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next .

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

10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker . Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager ) и нажмем правой клавишей мыши на изображении RD Connection Broker . Там для нас будет доступна одна функция – Configure High Availability .

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

12. На вкладке Configure High Availability нам нужно заполнить 3 строки. Database connection string должна выглядеть следующим образом DRIVER=SQL Server Native Client 11.0 (или 10.50 если вы используете SQL Server 2008 R2);SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=. В нашем случае введем следующую строку DRIVER=SQL Server Native Client 11.0;SERVER=SQL.contoso.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB . В строку Folder to store database files введем путь заранее подготовленной нами папки C:\Base . В строку DNS round robin name введем созданный заранее FQDN нашей точки входа RD.contoso.com .

13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure .

14. На странице Progress дождемся окончания конфигурации.

Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode . Можно использовать эту ферму RDS через точку входа RD.contoso.com .

Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview .

Теги: Windows Server 8, Windows Server 2012, RDS, RDCB, Remote Desktop, Remote Desktop Connection Broker, Failover, high availability

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

• Как минимум 2 сервера с ролью RDCB (под ОС Windows Server 2012 / 2012 R2)
• SQL Server (редакция SQL server 2008 R2 Standard или выше) c минимум 4 Гб RAM
• Наличие установленного SQL Server Native Client
• Полные права серверов RD Connection Broker на БД SQL и каталог установки SQL
• Минимум один сервер с ролью Remote Desktop Session Host в ферме
• Разрешенные исключения для портов SQL server в фаерволе Windows

Важно . Перед началом создания отказоустойчивой конфигурации RDCB, убедитесь, что эта роль установлена только на одном из серверов.

Всем серверам, на которых будут установлены роли RD Connection Broker необходимо назначить статические ip-адреса и включить в домен Active Drectory.

• RDCB1.domain.ru — 172.25.104.71
• RDCB2.domain.ru — 172.25.104.171

В 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 записи вида:

• A RDCB_lb.domain.ru 172.25.104.71 (ip адрес RDCB1)
• A RDCB_lb.domain.ru 172.25.104.171 (ip адрес RDCB2)

С помощью консоли 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 и перенести в нее локальную конфигурацию.

Заполним три поля:

• Database Connection String – строка подключения с базе на SQL сервере.Для SQL 2008 R2 : DRIVER=SQL Server Native Client 10.0;SERVER=
  

  Для SQL 2012 :DRIVER=SQL Server Native Client 11.0;SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=

• Folder to store database files – каталог, в котором будут храниться файла БД: C:\SQLDB . Папка находится на SQL сервере, мы ранее ее создали и предоставили доступ группе серверов RDCB.
• DNS Round Robin name : FQDN имя фермы RDCB, для которой мы создавали записи в DNS для Round Robin (в нашем примере это RDCB_lb ). Именно по этому адресу будут обращаться RDP клиенты при подключении к серверам RD Connection Broker.

Затем откроем 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.

Remote Desktop Services 2012 – Отказоустойчивая ферма Remote Connection Broker нового поколения

• Чулан *

Если в версиях 2008/R2 использовалась схема Active/Passive для кластеризации службы RD Connection Broker , то в версии Windows Server 2012 схема работы служб RD переработана в корне. И для отказоустойчивой работы службы RD Connection Broker предлагается схема Active/Active .
Если в предыдущих версиях Connection Broker хранил всю информацию о пользовательских сессиях в локальной базе и, для развёртывания отказоустойчивой фермы, нам предлагалось использовать Failover Cluster, то в новой схеме Failover Cluster не используется. RD Connection Broker хранит свои данные в базе данных SQL Server , а клиенты подключаются к серверам RD Connection Broker используя DNS Round Robin .

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

Четыре виртуальных сервера на базе Windows Server 2012 Standard EN . Серверу, выполняющему роль контроллера домена в лесу contoso.com и DNS сервера присвоено имя DC1 и IP адрес 10.0.0.1. Сервер базы данных нашей фермы имеет имя SQL и IP адрес 10.0.0.10. Два сервера с установленной ОС, роли на них будут добавлены в процессе развертывания служб RDS.

Визуально схема будет выглядеть так:

В нашем случае серверы RD1 и RD2 будут являться как Remote Desktop Session Host , так и Remote Desktop Connection Broker .
На сервере SQL будет установлена SQL Server 2012 Standard (так же возможно использование SQL Server 2008 R2 в редакции не ниже Standard).

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

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

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

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

5. Создадим имя DNS Round Robin для каждого RD Connection Broker сервера. В нашем случае это будет 2 записи A с именем RD указывающих на IP адреса 10.0.0.3 и 10.0.0.4.

6. Перед тем как создавать нашу ферму, объединим наши будущие RDS сервера в группу. Откроем Manage – Create Server Group , добавим оба сервера в группу и дадим ей название RDS .

Создание отказоустойчивой фермы Remote Desktop Connection Broker

1. Запустите Add Roles and Features Wizard на сервере RD1 и переключите режим установки на Remote Desktop Services installation .

2. Оставьте опцию Standard deployment , так как мы будем делать развертывание на несколько серверов.

3. Выберем Session-based desktop deployment , так как в данной конфигурации мы не рассматриваем ферму VDI.

4. Помимо ролей RD Connection Broker и RD Session Host будет так же установлена роль RD Web Access . Отказаться от нее почему то нельзя. По крайней мере, я не нашел такой возможности.

5. На следующей странице выберем сервер RD1 для установки роли RD Connection Broker .

6. На странице RD Web Access выберем сервер доступа через веб. В нашем случае это будет тот же сервер что и RD Connection Broker . Установим чекбокс Install the RD Web Access role on the RD Connection Broker server и перейдем к следующей странице.

7. Добавим оба сервера в список для установки на них роли RD Session Host на одноименной странице и нажмем Next .

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

10. Приступим, собственно, к созданию отказоустойчивой конфигурации RD Connection Broker . Для этого перейдем на вкладку Overview раздела Remote Desktop Services менеджера серверов (Server Manager ) и нажмем правой клавишей мыши на изображении RD Connection Broker . Там для нас будет доступна одна функция – Configure High Availability .

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

12. На вкладке Configure High Availability нам нужно заполнить 3 строки. Database connection string должна выглядеть следующим образом DRIVER=SQL Server Native Client 11.0 (или 10.50 если вы используете SQL Server 2008 R2);SERVER=;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=. В нашем случае введем следующую строку DRIVER=SQL Server Native Client 11.0;SERVER=SQL.contoso.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB . В строку Folder to store database files введем путь заранее подготовленной нами папки C:\Base . В строку DNS round robin name введем созданный заранее FQDN нашей точки входа RD.contoso.com .

13. На странице подтверждения еще раз проверим введенные нами данные и нажмем Configure .

14. На странице Progress дождемся окончания конфигурации.

Собственно это все, как мы можем видеть на странице Overview раздела Remote Desktop Services менеджера сервера наш RD Connection Broker работает в режиме High Availability Mode . Можно использовать эту ферму RDS через точку входа RD.contoso.com .

Добавление серверов RD Connection Broker делается через то же самое контекстное меню на странице Overview .

Теги: Windows Server 8, Windows Server 2012, RDS, RDCB, Remote Desktop, Remote Desktop Connection Broker, Failover, high availability

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

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. Установка лицензий на сервер лицензирования службы удаленных рабочих столов

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

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

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

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

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

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

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

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

Помогла ли Вам данная статья?