Ранее мы рассматривали пример скриптовой реализации контроля простаивающих пользовательских сеансов на серверах Remote Desktop Session Host (RDSH). В комментариях к этой заметке один из наших постоянных читателей - Солодовников Матвей (aka equinox) отметил то обстоятельство, что при использовании представленного скрипта возникают проблемы с правильностью определения времени простоя сеансов. И связано это с тем, что командлет Get-RDUserSession может возвращать некорректное значение времени простоя IdleTime для активных сессий со статусом STATE_ACTIVE. Наша практика использования скрипта подтвердила наличие этой проблемы, поэтому в данной заметке мы рассмотрим альтернативный вариант скрипта, решающий данный вопрос.
-
Отключение и завершение простаивающих сеансов на серверах Remote Desktop Session Host в зависимости от дня месяца и членства в доменной группе. Вариант 2: Избавляемся от некорректных значений IdleTime в Get-RDUserSession
-
Отключение и завершение простаивающих сеансов на серверах Remote Desktop Session Host в зависимости от дня месяца и членства в доменной группе
Как правило, для отключения неактивных и завершения отключенных сессий на серверах сеансов служб удалённых рабочих столов Remote Desktop Session Host в Windows Server 2012 R2 администраторы используют возможности групповых политик домена Active Directory. Однако иногда может возникать потребность в управлении неактивными сеансами по хитрым правилам, которые невозможно уложить в рамки стандартных механизмов GPO или даже GPP. В таких случаях для управления сеансами можно прибегнуть к возможностям PowerShell. -
Windows Server 2012 R2 Remote Desktop Connection Broker - Подключение было запрещено, так как учетная запись пользователя не имеет прав для удаленного входа в систему.
В продолжение темы, ранее описанной в заметке Windows Server 2012 R2 Remote Desktop Connection Broker — Невозможно подключиться к высоко-доступной ферме RDS — Подключение было запрещено… один из комментаторов к этой заметке навёл на идею использовать для подключения к высоко-доступному экземпляру RDCB вместо специально настроенного RDP-файла на стороне клиентов, настройку параметра реестра DefaultTsvUrl на серверах RDCB. -
Windows Server 2012 R2 Remote Desktop Connection Broker - Предупреждение безопасности RDP-клиента при использовании доверенного сертификата.
Выполнено развёртывание Remote Desktop Service на базе Windows Server 2012 R2 в конфигурации с высоко-доступным RD Connection Broker. В свойствах развёртывания для нужд RD Connection Broker SSO назначен сертификат, выпущенный внутренним Центром сертификации, корневому сертификату которого доверяют все клиентские компьютеры локальной сети. Казалось бы, все минимальные условия для беспроблемного подключения клиентов к ферме RDS соблюдены, однако в процессе подключения у RDP-клиента возникает дополнительный вопрос о том, действительно ли мы доверяем “Издателю”.
-
Windows Server 2012 R2 Remote Desktop Connection Broker - Невозможно подключиться к высоко-доступной ферме RDS - Подключение было запрещено…
Наконец-то добрались руки до того, чтобы развернуть новую ферму высоко-доступного RD Connection Broker на базе Windows Server 2012 R2. В отличие от конфигурации, которая описывалась ранее, было решено выполнить разделение ролей RDS и отказаться от использования NLB в пользу DNS Round Robin. При планировании развёртывания акцент был сделан на то, чтобы в итоге получить конфигурацию, которую можно будет считать более или менее поддерживаемой Microsoft. В результате получилась конфигурация из двух виртуальных серверов с совмещенными ролями RD Connection Broker/RD Web Access и пяти виртуальных серверов с выделенной ролью RD Session Host. А в силу того, что роли RD Connection Broker и RD Web Access не сильно требовательны к ресурсам, мы не стали создавать для них выделенные сервера, а установили эти роли на уже работающих серверах App-V 5.0 (с ролями Management Server, Publishing Server и Reporting Server, по аналогии с теми, которые были описаны в заметке App-V 5 for RDS - Разворачиваем инфраструктуру повышенной доступности, только уже на базе Windows Server 2012 R2). Читать далее... -
High Availability RD Connection Broker на базе Windows Server 2012–выявленная закономерность в конфигурации с более чем 3 серверами
В процессе тестирования конфигурации описанной в предыдущей статье выявлена странная закономерность в поведении работы высоко-доступного экземпляра RD Connection Broker (RDCB). Обнаружено, что если роль RDCB (в режиме High Availability) добавлена в развёртывании RDS более чем на три сервера (в нашем случае - на пяти серверах), то адекватно работают с общей базой данных RDCB не более трёх серверов, на которые раньше всего была развёрнута эта роль. -
Remote Desktop Services – Строим отказоустойчивую ферму RD Connection Broker на базе Windows Server 2012
Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
- Среда исполнения
- Подготавливаем виртуальные сервера
- Создаём кластер NLB
- Подготавливаем SQL Server
- Устанавливаем роли Remote Desktop Services
- Создаём высоко-доступный RD Connection Broker
- Добавляем сервера в высоко-доступный RD Connection Broker
- Добавляем на сервера роль RD Web Access
- Создаём коллекцию сеансов – Session Collection
- Настраиваем цифровые сертификаты
- Настраиваем веб-узлы RD Web Access
- Настраиваем Roaming User Profiles и Folder Redirection
- Публикуем приложения RemoteApp
- Устанавливаем языковой пакет
- Настраиваем перенаправление печати -
Remote Desktop Services - Строим отказоустойчивую ферму RD Connection Broker
Начиная с этой записи, постараюсь сделать ряд заметок о Службах удалённых рабочих столов 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 будет использоваться локальная база с информацией о всех пользовательских сессиях в ферме и лишь одна из нод кластера будет иметь активный экземпляр этой БД, который будет использоваться при обслуживании пользовательских запросов всей этой фермы. В случае недоступности активной ноды БД перестроится на другом сервере и начнёт обслуживать запросы клиентов.
Онлайн-курсы Евгения Лейтана
Внедрение Microsoft System Center Operations (SCOM) 2016/201913 уроков (6 часов видео), лабораторные работы и вручение именного сертификата.
Промокод "IT-KB_60" со скидкой 60%!
RSS - Записи