Установка и настройка терминального сервера на windows server

▏Где искать следы подключения по RDP▕

Логи. В первую очередь следует немедленно проверить логи событий:
%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx
Событие 1149 для успешного подключения до аутентификации с использованием логина и пароля, но после аутентификации IP-адреса источника подключения

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

%SystemRoot%\System32\Winevt\Logs\Security.evtx
Событие 4624 — для успешного входа, 4625 — для неудачного входа, 4778 — для переподключения, 4634 — для отключения
Стоит обратить внимание на «LogonType». Для удаленных подключений оно будет равно 3, 10 или 7
Здесь необходимо искать успешные события входа с необычных IP-адресов, обращать внимание на неуспешные события входа — это может быть атака перебором.

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-TerminalServices-LocalSessionManager%4Operational.evtx
События 21, 22 и 25 — для успешного входа или переподключения, 23 — для отключения

Следует искать события с необычных IP-адресов.

Нередко злоумышленники чистят логи. При этом чаще всего чистят только Security.evtx, чуть реже — Security.evtx и Microsoft-Windows-TerminalServices-RemoteConnectionManager%4Operational.evtx сразу. По этой причине крайне желательно просматривать все три лога, а лучше заранее настроить перенаправление событий в SIEM-систему.

Сессии легитимных пользователей. Практически всегда злоумышленники, которые занимаются распространением шифровальщиков, начинают изучение внутренней сети своей жертвы почти сразу после проникновения. Иногда им удается переподключиться к уже имеющимся сессиям RDP-серверов, доступных из внутренней сети. Это может произойти, когда подключение легитимного пользователя уже установлено, но на уровне TCP оно разорвано (например, было закрыто окно RDP). В этом случае при повторном подключении сессия восстанавливается и злоумышленник входит на сервер. Это означает, что в логе можно увидеть, что подключение инициировано легитимным пользователем в день X, а в день X+N с той же машины уже переподключится атакующий. Поэтому следует смотреть не только на события установки подключений, но и на события переподключений и отключений.

Если следы обнаружены

• постараться изолировать злоумышленника (или вовсе отключить инфраструктуру от интернета, или отключить критичные серверы от локальной сети);
• проверить контроллер домена на следы взлома, а также проверить файловые помойки и другие возможные цели злоумышленника.

Решение проблемы

Ошибка вроде очевидная, что не включен RDP доступ, если бы это был рядовой сервер я бы понял, но тут служба удаленного доступа точно работала и была включена, так как на данный сервер так же распространялась групповая политика делающая, это автоматически, я проверил применение GPO, все было хорошо. Первым делом я полез смотреть логи Windows, это можно сделать классическим методом или через модный Windows Admin Center.

Журналы которые нас будут интересовать находятся в таких расположениях:

• Microsoft-Windows-RemoteDesktopServices-RdpCoreTS/Operational
• Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational
• Microsoft-Windows-TerminalServices-SessionBroker/Admin
• Microsoft-Windows-TerminalServices-SessionBroker/Operational
• Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational

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

Первое, что мне бросилось в глаза, это предупреждение с кодом ID 101:

ID 101 RemoteDesktopServices-RdpCoreTS: The network characteristics detection function has been disabled because of Reason Code: 2(Server Configuration).

Далее было такое предупреждение:

Событие с кодом ID 226: RDP_UDPLOSSY: An error was encountered when transitioning from UdpLossyStateSynRecv in response to UdpEventErrorHandshakeTO (error code 0x80040004).

Далее нужно посмотреть, как RDCB брокеры взаимодействовали с сессией пользователя. В журнале «Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational» я обнаружил событие с кодом ID 1149, в котором я вижу, что определенный пользователь был успешно аутентифицирован на RDS ферме, он получил некий IP адрес.

Remote Desktop Services: User authentication succeeded: User: vpn_user Domain: Root.PYATILISTNIK.ORG Source Network Address: 10.10.31.47

Далее я стал изучать информацию из журнала «Microsoft-Windows-TerminalServices-SessionBroker/Operational». Тут я так же обнаружил, что брокер успешно ответил и отправил пользователя на определенный RDSH хост. Тут есть событие с кодом ID 787.

Событие с кодом ID 787: Session for user ROOT\vpn_user successfully added to RD Connection Broker’s database. Target Name = term01.root.pyatilistnik.org Session ID = 18 Farm Name = TermRoot

За ним я видел событие с кодом ID 801, которое имело вот такое сообщение:

RD Connection Broker successfully processed the connection request for user ROOT\vpn_user. Redirection info: Target Name = TERM01 Target IP Address = 10.10.31.47 Target Netbios = TERM01 Target FQDN = term01.root.pyatilistnik.org Disconnected Session Found = 0x0

тут видно, что брокер даже смог обнаружить предыдущую сессию на данном терминале, о чем говорит строка Disconnected Session Found = 0x0

И вы увидите событие с кодом ID 800:

RD Connection Broker received connection request for user ROOT\vpn-user. Hints in the RDP file (TSV URL) = tsv://MS Terminal Services Plugin.1.TermRoot Initial Application = NULL Call came from Redirector Server = TERMRDCB.root.pyatilistnik.org Redirector is configured as Virtual machine redirector

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

Далее переходим в журнал «Microsoft-Windows-TerminalServices-SessionBroker-Client/Operational» тут будет два события,об успешном общении RDS брокера и клиента.

Событие с кодом ID 1307: Remote Desktop Connection Broker Client successfully redirected the user ROOT\vpn-user to the endpoint term01.root.pyatilistnik.org. Ip Address of the end point = 10.10.31.47

Remote Desktop Connection Broker Client received request for redirection. User : ROOT\vpn-user RDP Client Version : 5

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

Стандартное развертывание службы удаленных рабочих столов

Перед тем как создавать высоко доступную ферму RDS, вы должны произвести базовую инсталляцию, а именно нам необходимо установить три роли на текущие сервера, для этого в правом верхнем углу выберите пункт «Управление — Добавить роли и компоненты».

Стандартный тип развертывания — это лучший метод развертывания, и вы должны выбрать этот тип развертывания в производственной среде

В мастере добавления ролей выберите пункт «Установка служб удаленных рабочих столов (Remote Desktop Services Installation)» и нажимаем далее.

Выбираем первый пункт «Стандартное развертывание (Standard Deployment)» — данный тип развертывания позволяет устанавливать роли Remote Desktop Services на нескольких серверах одновременно.

Выбираем второй пункт «Развертывание рабочих столов на основе сеансов (Session-based desktop deployment)»

Это развертывание рабочих столов на основе сеансов позволяет пользователям подключаться к коллекциям сеансов, включающим опубликованные удаленные приложения RemoteApp и рабочие столы, основанные на сеансах

Список компонентов устанавливаемых при стандартной конфигурации RDS фермы. Тут будет установлен:

• Посредник подключений к удаленным рабочим столам (Connection Broker)
• Веб-доступ к удаленным рабочим столам
• Узел сеансов удаленных рабочих столов

На следующем шаге вам нужно выбрать и перенести в правую область сервер, который будет нести на себе роль «Посредник подключений к удаленным рабочим столам (RD Connection Broker)». В моем примете, это первый сервер RDCB01.root.pyatilistnik.org.

Второй сервер на данном этапе добавлять не нужно

Далее у нас идет выбор сервера для установки роли «Веб-доступ к удаленным рабочим столам (RD Web Access)», так как я пока не планирую использовать веб доступ RemoteApp, а настрою это потом, то я воспользуюсь галкой «Установить службу веб-доступа к удаленным рабочим столам на сервере посреднике подключений к удаленному рабочему столу (Install the RD Web Access role service on the RD Connection Broker server)»

Данную роль нельзя пропустить в мастере стандартной установки служб Remote Desktop Services, но она нам пригодится еще очень сильно

Последним идет пункт по установке роли на сервера к которым вы будите непосредственно подключаться, выбираем нужные сервера и инсталлируем на них роль «Узел сеансов удаленных рабочих столов (RS Session Host)». В моем примере, это два сервера rdsh01 и rdsh02.

Процесс установки ролей подразумевает, что потребуется перезагрузка сервера, для этого вам необходимо выставить галку «Автоматически перезапускать конечный сервер, если это потребуется (Restart the destination server automatically if required )» и нажать кнопку «Развернуть»

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

У вас должна произойти успешная установка службы «службы удаленных рабочих столов». Все необходимые сервера будут перезагружены.

Давайте убедимся, что все серверы получили свои роли. Для этого на сервере, где вы добавляли сервера в оснастку «Диспетчер серверов (Производили установку)», откройте оснастку и перейдите в раздел «Службы удаленных рабочих столов».

Кстати никто вам не мешает собрать оснастку управления службами Remote Desktop Services на другом компьютере, посмотрите как это делать

На вкладке «Общие сведения» посмотрите в разделе «Серверы развертывания», кто и какие роли себе установил.

Перейдите в раздел «Коллекции» и убедитесь, что список пуст, но зато присутствуют два ваших хоста узла сеансов удаленных рабочих столов, к котором будут подключаться конечные пользователи. Они будут иметь статус «Истина (True)», что говорит о разрешении подключаться (Режим стока выключен)

Следующим шагом мы создадим новую коллекцию для подключения к службам Remote Desktop Services High Availability на Windows Server 2019.

Проверка состояния протокола RDP

Проверка состояния протокола RDP на локальном компьютере

Сведения о том, как проверить и изменить состояние протокола RDP на локальном компьютере, см. в разделе (Как включить удаленный рабочий стол).

Примечание

Если параметры удаленного рабочего стола недоступны, см. раздел .

Проверка состояния протокола RDP на удаленном компьютере

Важно!

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

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

1. Сначала откройте меню Пуск и выберите Выполнить. В появившемся текстовом поле введите regedt32.
2. В редакторе реестра нажмите Файл и выберите пункт Подключить сетевой реестр.
3. В диалоговом окне Выбор: «Компьютер» введите имя удаленного компьютера, выберите Проверить имена и нажмите кнопку ОК.
4. Перейдите в раздел HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server и в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services.
   • Если раздел fDenyTSConnections имеет значение , значит протокол RDP включен.
   • Если раздел fDenyTSConnections имеет значение 1, значит протокол RDP отключен.
5. Чтобы включить протокол RDP, для fDenyTSConnections замените значение 1 на .

Проверка блокировки объектом групповой политики протокола RDP на локальном компьютере

Если не удается включить протокол RDP в пользовательском интерфейсе или для fDenyTSConnections возвращается значение 1 после его изменения, объект групповой политики может переопределять параметры на уровне компьютера.

Чтобы проверить конфигурацию групповой политики на локальном компьютере, откройте окно командной строки с правами администратора и введите следующую команду:

Когда команда будет выполнена, откройте файл gpresult.html. Выберите Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Службы удаленных рабочих столов\Узел сеансов удаленных рабочих столов\Подключения и найдите политику Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.

• Если для параметра этой политики задано значение Включено, групповая политика не блокирует подключения по протоколу RDP.

• Если же для параметра этой политики задано значение Отключено, проверьте результирующий объект групповой политики. Ниже показано, какой объект групповой политики блокирует подключения по протоколу RDP.

Проверка блокировки объектом групповой политики протокола RDP на удаленном компьютере

Чтобы проверить конфигурацию групповой политики на удаленном компьютере, нужно выполнить почти такую же команду, что и для локального компьютера.

В файле (gpresult-<computer name>.html), который создается после выполнения этой команды, используется такой же формат данных, как в версии файла для локального компьютера (gpresult.html).

Изменение блокирующего объекта групповой политики

Эти параметры можно изменить в редакторе объектов групповой политики (GPE) и консоли управления групповыми политиками (GPM). Дополнительные сведения об использовании групповой политики см. в статье Advanced Group Policy Management (Расширенное управление групповыми политиками).

Чтобы изменить блокирующую политику, используйте один из следующих методов.

• В GPE укажите определенный уровень для объекта групповой политики (локальный или доменный) и выберите Конфигурация компьютера > Административные шаблоны > Компоненты Windows > Службы удаленных рабочих столов > Узел сеансов удаленных рабочих столов > Подключения > Разрешить пользователям удаленное подключение с использованием служб удаленных рабочих столов.
  1. Задайте для политики значение Включена или Не задана.
  2. На затронутых компьютерах откройте окно командной строки с правами администратора и выполните команду gpupdate /force.
• В GPM перейдите к подразделению, в котором блокирующая политика применяется к соответствующим компьютерам, и удалите эту политику.

Базовая настройка терминального сервера

Сначала проверим имя рабочей группы и описание компьютера.

1. Открываем «Панель управления», переходим в раздел «Система».
2. Нажимаем «Изменить параметры».
3. На вкладке «Имя компьютера» смотрим, как он идентифицируется в сети. Если имя компьютера или рабочей группы слишком сложное, нажимаем «Изменить» и задаем другие идентификаторы. Для применения нужно перезагрузить систему.

После проверки имени смотрим и при необходимости меняем сетевые настройки. В «Панели управления» открываем раздел «Сетевые подключения».

Переходим в свойства используемого подключения, открываем свойства «IP версии 4». Указываем настройки своей сети. IP, маска и шлюз должны быть статичными.

Сведения о подключении

Параметры RDP	Описание	Значения	Значение по умолчанию	Поддержка Виртуального рабочего стола Azure
full address:s:value	Имя компьютера.Этот параметр указывает имя или IP-адрес удаленного компьютера, к которому вы хотите подключиться.Это единственный обязательный параметр в RDP-файле.	Допустимое имя, IPv4- или IPv6-адрес.		Нет
alternate full address:s:value	Указывает альтернативное имя или IP-адрес удаленного компьютера.	Допустимое имя, IPv4- или IPv6-адрес.		Нет
username:s:value	Указывает имя учетной записи пользователя для входа на удаленный компьютер.	Любое допустимое имя пользователя.		Нет
domain:s:value	Указывает имя домена, в котором будет использоваться учетная запись пользователя для входа на удаленный компьютер.	Допустимое доменное имя, например CONTOSO.		Нет
gatewayhostname:s:value	Указывает имя узла шлюза удаленных рабочих столов.	Допустимое имя, IPv4- или IPv6-адрес.		Нет
gatewaycredentialssource:i:value	Задает метод проверки подлинности шлюза удаленных рабочих столов.	— 0: запрос пароля (NTLM).- 1: использование смарт-карты.- 2: использование учетных данные находящегося в системе пользователя.- 3: запрашивание у пользователя учетных данных и использование базовой аутентификации.- 4: пользователь может сделать выбор позже.- 5: использование аутентификации на основе файлов cookie.	Нет
gatewayprofileusagemethod:i:value	Указывает, следует ли использовать параметры по умолчанию шлюза удаленных рабочих столов.	— 0: используется режим профиля по умолчанию, как указано администратором.- 1: используются явные параметры, указанные пользователем.	Нет
gatewayusagemethod:i:value	Указывает, в каких случаях следует использовать шлюз удаленных рабочих столов для подключения.	— 0: шлюз удаленных рабочих столов не используется.- 1: шлюз удаленных рабочих столов используется всегда.- 2: шлюз удаленных рабочих столов используется, если не удается установить прямое подключение к узлу сеансов удаленных рабочих столов.- 3: используются параметры по умолчанию шлюза удаленных рабочих столов.- 4: шлюз удаленных рабочих столов не используется, подключение обходит шлюз для локальных адресов.Значения 0 или 4 этого свойства действуют практически одинаково, но значение 4 позволяет обходить локальные адреса.	Нет
promptcredentialonce:i:value	Определяет, сохраняются ли учетные данные пользователя и используются ли для шлюза удаленных рабочих столов и на удаленном компьютере.	— 0: удаленный сеанс не будет использовать те же учетные данные.- 1: удаленный сеанс будет использовать те же учетные данные.	1	Нет
authentication level:i:value	Определяет параметры уровня аутентификации на сервере.	— 0: если аутентификация на сервере не пройдена, можно подключиться к компьютеру без предупреждения (Подключаться без предупреждения).- 1: если аутентификация на сервере не пройдена, не устанавливать подключение (Не подключаться).- 2: если аутентификация на сервере не пройдена, выводится предупреждение и разрешается подключиться или отклонить подключение (предупреждение).- 3: обязательная аутентификация не указана.	3	Нет
enablecredsspsupport:i:value	Определяет, используется ли клиент для аутентификации поставщика поддержки безопасности учетных данных (CredSSP), если он доступен.	— 0: RDP не будет использовать CredSSP, даже если операционная система поддерживает CredSSP.- 1: RDP будет использовать CredSSP, если операционная система поддерживает CredSSP.	1	Да
disableconnectionsharing:i:value	Определяет, выполняет ли клиент повторное подключение к какому-либо существующему отключенному сеансу или инициирует новое подключение.	— 0: повторное подключение к имеющемуся сеансу.- 1: инициация нового подключения.	Нет
alternate shell:s:value	Определяет программу, запускаемую автоматически в удаленном сеансе в качестве оболочки вместо Проводника.	Допустимый путь к исполняемому файлу, например C:\ProgramFiles\Office\word.exe.		Да

Развертывание VDI: поддерживаемые гостевые ОС

Серверы узлов виртуализации удаленных столов Windows Server 2016 и Windows Server 2019 поддерживают следующие гостевые ОС:

• Windows 10 Корпоративная
• Windows 8.1 Корпоративная
• Windows 7 SP1 Корпоративная

Примечание

• Службы удаленных рабочих столов не поддерживают разнородные коллекции сеансов. Операционные системы всех виртуальных машин в коллекции должны быть одной версии.
• Вы можете иметь отдельные однородные коллекции с разными версиями гостевой ОС на одном узле.
• Узел Hyper-V, используемый для запуска виртуальных машин, должен иметь ту же версию операционной системы, что и узел Hyper-V, использованный для создания исходных шаблонов виртуальных машин.

Настройка на терминальном сервере

Сессии можно настроить для конкретного сервера в настройках сервера терминалов. Процесс немного отличается в зависимости от версии операционной системы Windows.

Windows 2012 и выше

В диспетчере серверов переходим в службы удаленных рабочих столов:

Переходим в коллекцию, для которой хотим поменять настройки сеанса:

В свойствах коллекции кликаем по Задачи — Изменить свойства:

Переходим в раздел Сеанс и выставляем ограничения:

* где Окончание разъединенного сеанса — время, через которое для пользователей с завершенными сеансами произойдет выход из системы; Ограничение бездействующего сеанса — время, через которое сеанс перейдет в разъединенный, если пользователь в нем не работает (не проявляет никакой активности).
 

Windows 2008 R2 и ниже

Нажимаем Пуск — Администрирование — Службы удаленных рабочих столов — Конфигурация узла сеансов удаленных рабочих столов:

В разделе «Подключения» дважды кликаем по RDP-Tcp:

На вкладке «Сеансы» ставим галочку Переопределить параметры пользователя и выставляем необходимые лимиты:

* где Завершение отключенного сеанса — время, по достижении которого отключенный сеанс будет завершен, а для пользователя будет выполнен выход; Ограничение бездействующего сеанса — ограничение на сеанс, в котором пользователь не работает.

Первая программа, о которой мы расскажем называется Cyberarms Intrusion Detection and Defense Software (IDDS).

количество неудачных попыток авторизации за последние 30 дней

К сожалению, судя по всему, разработка была прекращена в 2017-м году, но тем не менее программа (с некоторыми нюансами — о них далее) работает даже на ОС Windows Server 2019.

Принцип действия довольно таки простой, но в тоже время эффективный: после нескольких неудачных попыток ввода пароля(количество для блокировки определено в параметрах) срабатывает Soft lock(подозрение в брутфорсе), в журнале создается инцидент и IP помечается как подозрительный. Если новых попыток не последовало, то спустя 20 минут адрес убирается из списка наблюдаемых. Если же перебор паролей продолжается, то IP адрес «злоумышленника» добавляется в запрещающее подключения правило брандмауэра Windows (должен быть в активированном состоянии) и тем самым подбор пароля с этого адреса временно прекращается, так как подключения полностью блокируются. Блокировка Hard lock продлится 24 часа — такой параметр выставлен по умолчанию. Вечную блокировку,»Hard lock forever», включать не рекомендуем, иначе количество IP в правиле брандмауэра быстро «распухнет» и программа будет тормозить.

Soft and Hard lock threshold — counts and duration

Устанавливается программа просто — скачиваем архив с установщиком, распаковываем во временную папку. Cкачиваем и устанавливаем Microsoft Visual C++ 2010 x64 (vcredist_x64.exe) и только после этого запускаем пакет установщика Windows -Cyberarms.IntrusionDetection.Setup.x64.msi, потому как у setup.exe скачать и установить автоматически Visual C++ не получается.

Далее производим настройку — активируем агент для защиты RDP сессий «TLS/SSL Security Agent», во вкладке «AGENTS»:

Enable «TLS/SSL Security Agent»

Как выкинуть пользователя из оснастки управления RDS

И так, у меня есть мой любимый, тестовый пользователь в Active Directory, по имени Барбоскин Геннадий Викторович. Предположим, что он зашел на терминальный стол и нам по причине зависания его сессии, нужно сделать ему выход. Первый метод, это использование оснастки по управлению RDS фермой, я вам рассказывал, как ее собирать. Открываем раздел с вашей коллекцией RDS фермы. В поисковом фильтре указываем логин или фамилию нужного сотрудника. В результате получаем хост, где он работает.

Щелкаем по нему правым кликом. В контекстном меню будет пункт «Выйти», это и соответствует завершению сессии (Log off). Так же есть пункт «Отключиться», если выберите его, то пользователь будет выброшен с терминального сервера, но его сессия останется на нем, данная операция равносильна тому, если пользователь просто нажал в окне с названием терминального сервера крестик.

После того, как вы выбрали пункт «Выйти», начнется корректное завершение сессии пользователя на RDS ферме. Сам пользователь увидит сообщение «Работает служба профилей пользователей» и у него закроется окно без ошибки.

О данном руководстве

Данный документ предназначен как технический обзор и набор пошаговых инструкций для отработки различных сценариев использования RD). Для опытных системных администраторов это руководство содержит основные задачи, необходимые для ознакомления с последними нововведениями RDS в среде Windows Server 2008 R2. Для администраторов, впервые знакомящихся с RDS, данное руководство содержит максимальный объем вводной информации, чтобы свести к минимуму необходимость ознакомления с дополнительной документацией. Дополнительную информацию, в том числе пошаговые руководства, можно получить на сайте Microsoft TechNet.

Каждый сценарий основывается на предыдущем. Хотя вопросы лицензирования не рассматриваются в данном руководстве, правильное лицензирование является обязательным требованием использования RDS. Некоторые сценарии могут требовать более детального повторения предыдущих шагов. Если не сказано иное, следующие нюансы относятся ко всем сценариям:

• Лучше вместе с Windows 7! (Better together with Windows 7) Связка Windows Server 2008 R2 и Windows 7 содержит технологии улучшающие работу пользователей. В частности был учтен опыт корпоративных пользователей и мнений IT Pro специалистов для улучшения безопасности и управления взаимодействия систем.
• Сервер удаленного рабочего стола – Удаленный рабочий стол (RD Session Host – Session-based Desktops). Классический удаленный рабочий стол (сервер терминалов) подразумевающий установку роли RD на выделенном сервере и работу пользователей с собственным удаленным рабочим столом. Данная среда открыта для пользователей имеющих доступ к серверу.
• Сервер удаленного рабочего стола – Удаленные приложения (RD Session Host – RemoteApp). Удаленные приложения (RemoteApp) были внедрены в Windows Server 2008. Это программы, удаленный доступ к которым можно получить через Службы удаленного рабочего стола (RDS) и которые работают так, как будто они запущены на локальном компьютере пользователя. Пользователи могут запускать программы RemoteApp вместе со своими локальными программами. Данная функция облегчает работу пользователей, поскольку стирает различие между удаленным и локальным рабочим столом пользователя. В Windows Server 2008 R2 Удаленные приложения (RemoteApp) были доработаны, чтобы обеспечить возможность управления доступом к Удаленным приложениям (RemoteApp) как по отдельным пользователям, так и по группам безопасности.
• Виртуальный сервер удаленного рабочего стола – Персональный рабочий стол и пул рабочих столов (RD Virtualization Host – Personal Desktops and Pooled Desktops). Обновленные RDS позволяют использовать инфраструктуру виртуальных рабочих столов (Virtual Desktop Infrastructure (VDI)) при использовании Hyper-V. Виртуальные рабочие столы могут быть персональными, – индивидуальные для каждого пользователя в отдельности, либо могут быть объединены в единый пул, с общими настройками и приложениями.
• Удаленные приложения и подключение к удаленному рабочему столу (RemoteApp & Desktop Connections). В Windows Server 2008 используются Web Access для создания единой веб-страницы входа, на которой доступны все опубликованные Удаленные приложения. В Windows Server 2008 R2 и Windows 7, пользователи могут подписываться на Удаленные приложения, при этом Удаленные приложения будут автоматически устанавливаться на рабочих станциях пользователей: ярлыки приложений будут автоматически создавать в меню Пуск.

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

Архитектура Служб удаленного рабочего стола (Remote Desktop Services Architecture)

Архитектура RDC призвана обеспечивать масштабируемость и надежность предоставления услуг, позволяя пользователям получать доступ к приложениям, не требуя от них новых знаний. В данном разделе содержится краткий обзор роли RDS. В нем также содержится подробная информация о дополнительных функциях и возможностях, которые использует RDS. Имейте в виду, что для того, чтобы воспользоваться новыми функциями RDS, на клиентском компьютере должна быть установлена последняя версия клиента RDC (Rremote Desktop Client) с поддержкой RDP 7.0.

Установка Terminal Services Manager

Запускаем исполняемый файл, я это делаю на своей тестовой виртуальной машине с Windows Server 2019. Первое что вас спросят, это в каком режиме вы решили установить утилиту TSM. На выбор будет два варианта:

• Install for all users — Установка для всех пользователей данного компьютера
• Install for me only — Установка Terminal Services Manager исключительно для вас на данном компьютере

Далее вам нужно принять лицензионное соглашение, выбрав пункт «I accept the agreement» и нажать «next».

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

Оставьте галку на пункте «Create a desktop shortcut», чтобы у вас был создан ярлык на рабочем столе.

Для завершения инсталляции Terminal Services Manager нажмите кнопку «Install».

Запускаем Terminal Services Manager.

Удаление старых серверов лицензирования через реестр

Может получиться ситуация, что у вас сервера лицензирования были добавлены не через политику, как того требует инфраструктура Active Directory, а через реестр, либо может быть ситуация, что в реестре остались мусорные записи, которые политикой не получается перезаписать. В таких ситуациях вам необходимо самостоятельно проверить вот эту ветку реестра. Запустите окно выполнить и введите в нем regedit, чтобы открыть редактор реестра.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services

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

Еще можете проверить вот такую ветку реестра:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Policies\Microsoft\Windows NT\Terminal Services

Тут то же может быть ключ LicenseServers.

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

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core

Тут будет ключ реестра LicensingMode, который может содержать три значения:

• 2 — Задает режим лицензирования на устройство
• 4 — Задает режим лицензирования на пользователя
• 5 — Режим лицензирования не настроен

Подробнее на https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/unattend/microsoft-windows-terminalservices-remoteconnectionmanager-licensingmode

Особый порт для подключения

По умолчанию, для подключения к терминальному серверу по RDP используется порт 3389. Если необходимо, чтобы сервер слушал на другом порту, открываем реестр, и переходим в ветку:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Находим ключ PortNumber и задаем ему значение в десятично представлении, равное нужному номеру порта:

Также можно применить команду:

reg add «HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp» /v PortNumber /t REG_DWORD /d 3388 /f

* где 3388 — номер порта, на котором будет принимать запросы терминальный сервер.

Создание пула серверов на сервере посредника подключений (RD Connection Broker)

Пул серверов, это удобное объединение серверов в общий список для быстрого управления и развертывания на них ролей и компонентов. Все манипуляции производятся из единой консоли управления «Диспетчер серверов». Откройте оснастку «Диспетчер серверов» раздел «Все серверы». Щелкните по нему правым кликом и нажмите «Добавление серверов».

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

На вкладке Active Directory вам необходимо указать в каком домене вы будите производить поиск, в поле «Имя (Общие)» находим нужные вам сервера.

Выбираем нужные сервера и переносим их в раздел «Выбрано».

Нажимаем «Ok».

В итоге в вашей оснастке «Диспетчер серверов» вы увидите все добавленные хосты. которые будут участниками Remote Desktop Services High Availability на Windows Server 2019.

Если у ваших серверов будет статус «В сети: счетчики производительности не запущены», то запустите их через правый клик

В результате все должно быть в статусе «В сети».