RDS на Windows Server 2025 без домена: почему тишина вместо «отключим через 60 минут» — не повод оставлять Per User CAL

Пишу для IT-директора и для владельца небольшого офиса, у которого терминальный сервер поднят в рабочую группу, куплены Per User CAL, и всё три месяца работает без единой жалобы. Я объясню, почему на Windows Server 2025 отсутствие предупреждения «сеанс будет отключён через 60 минут» не доказывает вообще ничего, что на самом деле разрешено в workgroup, как за пятнадцать минут проверить собственный стенд и во что обходится обнаружить проблему на 121-й день, а не на первый.

Тишина в Windows Server 2025 — это не справка о лицензионной чистоте

Ситуация, которую я вижу примерно раз в квартал. Компания поднимает терминальный сервер на Windows Server 2025 Standard. Домен не заводят — «нас полтора десятка, зачем». Ставят роли RD Session Host и RD Licensing на одну машину, активируют сервер лицензий, заливают купленную пачку Per User CAL, в политике выбирают режим «На пользователя». Люди заходят, работают в 1С и в банк-клиенте. Неделя, месяц, три. Ни одного всплывающего окна, ни одного разрыва. IT-директор делает вывод: раз система не ругается — значит, всё собрано правильно. Вот этот вывод и стоит потом денег.

Разберём, откуда взялась привычка ждать предупреждения. Механизм называется soft enforcement — «мягкое принуждение». Microsoft ввела его в Windows Server 2016 для лицензий Per Device и в Windows Server 2019 для Per User. Работал он так: если сервер лицензий недоступен, режим настроен криво или CAL нет вообще, пользователя всё равно пускали, но показывали табличку «There is a problem with your Remote Desktop license, and your session will be disconnected in 60 minutes» и через час рвали сеанс. Неприятно, зато честно: сервер прямым текстом сообщал, что с лицензированием беда.

А теперь ключевое. В статье Microsoft про это сообщение в шапке стоит «Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016», а внутри — отдельная врезка: soft enforcement был удалён в Windows Server 2022. На 2025-м этого механизма просто нет. Он не «не сработал», не «не настроен» — его физически не существует в системе. Значит, у вас исчез единственный индикатор, по которому раньше можно было заметить проблему до того, как она станет аварией. Сервер молчит не потому, что доволен вашей схемой, а потому, что разучился жаловаться.

• тишина НЕ доказывает, что CAL подходящего типа;
• тишина НЕ доказывает, что CAL подходящей версии;
• тишина НЕ доказывает, что сервер лицензий вообще выдаёт лицензии, а не просто стоит рядом;
• тишина НЕ доказывает, что льготный период не идёт прямо сейчас.

Что реально разрешено в рабочей группе: только Per Device

Есть статья Microsoft (KB2473823) про то, как сервер лицензий выдаёт CAL между доменами, лесами и рабочими группами. Раздел про workgroup написан коротко и без вариантов толкования: в среде рабочей группы можно использовать ТОЛЬКО Per Device CAL, поэтому на сервер лицензий следует устанавливать только Per Device; учёт и отчётность по Per User CAL в режиме рабочей группы не поддерживаются; роли RD Session Host и RD Licensing можно поставить на один и тот же сервер. Всё. Никакого «но если очень хочется» там нет.

Причина техническая и она вполне логичная. Per User CAL по своей природе привязывается к учётной записи в Active Directory: сервер лицензий пишет служебные атрибуты прямо в объект пользователя в каталоге. Нет каталога — некуда писать. Поэтому в рабочей группе Per User лицензии не то чтобы «запрещены злым Microsoft», они там нефункциональны: их невозможно ни выдать по-настоящему, ни отследить, ни показать в отчёте. Сервер лицензий в этом режиме — декорация. Per Device CAL, наоборот, отслеживается независимо от членства в Active Directory, это прямо сказано в сравнительной таблице документации.

Второй слой — сама модель Per User. В документации по CAL написано прямым текстом: при использовании модели «на пользователя» лицензирование не является принудительным, каждый пользователь получает право подключаться с любого числа устройств, а сервер выдаёт CAL из доступного пула либо из пула переиспользованных. Ответственность за то, чтобы лицензий хватало, лежит на администраторе. Пул Per User можно переполнить — и это будет нарушением условий лицензирования RDS, о котором никто не сообщит. То есть Per User в рабочей группе — это двойная тишина: не принуждается сама модель и не работает учёт из-за отсутствия домена.

И третий пункт, про который забывают чаще всего: льготный период. Без сервера лицензий RDS работает 120 дней. Дальше клиент обязан получить действительную RDS CAL от сервера лицензий, иначе вход в удалённый сеанс запрещён. Не «предупреждение», не «час на подумать» — отказ. Пилот, который вы запустили в феврале, спокойно доживёт до июня и рухнет в один день, целиком, у всех сразу. Предупреждение система всё-таки пишет — событие 1129 в журнале о скором окончании льготного периода, — но в рабочей группе без мониторинга его, как правило, никто не читает.

• Workgroup → только Per Device CAL, Per User не учитываются;
• RD Session Host и RD Licensing допустимо совмещать на одной машине;
• если сервер лицензий стоит на другой машине рабочей группы — обеспечьте к нему сетевой доступ и укажите его имя явно (автопоиск сервера лицензий не поддерживается начиная с 2008 R2), а после обновления безопасности CVE-2024-38099 ещё и сохраните для NETWORK SERVICE на Session Host учётные данные локального пользователя сервера лицензий через `cmdkey`, иначе запросы на лицензии будут отклоняться как анонимные;
• льготный период — 120 дней, после него без валидной CAL вход блокируется.

Версии CAL: лицензии 2022 к хосту 2025 не подойдут

Вторая мина, на которую наступают одновременно с первой. Люди докупают RDS CAL «как в прошлый раз» — то есть 2019-е или 2022-е — и ставят новый сервер на 2025. Правило совместимости простое и одностороннее: CAL более ранней версии не даёт доступа к более новому Windows Server, а CAL более новой версии к старому — даёт. Формулировка из документации: если у вас RDS CAL для Windows Server 2022, вы можете подключаться к Session Host на 2022 и ниже, но не к Session Host на Windows Server 2025.

Плюс отдельное правило для самого сервера лицензий: устанавливать CAL можно только на сервер лицензий той же версии Windows Server или более новой. На сервере лицензий 2022 вы физически не установите CAL 2025 — мастер их не примет. Отсюда практический вывод, который я применяю всегда: сервер лицензий ставим на самой свежей из имеющихся ОС. Сервер лицензий на Windows Server 2025 обслуживает пакеты CAL 2025, 2022, 2019 и 2016 — то есть закрывает весь ваш парк, включая старые терминалки.

Вот две таблицы, сведённые в списки. Держите их под рукой при закупке — они экономят повторную покупку целиком.

• Session Host 2025 — принимает только CAL 2025;
• Session Host 2022 — принимает CAL 2025 и 2022;
• Session Host 2019 — принимает CAL 2025, 2022, 2019;
• Session Host 2016 — принимает CAL 2025, 2022, 2019, 2016;
• Сервер лицензий 2025 — ставит любые CAL 2016–2025;
• Сервер лицензий 2022 — ставит CAL 2022, 2019, 2016, но НЕ 2025;
• Сервер лицензий 2019 — ставит CAL 2019 и 2016.

Разбор: бухгалтерское бюро «Сальдо-Про», 14 рабочих мест, 121-й день

Прошлым летом к нам обратилось бухгалтерское бюро — назову его «Сальдо-Про» — с формулировкой «утром никто не может зайти на сервер». Четырнадцать рабочих мест, из них двенадцать бухгалтеров работают только терминально: 1С:Бухгалтерия и ЗУП клиентов бюро, сервисы сдачи отчётности, банк-клиенты. Домена нет и никогда не было, локальные учётки заводили руками. Сервер — небольшая стоечная машина с Windows Server 2025 Standard, 4 vCPU и 24 ГБ памяти, поднят приходящим подрядчиком в начале февраля. Роли RD Session Host и RD Licensing на одной машине, сервер лицензий активирован по интернету — тут всё по учебнику. Дальше — нет.

Что нашли за первый час. В политике Set the Remote Desktop licensing mode стояло «Per User». На сервере лицензий лежал один пакет — 15 Per User CAL для Windows Server 2022. То есть сразу две ошибки в одном месте: неверный тип лицензий для рабочей группы и неверная версия для хоста 2025. Диагностика подтвердила: lsdiag.msc показывал, что подходящих лицензий для этого Session Host не найдено, а в журнале Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin за ночь на 121-й день лежало событие 1128 — льготный период RD Licensing истёк, служба не зарегистрировалась на сервере лицензий с установленными лицензиями. За две недели до этого в том же журнале ежедневно появлялось событие 1129 — «льготный период скоро истечёт», но журналы на сервере никто не открывал. Для пользователей это были четыре месяца без единого сигнала.

Почему подрядчик и IT-директор были уверены, что всё в порядке: они помнили про табличку «отключим через 60 минут» по опыту с Windows Server 2016 и 2019. Табличек не было — значит, лицензии приняты. На 2025 их не было бы в любом случае: soft enforcement убрали в 2022-й версии. Причём в модели Per User, как мы разобрали выше, принуждения нет вообще — сеансы открывались бы и открывались, пока не кончился льготный период. Сервер не «сломался» на 121-й день, он ровно в этот день впервые начал вести себя штатно.

Чем закончилось. Купили 16 Per Device CAL для Windows Server 2025 — по одной на каждый компьютер и тонкий клиент плюс небольшой запас на замену техники. Старые Per User 2022 в этой схеме не пригодились никак, деньги на них фактически списали в убыток — для бюро такого размера это заметная сумма, сопоставимая с ценой самого сервера. Пакет 2022 остался на сервере лицензий: он не мешает, просто не выдаётся хосту 2025. Переключили режим на Per Device, указали сервер лицензий явно как 127.0.0.1, перезапустили службы, прогнали lsdiag.msc до зелёного состояния. Всех вернули в работу за три с половиной часа с момента звонка — в бухгалтерии, где у каждого на день запланированы платёжки и выписки клиентов, это ощущалось как потерянный рабочий день. Отдельно, уже спокойно, обсудили домен: на 14 рабочих мест с одним сервером и без планов роста AD не окупается, поэтому бюро осталось в рабочей группе на Per Device, а проверку лицензирования мы включили в ежемесячный регламент.

• Симптом: одномоментный отказ входа у всех пользователей, без предупреждений накануне;
• Триггер: истечение 120-дневного льготного периода;
• Корневая причина №1: Per User CAL в рабочей группе — не поддерживается;
• Корневая причина №2: CAL 2022 на Session Host 2025 — несовместимы;
• Стоимость ошибки: повторная закупка CAL на всех плюс полдня простоя 12 бухгалтеров.

Проверка своего стенда за пятнадцать минут

Если у вас терминальный сервер в рабочей группе и вы дочитали до этого места — просто прогоните четыре проверки. Первая: сколько осталось от льготного периода. Метод возвращает число дней до конца льготного периода, ноль означает, что период закончился. Само по себе это число не доказывает ни наличие, ни отсутствие лицензий — счётчик тикает от первого запуска роли. Смотреть его нужно в паре с третьей проверкой: если дни ещё есть, а сервер лицензий не выдал хосту ни одной CAL, вы живёте в кредит, что бы ни было написано в накладной.

$s = Get-CimInstance -Namespace root/cimv2/terminalservices -ClassName Win32_TerminalServiceSetting
(Invoke-CimMethod -InputObject $s -MethodName GetGracePeriodDays).DaysLeft

Вторая: какой режим лицензирования и какой сервер лицензий реально прописан. Если настройка делалась политикой — смотрите ветку Policies, если через консоль Remote Desktop Services — вторую пару ключей. Значение LicensingMode равно 2 для Per Device и 4 для Per User; в рабочей группе допустима только двойка. Настройки, заданные групповой политикой, перекрывают то, что вы видите в графических консолях, — это отдельная классическая ловушка: в GUI показано одно, работает другое.

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' |
  Select-Object LicensingMode, LicenseServers

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core' |
  Select-Object LicensingMode

Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers\SpecifiedLicenseServers'

Третья: что за пакеты CAL лежат на сервере лицензий — тип, версия, сколько выдано. Тут сразу видно и «Per User вместо Per Device», и «2022 вместо 2025», и пакет, из которого не выдано ни одной лицензии за полгода (верный признак, что хост его не берёт).

Get-CimInstance -ClassName Win32_TSLicenseKeyPack |
  Select-Object KeyPackId, ProductVersion, TypeAndModel,
                TotalLicenses, IssuedLicenses, AvailableLicenses |
  Format-Table -AutoSize

Четвёртая: журналы. События 1128, 1129 и 1130 от источника TerminalServices-RemoteConnectionManager — это соответственно «льготный период истёк», «льготный период скоро истечёт» и «сервер лицензий не указан». На разных сборках они попадают либо в оперативный журнал роли, либо в System, поэтому проверяю оба. И отдельно — графический диагност lsdiag.msc (RD Licensing Diagnoser) плюс консоль управления лицензиями licmgr.exe: первый прямым текстом пишет, каких лицензий не хватает, второй показывает пакеты и активацию.

Get-WinEvent -FilterHashtable @{
  LogName = 'Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin'
  Id      = 1128,1129,1130
} -MaxEvents 20 -ErrorAction SilentlyContinue |
  Format-Table TimeCreated, Id, LevelDisplayName -AutoSize

Get-WinEvent -FilterHashtable @{ LogName='System'; Id=1128,1129,1130 } `
  -MaxEvents 20 -ErrorAction SilentlyContinue |
  Format-Table TimeCreated, Id -AutoSize

• `GetGracePeriodDays` показывает остаток дней, а в `Win32_TSLicenseKeyPack` у пакета нужного типа `IssuedLicenses = 0` — хост живёт на льготном периоде;
• `LicensingMode = 4` в рабочей группе — конфигурация не поддерживается;
• событие 1129 — до конца льготного периода остались дни, пора действовать, а не ждать 1128;
• событие 1130 — сервер лицензий не указан, автопоиск в 2025 не спасёт;
• `lsdiag.msc` жёлтый или красный — считайте, что льготный период уже тикает.

Как я разворачиваю RDS в рабочей группе, когда домена нет

Схема, которую я ставлю у клиентов до 50 рабочих мест, когда AD по каким-то причинам не заводится. Обе роли — на одну машину, это официально допустимо и снимает половину проблем с доступностью сервера лицензий. Ставим фичи, перезагружаемся, дальше активируем сервер лицензий через licmgr.exe (мастер активации, вариант «Автоматически» при наличии интернета) и заливаем пакет Per Device CAL нужной версии.

Install-WindowsFeature -Name RDS-RD-Server, RDS-Licensing -IncludeManagementTools
Restart-Computer

Дальше — режим и адрес сервера лицензий. Я задаю их через реестр в ветке Policies: так значение переживает эксперименты в GUI и его видно одной командой при следующем аудите. LicensingMode = 2 — это Per Device, единственный допустимый вариант без домена. В LicenseServers для совмещённой роли пишу 127.0.0.1. Затем gpupdate /force и перезапуск службы удалённых рабочих столов (или, что честнее, перезагрузка сервера в окно обслуживания).

$p = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services'
New-Item -Path $p -Force | Out-Null
New-ItemProperty -Path $p -Name LicensingMode  -PropertyType DWord  -Value 2 -Force
New-ItemProperty -Path $p -Name LicenseServers -PropertyType String -Value '127.0.0.1' -Force
gpupdate /force

То же самое руками делается в gpedit.msc: Конфигурация компьютера → Административные шаблоны → Компоненты Windows → Службы удалённых рабочих столов → Узел сеансов удалённых рабочих столов → Лицензирование. Два параметра: «Задать режим лицензирования удалённых рабочих столов» → Per Device и «Использовать указанные серверы лицензирования удалённых рабочих столов» → 127.0.0.1. После этого обязательно lsdiag.msc — он должен быть чистым, без предупреждений. Не «работает же, значит норм», а именно зелёный диагност.

Пользователи в рабочей группе заводятся локально и добавляются в группу «Пользователи удалённого рабочего стола». Мелочь, но её тоже стоит держать в скрипте, а не в памяти админа: при переустановке сервера половина времени уходит на восстановление списка.

• `Install-WindowsFeature RDS-RD-Server, RDS-Licensing -IncludeManagementTools` → перезагрузка;
• `licmgr.exe` → активировать сервер лицензий → установить пакет Per Device CAL нужной версии ОС;
• режим Per Device + сервер лицензий `127.0.0.1` через политику или реестр;
• `gpupdate /force`, перезапуск служб, проверка `lsdiag.msc` до зелёного;
• `New-LocalUser` + `Add-LocalGroupMember -SID S-1-5-32-555` (группа «Пользователи удалённого рабочего стола», по SID — чтобы скрипт работал и на русской, и на английской Windows) — скриптом, не руками.

Где я не буду драматизировать: что спорно и на что можно забить

Честно про минусы Per Device, чтобы вы шли в эту схему с открытыми глазами. Лицензия привязывается к устройству физически. Первое подключение выдаёт временную CAL на 90 дней, при повторном подключении она превращается в постоянную со сроком от 52 до 89 дней (период рандомизирован специально, чтобы не было пиков продления), и дальше обновляется автоматически, когда до окончания остаётся меньше семи дней. Постоянные Per Device CAL нельзя переполнить — при исчерпании пула новое устройство просто не пустят. Отозвать можно не более 20 % от общего количества. То есть при переустановке Windows на тонком клиенте или замене ноутбука вы тратите лицензию, а вернуть её можете не всегда.

Практический вывод из этого: закладывайте запас 10–15 % при закупке Per Device CAL, если у вас живой парк с ротацией техники. Не 100 % и не двойной — именно 10–15 %. За четыре года наблюдений расход на переустановки у компаний до 50 рабочих мест укладывался в этот коридор, а лимита отзыва в 20 % хватало на всё остальное.

Теперь про то, на что можно забить. Старый пакет Per User CAL, который остался на сервере лицензий, удалять не обязательно — он не конфликтует и не мешает выдаче Per Device. Дырка в бюджете от этого не зарастёт, но и вреда нет. Гнаться за отдельной машиной под сервер лицензий на 20–40 рабочих мест тоже не надо: Microsoft прямо разрешает совмещение ролей, а отдельный сервер добавит вам только новую точку отказа и ещё один канал сетевых проблем.

И спорный вопрос, по которому единого правильного ответа нет: заводить ли домен ради Per User. Аргумент за — Per User честнее по деньгам, если у человека три устройства, и открывает нормальное управление политиками. Аргумент против — AD это не только контроллер, это резервирование, бэкап состояния системы, регламент восстановления и, как правило, вторая машина. Моя позиция: до 20 рабочих мест — как у «Сальдо-Про» — рабочей группы с Per Device достаточно, от 30 и выше домен уже окупается не лицензиями, а управляемостью. В диапазоне 20–30 решает конкретика — сколько устройств на человека, есть ли удалёнка с личных ноутбуков, планируется ли рост. Только не переезжайте в домен ровно в тот момент, когда сгорел льготный период: сначала верните людей в работу на Per Device, а миграцию планируйте отдельным проектом.

• запас Per Device CAL при закупке — 10–15 %;
• лимит отзыва — 20 % от общего числа CAL, это потолок, а не резерв «на всякий случай»;
• старые несовместимые пакеты CAL можно оставить на сервере лицензий, они не мешают;
• совмещение RD Session Host и RD Licensing на 20–40 РМ — норма, а не компромисс;
• миграция в домен — отдельный проект, а не аварийная мера.

Частые вопросы