Работа с аппаратными многопользовательскими ключами защиты HASP в терминальной среде Windows Server часто сопровождается неприятными симптомами. Пользователи регулярно сталкиваются с ошибками типа «Не найден ключ защиты программы», лицензии самопроизвольно блокируются с признаком Timeout = 0 в мониторе AKS (HASP Monitor), а реальное количество доступных подключений оказывается значительно меньше номинала ключа. При этом перезапуск службы HASP Loader или всего сервера помогает лишь временно.
В этой статье мы подробно разберем, почему возникают подобные сбои в терминальном режиме, и проанализируем комплексные методы решения этой проблемы — от переноса менеджера лицензий до тонкой настройки реестра Windows и конфигурационных файлов 1С.
Для начала проанализируем ситуацию, описанную системными администраторами. В утилите AKS Monitor сессии отображаются в статусе активных, но имеют timeout = 0. Это так называемые «зависшие» или «фантомные» лицензии. В штатном режиме менеджер лицензий HASP LM обменивается с клиентом пакетами для проверки активности. Если клиент закрыл сессию некорректно, таймаут должен постепенно уменьшаться, после чего лицензия возвращается в пул.
Однако в терминальном режиме на одном IP-адресе (адресе терминального сервера) работают десятки пользователей. Возникает конфликт одновременной раздачи. Рассмотрим основные причины возникновения зависших лицензий:
1cv8.exe. При этом сетевое соединение разрывается некорректно, и HASP LM считает, что клиент все еще удерживает лицензию.HASP LM, и самим сервером «1С:Предприятия» (если в свойствах базы включена опция Разрешить выдачу лицензий сервером). В этом случае лицензии блокируются намертво с нулевым таймаутом до перезапуска служб.Официальная документация разработчиков защиты Aladdin (ныне Thales) прямо указывает на то, что стабильная работа менеджера лицензий (HASP LM) на одной машине с активной службой терминалов (Remote Desktop Services) не гарантируется. Терминальный сервер создает слишком высокую нагрузку на сетевой стек и искажает логику идентификации клиентов по IP/имени компьютера.
Самым простым и надежным решением является физический или виртуальный перенос ключа и службы LM:
По умолчанию платформа 1С пытается обнаружить ключ защиты в локальной сети с помощью широковещательных UDP-запросов (Broadcasting) по порту 475. В терминальной среде, где запущено множество сеансов, это вызывает лавинообразный рост сетевых запросов, задержки и регулярные потери ключа.
Чтобы стабилизировать подключение, переведем обмен данными на направленный протокол TCP и жестко укажем адрес сервера лицензий.
Выполним настройку на стороне клиента (на терминальном сервере). Для этого найдем файл nethasp.ini. Обычно он располагается в каталоге C:\Program Files\1cv8\conf\ или в папке конкретной версии платформы (например, C:\Program Files\1cv8\8.3.X.X\bin\conf\). Приведем его к следующему виду:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.50 ; Укажите здесь реальный IP-адрес ПК, куда перенесли ключ
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = TCP ; Переключаем с UDP на более надежный TCP
NH_USE_BROADCAST = Disabled ; Отключаем широковещательный опрос сети
NH_CLIENT_NAME = TerminalServer ; Уникальное имя клиента для монитора
Теперь настроим серверную часть менеджера лицензий на том компьютере, где физически установлен ключ. Найдем файл настроек службы nhsrv.ini (он лежит в папке с установленным HASP LM). Чтобы служба гарантированно применила параметры, скопируем этот файл также в системную папку C:\Windows\System32 (или C:\Windows\SysWOW64 для 64-битных систем) и пропишем в нем отключение неиспользуемых протоколов:
[NHS_IP]
NHS_USER_IPP_ONLY = enabled
NHS_USE_UDP = disabled ; Отключаем нестабильный UDP
NHS_USE_TCP = enabled ; Разрешаем только TCP-подключения
После внесения изменений обязательно перезапустим службу HASP Loader на сервере лицензий.
Часто системные администраторы замечают, что пользователь закрыл 1С, но его сессия в диспетчере служб терминалов RDS продолжает висеть в состоянии «Дисконнект» или «Активен», удерживая лицензию. Виновником этой проблемы является системный процесс печати SplWOW64.exe.
Когда пользователь запускает 32-битное приложение 1С на 64-битной операционной системе Windows Server и отправляет документ на печать, операционная система порождает транслятор печати — процесс SplWOW64.exe. По умолчанию этот процесс остается активным в сессии пользователя в течение 20 минут после закрытия основного приложения, чтобы ускорить последующую печать. Терминальный сервер видит активный системный процесс и не закрывает сессию до конца, из-за чего лицензия HASP остается заблокированной.
Для решения этой проблемы настроим принудительное завершение этого процесса через реестр терминального сервера:
regedit на терминальном сервере от имени администратора.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PrintDWORD 32 бита) и присвоим ему десятичное значение 1 (это сократит время удержания процесса в памяти до 1 секунды после закрытия печати).HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcsDWORD 32 бита) и присвоим ему значение 0 (это даст команду системе завершать процесс немедленно при выходе пользователя).Для применения настроек реестра потребуется перезагрузить терминальный сервер во внерабочее время.
Если мы используем клиент-серверный вариант работы (1С + MS SQL Server / PostgreSQL), нам необходимо четко разграничить логику подсчета лицензий. Существует два принципиально разных механизма:
Чтобы избежать хаотичного расхода и блокировок, настроим параметры информационной базы в консоли администрирования кластера 1С:
Администрирование серверов 1С Предприятия.Также, если используются рабочие процессы кластера, обратим внимание на частоту их перезапуска. Рекомендуется настроить интервал перезапуска рабочих процессов в свойствах кластера (параметр Интервал перезапуска процессов установить равным 86400 секунд — 24 часа), чтобы автоматически высвобождать зависшие сеансы в нерабочее время.
Многие компании отказываются от аппаратных USB-ключей в пользу программных лицензий (пин-кодов). Однако в терминальном режиме здесь тоже есть свои нюансы. Если установить несколько однопользовательских программных лицензий на терминальный сервер, они могут начать конфликтовать или перестать видеться платформой.
Разберем по шагам правильный алгоритм перевода терминального сервера на программные лицензии:
.lic и файл conn8211.pfl во всех пользовательских каталогах, а также в общей папке C:\ProgramData\1C\licenses\.C:\ProgramData\1C\licenses, чтобы все пользователи терминала имели к ним беспрепятственный доступ на чтение.При использовании виртуализации (VMware ESXi, Microsoft Hyper-V, Proxmox) часто возникает проблема физического отсутствия USB-портов в гостевой операционной системе. Использование программных эмуляторов (дампов ключей) незаконно и приводит к нестабильности платформы.
Рассмотрим цивилизованные и стабильные методы решения этой задачи:
Резюмируя все вышесказанное, для стабильной работы 1С на терминальном сервере необходимо отказаться от локальной установки менеджера лицензий на терминальной машине, жестко прописать параметры TCP-подключения в файле nethasp.ini, настроить реестр Windows для корректного завершения сессий печати и разграничить зоны ответственности между сервером приложений и менеджером лицензий HASP.