Remote Desktop Services - Строим отказоустойчивую ферму RD Connection Broker

imageНачиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов Microsoft Windows Server 2008 R2 – серверной роли Remote Desktop Services (RDS). Для начала рассмотрим процесс создания фермы серверов RDS с использованием механизма балансировки нагрузки с помощью Remote Desktop Connection Broker (RDCB).

Описание задачи

Не будем заострять внимания на описании функций служб Remote Desktop Services, так как этой информации более чем достаточно в официальных источниках Microsoft. Предметом этой заметки будет пошаговое практическое описание процесса создания фермы из трёх виртуальных серверов, на каждом из которых будут совмещены компоненты RD Session Host и кластеризованная служба RD Connection Broker. То есть мы попробуем при минимуме серверных экземпляров Windows Server 2008 R2 собрать отказоустойчивое решение RDS.

По информации доступной из блога TechNet Blogs > Mark Ghazai's Blog > Windows Server 2008 R2 Highly Available (Clustered) Remote Desktop Connection Broker на каждом из серверов в кластере RD Connection Broker будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.


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

Три виртуальных сервера на базе Windows Server 2008 R2 Enterprise EN. Корпоративная редакция ОС потребуется нам из-за необходимости использования средств Windows Failover Clustering.

Каждый из серверов имеет по два сетевых интерфейса.

Серверам присвоены имена - KOM-AD01-RDS01 , KOM-AD01-RDS02 и KOM-AD01-RDS03.

Создаваемый в процессе описания кластерный экземпляр Windows Failover Clustering будет иметь имя KOM-AD01-RDSCL.

Кластеризованный экземпляр службы RD Connection Broker будет иметь имя KOM-AD01-RDCB

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

image


Настраиваем сетевые параметры

Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.

Выполним описанные ниже настройки на каждом из трёх серверов.

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

image


NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.

image


Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.

В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:

image


В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.

Здесь же, по кнопке Advanced откроем окно дополнительных настроек

image

В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS 

image


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


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

На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles

image

В открывшемся окне мастера выбираем роль Remote Desktop Services

image

Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker

image


На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication

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

image

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

image

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

image


На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под Desktop Experience понимается установка дополнительных пользовательских компонент в составе:

  • Windows Calendar
  • Windows Mail
  • Windows Media Player
  • Desktop themes
  • Video for Windows (AVI support)
  • Windows Photo Gallery
  • Windows SideShow
  • Windows Defender
  • Disk Cleanup
  • Sync Center
  • Sound Recorder
  • Character Map
  • Snipping Tool

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

image


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

image


Включаем поддержку кластеров - Failover Clustering

На каждом из серверов выполняем установку компоненты для возможности работы с кластером - Failover Clustering. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Features вызываем мастер добавления возможностей действием Add Features

image

В открывшемся окне мастера добавления возможностей выбираем Failover Clustering

image


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

На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster

image


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

image


На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.

image


Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов - Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх. Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI

image


В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.

 

Настраиваем кластерные ресурсы

После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.

image


Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application

image


В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker

image


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

На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker

image


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

image


После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.

image


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

image


Включаем сервера в ферму RD Connection Broker

На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.

image


Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.

image


На вкладке RD Connection Broker нажимаем кнопку Change Settings.

image


В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name
по рекомендации оставим схожим с именем кластерного экземпляра.

image


Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.

image


Тип перенаправления оставим в значении по умолчанию - IP address redirection и отметим IP адрес интерфейса которым у нас будут обслуживаться пользовательские сессии на этом конкретном сервере.

В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.

Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker

image


… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker

image


После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host

image


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

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

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

image


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

image


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

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

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

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

image


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

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

certutil -getreg Policy\EditFlags

image

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

certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 
net stop certsvc 
net start certsvc

Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:

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

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

[Version]

Signature="$Windows NT$"

 

[NewRequest]

Subject = "CN=KOM-AD01-RDSCB.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.3 ; Code signing

 

[RequestAttributes]

SAN  = "dns=KOM-AD01-RDSCB.holding.com&"

_continue_ = "dns=KOM-AD01-RDS01.holding.com&"

_continue_ = "dns=KOM-AD01-RDS02.holding.com&"

_continue_ = "dns=KOM-AD01-RDS03.holding.com&"

_continue_ = "dns=KOM-AD01-RDSCB&"

_continue_ = "dns=KOM-AD01-RDS01&"

_continue_ = "dns=KOM-AD01-RDS02&"

_continue_ = "dns=KOM-AD01-RDS03&"

_continue_ = "dns=10.160.0.39&"

_continue_ = "dns=10.160.0.41&"

_continue_ = "dns=10.160.0.42&"

_continue_ = "dns=10.160.0.43&"

 

 

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

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

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

Итак на веб-узле локального ЦС последовательно перейдём по ссылкам:

Request a certificate >
advanced certificate request >
Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.

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

image


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

View the status of a pending certificate request

image


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

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

CertReq -accept certnew.p7b

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

image


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

image


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

image


В окне выбора сертификатов выбираем соответствующий сертификат…

image


После этого сохраняем настройки свойств подключения

image


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

image


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

image


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

image


Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03

image


Далее указываем имя файла в который будет экспортирован сертификат

image


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

image


В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом

image


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

image


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

image


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

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

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

Дополнительные источники информации:

Всего комментариев: 79 Комментировать

  1. Обратная ссылка: Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки « ИТ Блог Алексея Максимова /

  2. Петр /

    Алексей, не могу понять, в чем заключается отказоустойчивость фермы...
    На каждый сервер из фермы распределяется по 30% пользователей. Для новых подключений можно сказать, что ферма отказоустойчива. НО. Как быть с активными сессиями? Например, необходимо в рабочее время один сервер выключить, при этом пользователю желательно увидеть только обрыв связи, а потом восстановление в свою же сессию. Подскажите, как быть в таком случае?

  3. Алексей Максимов /

    RDCB в описанной реализаци не решит проблемы "горячего" переключения пользователей. Он больше ориентирован на оперативное восстановление возможности работы пользователей при выходе из строя одного из серверов. Если же требуется планово вывести какой-то сервер из кластера в обслуживание, то вам нужно разослать оповещение пользователям нужной ноды с просьбой о сохранении всех открытых файлов и завершении работы например на 10 минут. Пользователи сидящие на нужной вам ноде выходят из фермы; Вы в кластере отсанавливаете освободившуюся ноду (чтобы на неё не попадали запросы пользоватиелей); Пользователи снова заходят в ферму, попадая при этом уже на другие ноды, а благодаря механизму перемещаемых профилей они по прежднему смогут работать с файлами, хранящимися в их профилях.

    1. Петр /

      По данной статье и следующей (о профилях) реализовал RDCB. Отличное описание настроек.
      Вопрос по решению проблемы с "горячим" переключением пользователей остается открытым. Хотелось бы узнать, сталкивались ли Вы с его решением на практике и возможными вариантами реализации.

  4. Alex /

    "Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети."

    C этим могут быть проблемы, нарвался на ошибку типа:

    Ресурсу "Сетевое имя 'Network Name (com1)'" кластера не удалось удалить связанный объект компьютера в домене '' по следующей причине: Не удается создать учетную запись компьютера.

    Решение здесь:
    http://technet.microsoft.com/ru-ru/library/dd421851%28v=exchg.80%29.aspx

    1. Алексей Максимов /

      Это из разряда граблей, которые администраторы расставляют себе сами. Например установил на объект компьютера в AD признак защиты от удаления, а потом пытаешься выполнять манипуляции с кластерным экземпляром (удаление/повторное создание) и получаешь черенком по лбу :)

      1. Alex /

        Алексей, доброго время суток.
        Ферма настраивается на серверах Windows 2008 R2 Enterprise. А контроллер домена у нас все еще на базе Windows 2003 server. Не приходилось ли настраивать ферму в таком окружении? Могут ли из-за этого возникнуть какие-нибудь проблемы? Я сначала думал, что грабли на которые я наступил связаны именно с этим.

  5. Алексей Максимов /

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

  6. Обратная ссылка: SAP Business Explorer Analyzer в Терминальной ферме. | IT Blog /

  7. Юрий /

    Алексей, добрый день. А как быть с кластером, если есть несколько железных серверов? Не вижу необходимости держать все три ноды виртуалками на одном железном сервере. У меня есть 6 железных серверов, на каждом живет Xen и виртуальные W2K8R2. Как их правильно в кластер и с брокером?

    1. Алексей Максимов /

      Юрий :

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

      А вам вроде бы тут никто и не внушал то что есть необходимость держать три виртуалки на одном железном сервере. Как размазать виртуалки по хостам - дело абсолютно ваше личное. А для построения фермы в бОльшим количеством виртуалок по предложенной мной схеме нужно придерживаться нечетного количества виртуальных серверов, например 5 или 7, чтобы смог работать принцып определения большинства активных узлов в кластере, то есть минимум живыми должно быть половина нод + 1 (кластер с моделью кворума большинства узлов – Node Majority). Либо если вы хотите использовать именно 6 нод, тогда меняйте модель кластера - например используйте в качестве дополнительного голоса в кластере шару-свидетель на стороннем сервере, хотя схемы со всякими там левыми сведетелями тоже "палка о двух концах".

  8. Юрмй /

    Это понятно.... Оставлю одну виртуалку вне кластера. Вопрос по сетевым подкючениям. Для нормальной работы достаточно ли одного линка или все таки правильнее использовать две сетевых карты, подкюченные к разным коммутаторам (или к разным vlan)?

    1. Алексей Максимов /

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

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

  9. Антон. /

    Отличная статья! Спасибо!
    Хотел бы узнать, есть ли доступная GUI утилита для выдергивания списка залогинившихся пользователей через RDCB из активной БД ?
    Смотреть на каждом сервере список не очень удобно.

    1. Алексей Максимов /

      Это стандартная консоль Remote Desktop Services Manager (%windir%system32tsadmin.msc). Она в одном месте отображает сессии пользователей на всех серверах фермы и позволяет ими управлять. В этой статье есть даже скришот этой консоли http://amaksimov.files.wordpress.com/2011/12/image35.png

      1. Антон. /

        Да, но если у меня 3 сервера HOST и почти (в теории планируется) 350-400 подключений, то мне необходимо в одну единицу времени знать сколько сейчас подключений активных. На текущий момент делаю 3 запроса в PS на предмет количества сессий на каждом хосте и потм суммирую. Хотелось бы иметь инструмент читающий информацию из БД брокера. Может я не прав конечно....

        1. Николай Николаевич /

          Для этого я использую Zabbix. Сделал в нём скрин лист где показана загрузка всех TS и количество активных ts сессий.

  10. Алексей Максимов /

    Если для оперативного выяснения, то да - PowerShell. Если же инфа о количестве сессий нужна за период для какого-то планирования распределения ресурсов - то лучший вариант это MP для RDS в SCOM который собирает статистику по системным счетчикам производительности и по этим данным можно получить налядный график в разрезе времени.

    1. Антон. /
  11. Антон. /

    Добрый день!
    Хотел бы узнать. А сколько времени хранится в базе RDS Broker информация о количестве логонов, реконектов и общего числа сессий ?

    Нашел на просторах инета скрипт, который мне для моего имени RDC фермы выдает следующее :
    Total sessions created: 487
    Total sessions disconnected: 540
    Total sessions reconnected: 71

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

    Цитата:

    ;Для получения списка пользователей с RDS фермы можно воспользоваться 2 скриптами
    ;основной скрипт

    @echo off
    for /F "eol=; tokens=1" %%i in (list_servers.txt)do @showusersonserver.cmd %%i
    pause

    ;и скрипт showusersonserver.cmd

    @echo off
    set result_file=result_%date:~6,4%_%date:~3,2%%date:~0,2%%time:~0,2%%time:~3,2%
    echo %1 >>%result_file%
    Query session /server:%1 /counter >> %result_file%

    ;в файле list_servers.txt просто перечисление серверов фермы

    1. Николай Николаевич /

      Используйте систему мониторинга , nagios или zabbix

  12. voffka /

    Вроде все фурычит, но на шаге с сертификатами нужно указать ТЕМПЛЕЙТ. Вот подсунул ему "веб сервер" - ругается на сертификат. какой правильно темплейт ему подсовывать при сабмите запроса ?

    1. Алексей Максимов /

      Не уверен что шаблон "веб сервер" подойдёт.
      Как отмечено, необходимый минимум это:

      OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
      OID=1.3.6.1.5.5.7.3.3 ; Code signing

      Поэтому или надо делать специальный шаблон, или делать сертификат по кастомному запросу, как это описано здесь.

  13. voffka /

    Короче, с сертификатом налом. По инструкции вашей - не пашет. Ругается, как не крути ... http://www.mytechstuff.info/2012/01/blog-post.html вот тут более разжеванно, но таже беда. все тожесамое

  14. voffka /

    С сертификатом поборол беду. У вас запрос с ошибками в статье. Долго расписывать (нужно тут еще шаблон создавать измененный). Кому надо - обращайтесь на почту.

    1. Алексей Максимов /

      Хватит воды. По существу. О каких ошибках речь. Все написано по проделанной на практике работе.
      Заметка писалась вообще не на примере доменного ЦС, а на примере изолированного. Там нет такого понятия как шаблоны сертификатов в принципе, и поэтому здесь об этом нет ни слова.

      1. voffka /

        С доменным ЦС запрос будет такой

        [Version]
        Signature="$Windows NT$"

        [NewRequest]
        Subject = "CN=TS.domain.local";
        Exportable = TRUE; Private key is exportable
        KeyLength = 2048
        KeySpec = 1; Key Exchange – Required for encryption
        KeyUsage = 0xA0; Digital Signature, Key Encipherment
        MachineKeySet = TRUE
        ProviderName = "Microsoft RSA SChannel Cryptographic Provider"
        RequestType = PKCS10

        [EnhancedKeyUsageExtension]
        OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
        OID=1.3.6.1.5.5.7.3.3 ; Code signing

        [RequestAttributes]
        SAN="dns=TS.domain.local&dns=TS01.domain.local&dns=TS02.domain.local&dns=TS03.domain.local&dns=TS04.domain.local&dns=TS&dns=TS01&dns=TS02&dns=TS03&dns=TS04"

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

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

        Мож оно кому пригодится ...

  15. Taryel /

    Здравствуйте, Алексей я поднял тестовую среду по вашей статье до сертификатов еще не дошоль. кластер поднался без проблем и имя созолос в днс -е и для сомого кластера и для точки подклучения для клиетов ип аддресс и названия точки подлучения пингуется но при наборе ип или имени броккера в R.D.C подклучение не произходит по иде я должен бил попаст на активнузю ноду кластера с брокером?

    1. Алексей Максимов /

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

  16. Taryel /

    то есть клиент подключается к активное ноде с названием tersrv03.contoso.com, после того как не дай бог этот сервер упадет и активной Нодой станет tersrv02.contoso.com клиенты должны будут подключаться к адресу tersrv02.contoso.com. Если это так то как можно создат единую точку входа для ползовотелей. Я думал что етa точка должна била быт ИП или FQDN Client Access Pointa . На у меня почемута етот адрес не отвечает на 3389 порту.

    1. Алексей Максимов /

      Клиенты должны подключаться именно к FQDN брокера, а не какого-то отдельного сервера. А то почему у вас брокер не отвечает клиентам - вопрос не ко мне.

    2. voffka /

      у вас должен был появится (в моем случае я руками создал, ибо нужны права в домене на создание обьектов) еще 1 компьютер в домене с именем кластера. В данной статье это dns=KOM-AD01-RDSCB.holding.com. Вот туда и нужно стучать, а отвечать вам уже должна та нода, которую брокер выбрал. В данной схеме брокер плавающий получается. Тоесть брокер всегда живет только на одной ноде. Если она отвалится - он переедет на другую.

  17. voffka /

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

  18. Taryel /

    я понял. Значит в ДНС - е надо создат 3 записи типа А terminal.contoso.com указиваюшие на ип адреса всех терминалних серверов входаших в ферму. Когда 3 клиента подклучется к terminal.contoso.com хозаин роли Брокера разкидовает их о етим 3м серверам и записовает инфу о местонахаждении каждого ползовотеля в свою локалную базу после чего репличирует ету инфу на другие НОДИ в кластере. После отклучения хозаена роли брокера один из нод берот на себя ету рол и при переподклучении ползовотелей он уже знает у кого где ест откритий сеанс и перенаправлает их на соотведствуяшиые сервера.

  19. Taryel /

    добрый вечер, наконец то добрался дo сертификатов, у меня CA Enterprise метод описонний в стате для меня не работает, метод которий предлогает voffka тоже не сработал .Зделал как говарится в етой стате http://compulinx.blogspot.com/2011/03/how-to-setup-remote-desktop-session_06.html и у клиентов не вискакивает никаких предупреждений все роботает.
    другой вопрос про sizeing. Может кто небут подсказат как расчитоват ресурсы. Примерно 200 ползовотелей 2 сервера

    1. Николай Николаевич /

      Тут будет основной упор на производительность HDD. RAID10 из хардов по 10К точно потянет.

  20. Сергей /

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

    1. Алексей Максимов /

      Могу предположить что для кластерного адреса брокера вы использовали адрес из подсети в которую не входит интерфейс самого сервера. Обратите внимание на то что в моём описании и для адреса кластерного экземпляра брокера и для адресов самих серверов выбрана одна подсеть 10.160.0.0/24. Соответсвенно адрес шлюза для активной на данный момент ноды используется с интерфейса самой ноды и поэтому беспрепятсвенно работает маршрутизация трафика в другие подсети.

      1. Василь /

        Такая вот непонятная ситуация возникла – ферма поднята из 5-ти серверов, всё работало нормально на протяжении пары месяцев, служба RDSCB установлена на всех серверах, т.е. переезжала по серверам. И вот не так давно перестало работать распредение нагрузки – все пользователи заходят только на один из серверов. При принудительной передаче роли RDSCB на другой сервер часть клиентов отвалилась и они зашли уже на другой сервер, остальные так и продолжают нормально работать на предыдущем сервере. Мастер проверки кластера проводит все проверки с положительным результатом, сети настроены нормально. Может подскажете, куда копать? Заранее благодарен за любую оказанную помощь и участие!

        1. Николай Николаевич /

          Был такой глюк. Оказалось что была проблема с именами терминалок добавленными в группу брокера. Появилась после установки MUI. Нужно удалить и заново добавить всех членов в группу на всех серверах

          1. Николай Николаевич /

            Точнее с именами групп . осле установки MUI группы для брокера стали называться по Русски

  21. Алексей Максимов /

    Куда компать не подскажу, потому что не знаю откуда могут расти ноги у проблемы. Для анализа ситуации нет вообще никаких данных кроме "работало, а потом вдруг перестало". Как вариант (наиболее оперативный) - разобрать кластер и собрать заново.

  22. Scorpion /

    Если уж подставляешь "правильный" сертификат, то зачем же оставлять режим Negotiate? Почему сразу не поставить TLS1.0? Смысл идеи с сертификатами теряется, тем более, что в допуске "в нашем окружении нет устаревших клиентов", а поддержка NLA идет уже с XP SP3.

    1. Алексей Максимов /

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

      1. Scorpion /

        Подскажу подробности: у клиентов ХР по умолчанию не работает "понимание" NLA. SSL/TLS здесь не при чем, эти протоколы они понимают еще с SP0. Не понимаю совсем старые Win95-98, но таких даже в домен завести проблемно. Используя Negotiate можно по требованию клиента просадить уровень связи до LM или Plan Text, в которых сертификат не нужен по умолчанию. Ещ раз, ты разговор ведешь о "неустаревших" клиентах, а там гайки закручивать надо до упора.

  23. Scorpion /

    И уж конечно же "правильный" сертификат для RDP-сервера должен в поле EKU содержать OID 1.3.6.1.4.1.311.54.1.2, который хардкодово знает RDP-клиент (Если разговор об использовании NLA, то RDP-клиент должен быть не ниже 6.1, а значит там этот OID уже есть). И, желательно, что б вместе с 1.3.6.1.5.5.7.3.1 - Server Authentication присутсвовал и 1.3.6.1.5.5.7.3.2 - Client Authentication. Code signing - по необходимости/желанию.

    1. Алексей Максимов /

      По поводу OID могу сказать что на момент написания заметки в библиотеке течнета я нигде не видел упоминания о 1.3.6.1.4.1.311.54.1.2. Ну и как то ферма с вышеописанными сертификатами работает и по сей день.

      1. Scorpion /

        Вот к примеру, на вскидку, статья написанная гораздо раньше твоей, где этот OID уже упоминается. http://appjournal.livejournal.com/4853.html.
        Еще раз. Этот OID был введен еще с 2008 сервера SP1 (если не ошибаюсь), а ты пишешь про 2008R2, в котором это уже изначально заложено. Вариант нашел/ненашел - не серьезный.
        Про "как то ферма с вышеописанными сертификатами работает и по сей день". Именно, что как-то. Подсунь туда же сертификат сделанный на основе шаблона "веб-сервер" и он так же будет скушан и ни один клиент не подавится (не нравится слово "шаблон" - сделай ручками, через request). Разговор идет о "правильном" сертификате, а он должен содержать "правильный" OID. Я прекрасно понимаю, что статья не о сертификатах, а о ферме в целом, но такие нюансы отравляют впечатление об достаточно хорошей, доходчивой статье.

  24. Алексей Максимов /

    При развертывании фермы и написании своей заметки я руководствовался достуными на тот момент материалами библиотеки течнета, где говорилось о том что для RD сервера вполне достаточно двух OID:
    Проверка подлинности сервера (1.3.6.1.5.5.7.3.1)
    Подписывание кода (1.3.6.1.5.5.7.3.3)
    Теперь вы готовы меня распять за то что я не использую OID 1.3.6.1.4.1.311.54.1.2., информация о котором я могу найти на сегодня только в статье http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx , где даже не приводится вменяемого описания причин, по которым этот OID обязательно должен присутствовать в сертификате...
    Вы поймите, я с вами не спорю, а просто не вижу (или не знаю/ не понимаю) причин по которым я, хоть тресни, должен был использовать этот OID.

    По поводу того что вы назвали статьей в LJ...возникает ощущение что в этой "писанине" человек даже сам не понимал о чём говорит, ибо сначало сказано, что он использовал сертификат без упоминания OID 1.3.6.1.5.5.7.3.3, а потом написано "В оснастках RemoteApp во всевозможных местах был указан сертификат выданный корп. CA", что само по себе заблуждение, т.к. я прекрасно помню тот момент, что оснастка управления RemoteApp попросту не давала назначить для использования сертификат для подписывания RDP-файлов, если в нём отсутствовал этот OID.

    1. Баф /

      Тяжело вам приходится :) Пулемёт подарить?

  25. Антон /

    Алексей, добрый день. Насколько я понял механизм работы такой конструкции, в кластере есть понятие того, на какой сервер пошлет пользователя Connection Broker, Причем такой сервер указан только один. Если этот север оказывается не в сети, то параметр текущего указывает уже на другой сервер и fail-over срабатывает. Но как сделать так, чтобы во всей этой связке удаленные соединения поступали не только на сервер, указанный текущим, а на другие сервера фермы тоже? Другими словами: как правильно разделить нагрузку между работающими серверами кластера?

    1. Алексей Максимов /

      За равномерное распределение пользователей по серверам как раз и отвечает движок Connection Broker

  26. Обратная ссылка: Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012 | Блог IT-KB /

  27. Обратная ссылка: Решаем проблему запуска SAP Business Explorer Analyzer из Excel 2010 в ферме серверов RDS | Блог IT-KB /

  28. Александр /

    а как быть с приложениями?, мне бы хотелось чтобы на таком кластере крутилось 1с например, такое возможно?
    Хорошее решение для тонких клиентов. Спасибо!

    1. Алексей Максимов / Автор записи

      Александр, 1С разумеется возможно, как и массу других бизнес-приложений. Если же говорить в целом об архитектуре, то на самом деле RDCB на Windows Server 2008 R2 на сегодня это уже неактуально. Думаю стоит смотреть в сторону более новых систем, например по этому сценарию.

  29. Александр /

    я понимаю, но имеем лицензии только на 2008 сервер

  30. Павел /

    А через веб морду приложения видны? Что указали в источниках remoteapp?

    1. Алексей Максимов / Автор записи

      Если речь идёт про настройки источников в веб-интерфейсе RDWA, то в нём был указан адрес кластера RD Connection Broker (KOM-AD01-RDCB).

      1. Павел /

        А в настройках самого брокера? Роли->Службы УРС-> Диспетчер подключений к удаленным рабочим столам->Источники RemoteApp

        1. Алексей Максимов / Автор записи

          Сейчас по пунктам перемещения в интерфейсе настроек RDS WS2008R2 уже не сориентируюсь :) Перед глазами таких систем уже нет, так как перебрался на Windows Server 2012, а там всё кардинально по другому и поэтому старые системы уже начал забывать. Если со скриншотами зададите вопрос в форуме - возможно пойму о чём идёт речь и что-то отвечу.

  31. Scorpion /

    Хотел спросить, может встречался с такой ситуацией. В "Диспетчере служб удаленных рабочих столов" на вкладке "Пользователи" некоторые сервера фермы указаны, как DN, а некоторые и как DN и как FQDN, т.е. 2 раза каждый пользователь. С чем это может быть связано? причем день ото дня ситуация меняется.

  32. Сергей Кожанов /

    Алексей, прежде всего, огромное спасибо за столь подробную статью. У меня есть несколько вопросов:

    1. В чем преимущества данной схемы над схемой, где RDCB использует для хранения сессий SQL-базу данных (пример описан здесь http://habrahabr.ru/sandbox/49629/)

    2. Немного непонятно, как сделать отказоустойчивой точку вхождения пользователей в ферму? Представим ситуацию: все это хозяйство находится в удаленном ДЦ. Пользователи видят только белые адреса серверов в Интернете. Я вижу это так: каким-то внешним DNS-сервером рандомно кидать пользователей на 1 из 3 серверов с RDCB, а они, в свою очередь, решат, на какой сервер отправить входящее подключение. Верно?

    1. Алексей Максимов / Автор записи

      1. Вопрос поставлен некорректно. В данной статье рассматривается RDCB на базе Windows Server 2008 R2, а в приведённой Вами ссылке речь идёт о Windows Server 2012. В этих двух системах RDCB различается.
      Для Windows Server 2012 у меня была написана отдельная статья http://blog.it-kb.ru/2013/09/05/remote-desktop-services-rds-rd-session-host-and-web-access-in-farm-high-availability-rd-connection-broker-in-nlb-cluster-on-windows-server-2012/

      2. Можно и так, А вообще для подключения клиентов к RDS-серверам из Интернет рекомендуется использовать отдельную роль RD Gateway

  33. Сергей Кожанов /

    Спасибо! Еще немного непонятно с точкой вхождения в вашей схеме. У вас это некий узел 10.160.0.39. Именно к этому адресу будут подключаться пользователи? Это же отдельный сервер, его тоже нужно сделать отказоустойчивым? Или я где-то упустил нить..?))

    1. Алексей Максимов / Автор записи

      10.160.0.39 - это адрес кластерного экземпляра RDCB, а не какой-то "отдельный сервер". Это точка подключения клиентов.

  34. Алексей /

    День добрый! После создания фермы, в корневом элементе консоли Remote Desktop Services Manager в меню действий выбираем пункт Import from RD Connection Broker, и сервера не появляются в списке фермы, или появляются но два из трех. Все сделал исходя из вашей статьи, за которую вам отдельное спасибо! При этом ферма работает, пользователи подключаются по имени кластеризованного экземпляра RDCB на различные узлы. Служба RDCB запущена на одном из трех узлов. В чем может быть проблема подскажите плз?

  35. balintrue /

    Алексей, добрый день! Отличная статья, одна из "жемчужин" Вашего блога, спасибо. Хотел уточнить один момент: возможно ли заменить сертификат, созданный кастомным запросом на wildcard, созданный сторонним издателем на мой внешний домен (*.domen.ru)? На внутреннем DNS сервере AD (внутренний домен domain.local) зона domain.ru присутствует и я могу назначить внутренним машинам А-записи в domain.ru. Сможет ли данная схема работать в этом случае?

    1. Алексей Максимов / Автор записи

      Не скажу. Надо пробовать. У меня фермы на 2008 R2 уже давно нет (перебрались на 2012 R2), поэтому даже и проверить негде.

      1. balintrue /

        Алексей, я проверил, с wildcard все работает. Появилось еще два вопроса:
        1) В статье Вы написали: Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…
        Когда я импортировал по имени фермы, у меня отображается только один сервер, текущий в кластере, два остальных не видны и служба RD Connection Brocer на них не запущена и не запускается.
        2) Я пытался "прикрутить" созданную ферму к порталу UAG (там используется тот же wildcard, что и на терминальной ферме), но при вызове удаленного приложения появляется предупреждение о том, что запускаемое удаленное приложение может нанести вред локальному или удаленному компьютеру (если нажать ок приложение запустится). Ранее я думал, что подобная ситуация возникает из-за того, что опубликованные приложения подписаны сертификатом локального домена (*.domain.local). Но на новой ферме все опубликованные приложения подписаны внешним сертификатом. Получается, что есть какие-то особенности публикации приложений на UAG? Если пользоваться простым клиентом RDP (открыт порт фермы наружу), то все работает, а через UAG - нет.

  36. Михаил Калякин /

    certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2

    Тут не хватает бэкслеша "policy\EditFlags". Лоб себе расшиб об эти грабли пока не понял. А так все работает, за статью огромное спасибо!

    1. Алексей Максимов / Автор записи

      Виноват. Исправлюсь.

    2. Eugene Leitan /

      Согласен. Не хватает бекслеша.
      Алексей, просьба попроавить в статье!

      1. Алексей Максимов / Автор записи

        Исправил.

  37. Семен /

    Настраиваю отказоустойчивый кластер

    Делаю создать новый кластер добавляю ноды terminal01 terminal02 terminal03

    Назначаю Имя кластера ввожу IP

    Проблема не проходит установка

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

  38. Максим /

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

  39. Алексей /

    Настроил по инструкции тестовую ферму из 3 серверов + SQL(пока без сертификатов). Вместо NLB использую DNS RR. Все развернуто в виртуальной среде VMware.
    Эксперимент: подключаю 6 пользователей к ферме. RDCB раскидывает по 2 пользователя на каждый RDSH. Отключаю от сети один из серверов. 2 пользователя отваливаются. Пытаюсь подключиться снова - RDCB запрашивает авторизацию, а после успешной авторизации не происходит создание новой сессии на другом RDSH. Клиент просто не может установить соединение.
    Сессии "отвалившегося" сервера продолжают фигурировать в списке, закрыть их не получается. Пользователи не могут работать.
    Если я правильно понимаю ситуацию, RDCB проводит авторизацию, видит, что у пользователя уже есть активная сессия и пытается переправить пользователя на "мертвый" сервер.
    Google молчит. Натыкался на несколько подомных случаев, но все они остались без ответа.
    Помогите решить проблему. 2 недели уже бьюсь.

    1. greyishcat /

      А почему DNS RR? Он ведь не умеет определять живучесть конечного сервера. Может отправлять запросы на подключение в никуда. А вообще все похоже на то, что служба RDCB у вас висит не на тех сетевых интерфейсах. Похоже, что на адаптере, который относится к кластерной сети. Хотя я могу ошибаться...

  40. Александр /

    Алексей спасибо за статью, очень информативно, а вот если бы Вы написали статью как на любой терминальной ферме правильно настроить 1С 8,3 отказоустойчивый кластер, было бы шикарно. Потому как мои попытки оказались четными.

Добавить комментарий