При совместной работе с серверными и файловыми (локальными) информационными базами системные администраторы часто сталкиваются с ситуацией, когда пользователи успешно подключаются к серверной базе 1С:Предприятия, но при попытке открыть локальную базу получают сообщение о нехватке лицензий. При этом утилита HASP Monitor показывает, что из доступного пула (например, 30 лицензий) занято всего несколько штук. Разберем детально, почему так происходит, как устроена сетевая раздача аппаратных ключей и как устранить данную проблему.
Анализ причин: как сервер 1С и локальные клиенты делят сетевой ключ
Для понимания корня проблемы проанализируем разницу в механизмах получения лицензий для клиент-серверного и файлового вариантов работы:
Раздача лицензий сервером 1С: Если в свойствах информационной базы в консоли администрирования кластера включен параметр «Разрешить выдачу лицензий сервером 1С:Предприятия» со значением Да, сервер приложений берет лицензии с сетевого аппаратного ключа HASP на себя. При подключении каждого клиентского сеанса рабочий процесс кластера (rphost) резервирует лицензию из общего пула. В утилите HASP Monitor такие лицензии могут отображаться как одно общее подключение от имени сервера либо не отображаться вовсе. В результате физический пул ключа фактически занят серверными сеансами, хотя монитор показывает малое число прямых клиентов.
Запуск локальных (файловых) баз: Сервер приложений 1С физически не может выдать лицензию клиенту, который открывает файловую базу по сети или локально с диска. В этом режиме клиентская платформа обязана сама обнаружить ключ защиты через службу HASP License Manager (HASP Loader). Если весь пул ключа уже занят сервером 1С, клиент получает отказ.
Зависание неактивных сессий в HASP License Manager: При аварийном завершении работы клиентов сетевые сокеты службы раздачи лицензий могут оставаться открытыми до истечения сетевых таймаутов, удерживая доступные слоты.
Способ 1. Перезапуск службы HASP Loader и сброс зависших сессий
Если пользователи аварийно выходили из программы или в службе накопились некорректные дескрипторы, разберем оперативное решение проблемы:
Откроем оснастку управления службами операционной системы (services.msc) на сервере, где физически установлен аппаратный ключ.
Найдем службу HASP Loader (или Sentinel HASP License Manager).
Выполним перезапуск службы. Все зависшие сетевые подключения будут сброшены, и служба заново считает доступное число свободных лицензий с USB-ключа.
Попросим пользователя повторно запустить локальную базу 1С.
Способ 2. Отключение раздачи клиентских лицензий сервером 1С
Рассмотрим сценарий, когда аппаратный ключ на 30 пользователей должен одинаково обслуживать как серверные, так и локальные базы. Чтобы избежать монопольного захвата или некорректного распределения лицензий сервером 1С, переведем раздачу на сторону клиентов:
Перейдем в ветку нужной информационной базы и откроем ее свойства.
Найдем параметр «Разрешить выдачу лицензий сервером 1С:Предприятия» и переведем его в значение Нет.
Нажмем «Применить» и сохраним настройки.
Теперь при подключении к серверной базе каждый клиентский компьютер будет самостоятельно запрашивать лицензию у сетевого ключа HASP через службу HASP License Manager. Это обеспечит единый прозрачный пул как для серверных, так и для файловых баз, а все подключения будут корректно видны в HASP Monitor.
Способ 3. Точная настройка клиента через файл nethasp.ini
По умолчанию платформа 1С ищет сетевой ключ с помощью широковещательных пакетов (Broadcast) по протоколам UDP/IPX/NetBIOS. В сложных сетях или при наличии нескольких сетевых интерфейсов широковещательные запросы блокируются маршрутизаторами или брандмауэром. Настроим прямое обращение клиентов к серверу с ключом:
Перейдем в каталог настроек платформы на рабочем месте пользователя: для 64-битной версии — C:\Program Files\1cv8\conf\, для 32-битной — C:\Program Files (x86)\1cv8\conf\.
Откроем или создадим файл конфигурации nethasp.ini.
Зададим параметры прямого подключения по протоколу TCP/IP, отключив лишние протоколы и широковещательный поиск:
Где вместо 192.168.1.100 укажем точный статический IP-адрес компьютера, в который установлен USB-ключ защиты. Это гарантирует мгновенное нахождение ключа при запуске локальных баз в обход сетевых ограничений.
Способ 4. Проверка портов брандмауэра и драйверов защиты
Разберем дополнительные параметры сетевого взаимодействия:
Убедимся, что на сервере с ключом в брандмауэре открыт сетевой порт 475 для протоколов TCP и UDP.
Проверим актуальность установленного драйвера Sentinel HASP/LDK. Устаревшие версии драйверов и службы License Manager могут приводить к сбоям подсчета сессий при одновременных обращениях. Обновим драйвер защиты до актуальной версии с официального сайта производителя.