Как сделать терминальную ферму

Обновлено: 07.07.2024

wtware и ферма терминальных серверов windows 2012 R2

wtware и ферма терминальных серверов windows 2012 R2

Имеется:
wtware сервер v.5.2.26 (192.168.1.251) с tftp без dhcp
dhcp сервер на windows 2012 r2 (192.168.1.252)
rd connection broker сервер на windows 2012 r2 (192.168.1.246 - RDCB1.EA.LOCAL)
rd session host сервера на windows 2012 r2 (192.168.1.239 и 192.168.1.227)

Подключение из windows через mstsc.exe проходит как надо. Посредник подключение перенаправляет на нужный сервер сессий.
Тонкий же клиент попадает именно на сервер посредника. Перенаправление на сервера сессий не происходит.

Конфиг тонкого клиента:
language=ru,default
keyswitch=alt-shift
shared_disk=usb
disk=
sound=on
timezone=
numlock=off
resolution=1024x768
shared_usb=
mouse_accel_mult=2
graphic=af
printer=usb
scanner=on
turnoffmenu=off
user=ea\ean
bpp=16
video=auto
server=RDCB1.EA.LOCAL
infobox=lctrl
loadbalanceinfo=tsv://MS Terminal Services Plugin.1.farm
ask_password=off
template Common
connection

В логе всё выглядит хорошо, но сервер не присылает пакет перенаправления.

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

2. Покажи .rdp файл соединения с виндовса, который точно работает.

1. Сделал как сказали. Заработало. Но не так как ожидалось.
Если на клиенте включить параметр ask_password=on, то выводиться окно WP_20150514_001.jpg. Жмем интер, попадаем в WP_20150514_002.jpg. Жмем другой пользователь, попадаем в WP_20150514_003.jpg. После ввода пароля подключает уже на сервер сессий, но так же требует повторный ввод пароля WP_20150514_004.jpg.
Настройка параметров безопасности для сеансов WP_20150514_005.jpg. Политика безопасности "требовать проверку подлинности пользователя для удаленных подключений путем проверки подлинности на уровне сети" отключена.
Без параметра ask_password просто не выводиться окно WP_20150514_001.jpg, а далее все точно так же, как и с ним.
Все скрины и логи в вложениях.

2.
redirectclipboard:i:1
redirectprinters:i:1
redirectcomports:i:0
redirectsmartcards:i:1
devicestoredirect:s:*
drivestoredirect:s:*
redirectdrives:i:1
session bpp:i:32
prompt for credentials on client:i:1
server port:i:3389
allow font smoothing:i:1
promptcredentialonce:i:0
videoplaybackmode:i:1
audiocapturemode:i:1
gatewayusagemethod:i:0
gatewayprofileusagemethod:i:1
gatewaycredentialssource:i:0
full address:s:RDCB1.EA.LOCAL
workspace id:s:rdcb1.EA.Local
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.farm
use multimon:i:1

Вложения 2.rar (199.61 КБ) 570 скачиваний 1.rar (225.32 КБ) 561 скачивание logs.rar (69.21 КБ) 531 скачивание

twin писал(а): Но не так как ожидалось.
Если на клиенте включить параметр ask_password=on, то выводиться окно WP_20150514_001.jpg. Жмем интер, попадаем в WP_20150514_002.jpg.

НЕ вводим пароль, а сразу жмём интер?

В виндовсе ты вводишь логин и пароль на клиенте. В интерфейсе, который рисует клиентский mstsc.exe. И потом клиентский mstsc.exe шлёт эти логин и проль серверам и в первый, и во воторой раз при перенаправлении. Потому и не видишь экранов ввода юзера и пароля.

Втварь тебе предлагает ввести логин и пароль, когда в конфиге написано ask_password=on. Ты отказываешься вводить пароль. Действительно, почему же не оно без пароля не работает?

Если втварь знает юзернейм И пароль, она их скажет серверу. И при перенаправлении второму серверу тоже скажет. Юзернейм и пароль придётся ввести один раз в втвари. Так же, как и в mstsc.exe

Задача: для себя как шпаргалка пошагово рассмотреть, как развернуть терминальный сервер , активировать лицензии на пользователя и на устройство в операционной среде Windows Server 2008 R 2, чтобы в последствии можно было тестировать различные штуки и настраивать такие вещи, как:

  • Терминальная ферма
  • Перемещаемые профили для терминального профиля
  • Распределение нагрузки
  • Подключение c Ubuntu станций к терминальной ферме

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

Srv — ad . polygon . local

Srv-ts.polygon.local

w7x86.polygon.local

Переходим на станцию srv-ts: —

Start – Control Panel – Category (Small Icons) – Administrative Tools – Server Manager – Roles – Add Roles – Remote Desktop Services

Remote Desktop Session Host

Remote Desktop Licensing

В процессе установки потребуется выбрать метод проверки подлинности — требовать проверку подлинности на уровне сети или нет. Включение проверки (рекомендуемое) обеспечит повышенную безопасность, но в этом режиме к серверу не смогут подключаться пользователи с устаревшими клиентами (rdp 5.х и ниже).

На заметку: версию RDP клиента всегда можно обновить.

Я указываю: Do not require Network Level Authentication

На заметку: метод проверки подлиности всегда можно изменить если что.

Далее потребуется указать по какому принципу осуществлять выдачу лицензий на работы с терминальным сервером;

Я выбираю на пользователя — Per User

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

Далее указываю, что лицензии будут распространяться на текущий домен — This domain

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

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

Ниже я рассмотрю пошаговые действия по активации сервера лицензий терминалов:

Start – Control Panel – Administrative Tools – Remote Desktop Services – Remote Desktop Licensing Manager

после чего переключаемся в окно где был сгенерирован Product IT нашей системы и из буфера обмена копируем данный ключ в соответствующее поле :

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

И конечно же не за бываем отметить пункт « Start Install Licenses Wizard now”

Теперь переходим к получению клиентский лицензий ( CALs), когда выбрали пункт на предыдущем скриншоте « Start Install Licenses Wizard now” — мастер перекидывает на диалоговое окно активации клиентский лицензий.

Из этого окна копируем в буфер обмена идентификатор вашего сервера:

Следующим шагом указываем нужное количество необходимых нам лицензий (если покупали ключ, то то количество лицензии которое идет по этому ключу), тип продукта, а также номер соглашения по программе лицензирования (данные номера обычно получают входе покупки или найденный в сети интернета):

В данной заметке я рассматриваю:

Хоть я и повторюсь, но сделаю это наглядно: номера соглашения могут быть случайными цифрами вроде этих: 6565792 , 5296992 , 3325596

и в конечном итоге Веб страница лицензирования сформирует код пакета ключей который нужно будет ввести в Мастере установки клиентской лицензии удаленных рабочих столов:

Скопировав выше код пакета в буфер обмена переключаемся на окно активации клиентских лицензии и вставляем его в соотвествующее поле :

Нажимаем “Next” и радуемся тому, что лицензирование на пользователя успешно завершено

После чего теперь оснастка в которой я показывал как активировать сервер терминалов порадует такой возможностью, как наблюдение за тем какое количество лицензии сейчас используется:

, замечу, что это мы активировали лицензии на пользователя равное 9999 (как пример), по аналогичному принципу проделываем получения кода активации на компьютер. Здесь же заострять пошаговость этого процесса я не буду.

Хотя, нет все же распишу, но без указания скриншотов шагов:

Start – Control Panel – Category (Small Icons) – Administrative Tools – Remote Desktop Services – Remote Desktop Licensing Manager – раскрываем: All Servers – srv-ts, через правый клик на srv-ts вызываем мастер: Install Licenses

копируем License Server ID в буфер обмена.

Выбираем программу лицензирования : «Соглашение Enterprise agreement”

Указываем Организацию: OOO “Ekzorchik” (произвольное значение)

Указываем страна/регион: — Россия (произвольное значение)

Следующим шагом для получения клиентский лицензий доступа нужно предоставить кое какую информацию:

Указываем количество: 9999 (к примеру)

Указываем номер соглашения: 6565792 (к примеру)

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

На заметку: полученную страницу с кодом активации лучше распечатать, либо сохранить в электронном виде на всякий случай.

Вот собственно и все, шаги установки, процесса активации и регистрации клиентских лицензии расписаны в полной мере. Вот собственно и всё, с уважением автор блога ekzorchik.

Виртуалки пришлось заменить на железо. Даже вроде бы мощная виртуалка не выдерживает больше 15 пользователей по процессору. А вот на современном железном сервере с 36 ядрами каждый пользователь отъедает примерно 1% CPU. Поедание помяти сильно зависит от используемых приложений. У нас примерно 1.5 Гб. Все это, процессор и память, приведено на одного активно работающего офисного (MS Office) пользователя запускающего браузер.

Так как число пользователей на ферме выросло, дежурные администраторы запросили удаленное подключение к сессиям пользователей. Это позволяет сделать Удаленный помощник (Remote Assistant). (Раньше можно было настроить делегирование Shadow, но я не уверен даже, что теперь это можно для серверов 2019.)

Как минимум его надо установить как Feature на все терминальные серверы и компьютера администраторов. Если нет SCCM, то придется настраивать вручную группы доступа. Ручной запуск msra.exe /offerra

Для подключения из командной строки нужно знать имя сервера, на котором сессия пользователя. Пользователь может это посмотреть так: меню Пуск — набрать Имя — выбрать Просмотр имени сервера. Администратор может использовать командлет Get-RDUserSession, если есть права.


Remote Desktop Services

Введение.

Часто на форумах technet возникают вопросы о различного рода проблем терминальной фермы. Я заметил, что многие её неверно проектируют и ссылаются на источники в интернетах, где не правильно описывается схема работы. Давайте разберемся.

Основные сервисы терминальной фермы.

  • Remote Desktop Connection Broker (RD Connection Broker) — Посредник подключений к удаленному рабочему столу.
  • Remote Desktop Web Access (RD Web Access) — Веб-доступ к удаленным рабочим столам.
  • Remote Desktop Session Host (RD Session Host) — Узел сеансов удаленных рабочих столов.

Первый сервис и является ключевым. Давайте обратимся к официальной документации по его работе: Посредник подключений к удаленному рабочему столу

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

Обратите внимание на выделенный участок. Это ключевой фактор при работе терминальной фермы. Здесь явно говориться, что не правильно балансировать клиентские подключения с помощью DNS RR об RDSH сервера. Это не поддерживаемый сценарий. Подключение должно быть строго на Брокер. Именно он занимается клиентскими подключениями.

Картинка выше показывает алгоритм подключения: Как видно, всё просто, клиент подключается к Брокеру, Брокер перенаправляет на член RDSH из коллекции серверов. Но этот нюанс большинство упускает и делают неправильно.

Главная ошибка проектирования.

И так далее. Таким образом, если взглянуть на схему Выше, картинку, то Вы используете сразу 7 шаг. Здесь и начинаются различного рода проблемы. Функционал Брокера не используется.

  1. У Вас возникают проблемы с сертификатами.
  2. Переведенный в режим обслуживания RDSH сервер игнорируется пользователем, он по-прежнему на него пытается подключиться, почему ? Потому что у него всё так же присутствует DNS запись с этим IP адресом RDSH сервера.
  3. Могут возникнуть различные ошибки подключения.
  4. Сложность в контролировании валидных DNS записей RDSH серверов. А если у Вас тысяча серверов ? Будете руками вычищать\добавлять постоянно DNS записи ?

Список можно продолжать, я указал основные, но итог один, Вы не контролируете соединение пользователя на RDSH.

Как настраивать ?

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

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


Если открыть RDP файл любым текстовым редактором, который скачан с RdWeb, можно увидеть новые уникальные строки:

Когда Вы заходите на Брокер, с помощью этого ярлыка, он Вас перенаправляет на член RDSH в этой коллекции.


Вывод.

Развернуть терминальную ферму просто, но большинство упускает тот момент, что подключаться нужно на Брокер, для чего он и предназначен. В итоге Вы имеете:

  1. Единую и правильную точку входа.
  2. На брокере Вы ставите сразу централизованно сертификат на все сервисы через свойства развёртывания коллекции.
  3. RDP ярлык, который не выводит каких-то лишних предупреждений, что не доверенный сертификат и тому подобное. Сам ярлык подписан сертификатом.
  4. Брокер проксирует на RDSH сервера, Вам не надо их как-то дополнительно настраивать, устанавливать сертификаты, службы лицензирования и так далее, всё это через свойства развёртывания коллекции на брокере.
  5. Настраивая коллекцию сеансов на брокере, Вы устанавливаете централизованную политику безопасности и шифрования, можете редактировать настройки параметров RDP ярлыка, проброс принтеров, дисков, дополнительные опции через PowerShell, можете изменять время активного сеанса, разъединенного и так далее.
  6. Вы больше не заботитесь о DNS записях, которыми балансировали подключение через DNS RR на RDSH.
  7. Происходит корректный перевод серверов в режим обслуживания или вывод\ввод из коллекции.

В других статьях мы рассмотрим развёртывание, высокую доступность, тему сертификатов, преимущество использования виртуальных дисков FSLogix вместо User Profile Disks, почему терминальная ферма на Windows Server 2019 может деградировать в производительности, приводить к неработающему меню пуск, черному экрану и т.д. Расскажу, какие групповые политики я предпочитаю использовать и многое другое.

С Уважением, Андрей.

Читайте также: