Администрирование аппаратных ключей защиты HASP в крупных инфраструктурах «1С:Предприятия» нередко преподносит неприятные сюрпризы. Типичная ситуация: в организации куплено и установлено несколько сетевых ключей (например, два по 50 лицензий и один на 100), распределенных по разным серверам сети. Физически лицензий должно хватать с запасом, однако пользователи регулярно сталкиваются с ошибками запуска и сообщениями об отсутствии свободных лицензий. При этом мониторинг показывает странную картину: один или два ключа переполнены, а самый емкий ключ простаивает практически пустым.
В этой статье мы подробно разберем внутреннюю логику работы платформы «1С:Предприятие» с HASP-ключами, проанализируем ключевые системные ограничения и настроим инфраструктуру так, чтобы полностью устранить дефицит лицензий и добиться их равномерного распределения.
Для того чтобы эффективно решить проблему, нам необходимо понять, как именно сервер 1С и клиентские лицензии взаимодействуют друг с другом. Выделим несколько неочевидных системных ограничений, которые чаще всего приводят к «зависаниям» и неравномерной нагрузке на ключи.
1. Жесткое ограничение сервера 1С: «Правило одной серии»
Если в настройках информационных баз в консоли администрирования кластера включен параметр «Разрешить выдачу лицензий сервером 1С:Предприятия» (установлено значение «Да»), то подсчетом и раздачей лицензий занимается непосредственно сервер приложений. В этом режиме вступает в силу жесткое аппаратное ограничение платформы 1С.
Все сетевые многопользовательские ключи на 5, 10, 20, 50, 100 и более пользователей относятся к одной и той же серии — ORGL8. Согласно правилам работы платформы, сервер 1С при опросе менеджеров лицензий по сети может подключиться только к одному сетевому ключу серии ORGL8. Все остальные сетевые ключи этой же серии на других серверах будут им полностью проигнорированы. Сервер случайным образом выберет один из ключей (например, на 50 лицензий), забьет его до предела, после чего начнет сообщать пользователям о нехватке лицензий, хотя ключ на 100 мест на соседнем сервере будет полностью свободен.
Исключение из этого правила составляют только локально установленные ключи (вставленные в USB-порт самого сервера 1С) и ключи разных серий (например, сочетание ключей серии ORGL8, ORG8A на 300 мест и ORG8B на 500 мест).
2. Причина «зависших» лицензий с нулевым таймаутом (Timeout 0)
В процессе мониторинга через утилиту Aladdin Monitor администраторы часто сталкиваются со статусом сессии Timeout 0. Это следствие так называемого смешанного режима работы, когда часть баз настроена на раздачу лицензий сервером, а другая часть — напрямую клиентами. В таком случае менеджер лицензий HASP LM считает лицензии занятыми и не освобождает их мгновенно при закрытии сеансов (из-за сетевых сбоев или некорректного завершения RDP-сессий). Блокировка может сохраняться до 36 часов. Перезапуск службы nhsrv (HASP LM) не всегда решает проблему, поскольку информация о сессиях кэшируется драйвером защиты операционной системы.
3. Кэширование лицензий в файле 1cv8conn.pfl и двойной расход
При первом успешном запуске платформа 1С сохраняет адрес найденного менеджера лицензий в локальный файл кэша пользователя — 1cv8conn.pfl. При последующих запусках 1С игнорирует общий порядок опроса из nethasp.ini и обращается напрямую к этому серверу. Если пользователь запускает вторую базу, а на сохраненном сервере лицензий уже нет, платформа находит свободную лицензию на втором ключе. В итоге один и тот же сотрудник занимает две лицензии на разных ключах вместо одной, что удваивает расход сетевых ресурсов.
---
Самый надежный способ заставить систему использовать весь доступный пул лицензий (50+50+100) — перевести базы в режим самостоятельного получения лицензий клиентскими машинами. Выполним это по шагам:
После выполнения этой настройки сервер 1С перестанет самостоятельно раздавать лицензии. Каждое клиентское приложение при запуске будет обращаться к менеджерам лицензий по сети напрямую, используя файл конфигурации nethasp.ini. Это позволит распределить нагрузку на все три ключа равномерно.
---
Чтобы клиенты корректно находили все три ключа и не использовали устаревший кэш с предыдущими адресами, настроим конфигурационные файлы на рабочих местах пользователей или терминальных серверах.
Отредактируем файл nethasp.ini (обычно он располагается в каталоге установки платформы C:\Program Files\1cv8\conf\). Настроим секцию протокола TCP/IP:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.207, 192.168.1.238, 192.168.1.223
NH_PORT_NUMBER = 475
NH_USE_BROADCAST = Disabled
Обратите внимание, что мы отключили широковещательную рассылку (NH_USE_BROADCAST = Disabled) и явно перечислили IP-адреса всех трех серверов лицензирования через запятую. Это ускорит запуск программы и исключит хаотичный поиск ключей в сети.
Для борьбы с проблемой двойного расхода лицензий из-за кэширования файлов 1cv8conn.pfl настроим автоматическое удаление этого файла при входе пользователя в систему. Напишем простой скрипт на языке командного интерпретатора (Batch) и добавим его в групповые политики (GPO) на вход в систему (Logon Script):
@echo off
set "pfl_path=%APPDATA%\1C\1Cv8"
if exist "%pfl_path%\1cv8conn.pfl" (
del /f /q "%pfl_path%\1cv8conn.pfl"
)
set "pfl_path_local=%LOCALAPPDATA%\1C\1Cv8"
if exist "%pfl_path_local%\1cv8conn.pfl" (
del /f /q "%pfl_path_local%\1cv8conn.pfl"
)
Регулярное удаление этого файла при старте сессии гарантирует, что 1С всегда будет опрашивать ключи строго по порядку, указанному в nethasp.ini, предотвращая избыточное выделение нескольких лицензий одному пользователю.
---
Если несколько менеджеров лицензий HASP LM работают в одном широковещательном сегменте сети без предварительной настройки, они начинают конфликтовать за NetBIOS-имена. По умолчанию каждый из них пытается зарегистрировать в сети имя HASP_LM. Проанализируем, как решить эту коллизию.
На каждом из серверов, где установлены физические USB-ключи защиты, найдем конфигурационный файл менеджера лицензий nhsrv.ini (он находится в папке установки драйверов Aladdin/Sentinel). Отредактируем секцию [NHS_SERVER], назначив каждому серверу уникальное имя:
На сервере 1 (192.168.1.207):
[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM_SERV207
На сервере 2 (192.168.1.238):
[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM_SERV238
На сервере 3 (192.168.1.223):
[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM_SERV223
После изменения параметров обязательно перезапустим службу менеджера лицензий HASP Loader на каждом сервере. Теперь в файле nethasp.ini на клиентских местах мы можем явно сопоставить адреса и имена серверов:
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.207, 192.168.1.238, 192.168.1.223
NH_SERVER_NAME = LM_SERV207, LM_SERV238, LM_SERV223
Эта тонкая настройка полностью устраняет сетевые коллизии, гарантируя стабильный доступ клиентов ко всему объёму лицензий.
---
Если лицензии все же оказались заблокированы в состоянии Timeout 0, перезагружать весь физический сервер бэкапов или почтовую службу не требуется. Достаточно сбросить состояние низкоуровневого драйвера защиты Hardlock/LDK.
Для этого выполним в командной строке от имени администратора на проблемном сервере лицензирования следующие команды:
net stop "Sentinel Local License Manager"
net stop "HASP Loader"
taskkill /f /im nhsrv.exe
net start "Sentinel Local License Manager"
net start "HASP Loader"
Если служба драйвера зависла намертво и не реагирует на стандартные команды остановки, используем утилиту командной строки haspdinst.exe, которая поставляется вместе с драйверами 1С. Выполним полную очистку и повторную инициализацию стека драйверов:
haspdinst.exe -purge
haspdinst.exe -i
Эта процедура принудительно выгружает зависшие дескрипторы USB-портов и очищает таблицу активных лицензий в памяти драйвера, мгновенно освобождая заблокированные лицензии без остановки операционной системы.
---
В современных версиях платформы 1С реализована альтернатива устаревшему софту от Aladdin — собственный программный компонент «1С:Предприятие – Менеджер Лицензий» (утилита rmlic). Рассмотрим преимущества перехода на данный инструмент:
Timeout 0).Для перехода на rmlic достаточно установить данный компонент из дистрибутива технологической платформы 1С на сервер, где физически установлены ключи, и переключить режим работы кластера в режим использования сервера лицензирования. Это кардинально повышает отказоустойчивость системы защиты и навсегда избавляет администраторов от ручной правки конфигурационных файлов .ini.