Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов 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 в нашем случае будет выглядеть так:
Настраиваем сетевые параметры
Итак, на каждом сервере мы имеем по два сетевых интерфейса. Назовём их NIC1 – Public и NIC2 – Cluster и условимся, что согласно нашей схемы, NIC1 будет отвечать за управление самим сервером (будет зарегистрирован в DNS на FQDN имя сервера) а NIC2 будет отвечать за работу сервера в кластере Windows Failover Cluster.
Выполним описанные ниже настройки на каждом из трёх серверов.
Откроем окно настройки сетевых подключений и в меню Advanced > Advanced Settings и проверим порядок использования подключений (Connections).
NIC1 должен иметь приоритет над NIC2, то есть в списке подключений должен стоять первым.
Интерфейс NIC1 настроим обычным образом, задав ему IP адрес (согласно нашей схемы), маску подсети, IP адрес шлюза, адреса DNS серверов. Несколько иначе будет настроен интерфейс NIC2.
В свойствах кластерного интерфейса NIC2 можно отключить все компоненты, за исключением TCP/IP:
В свойствах компонента TCP/IP зададим только выделенный IP адрес и маску подсети. Кластерная подсеть должна отличаться от от подсети интерфейса NIC1 иначе в дальнейшем при создании кластера могут возникнуть проблемы с автоматическим созданием кластерных сетей. Также нужно понимать, что так как мы не указываем на этом интерфейсе адрес шлюза, все три сервера через этот интерфейс должны находиться в одном физическом сегменте сети.
Здесь же, по кнопке Advanced откроем окно дополнительных настроек
В окне дополнительных настроек TCP/IP на закладке DNS отключаем опцию регистрации этого подключения в DNS – Register this connection’s addresses in DNS
Как было сказано ранее, указанные настройки сетевых интерфейсов нужно сделать по аналогии согласно нашей схемы на всех трёх серверах.
Устанавливаем роль Remote Desktop Services
На каждом из серверов выполняем установку необходимых нам компонент роли Remote Desktop Services. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Roles вызываем мастер добавления ролей действием Add Roles
В открывшемся окне мастера выбираем роль Remote Desktop Services
Далее нам будет предложено выбрать соответствующие службы роли. Отмечаем Remote Desktop Session Host и Remote Desktop Connection Broker
На следующем шаге нужно выбрать режим аутентификации. Учитывая то, что в нашем окружении нет устаревших клиентов не поддерживающих NLA, выбираем рекомендуемый метод – Require Network Level Authentication
Значение этой настройки, как и всех других в этом мастере можно будет в изменить позже в любое время после установки роли с помощью оснасток управления RDS
На шаге выбора режима лицензирования выбираем опцию Configure later , так как для конфигурирования параметров режима лицензирования наших терминальных серверов мы в дальнейшем будем использовать возможности доменных групповых политик.
На шаге выбора групп добавим заранее созданную доменную группу безопасности, в которую будут включаться пользователи имеющие потребность в доступе к ресурсам расположенным на серверах создаваемой фермы RDS. После установки роли на сервере будет создана специальная локальная группа безопасности Remote Desktop Users в которую и будут включены выбранные нами на этом шаге группы
На следующем шаге мы сможем включить признак установки поддержки расширенных медиа компонент. Под 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
В многопользовательской среде должен быть взят за правило принцип необходимого минимума приложений и поэтому, следуя этому принципу мы не будем устанавливать этот "винегрет".
Далее, после окончания процесса установки роли RDS потребуется перезагрузка сервера. После перезагрузки сервера войдём в систему и дождёмся автоматического открытия окна мастера добавления ролей, который должен будет сообщить нам об успешном окончании процесса.
Включаем поддержку кластеров - Failover Clustering
На каждом из серверов выполняем установку компоненты для возможности работы с кластером - Failover Clustering. Для этого в оснастке Server Manager (ServerManager.msc) в разделе Features вызываем мастер добавления возможностей действием Add Features
В открывшемся окне мастера добавления возможностей выбираем Failover Clustering
Создаём кластер
На любом из трёх серверов, например на сервере KOM-AD01-RDS01 открываем оснастку Failover Cluster Manager (Cluadmin.msc) и в меню действий Action выбираем пункт создания нового кластера – Create a Cluster
В открывшемся мастере создания кластера добавляем все три сервера которые мы планируем включить в будущий кластер
На следующем шаге мастера укажем имя и IP адрес выделенный для администрирования кластера. Нужно учесть, что здесь задается не то имя, которое будет использоваться для подключения клиентов RDS, а то которое необходимо для обслуживания самого кластерного экземпляра Windows Server 2008 R2, на который мы в последствии будем добавлять кластеризованную службу RD Connection Broker.
Далее, исходя из нашей конфигурации, мастером будет автоматически создан кластер с моделью кворума большинства узлов - Node Majority. Это значит, что наш кластер будет оставаться в работоспособном состоянии (принимать запросы от клиентов) только в том случае, если будет доступно минимум два серверных узла из трёх. Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI
В процессе создания кластера в домене должна быть создана его учетная запись (cluster name object) и выполнена регистрация указанного имени в DNS.
Настраиваем кластерные ресурсы
После того как экземпляр кластера создан, нам нужно настроить кластерные сети, чтобы один сетевой интерфейс использовался для клиентских подключений, а второй был ограничен исключительно для использования межузлового кластерного обмена. В свойствах кластерной сети, предназначенной для Cluster Heartbeat (в нашем случае это Cluster Network 2) должна быть отключена опция Allow clients to connect through this network. Таким образом, мы заставим кластер использовать данную кластерную сеть, состоящую из интерфейсов NIC2, только в целях межузлового обмена.
Теперь в нашем кластере мы можем создать службу RD Connection Broker. Для этого в разделе Services and applications выберем пункт Configure a Service or Application
В открывшемся мастере высокой доступности из списка доступных для кластеризации служб и приложений выберем службу Remote Desktop Connection Broker
Обратите внимание на то, что в официальной документации есть информация об ограничениях в ситуации когда вы хотите создать кластеризованный экземпляр службы RD Connection Broker в уже существующем кластере и при этом в этом кластере есть настроенные ранее службы типа Generic Service.
На следующем шаге мастера введём имя и IP адрес точки доступа к службе. Именно эти данные в дальнейшем и будут нами использоваться для настройки фермы RD Connection Broker
На этапе создания службы в кластере в домене также будет создана дополнительная учетная запись и будет произведена регистрация имени в DNS
После окончания работы мастера в консоли управления кластером мы можем убедиться в том что кластеризованный экземпляр службы успешно создан, запущен и его активным владельцем является сервер KOM-AD01-RDS02. Также обращаем внимание на то, что по умолчанию включён режим автозапуска данной службы при начале работы кластера.
Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети.
Включаем сервера в ферму RD Connection Broker
На каждом сервере с службой RD Connection Broker добавляем все наши сервера RD Session Host в локальную группу безопасности Session Broker Computers. В нашем случае это нужно сделать на всех трёх серверах.
Затем, на каждом из трёх наших серверов RD Session Host открываем консоль Remote Desktop Session Host Configuration (Start > Administrative Tools > Remote Desktop Services) и в разделе Edit settings, выбираем настройку Member of farm in RD Connection Broker.
На вкладке RD Connection Broker нажимаем кнопку Change Settings.
В окне RD Connection Broker Settings выбираем Farm member и вводим имя кластерного экземпляра службы RDCB. Имя создаваемой фермы в поле Farm name по рекомендации оставим схожим с именем кластерного экземпляра.
Отметим опцию Participate in Connection Broker Load-Balancing для включения механизма балансировки нагрузки в ферме RD Connection Broker. Значение Relative weight определяет относительный вес данного сервера в ферме (по умолчанию – 100). В том случае, если вы зададите вес одного сервера 100, а другого 50, это приведёт к тому, что сервер с меньшим весом будет получать в 2 раза меньше подключений.
Тип перенаправления оставим в значении по умолчанию - IP address redirection и отметим IP адрес интерфейса которым у нас будут обслуживаться пользовательские сессии на этом конкретном сервере.
В типичной конфигурации фермы RD Connection Broker предлагается использовать механизм DNS Round Robin для подключения клиентов к ферме. Вместо этого, в нашем случае, для подключения клиентов будет использоваться имя кластеризованного экземпляра RD Connection Broker и в дополнительных манипуляциях с DNS нет необходимости.
Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…
… и укажем FQDN имя нашего кластеризованного экземпляра RD Connection Broker
После этого в консоли должна появиться информация о созданной ферме и задействованных в ней серверах с ролью RD Session Host
Уже на этом этапе можно попробовать работу нашей фермы в действии подключившись RDP клиентом на адрес фермы. При отключении пользовательского сеанса и повторном подключении RDCB должен направлять нас в уже существующую сессию.
Настраиваем сертификаты серверов RDSH фермы RDCB
При попытке подключения к ферме RD Connection Broker по короткому имени или FQDN клиенты могут получать предупреждение безопасности, говорящее о том что нет доверия сертификату того сервера сеансов на который он был перенаправлен
Если открыть свойства этого сертификата мы увидим что сертификат создаваемый на сервере RDSH по умолчанию является самоподписанным.
Чтобы избежать таких предупреждений нам нужно создать для каждого сервера сеансов сертификат подписанный доверенным Центром сертификации (ЦС), например локальным изолированным или доменным ЦС.
При создании запроса на сертификат необходимо использовать политику применения - Проверка подлинности сервера (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
Мы можем создать единый сертификат который будет установлен на все сервера фермы и будет содержать в себе все возможные имена SAN.
Для того чтобы наш локальный ЦС мог корректно обрабатывать запросы сертификатов с SAN он должен быть настроен для этого. На примере изолированного ЦС проверить это можно выполнив на сервере ЦС команду.
certutil -getreg Policy\EditFlags
Если среди выведенных значений нет флага EDITF_ATTRIBUTESUBJECTALTNAME2, то его можно добавить с последующим перезапуском службы сертификации:
certutil -setreg policy\EditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2 net stop certsvc net start certsvc
Подробнее об использовании Subject Alternative Name в цифровых сертификатах можно найти по ссылкам:
- Windows Server TechCenter - How to Request a Certificate With a Custom Subject Alternative Name
- KB931351 - How to add a Subject Alternative Name to a secure LDAP certificate
- PowerShell Crypto Guy's weblog > How to add FQDN to HP iLO request
Подготовим файл параметров для создания запроса на получение нужного нам сертификата. Это обычный текстовый файл, назовём его например 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
После того как размещённый запрос на сертификат обработан администратором центра сертификации, мы можем с этого же веб-узла локального ЦС загрузить сертификат в формате Base 64 encoded пройдя по ссылке:
View the status of a pending certificate request
Будет предложено загрузить файл сертификата в формате PKCS #7 с именем certnew.p7b
Устанавливаем в систему полученный сертификат командой:
CertReq -accept certnew.p7b
После этого в консоли управления сертификатами в хранилище Local ComputerPersonal можно будет увидеть новый установленный сертификат, подписанный доверенным локальным ЦС
Затем на этом же сервере открываем консоль Remote Desktop Session Host Configuration и в разделе Connections, открываем свойства подключения.
В окне свойств подключения на закладке General в секции Security нажимаем кнопку Select для того чтобы выбрать только что установленный в систему сертификат
В окне выбора сертификатов выбираем соответствующий сертификат…
После этого сохраняем настройки свойств подключения
Теперь нам нужно установить этот же сертификат на другие два сервера – KOM-AD01-RDS02 и KOM-AD01-RDS03. Для этого в консоли управления сертификатами на сервере KOM-AD01-RDS01 выполним экспорт сертификата с закрытым ключом из хранилища Certificates /Local Computer/Personal.
В открывшемся мастере экспорта сертификата на странице Export Private Key выберем опцию Yes, export the private key
На странице Export File Format выбран один возможный вариант формата выгрузки - Personal Information Exchange – PKCS #12 (.PFX)
Затем вводим пароль для защиты закрытого ключа, который мы в дальнейшем будем использовать для импорта сертификата на серверах KOM-AD01-RDS02 и KOM-AD01-RDS03
Далее указываем имя файла в который будет экспортирован сертификат
Полученный файл в формате PFX копируем на другие два сервера и, открыв на них консоль управления сертификатами в хранилище Local ComputerPersonal вызываем мастер импорта сертификата
В открывшемся мастере импорта сертификата указываем расположение PFX файла содержащего сертификат с закрытым ключом
Затем указываем пароль, с которым ранее сертификат был экспортирован. Устанавливать признак экспортируемости ключа (Mark this key as exportable..) вовсе не обязательно.
На следующем шаге будет предложено выбрать хранилище сертификатов в которое производится импорт. Оставим значение Personal
После того как сертификат импортирован, откроем консоль Remote Desktop Session Host Configuration в разделе Connections, открываем свойства подключения и выполним привязку к установленному сертификату методом описанным ранее.
По завершении всех манипуляций с сертификатами желательно не забыть удалить все временные копии экспортированного сертификата с закрытым ключом.
В конечном результате описанных действий подключение клиентов должно работать без предупреждений безопасности.
Дополнительные источники информации:
RSS - Записи
Обратная ссылка: Remote Desktop Services – Используем перенаправление профилей пользователей и перемещаемые папки « ИТ Блог Алексея Максимова /
Алексей, не могу понять, в чем заключается отказоустойчивость фермы...
На каждый сервер из фермы распределяется по 30% пользователей. Для новых подключений можно сказать, что ферма отказоустойчива. НО. Как быть с активными сессиями? Например, необходимо в рабочее время один сервер выключить, при этом пользователю желательно увидеть только обрыв связи, а потом восстановление в свою же сессию. Подскажите, как быть в таком случае?
RDCB в описанной реализаци не решит проблемы "горячего" переключения пользователей. Он больше ориентирован на оперативное восстановление возможности работы пользователей при выходе из строя одного из серверов. Если же требуется планово вывести какой-то сервер из кластера в обслуживание, то вам нужно разослать оповещение пользователям нужной ноды с просьбой о сохранении всех открытых файлов и завершении работы например на 10 минут. Пользователи сидящие на нужной вам ноде выходят из фермы; Вы в кластере отсанавливаете освободившуюся ноду (чтобы на неё не попадали запросы пользоватиелей); Пользователи снова заходят в ферму, попадая при этом уже на другие ноды, а благодаря механизму перемещаемых профилей они по прежднему смогут работать с файлами, хранящимися в их профилях.
По данной статье и следующей (о профилях) реализовал RDCB. Отличное описание настроек.
Вопрос по решению проблемы с "горячим" переключением пользователей остается открытым. Хотелось бы узнать, сталкивались ли Вы с его решением на практике и возможными вариантами реализации.
"Нужно проверить то, что адрес кластерного ресурса службы RDCB корректно зарегистрировался в DNS и доступен в сети."
C этим могут быть проблемы, нарвался на ошибку типа:
Ресурсу "Сетевое имя 'Network Name (com1)'" кластера не удалось удалить связанный объект компьютера в домене '' по следующей причине: Не удается создать учетную запись компьютера.
Решение здесь:
http://technet.microsoft.com/ru-ru/library/dd421851%28v=exchg.80%29.aspx
Это из разряда граблей, которые администраторы расставляют себе сами. Например установил на объект компьютера в AD признак защиты от удаления, а потом пытаешься выполнять манипуляции с кластерным экземпляром (удаление/повторное создание) и получаешь черенком по лбу :)
Алексей, доброго время суток.
Ферма настраивается на серверах Windows 2008 R2 Enterprise. А контроллер домена у нас все еще на базе Windows 2003 server. Не приходилось ли настраивать ферму в таком окружении? Могут ли из-за этого возникнуть какие-нибудь проблемы? Я сначала думал, что грабли на которые я наступил связаны именно с этим.
Нет. Не приходилось. Описанный пример разворачивался в нативной среде Windows Server 2008 R2.
Обратная ссылка: SAP Business Explorer Analyzer в Терминальной ферме. | IT Blog /
Алексей, добрый день. А как быть с кластером, если есть несколько железных серверов? Не вижу необходимости держать все три ноды виртуалками на одном железном сервере. У меня есть 6 железных серверов, на каждом живет Xen и виртуальные W2K8R2. Как их правильно в кластер и с брокером?
А вам вроде бы тут никто и не внушал то что есть необходимость держать три виртуалки на одном железном сервере. Как размазать виртуалки по хостам - дело абсолютно ваше личное. А для построения фермы в бОльшим количеством виртуалок по предложенной мной схеме нужно придерживаться нечетного количества виртуальных серверов, например 5 или 7, чтобы смог работать принцып определения большинства активных узлов в кластере, то есть минимум живыми должно быть половина нод + 1 (кластер с моделью кворума большинства узлов – Node Majority). Либо если вы хотите использовать именно 6 нод, тогда меняйте модель кластера - например используйте в качестве дополнительного голоса в кластере шару-свидетель на стороннем сервере, хотя схемы со всякими там левыми сведетелями тоже "палка о двух концах".
Это понятно.... Оставлю одну виртуалку вне кластера. Вопрос по сетевым подкючениям. Для нормальной работы достаточно ли одного линка или все таки правильнее использовать две сетевых карты, подкюченные к разным коммутаторам (или к разным vlan)?
Это не имеет значения, - если вы используете виртуальную среду, то можете настроить абсолютно любую удобную для вас конфигурацию сети. Например при желании можно вообще все пять виртуальных машин сложить на один физический хост и пустить весь трафик через один физический интерфейс этого хоста или взять и разнести вообще всё на свете по разным хостам и физическим интерфейсам. Если вы чётко понимаете возможности своего оборудования и знаете что хотите получить на выходе, то помоему таких вопросов и возникать не должно.
Иногда мне задают такие вопросы в комментариях, от которых я прихожу в иступление, потому что просто не понимаю, что человек хочет услышать в ответ...
Повторю ещё раз: Правильно сформулированный вопрос содержит в себе половину ответа.
Отличная статья! Спасибо!
Хотел бы узнать, есть ли доступная GUI утилита для выдергивания списка залогинившихся пользователей через RDCB из активной БД ?
Смотреть на каждом сервере список не очень удобно.
Это стандартная консоль Remote Desktop Services Manager (%windir%system32tsadmin.msc). Она в одном месте отображает сессии пользователей на всех серверах фермы и позволяет ими управлять. В этой статье есть даже скришот этой консоли http://amaksimov.files.wordpress.com/2011/12/image35.png
Да, но если у меня 3 сервера HOST и почти (в теории планируется) 350-400 подключений, то мне необходимо в одну единицу времени знать сколько сейчас подключений активных. На текущий момент делаю 3 запроса в PS на предмет количества сессий на каждом хосте и потм суммирую. Хотелось бы иметь инструмент читающий информацию из БД брокера. Может я не прав конечно....
Для этого я использую Zabbix. Сделал в нём скрин лист где показана загрузка всех TS и количество активных ts сессий.
Если для оперативного выяснения, то да - PowerShell. Если же инфа о количестве сессий нужна за период для какого-то планирования распределения ресурсов - то лучший вариант это MP для RDS в SCOM который собирает статистику по системным счетчикам производительности и по этим данным можно получить налядный график в разрезе времени.
Да, пока для оперативного.
Использую или http://technet.microsoft.com/en-us/library/cc731503%28WS.10%29.aspx или http://gallery.technet.microsoft.com/scriptcenter/e8c3af96-db10-45b0-88e3-328f087a8700
Спасибо!
Добрый день!
Хотел бы узнать. А сколько времени хранится в базе 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 просто перечисление серверов фермы
Используйте систему мониторинга , nagios или zabbix
Вроде все фурычит, но на шаге с сертификатами нужно указать ТЕМПЛЕЙТ. Вот подсунул ему "веб сервер" - ругается на сертификат. какой правильно темплейт ему подсовывать при сабмите запроса ?
Не уверен что шаблон "веб сервер" подойдёт.
Как отмечено, необходимый минимум это:
OID=1.3.6.1.5.5.7.3.1 ; Server Authentication
OID=1.3.6.1.5.5.7.3.3 ; Code signing
Поэтому или надо делать специальный шаблон, или делать сертификат по кастомному запросу, как это описано здесь.
Короче, с сертификатом налом. По инструкции вашей - не пашет. Ругается, как не крути ... http://www.mytechstuff.info/2012/01/blog-post.html вот тут более разжеванно, но таже беда. все тожесамое
С сертификатом поборол беду. У вас запрос с ошибками в статье. Долго расписывать (нужно тут еще шаблон создавать измененный). Кому надо - обращайтесь на почту.
Хватит воды. По существу. О каких ошибках речь. Все написано по проделанной на практике работе.
Заметка писалась вообще не на примере доменного ЦС, а на примере изолированного. Там нет такого понятия как шаблоны сертификатов в принципе, и поэтому здесь об этом нет ни слова.
С доменным ЦС запрос будет такой
[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.
Далее в доменном центре сертификации нужно выполнить запрос, как написано выше, применив новый шаблон.
Мож оно кому пригодится ...
Здравствуйте, Алексей я поднял тестовую среду по вашей статье до сертификатов еще не дошоль. кластер поднался без проблем и имя созолос в днс -е и для сомого кластера и для точки подклучения для клиетов ип аддресс и названия точки подлучения пингуется но при наборе ип или имени броккера в R.D.C подклучение не произходит по иде я должен бил попаст на активнузю ноду кластера с брокером?
Активными являются все ноды кластера, но лишь одна из них выполняет функции RDCB (та которая является на данный момент владельцем кластерного экземпляра CB). При подключении по FQDN брокера клиент перенаправляется брокером на самую незагруженную ноду кластера.
то есть клиент подключается к активное ноде с названием tersrv03.contoso.com, после того как не дай бог этот сервер упадет и активной Нодой станет tersrv02.contoso.com клиенты должны будут подключаться к адресу tersrv02.contoso.com. Если это так то как можно создат единую точку входа для ползовотелей. Я думал что етa точка должна била быт ИП или FQDN Client Access Pointa . На у меня почемута етот адрес не отвечает на 3389 порту.
Клиенты должны подключаться именно к FQDN брокера, а не какого-то отдельного сервера. А то почему у вас брокер не отвечает клиентам - вопрос не ко мне.
у вас должен был появится (в моем случае я руками создал, ибо нужны права в домене на создание обьектов) еще 1 компьютер в домене с именем кластера. В данной статье это dns=KOM-AD01-RDSCB.holding.com. Вот туда и нужно стучать, а отвечать вам уже должна та нода, которую брокер выбрал. В данной схеме брокер плавающий получается. Тоесть брокер всегда живет только на одной ноде. Если она отвалится - он переедет на другую.
и да, спасибо вам за хорошую статью. По ней поднял у себя кластер, который прекрасно работает.
я понял. Значит в ДНС - е надо создат 3 записи типа А terminal.contoso.com указиваюшие на ип адреса всех терминалних серверов входаших в ферму. Когда 3 клиента подклучется к terminal.contoso.com хозаин роли Брокера разкидовает их о етим 3м серверам и записовает инфу о местонахаждении каждого ползовотеля в свою локалную базу после чего репличирует ету инфу на другие НОДИ в кластере. После отклучения хозаена роли брокера один из нод берот на себя ету рол и при переподклучении ползовотелей он уже знает у кого где ест откритий сеанс и перенаправлает их на соотведствуяшиые сервера.
добрый вечер, наконец то добрался дo сертификатов, у меня CA Enterprise метод описонний в стате для меня не работает, метод которий предлогает voffka тоже не сработал .Зделал как говарится в етой стате http://compulinx.blogspot.com/2011/03/how-to-setup-remote-desktop-session_06.html и у клиентов не вискакивает никаких предупреждений все роботает.
другой вопрос про sizeing. Может кто небут подсказат как расчитоват ресурсы. Примерно 200 ползовотелей 2 сервера
Тут будет основной упор на производительность HDD. RAID10 из хардов по 10К точно потянет.
Алексей, добрый день. Прочитал статью - все отлично описано, но есть такой вопрос - откуда берется адрес шлюза для единой точки входа? У меня получается странная вещь, если подключаться из этой же подсети, все работает на ура, если же из другой - ресурсы даже не пингуются
Могу предположить что для кластерного адреса брокера вы использовали адрес из подсети в которую не входит интерфейс самого сервера. Обратите внимание на то что в моём описании и для адреса кластерного экземпляра брокера и для адресов самих серверов выбрана одна подсеть 10.160.0.0/24. Соответсвенно адрес шлюза для активной на данный момент ноды используется с интерфейса самой ноды и поэтому беспрепятсвенно работает маршрутизация трафика в другие подсети.
Такая вот непонятная ситуация возникла – ферма поднята из 5-ти серверов, всё работало нормально на протяжении пары месяцев, служба RDSCB установлена на всех серверах, т.е. переезжала по серверам. И вот не так давно перестало работать распредение нагрузки – все пользователи заходят только на один из серверов. При принудительной передаче роли RDSCB на другой сервер часть клиентов отвалилась и они зашли уже на другой сервер, остальные так и продолжают нормально работать на предыдущем сервере. Мастер проверки кластера проводит все проверки с положительным результатом, сети настроены нормально. Может подскажете, куда копать? Заранее благодарен за любую оказанную помощь и участие!
Был такой глюк. Оказалось что была проблема с именами терминалок добавленными в группу брокера. Появилась после установки MUI. Нужно удалить и заново добавить всех членов в группу на всех серверах
Точнее с именами групп . осле установки MUI группы для брокера стали называться по Русски
Куда компать не подскажу, потому что не знаю откуда могут расти ноги у проблемы. Для анализа ситуации нет вообще никаких данных кроме "работало, а потом вдруг перестало". Как вариант (наиболее оперативный) - разобрать кластер и собрать заново.
Если уж подставляешь "правильный" сертификат, то зачем же оставлять режим Negotiate? Почему сразу не поставить TLS1.0? Смысл идеи с сертификатами теряется, тем более, что в допуске "в нашем окружении нет устаревших клиентов", а поддержка NLA идет уже с XP SP3.
Ничего не теряется. Новые клиенты будут использовать усиленные механизмы защиты соединения, старые - нет. С клиентами XP и была какая-то засада, но сейчас подробности уже не вспомню.
Подскажу подробности: у клиентов ХР по умолчанию не работает "понимание" NLA. SSL/TLS здесь не при чем, эти протоколы они понимают еще с SP0. Не понимаю совсем старые Win95-98, но таких даже в домен завести проблемно. Используя Negotiate можно по требованию клиента просадить уровень связи до LM или Plan Text, в которых сертификат не нужен по умолчанию. Ещ раз, ты разговор ведешь о "неустаревших" клиентах, а там гайки закручивать надо до упора.
И уж конечно же "правильный" сертификат для 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 - по необходимости/желанию.
По поводу OID могу сказать что на момент написания заметки в библиотеке течнета я нигде не видел упоминания о 1.3.6.1.4.1.311.54.1.2. Ну и как то ферма с вышеописанными сертификатами работает и по сей день.
Вот к примеру, на вскидку, статья написанная гораздо раньше твоей, где этот OID уже упоминается. http://appjournal.livejournal.com/4853.html.
Еще раз. Этот OID был введен еще с 2008 сервера SP1 (если не ошибаюсь), а ты пишешь про 2008R2, в котором это уже изначально заложено. Вариант нашел/ненашел - не серьезный.
Про "как то ферма с вышеописанными сертификатами работает и по сей день". Именно, что как-то. Подсунь туда же сертификат сделанный на основе шаблона "веб-сервер" и он так же будет скушан и ни один клиент не подавится (не нравится слово "шаблон" - сделай ручками, через request). Разговор идет о "правильном" сертификате, а он должен содержать "правильный" OID. Я прекрасно понимаю, что статья не о сертификатах, а о ферме в целом, но такие нюансы отравляют впечатление об достаточно хорошей, доходчивой статье.
При развертывании фермы и написании своей заметки я руководствовался достуными на тот момент материалами библиотеки течнета, где говорилось о том что для 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.
Тяжело вам приходится :) Пулемёт подарить?
Алексей, добрый день. Насколько я понял механизм работы такой конструкции, в кластере есть понятие того, на какой сервер пошлет пользователя Connection Broker, Причем такой сервер указан только один. Если этот север оказывается не в сети, то параметр текущего указывает уже на другой сервер и fail-over срабатывает. Но как сделать так, чтобы во всей этой связке удаленные соединения поступали не только на сервер, указанный текущим, а на другие сервера фермы тоже? Другими словами: как правильно разделить нагрузку между работающими серверами кластера?
За равномерное распределение пользователей по серверам как раз и отвечает движок Connection Broker
Обратная ссылка: Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012 | Блог IT-KB /
Обратная ссылка: Решаем проблему запуска SAP Business Explorer Analyzer из Excel 2010 в ферме серверов RDS | Блог IT-KB /
а как быть с приложениями?, мне бы хотелось чтобы на таком кластере крутилось 1с например, такое возможно?
Хорошее решение для тонких клиентов. Спасибо!
Александр, 1С разумеется возможно, как и массу других бизнес-приложений. Если же говорить в целом об архитектуре, то на самом деле RDCB на Windows Server 2008 R2 на сегодня это уже неактуально. Думаю стоит смотреть в сторону более новых систем, например по этому сценарию.
я понимаю, но имеем лицензии только на 2008 сервер
А через веб морду приложения видны? Что указали в источниках remoteapp?
Если речь идёт про настройки источников в веб-интерфейсе RDWA, то в нём был указан адрес кластера RD Connection Broker (KOM-AD01-RDCB).
А в настройках самого брокера? Роли->Службы УРС-> Диспетчер подключений к удаленным рабочим столам->Источники RemoteApp
Сейчас по пунктам перемещения в интерфейсе настроек RDS WS2008R2 уже не сориентируюсь :) Перед глазами таких систем уже нет, так как перебрался на Windows Server 2012, а там всё кардинально по другому и поэтому старые системы уже начал забывать. Если со скриншотами зададите вопрос в форуме - возможно пойму о чём идёт речь и что-то отвечу.
Хотел спросить, может встречался с такой ситуацией. В "Диспетчере служб удаленных рабочих столов" на вкладке "Пользователи" некоторые сервера фермы указаны, как DN, а некоторые и как DN и как FQDN, т.е. 2 раза каждый пользователь. С чем это может быть связано? причем день ото дня ситуация меняется.
Алексей, прежде всего, огромное спасибо за столь подробную статью. У меня есть несколько вопросов:
1. В чем преимущества данной схемы над схемой, где RDCB использует для хранения сессий SQL-базу данных (пример описан здесь http://habrahabr.ru/sandbox/49629/)
2. Немного непонятно, как сделать отказоустойчивой точку вхождения пользователей в ферму? Представим ситуацию: все это хозяйство находится в удаленном ДЦ. Пользователи видят только белые адреса серверов в Интернете. Я вижу это так: каким-то внешним DNS-сервером рандомно кидать пользователей на 1 из 3 серверов с RDCB, а они, в свою очередь, решат, на какой сервер отправить входящее подключение. Верно?
1. Вопрос поставлен некорректно. В данной статье рассматривается RDCB на базе Windows Server 2008 R2, а в приведённой Вами ссылке речь идёт о Windows Server 2012. В этих двух системах RDCB различается.
Для Windows Server 2012 у меня была написана отдельная статья https://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
Спасибо! Еще немного непонятно с точкой вхождения в вашей схеме. У вас это некий узел 10.160.0.39. Именно к этому адресу будут подключаться пользователи? Это же отдельный сервер, его тоже нужно сделать отказоустойчивым? Или я где-то упустил нить..?))
10.160.0.39 - это адрес кластерного экземпляра RDCB, а не какой-то "отдельный сервер". Это точка подключения клиентов.
День добрый! После создания фермы, в корневом элементе консоли Remote Desktop Services Manager в меню действий выбираем пункт Import from RD Connection Broker, и сервера не появляются в списке фермы, или появляются но два из трех. Все сделал исходя из вашей статьи, за которую вам отдельное спасибо! При этом ферма работает, пользователи подключаются по имени кластеризованного экземпляра RDCB на различные узлы. Служба RDCB запущена на одном из трех узлов. В чем может быть проблема подскажите плз?
Алексей, добрый день! Отличная статья, одна из "жемчужин" Вашего блога, спасибо. Хотел уточнить один момент: возможно ли заменить сертификат, созданный кастомным запросом на wildcard, созданный сторонним издателем на мой внешний домен (*.domen.ru)? На внутреннем DNS сервере AD (внутренний домен domain.local) зона domain.ru присутствует и я могу назначить внутренним машинам А-записи в domain.ru. Сможет ли данная схема работать в этом случае?
Не скажу. Надо пробовать. У меня фермы на 2008 R2 уже давно нет (перебрались на 2012 R2), поэтому даже и проверить негде.
Алексей, я проверил, с wildcard все работает. Появилось еще два вопроса:
1) В статье Вы написали: Для того чтобы проверить то, что наша ферма действительно создалась, в корневом элементе консоли Remote Desktop Services Manager в меню действий выберем пункт Import from RD Connection Broker…
Когда я импортировал по имени фермы, у меня отображается только один сервер, текущий в кластере, два остальных не видны и служба RD Connection Brocer на них не запущена и не запускается.
2) Я пытался "прикрутить" созданную ферму к порталу UAG (там используется тот же wildcard, что и на терминальной ферме), но при вызове удаленного приложения появляется предупреждение о том, что запускаемое удаленное приложение может нанести вред локальному или удаленному компьютеру (если нажать ок приложение запустится). Ранее я думал, что подобная ситуация возникает из-за того, что опубликованные приложения подписаны сертификатом локального домена (*.domain.local). Но на новой ферме все опубликованные приложения подписаны внешним сертификатом. Получается, что есть какие-то особенности публикации приложений на UAG? Если пользоваться простым клиентом RDP (открыт порт фермы наружу), то все работает, а через UAG - нет.
certutil -setreg policyEditFlags +EDITF_ATTRIBUTESUBJECTALTNAME2
Тут не хватает бэкслеша "policy\EditFlags". Лоб себе расшиб об эти грабли пока не понял. А так все работает, за статью огромное спасибо!
Виноват. Исправлюсь.
Согласен. Не хватает бекслеша.
Алексей, просьба попроавить в статье!
Исправил.
Настраиваю отказоустойчивый кластер
Делаю создать новый кластер добавляю ноды terminal01 terminal02 terminal03
Назначаю Имя кластера ввожу IP
Проблема не проходит установка
Идет установка и на этапе настройка объекта компьютера как объект имени кластера операция идет дольше чем ожидалось зависает
Возникла проблема с генерацией сертификата, форма отличается от вашей, в ней присутствует еще поле шаблон сертификата которое не убирается, и в нем отсутствует проверка подлинности сервера. Соответственно сертификат генерируется не правильно, пробовал несколько раз на разных развернутых с нуля ЦС, может где настройка есть?
Настроил по инструкции тестовую ферму из 3 серверов + SQL(пока без сертификатов). Вместо NLB использую DNS RR. Все развернуто в виртуальной среде VMware.
Эксперимент: подключаю 6 пользователей к ферме. RDCB раскидывает по 2 пользователя на каждый RDSH. Отключаю от сети один из серверов. 2 пользователя отваливаются. Пытаюсь подключиться снова - RDCB запрашивает авторизацию, а после успешной авторизации не происходит создание новой сессии на другом RDSH. Клиент просто не может установить соединение.
Сессии "отвалившегося" сервера продолжают фигурировать в списке, закрыть их не получается. Пользователи не могут работать.
Если я правильно понимаю ситуацию, RDCB проводит авторизацию, видит, что у пользователя уже есть активная сессия и пытается переправить пользователя на "мертвый" сервер.
Google молчит. Натыкался на несколько подомных случаев, но все они остались без ответа.
Помогите решить проблему. 2 недели уже бьюсь.
А почему DNS RR? Он ведь не умеет определять живучесть конечного сервера. Может отправлять запросы на подключение в никуда. А вообще все похоже на то, что служба RDCB у вас висит не на тех сетевых интерфейсах. Похоже, что на адаптере, который относится к кластерной сети. Хотя я могу ошибаться...
Алексей спасибо за статью, очень информативно, а вот если бы Вы написали статью как на любой терминальной ферме правильно настроить 1С 8,3 отказоустойчивый кластер, было бы шикарно. Потому как мои попытки оказались четными.
Отвечу спустя 3 года :)
Об этом будет написано в Вики. Чуть позже. Черновики уже готовы.
Та часть, которая касается настройки экземпляра SQL Server под 1Сv 8.3 там уже почти закончена.
https://wiki.it-kb.ru/1c/setting-up-microsoft-sql-server-for-1c-enterprise-8-3
Здравствуйте!
Есть 4 физических сервера (win serv 2016) с функционалом Remote Desktop Session Host. У нас стоит задача расшаривания тома с дискового массива Dell на этих серверах, подключенных к нему посредством FC (без коммутатора). Насколько я понял, для этого нужно включать failover clustering на всех серверах и создавать кластер. Я это сделал. Том из массива подключен как кластерный диск (CSV). Тестировал одновременную запись на него с разных серверов. Вроде работает, чекдиск после этого не ругается. Дополнительно потребовалось установить фичу MPIO.
Вопросы:
1. Является ли это единственным / оптимальным решением задачи расшаривания.
2. Как правильно организовать доступ с клиентов к С:\ClusterStorage\Volume1 (так по дефолту монтируется кластерный диск). Напрашивается какая-нибудь прокладка. Что посоветуете?
3. Если нет задачи обезличивания серверов, то нет смысла ставить броккера?
4. Нужно ли поднимать какие-то кластерные роли? Что даст поднятие роли файлового сервера? Там два варианта.
5. Возникает ошибка при перезагрузке серверов кластера:
Cluster network name resource 'Имя кластера' encountered an error enabling the network name on this node. The reason for the failure was:
'Unable to obtain a logon token'.
The error code was '1311'.
You may take the network name resource offline and online again to retry.
Притом что реальное имя кластера "suits" есть в AD, и команда "nslookup suits" выдает IP кластера.
6. На расшареном диске будет ощутимый профит если использовать дедубликацию. Будут ли какие-то проблемы с ней. Одну я уже обнаружил. Проводник не верно показывает объем свободного места на диске с включенной дедубликацией, после удаления файлов.
Здравствуйте, Сергей.
Столько вопросов и все не по теме поста. Статья написана достаточно давно про WS2008 R2. Там службы RDS функционировали по другому, если сравнивать их с WS2016. Всё, что касается кластеризации, как таковой, и всяких там CSV и прочих дедуПликаций, лучше спрашивать на профильных форумах TechNet. Ну либо можете тут https://forum.it-kb.ru/ позадавать вопросы, разделяя их по отдельным логическим темам, а не сваливая всё в один сплошной поток сознания.
Могу согласится, что вопрос о дедубликации здесь лишний. Все остальное посвящено одной теме. И Вы затронули ее. Цитирую:
" Такая модель кластера снимает требование к общему кластерному диску и мы можем получить дополнительный уровень абстрагирования от физической среды с использованием FC/SAS/iSCSI "
Ответив на мои вопросы, Вы могли бы раскрыть ее.
Насчет "не по теме" - не согласен. Все, что описано в блоге есть в моем решении, за исключением брокера. Но я подумываю над его установкой.
По поводу различий 2008 и 2016, и всяких умных слов про актив пассив и т.п., хочу сказать, что я разницы не понимаю. Как я уже писал два пользователя могут одновременно зайти на разные узлы кластера и одновременно производить запись на кластерный диск, несмотря на то, что лишь один из них является владельцем диска, а у другого это диск (в диспетчере устройств) находится в состоянии reserved.
Ещё раз. Статья написана исключительно в контексте настройки роли RD Connection Broker и только применительно к WS2008 R2. И к WS2016 это не применимо вообще, так как начиная с WS2012 концепция повышения доступности RD Connection Broker существенно изменена.
Такое ощущение, что блог писал один человек, а сейчас мне отвечает кто-то другой.
Сергей ну зачем же так тупить то? Черным по белому и внятным языком тебе объесняют, что разница между 2008R2 и 2016 колоссальная!!!
Как говорил персонаж известного фильма, это слово редко удается использовать в речи. А в данном случае оно вообще не уместно, поскольку, для использования кластерных дисков на основе FC, iSCSI или SAS, похоже, что настройка одинакова, что для 2008, что для 2016.
Меня реально бесит, когда люди хуже меня разбирающиеся в теме пишут, что угодно, лишь бы скрыть это. Неужели так сложно написать "Я не знаю", или не писать вообще ничего !!!