Встановлення та налаштування RDS

Remote Desktop Services, або RDS, дає змогу централізовано запускати програми та робочі столи Windows на сервері. Користувач підключається через Remote Desktop, але обчислення виконуються всередині серверного контуру. Така модель спрощує супровід прикладного програмного забезпечення, контроль доступу та роботу з даними, які не повинні зберігатися на локальних пристроях.

Нижче розглянуто повноцінне розгортання RDS у доменному середовищі Windows Server 2022. Інструкція орієнтована на постійну експлуатацію, а не на тимчасовий стенд. Ми розділимо компоненти за ролями, створимо колекцію сеансів, налаштуємо ліцензування, сертифікати та базові обмеження для користувачів.

Перед початком варто перевірити стан домену, DNS і синхронізації часу. Якщо доменний контур ще не підготовлений, спочатку виконайте встановлення Active Directory на Windows Server 2022. RDS може працювати і в робочій групі, але централізоване керування користувачами, групами та політиками в такій конфігурації суттєво ускладнюється.

Планування архітектури та підготовка серверів

Повне розгортання RDS складається з кількох компонентів:

- **RD Session Host** запускає користувацькі сеанси та встановлені програми; - **RD Connection Broker** розподіляє підключення і повертає користувача до його активного сеансу; - **RD Web Access** публікує доступні ресурси через вебпортал; - **RD Licensing** видає клієнтські ліцензії RDS CAL; - **RD Gateway** приймає зовнішні RDP-підключення через HTTPS без прямої публікації TCP 3389; - **RD Virtualization Host** потрібен лише для сценаріїв VDI на Hyper-V.

Для невеликого контуру ролі Connection Broker, Web Access і Licensing можна об’єднати на одному сервері, а Session Host винести на окрему машину. Розміщувати всі компоненти разом допустимо для лабораторії, але така схема створює єдину точку відмови та ускладнює подальше масштабування.

Приклад мінімальної структури:

- `dc01.corp.example` — контролер домену та DNS; - `rds-mgmt01.corp.example` — Connection Broker, Web Access і Licensing; - `rds-sh01.corp.example` — перший Session Host; - `rds-gw01.corp.example` — RD Gateway для зовнішніх підключень.

Кожному серверу потрібно призначити статичну IP-адресу, правильні DNS-сервери та зрозуміле ім’я. Після цього машини слід приєднати до домену, інсталювати оновлення та перезавантажити.

Перевірити базові параметри можна через PowerShell:

Get-NetIPConfiguration
Get-DnsClientServerAddress -AddressFamily IPv4
Test-ComputerSecureChannel -Verbose
w32tm /query /status

DNS-імена всіх вузлів повинні коректно вирішуватися в обох напрямках. Особливо важливо, щоб Session Host бачив Connection Broker, а Broker — Session Host. Помилки DNS часто виглядають як несправність RDS, хоча фактично ролі не можуть встановити взаємне з’єднання.

Для адміністрування серверного середовища, оновлень і контролю конфігурації доцільно використовувати окремий регламент адміністрування серверів Windows і Linux. RDS не варто розглядати як ізольовану роль: його стабільність залежить від DNS, Active Directory, резервного копіювання, сховища профілів і моніторингу.

Встановлення ролей RDS і створення розгортання

Найзручніше встановлювати RDS через Server Manager: **Manage → Add Roles and Features → Remote Desktop Services installation**. Майстер пропонує два режими:

- **Quick Start** — швидке встановлення основних ролей на одному сервері; - **Standard deployment** — окремий вибір серверів для Connection Broker, Web Access і Session Host.

Для постійного середовища обирайте Standard deployment і модель **Session-based desktop deployment**. Quick Start корисний для тестування, але надалі перенесення ролей і зміна архітектури потребуватимуть додаткових операцій.

Те саме розгортання можна виконати через PowerShell. Спочатку на серверах встановлюються необхідні компоненти:

Install-WindowsFeature RDS-Connection-Broker -IncludeManagementTools
Install-WindowsFeature RDS-Web-Access -IncludeManagementTools
Install-WindowsFeature RDS-RD-Server -IncludeManagementTools

Команди потрібно запускати з підвищеними правами на відповідних вузлах. Для віддаленого встановлення можна явно вказати сервер:

Install-WindowsFeature `
  -ComputerName rds-sh01.corp.example `
  -Name RDS-RD-Server `
  -IncludeManagementTools

Після інсталяції ролей створіть RDS deployment із сервера керування:

New-RDSessionDeployment `
  -ConnectionBroker "rds-mgmt01.corp.example" `
  -WebAccessServer "rds-mgmt01.corp.example" `
  -SessionHost "rds-sh01.corp.example"

Перевірити склад розгортання можна так:

Get-RDServer -ConnectionBroker "rds-mgmt01.corp.example"

У результаті мають відображатися сервери та призначені їм ролі. Якщо Session Host не додається, перевірте доменне членство, WinRM, локальний брандмауер, DNS і права облікового запису, від якого виконується команда.

Не відкривайте TCP 3389 з інтернету безпосередньо на Session Host. Для зовнішніх користувачів слід розгортати RD Gateway, VPN або обидва механізми. Прямо опублікований RDP постійно сканується автоматизованими засобами та швидко стає ціллю для атак на паролі.

Створення колекції сеансів і налаштування користувачів

Session Collection об’єднує один або кілька Session Host і визначає, хто може підключатися, які параметри матиме сеанс та які ресурси будуть доступні. Створіть окрему доменну групу, наприклад `CORP\RDS-Users`, і додавайте до неї лише тих користувачів, яким потрібен віддалений робочий стіл.

Створення колекції через PowerShell:

New-RDSessionCollection `
  -CollectionName "Office-Desktop" `
  -SessionHost "rds-sh01.corp.example" `
  -ConnectionBroker "rds-mgmt01.corp.example" `
  -CollectionDescription "Основна колекція віддалених робочих столів"

Призначте дозволену групу:

Set-RDSessionCollectionConfiguration `
  -CollectionName "Office-Desktop" `
  -ConnectionBroker "rds-mgmt01.corp.example" `
  -UserGroup "CORP\RDS-Users"

Далі налаштуйте життєвий цикл сеансів. Відключений сеанс продовжує використовувати оперативну пам’ять і може зберігати відкриті файли або заблоковані записи в прикладній системі. Тому безстрокові сеанси небажані.

Set-RDSessionCollectionConfiguration `
  -CollectionName "Office-Desktop" `
  -ConnectionBroker "rds-mgmt01.corp.example" `
  -IdleSessionLimitMin 120 `
  -DisconnectedSessionLimitMin 30 `
  -BrokenConnectionAction LogOff `
  -AutomaticReconnectionEnabled $true

Конкретні значення залежать від робочого процесу. Для застосунків із тривалими операціями надто короткий тайм-аут може переривати завдання. Спочатку варто зібрати статистику реального використання, а потім поступово посилювати обмеження.

Якщо користувачам потрібні лише окремі програми, краще публікувати RemoteApp замість повного робочого столу. Спочатку отримайте список доступних застосунків:

Get-RDAvailableApp `
  -CollectionName "Office-Desktop" `
  -ConnectionBroker "rds-mgmt01.corp.example"

Після цього опублікуйте потрібну програму, наприклад Calculator:

New-RDRemoteApp `
  -CollectionName "Office-Desktop" `
  -Alias "Calculator" `
  -DisplayName "Калькулятор" `
  -FilePath "C:\Windows\System32\calc.exe" `
  -ConnectionBroker "rds-mgmt01.corp.example"

Для профілів користувачів не слід покладатися лише на локальні каталоги Session Host. Якщо серверів кілька, користувач може потрапити на інший вузол і не побачити звичного середовища. Для сучасних розгортань часто використовують FSLogix Profile Containers на окремому файловому сховищі. Сховище повинно мати достатню продуктивність, коректні NTFS-права, резервне копіювання та виключення для антивірусу, погоджені з правилами захисту.

Ліцензування, сертифікати та безпечний зовнішній доступ

Після встановлення RD Session Host діє обмежений пільговий період. До його завершення потрібно встановити роль RD Licensing, активувати сервер ліцензування та додати придбані RDS CAL. Звичайна Windows Server CAL не замінює RDS CAL.

Встановіть роль ліцензування:

Install-WindowsFeature RDS-Licensing -IncludeManagementTools

Після цього відкрийте **Remote Desktop Licensing Manager**, активуйте сервер і встановіть пакет ліцензій. RDS підтримує два основні режими:

- **Per User** — ліцензія призначається користувачу, який може працювати з різних пристроїв; - **Per Device** — ліцензія призначається конкретному пристрою, з якого можуть входити різні користувачі.

Задайте сервер і режим ліцензування в deployment:

Set-RDLicenseConfiguration `
  -LicenseServer "rds-mgmt01.corp.example" `
  -Mode PerUser `
  -ConnectionBroker "rds-mgmt01.corp.example"

Перевірте результат:

Get-RDLicenseConfiguration `
  -ConnectionBroker "rds-mgmt01.corp.example"

Для всіх клієнтських точок RDS потрібні довірені TLS-сертифікати. Самопідписані сертифікати придатні лише для початкової перевірки. У робочому контурі використовуйте сертифікат, ім’я якого збігається з DNS-іменем, через яке користувачі відкривають RD Web Access або RD Gateway.

Приклад імпорту PFX для RD Web Access:

$password = Read-Host "Пароль PFX" -AsSecureString

Set-RDCertificate `
  -Role RDWebAccess `
  -ImportPath "C:\Secure\rds.example.ua.pfx" `
  -Password $password `
  -ConnectionBroker "rds-mgmt01.corp.example" `
  -Force

Аналогічно сертифікат призначається ролям `RDPublishing`, `RDRedirector` і `RDGateway`, якщо вони присутні у схемі. Закритий ключ повинен зберігатися з обмеженими правами, а файл PFX після імпорту потрібно видалити із загальнодоступного каталогу.

Для зовнішнього доступу встановіть RD Gateway на окремому сервері або виділеному вузлі периметра. На міжмережевому екрані публікуйте HTTPS 443 до Gateway. Увімкніть Network Level Authentication, багатофакторну автентифікацію через сумісний провайдер і блокування облікових записів після повторних невдалих спроб.

Через Group Policy обмежте перенаправлення локальних дисків, буфера обміну, принтерів, COM-портів і USB-пристроїв відповідно до потреб команди. Централізований супровід таких ролей можна включити до загального процесу системного адміністрування, щоб окремо контролювати оновлення, журнали подій, резервні копії та доступи адміністраторів.

Типові помилки під час налаштування RDS

**Усі ролі встановлено на контролері домену.** Це збільшує поверхню атаки, змішує критичні функції та ускладнює відновлення. Session Host, Connection Broker і Gateway потрібно розміщувати на окремих серверах.

**TCP 3389 опубліковано безпосередньо в інтернет.** Навіть нестандартний порт не усуває ризик. Для зовнішнього входу використовуйте RD Gateway або VPN, NLA, MFA та фільтрацію джерел підключення.

**Сервер ліцензування встановлений, але не налаштований.** Наявність ролі ще не означає, що Session Host отримав правильний режим і адресу License Server. Перевіряйте конфігурацію командою `Get-RDLicenseConfiguration` та інструментом RD Licensing Diagnoser.

**Використовуються самопідписані сертифікати.** Користувачі звикають ігнорувати попередження, а клієнти можуть відхиляти підключення після посилення політик. Для робочого контуру потрібен довірений сертифікат із правильними DNS-іменами.

**Немає тайм-аутів для відключених сеансів.** Такі сеанси накопичуються, споживають пам’ять і блокують оновлення профілів. Встановіть розумні межі для бездіяльності та відключеного стану.

**Профілі зберігаються лише локально.** Після додавання другого Session Host користувачі отримують різне середовище на різних вузлах. Заздалегідь спроєктуйте централізоване сховище профілів і перевірте його продуктивність.

**Антивірус сканує профільні контейнери без винятків.** Це може спричиняти повільний вхід, блокування VHDX і пошкодження профілів. Винятки повинні бути точковими, документованими та узгодженими з моделлю захисту.

**Не контролюється навантаження Session Host.** Середнє завантаження процесора не показує короткі піки, дефіцит пам’яті або затримки диска. Збирайте показники CPU, RAM, latency сховища, кількості активних сеансів і часу входу користувача.

**Зміни перевіряються одразу на всіх користувачах.** Оновлення прикладних програм, політик або профільного агента краще спочатку застосовувати до тестового Session Host і пілотної групи.

Висновок

Коректне розгортання RDS — це не лише встановлення ролі Remote Desktop Session Host. Надійний контур включає Connection Broker, керовані колекції, сервер ліцензування, довірені сертифікати, контроль профілів і захищений канал зовнішнього доступу.

Починайте з домену, DNS і розподілу ролей. Потім створюйте колекцію, надавайте доступ через окремі групи Active Directory та встановлюйте обмеження для сеансів. До завершення пільгового періоду активуйте RDS CAL, а перед відкриттям віддаленого доступу замініть самопідписані сертифікати й розгорніть RD Gateway або VPN.

Після запуску регулярно перевіряйте журнали подій, стан ліцензування, вільну пам’ять, затримки сховища профілів і кількість відключених сеансів. Такий підхід перетворює RDS із набору серверних ролей на передбачувану та контрольовану платформу віддаленої роботи.