Сеанс RDP отключается через 60 минут: лицензии удалённых рабочих столов и льготный период

Сообщение «Возникла проблема с лицензией удалённых рабочих столов, сеанс будет отключён через 60 минут» значит одно: сервер сеансов не смог получить CAL у сервера лицензирования, а Windows пока не блокирует вход, но выгоняет раз в час. Лечится проверкой службы лицензирования, режима и адреса сервера. Ниже — порядок диагностики, причины и разбор на живом кейсе.

Что означает сообщение про 60 минут и почему оно появляется именно час

Ко мне с этим приходят регулярно, обычно в понедельник утром: у бухгалтера или кладовщика на экране жёлтое окно, что с лицензией удалённых рабочих столов проблема, а сеанс отключится через 60 минут. Первая реакция — «у нас закончился какой-то срок, срочно покупать». Не торопитесь. Мы в АйТи-Фреш обслуживаем терминальные серверы малых компаний, и в большинстве таких обращений лицензии вообще целы. Сломано не количество CAL, а путь, по которому сервер сеансов до них достаёт.

Microsoft описывает это сообщение в отдельной статье поддержки. Текст такой: «There is a problem with your Remote Desktop license, and your session will be disconnected in 60 minutes. Contact your system administrator to fix this problem.» Причина названа прямо: это работа функции мягкого применения лицензирования (soft enforcement). Она сообщает, что есть неполадка на сервере лицензирования либо что-то мешает связи между ним и сервером сеансов (RD Session Host). Раньше при такой неполадке пользователя просто не пускали. Теперь пускают, но на 60 минут за раз.

Важная деталь, которую упускают: после отключения человек может сразу зайти снова и вернуться в тот же сеанс. Данные не теряются, программа 1С остаётся открытой. Поэтому проблема долго живёт незамеченной — люди раздражаются, но терпят, а админу про неё не пишут. Я считаю это самым коварным свойством режима: сломанное лицензирование не падает громко, оно тихо портит жизнь всей смене. Если у вас жалуются на «странные выкидывания раз в час», сначала посмотрите, не появляется ли при входе это окно.

Отдельно отмечу, чем это сообщение НЕ является. Это не групповая политика с лимитом времени сеанса и не тайм-аут простоя: если бы лимит задавала политика, окна про лицензию вы бы не увидели. Это и не признак взлома. Это штатное сообщение лицензирования, и пока вы не разобрались с его причиной, любые правки таймаутов сеансов только запутают картину.

Льготный период 120 дней и мягкое применение: как они связаны

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

По версиям картина такая. Мягкое применение появилось в Windows Server 2016 для лицензирования «на устройство» и в Windows Server 2019 для лицензирования «на пользователя». В Windows Server 2022, как прямо сказано в статье Microsoft, эту функцию убрали. Значит, на 2022 и новее вы окна про 60 минут не увидите вообще, а сломанное лицензирование проявится иначе: по истечении льготного периода вход просто будет закрыт. Мой разбор того, почему тишина на новом сервере не доказывает, что всё в порядке, лежит в статье про RDS без домена и лицензии на устройство.

Из этого следует практический вывод: если вы видите окно про 60 минут, у вас, скорее всего, Windows Server 2016 или 2019 в роли сервера сеансов. Для режима «на пользователя» на 2019 Microsoft отдельно советует поставить на все серверы удалённых рабочих столов последние обновления, а если проблема останется — обращаться в поддержку Microsoft. Для режима «на устройство» причины перечислены конкретнее, и именно ими мы займёмся дальше.

Ещё одна ловушка — путать льготный период с временными лицензиями. Временная CAL «на устройство» выдаётся при первом подключении устройства и действует 90 дней, пока у сервера нет свободных постоянных. А льготные 120 дней отсчитываются у самого сервера сеансов. Эти сроки разные, и по одному из них вы не можете судить о втором. Когда я проверяю чужой терминал, я всегда записываю в заметку оба показателя отдельно.

Как за 15 минут найти причину: порядок проверки

Начинаю с самого дешёвого и самого частого. Первое — работает ли служба на сервере лицензирования. Microsoft перечисляет её первой в списке причин: если служба удалённых рабочих столов (лицензирование) не запущена, сервер не сможет выдать лицензию. Имя службы в реестре — TermServLicensing, и проверить её можно с одного клика в services.msc или так:

Get-Service -Name TermServLicensing
Start-Service -Name TermServLicensing

Второе — убедиться, что роль лицензирования назначена правильному серверу. В Диспетчере серверов откройте «Службы удалённых рабочих столов», раздел «Обзор», и проверьте список серверов развёртывания. Бывает, что роль «живёт» не там, где вы думаете, особенно после переносов виртуальных машин.

Третье, и самое интересное, — настройки лицензирования на самом сервере сеансов: режим и список серверов. Microsoft предлагает три места проверки: консоль служб удалённых рабочих столов в Диспетчере серверов («Изменить свойства развёртывания», вкладка RD Licensing), групповую политику и реестр. Тут главная засада: всё, что задано групповой политикой, перекрывает настройки из Диспетчера серверов. Я не раз видел, как админ старательно правит адрес в консоли, а старая политика из домена спокойно его затирает. Политика лежит здесь: «Конфигурация компьютера — Административные шаблоны — Компоненты Windows — Службы удалённых рабочих столов — Узел сеансов удалённых рабочих столов — Лицензирование». Там два параметра: «Использовать указанные серверы лицензирования удалённых рабочих столов» и «Задать режим лицензирования удалённых рабочих столов».

Если нужна проверка без мыши, смотрю реестр. По документации Microsoft, при управлении через групповую политику значения лежат в HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services: строка LicenseServers и параметр DWORD LicensingMode. При настройке через консоль они лежат в другом месте: LicensingMode в HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core, а адреса серверов — в многострочном значении SpecifiedLicenseServers по пути HKLM\SYSTEM\CurrentControlSet\Services\TermService\Parameters\LicenseServers\SpecifiedLicenseServers. Прочитать можно так:

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services' | Select-Object LicenseServers, LicensingMode
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\Licensing Core' | Select-Object LicensingMode

Числовые значения LicensingMode я по памяти не расшифровываю — смотрите таблицу значений в документации Microsoft для вашей версии.

Четвёртое — связность. Сервер сеансов должен достучаться до сервера лицензирования по имени и по сети, а между ними не должен стоять межсетевой экран, который режет обмен. Полный перечень портов между компонентами RDS Microsoft вынесла в отдельные страницы, и я не буду пересказывать их по памяти: откройте перечень портов для вашей версии и сверьте с правилами файрвола. Проверить имя и базовую доступность можно с сервера сеансов:

Resolve-DnsName lic01.example.com
Test-NetConnection -ComputerName lic01.example.com

И последнее перед тем, как лезть глубже: Microsoft советует воспроизводить проблему тем же способом, каким заходит пользователь. Если у вас есть брокер подключений, зайдите через веб-доступ RD Web, а если брокера нет — обычным mstsc напрямую на сервер сеансов.

Пять типичных причин и что с ними делать

Microsoft для режима «на устройство» называет четыре самые частые причины: не запущена служба лицензирования, неверно настроены свойства лицензирования, серверы сеансов не могут связаться с сервером лицензирования, и серверы сеансов, сервер лицензирования и пользователи не находятся в одном домене при неправильно настроенном доверии. Пятую я беру из той же статьи, где её велят проверить ещё до начала диагностики, — несовместимость версий CAL с версией хоста и сервера лицензирования. Все пять сведены в таблицу вместе с тем, с чего я начинаю лечение. | Симптом / причина | Как проверить | Что делать | |---|---|---| | Не запущена служба TermServLicensing | Get-Service на сервере лицензирования | Запустить и поставить автозапуск | | Неверный адрес сервера или режим | GPO, консоль, ключи реестра | Исправить в одном месте, убрать конфликт с GPO | | Нет связи сервера сеансов с сервером лицензирования | Resolve-DnsName, правила файрвола | Починить DNS, открыть порты по перечню Microsoft | | Разные домены/леса или рабочая группа | Где находятся оба сервера | Обеспечить доверие либо использовать только CAL на устройство | | CAL старее версии сервера сеансов | Версия ОС хоста и версия установленных CAL | Докупить CAL нужной версии |

Версии — отдельная история, и на неё стоит потратить минуту. По таблице совместимости Microsoft, CAL более ранней версии не годится для более новой версии Windows Server, а CAL новее — годятся для более старых. Пример из документации: лицензии Windows Server 2022 подключат вас к хосту на 2022 и ниже, но не к хосту на 2025. Для сервера лицензирования правило зеркальное: лицензии ставятся на сервер той же версии или новее. Подробно, с таблицами и ценами, про выбор между пользовательскими и устройственными лицензиями я писал в материале про CAL на пользователя и на устройство, поэтому здесь не повторяюсь.

Теперь рабочая группа. Если у вас нет домена, документация Microsoft однозначна: в рабочей группе допустимы только CAL «на устройство», а учёт и отчётность по CAL «на пользователя» там не поддерживаются. И есть свежая тонкость. После установки обновления безопасности для CVE-2024-38099 сервер лицензирования требует, чтобы сервер сеансов предъявлял не анонимные учётные данные при запросе лицензии. В рабочей группе это решается так: на сервере лицензирования создают отдельного пользователя, а на сервере сеансов от имени NT AUTHORITY\NETWORK SERVICE добавляют учётные данные командой cmdkey. Документация приводит такой порядок:

psexec.exe -I -u "NT AUTHORITY\NETWORK SERVICE" cmd.exe
cmdkey /add:<ИМЯ-СЕРВЕРА-ЛИЦЕНЗИРОВАНИЯ> /user:<ИМЯ-СЕРВЕРА-ЛИЦЕНЗИРОВАНИЯ>\<ПОЛЬЗОВАТЕЛЬ> /pass

Пароль система спросит сама. Есть и запасной вариант — отключить проверку параметром DisableWorkgroupAuthEnforcement в ветке TermServLicensing\Parameters, но Microsoft прямо предупреждает, что это повышает риски и будущие версии Windows могут перестать учитывать параметр. Я так не делаю.

Как исправить, когда причина найдена. Если вы настраиваете сервер сеансов без брокера подключений, адрес сервера и режим задают групповой политикой — центральной из домена или локальной на каждом хосте. Если брокер есть, можно использовать командлет, который описан в справке Microsoft:

Set-RDLicenseConfiguration -LicenseServer 'lic01.example.com' -Mode PerDevice -ConnectionBroker 'rdcb01.example.com' -Force

У командлета три набора параметров: только режим, только сервер, либо оба сразу. Допустимые значения режима — PerDevice, PerUser и NotConfigured. После правок обновите политику на хосте командой gpupdate /force и заново подключитесь, лучше с чистого устройства.

Кейс: сумочное производство «Кожа и строчка», 43 рабочих места

Условный клиент для этого разбора — сумочное производство «Кожа и строчка». Всего 43 рабочих места: офис, склад, раскройный и швейный цеха. Через удалённые рабочие столы работают 31 человек с 26 компьютеров, 1С и складской учёт запущены на одном терминальном сервере под Windows Server 2019, а сервер лицензирования стоит отдельной виртуальной машиной. Лицензирование — «на устройство»: в цехах и на складе за одним компьютером сидят разные смены, это тот самый случай, когда лицензии на устройство выгоднее. Всего на сервере лицензирования было активировано 30 CAL «на устройство» версии 2019 — с запасом на 26 машин, так что нехватку лицензий я исключил сразу.

Обращение звучало так: «со вторника у части людей жёлтое окно про лицензию, с каждым днём таких всё больше, в цехе выкидывает раз в час, а кладовщица посреди накладной каждый раз заново входит в сеанс». Нарастание по дням — характерный признак: CAL «на устройство» продлевается, только когда до окончания её срока остаётся меньше семи дней, поэтому машины «отваливались» по очереди, по мере того как подходили сроки продления. Сначала я проверил самое простое. Служба TermServLicensing на сервере лицензирования работала, лицензии в диспетчере лицензирования были на месте. Тогда я сравнил, куда смотрит сам хост: через gpresult увидел, что сервер сеансов получает от домена политику с указанием старого имени сервера лицензирования. За неделю до этого роль лицензирования перенесли на новую виртуальную машину с новым именем: лицензии туда установили и активировали заново, старую машину выключили, а в политике остался прежний адрес.

Исправление заняло около 40 минут вместе с диагностикой. В политике «Использовать указанные серверы лицензирования удалённых рабочих столов» я заменил имя на актуальное, сверил режим «на устройство» в параметре «Задать режим лицензирования», выполнил gpupdate /force на хосте и подключился с рабочей станции из цеха. Окно пропало. Ещё через час я специально понаблюдал за сеансом контрольного пользователя: отключения прекратились. Итог — без единой покупки и без простоя в смене. Отдельно мы после этого завели в чек-листе миграций виртуальных машин пункт «проверить, на что ссылаются политики и конфигурации RDS».

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

Чего не делать и как не попасть на это снова

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

Второе, что стоит сделать сразу, — убрать конфликт мест настройки. Выберите один источник правды: либо групповую политику, либо консоль Диспетчера серверов, но не оба сразу. Microsoft отдельно предупреждает, что групповая политика перекрывает консоль. В небольших компаниях я предпочитаю политику: она одинакова для всех хостов, видна в gpresult и переживает пересоздание сервера. Если вы разворачиваете ферму с нуля, учтите это на этапе проектирования, как описано в материале про развёртывание фермы RDS.

Третье — профилактика. Раз в месяц проверяйте четыре вещи: работает ли служба TermServLicensing, остаётся ли актуальным имя сервера в политике, достаточно ли CAL нужной версии и режима, и нет ли свежих жалоб на отключения по часам. Если сервер лицензирования когда-либо переносили, переименовывали или восстанавливали, сразу сверяйте адреса. Активацию сервера лицензирования Microsoft делает через Диспетчер лицензирования удалённых рабочих столов: автоматическое подключение идёт к Microsoft Clearinghouse исходящим соединением по TCP 443, а если выхода в интернет у сервера нет, доступны способы через веб-браузер и по телефону.

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

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