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

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