Ліцензування Remote Desktop Services

Remote Desktop Services дозволяє користувачам запускати робочі столи та програми на сервері Windows через RDP. Однак наявність ліцензії Windows Server не надає права на повноцінну багатокористувацьку роботу через RD Session Host. Для кожного користувача або пристрою, який підключається до сеансового вузла, зазвичай потрібна окрема клієнтська ліцензія Remote Desktop Services Client Access License — RDS CAL.

Після встановлення ролі RD Session Host сервер переходить у пільговий період. Він дає час на розгортання ліцензійної інфраструктури, але не замінює постійне ліцензування. Якщо до завершення цього періоду не активувати RD Licensing, не встановити придбані RDS CAL і не призначити сервер ліцензій, нові сеанси можуть перестати відкриватися.

Нижче розглянемо практичну схему для Windows Server 2022 та схожих актуальних версій: вибір типу CAL, установлення ролі, активацію сервера ліцензій, конфігурацію RD Session Host і перевірку результату. Якщо серверний контур потребує регулярного супроводу, ці операції доцільно включити до процесу системного адміністрування, а не залишати як одноразову дію під час запуску RDS.

Як побудована модель ліцензування RDS

Для стандартного розгортання потрібно розрізняти щонайменше два види ліцензій. Windows Server CAL надає користувачу або пристрою право звертатися до служб Windows Server. RDS CAL додатково покриває використання функцій Remote Desktop Services. У типовому сценарії доступу до RD Session Host потрібні обидва компоненти.

RDS CAL випускаються у двох основних моделях:

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

Модель Per User зазвичай зручніша для співробітників, які використовують кілька пристроїв або працюють віддалено. Per Device доцільна для змінних робочих місць, терміналів у виробничих приміщеннях, навчальних класів та інших сценаріїв, де одним комп’ютером користуються різні облікові записи.

RDS CAL не є ліцензіями на одночасні підключення. Наприклад, пакет із 30 User CAL не означає, що можна створити довільну кількість облікових записів за умови не більше 30 активних сеансів. Ліцензуванню підлягають конкретні користувачі або пристрої відповідно до вибраної моделі та умов Microsoft.

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

У середовищі без домену модель Per User не забезпечує повноцінного централізованого відстеження призначень. Для робочої групи зазвичай застосовують Per Device. Доменний варіант значно простіше контролювати через групові політики, тому перед масштабним розгортанням корисно завершити створення нового домену Active Directory та перевірити DNS і реплікацію контролерів домену.

Підготовка та встановлення RD Licensing

Роль RD Licensing можна розмістити на окремому сервері або разом із RD Session Host. Для невеликого середовища суміщення ролей технічно можливе, але окремий сервер ліцензій спрощує обслуговування кількох сеансових вузлів. Важливо, щоб RD Session Host міг стабільно визначати його ім’я через DNS і звертатися до нього мережею.

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

- сервер має статичну IP-адресу або стабільну DHCP-резервацію; - ім’я сервера коректно реєструється в DNS; - час синхронізований із доменною ієрархією; - адміністратор має інформацію про програму придбання та пакет RDS CAL; - версія CAL відповідає версії RD Session Host; - визначена єдина модель — Per User або Per Device.

Установити роль через PowerShell можна так:

Install-WindowsFeature RDS-Licensing -IncludeManagementTools

Після завершення перевірте стан компонента:

Get-WindowsFeature RDS-Licensing

У полі `Install State` має бути значення `Installed`. Графічні інструменти керування з’являться в меню **Server Manager → Tools**. Основна консоль називається **Remote Desktop Licensing Manager**, а засіб аналізу конфігурації — **RD Licensing Diagnoser**.

Якщо сервер ліцензій працюватиме в домені та обслуговуватиме User CAL, його комп’ютерний обліковий запис зазвичай додають до доменної групи **Terminal Server License Servers**. Це дає службі необхідні права для оновлення відомостей про призначені користувацькі ліцензії в Active Directory. Після зміни членства варто перезавантажити сервер або оновити його токен безпеки.

Для інфраструктури з кількома RD Session Host бажано окремо задокументувати FQDN сервера ліцензій, вибрану модель, номер договору, кількість установлених CAL і дату активації. Така документація особливо корисна під час міграції або відновлення. Практики експлуатації, оновлення та контролю серверних ролей також варто узгодити з процесом адміністрування серверів Windows і Linux.

Активація сервера та встановлення RDS CAL

Установлена роль ще не означає, що сервер ліцензій активований. Відкрийте **Remote Desktop Licensing Manager**, натисніть правою кнопкою на ім’я сервера та виберіть **Activate Server**. Майстер запропонує один із методів зв’язку з Microsoft:

- Automatic connection; - Web Browser; - Telephone.

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

Після активації запустіть **Install Licenses**. Подальші поля залежать від каналу придбання. Це може бути номер угоди, код авторизації, номер ліцензії або ключ пакета. Потрібно уважно вибрати:

1. програму ліцензування; 2. версію продукту; 3. тип CAL — User або Device; 4. кількість ліцензій.

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

Після встановлення розкрийте сервер у Licensing Manager і перевірте, що пакет відображається з правильною версією, моделлю та загальною кількістю. Для Device CAL консоль показуватиме видані й доступні ліцензії. Для User CAL технічний облік має інший характер: відображення виданих ліцензій допомагає з аудитом, але сам сервер не завжди блокує підключення в момент перевищення придбаної кількості. Це не скасовує необхідності підтримувати фактичну відповідність ліцензійним умовам.

Перед перенесенням ролі на інший сервер потрібно підготувати план міграції. Не варто просто встановлювати один пакет ключів на кількох серверах. Для повторної активації, пошкодження системи або зміни обладнання може знадобитися деактивація старого вузла чи допомога Clearinghouse.

Налаштування RD Session Host і перевірка

RD Session Host повинен знати дві речі: адресу сервера ліцензій і режим ліцензування. У домені найнадійніше задавати ці параметри через Group Policy. Відкрийте редактор потрібного GPO та перейдіть до:

`Computer Configuration → Administrative Templates → Windows Components → Remote Desktop Services → Remote Desktop Session Host → Licensing`

Увімкніть політику **Use the specified Remote Desktop license servers** і вкажіть FQDN сервера, наприклад `rdlic01.corp.example`. Потім увімкніть **Set the Remote Desktop licensing mode** та виберіть `Per User` або `Per Device`. Режим у політиці повинен відповідати встановленому пакету CAL.

Застосуйте політики на сеансовому вузлі:

gpupdate /force

Перевірити, з якого GPO надійшли налаштування, можна через звіт:

gpresult /h C:\Temp\rds-policy.html

Каталог для звіту має існувати. За потреби створіть його перед виконанням команди:

New-Item -Path C:\Temp -ItemType Directory -Force

Для сервера без домену параметри можна задати через локальну групову політику. Як контрольований технічний варіант також використовують реєстр. Значення `2` означає Per Device, а `4` — Per User:

$licenseServer = "rdlic01.corp.example"
$basePath = "HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core"
$serversPath = "HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers"

New-Item -Path $basePath -Force | Out-Null
New-ItemProperty -Path $basePath -Name LicensingMode -PropertyType DWord -Value 4 -Force
New-Item -Path "$serversPath\$licenseServer" -Force | Out-Null

Групова політика має вищий пріоритет, тому ручне редагування реєстру не виправить конфігурацію, якщо доменний GPO встановлює інші значення. Після зміни параметрів заплануйте перезавантаження RD Session Host, оскільки примусовий перезапуск служби Remote Desktop Services може розірвати активні сеанси адміністраторів і користувачів.

Далі відкрийте **RD Licensing Diagnoser** на сеансовому вузлі. У справній конфігурації він повинен визначити сервер ліцензій, режим і сумісний пакет CAL. Додатково перевірте журнали у **Event Viewer → Applications and Services Logs → Microsoft → Windows → TerminalServices-Licensing** та системний журнал. Події про неможливість знайти сервер, несумісну версію або відсутність доступних CAL потрібно усунути до завершення пільгового періоду.

Перевірку слід виконувати тестовим обліковим записом, який не має адміністративних привілеїв. Увійдіть через RDP, запустіть потрібну опубліковану програму або робочий стіл, завершіть сеанс і перевірте події. Сам факт успішного входу адміністратора не доводить, що ліцензування користувацьких сеансів налаштоване правильно.

Типові помилки

**Плутанина між Windows Server CAL і RDS CAL.** Звичайна серверна CAL не замінює право на використання Remote Desktop Services. Для користувацьких або пристроєвих сеансів потрібна відповідна RDS CAL.

**Розрахунок за одночасними сеансами.** RDS CAL призначаються користувачам або пристроям, а не плаваючому пулу активних підключень. Ліміти Session Host не змінюють ліцензійну модель.

**Невідповідність Per User і Per Device.** Якщо пакет установлений як User CAL, а RD Session Host працює в режимі Per Device, сервер не зможе коректно використати ці ліцензії. Перевіряти потрібно і пакет, і політику.

**Старі CAL для нового сервера.** Ліцензії попередньої версії не слід вважати автоматично сумісними з новішим Windows Server. Оновлення RD Session Host планують разом з оновленням ліцензій.

**Використання короткого імені замість FQDN.** У середовищах із кількома DNS-суфіксами коротке ім’я може визначатися нестабільно. У політиці краще вказувати повне доменне ім’я.

**Очікування до завершення пільгового періоду.** Відкладена активація створює ризик раптової відмови нових підключень. Сервер ліцензій потрібно налаштувати й протестувати одразу після розгортання RD Session Host.

**Ігнорування групових політик.** Локальні параметри можуть перезаписуватися доменним GPO. Якщо значення повертаються після `gpupdate`, потрібно аналізувати результуючу політику, а не повторно редагувати реєстр.

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

**Відсутність резервної документації.** Сам пакет CAL не відновлюється звичайним копіюванням каталогу Windows. Необхідно зберігати дані договору, ключі, тип програми придбання, кількість CAL і контакти, потрібні для повторної активації.

Висновок

Коректне ліцензування Remote Desktop Services складається не лише з придбання RDS CAL. Потрібно вибрати модель Per User або Per Device відповідно до реального способу роботи, перевірити сумісність версій, установити й активувати RD Licensing, додати пакет CAL, а потім призначити сервер ліцензій кожному RD Session Host.

У доменному середовищі параметри краще централізовано задавати через Group Policy. Після застосування політик конфігурацію необхідно перевірити в RD Licensing Diagnoser, журналах подій і тестовому сеансі звичайного користувача. Окремо слід вести облік придбаних і фактично призначених ліцензій, особливо для моделі Per User.

Не варто покладатися на пільговий період або на те, що RDP-підключення поки працюють. Завершеним можна вважати лише таке розгортання, у якому сервер ліцензій активований, пакет відповідає версії Session Host, режим однаковий на всіх рівнях, а результати перевірки не містять попереджень про ліцензування.