Как устранить дублирование лицензий 1С при использовании нескольких сетевых ключей HASP?

← На главную

При работе в сети с несколькими аппаратными ключами защиты HASP часто возникает неприятная ситуация: одна и та же рабочая станция или один и тот же пользователь «захватывает» лицензии сразу с нескольких ключей. В мониторе менеджера лицензий (AKSMon) это выглядит как дублирование сессий. В результате лицензий на всех сотрудников не хватает, хотя их общее количество превышает число активных пользователей. Рассмотрим причины этого поведения и разберем пошагово, как правильно настроить систему для исключения подобных конфликтов.

Почему возникают дубли лицензий?

Основная причина кроется в механизме поиска ключа платформой 1С. По умолчанию клиентское приложение использует широковещательные запросы (Broadcast) для поиска доступных менеджеров лицензий в локальной сети. Разберем основные факторы, провоцирующие проблему:

Широковещательный поиск: Когда клиент отправляет запрос в сеть, на него могут одновременно ответить несколько менеджеров лицензий. Платформа может «занять» лицензию на одном сервере, но при малейшем сбое сети или задержке отклика инициировать повторный поиск, который приведет к захвату лицензии уже со второго ключа.
Несколько сетевых интерфейсов: Если на сервере с менеджером лицензий или на клиентской машине активно более одного сетевого адаптера (например, локальная сеть и VPN), запросы могут дублироваться или маршрутизироваться некорректно.
Особенности платформы 8.2: Версия 8.2.19 и аналогичные не умеют суммировать лицензии с разных ключей одной серии (например, два ключа ORGL8 по 10 лицензий). Платформа видит их как два разных ресурса, что усложняет логику распределения.
Таймауты сессий: Если сессия «зависла» из-за сетевого лага, менеджер лицензий не освобождает ее мгновенно. При перезапуске программы пользователь получает новую лицензию, в то время как старая все еще числится занятой.

Решение 1: Адресная настройка через nnhasp.ini

Самый эффективный способ победить дублирование — это запретить платформе использовать широковещательные запросы и жестко указать, к какому серверу обращаться. Для этого мы будем редактировать файл nnhasp.ini. Этот файл обычно располагается в папке bin\conf или bin установленной платформы 1С.

Проанализируем необходимые изменения в секции [NH_TCPIP]:


[NH_TCPIP]
; Отключаем широковещательный поиск
NH_USE_BROADCAST = Disabled

; Указываем конкретные IP-адреса серверов, где установлены ключи
NH_SERVER_ADDR = 192.168.1.10, 192.168.1.11

; Оставляем только протокол TCP/IP, отключая лишние
NH_TCPIP = Enabled

В параметре NH_SERVER_ADDR следует перечислить IP-адреса всех ваших серверов с менеджерами лицензий через запятую. Это заставит 1С опрашивать серверы последовательно и только по указанным адресам, исключая случайный захват «чужих» лицензий из эфира.

Решение 2: Оптимизация работы менеджера лицензий (nhsrv.ini)

Помимо настройки клиента, необходимо обратить внимание на настройки самого менеджера лицензий на стороне сервера. Файл конфигурации nhsrv.ini находится в папке с установленным HASP License Manager.

Рассмотрим параметры, которые помогут стабилизировать работу:

NHS_IP_LIMIT: Позволяет ограничить список IP-адресов (интерфейсов), на которых менеджер будет слушать запросы. Это критично, если на сервере несколько сетевых карт.
NHS_USER_LIMIT: Можно явно ограничить максимальное количество лицензий, выдаваемых данным менеджером, чтобы он не пытался «обработать» больше запросов, чем физически позволяет ключ.
Настройка таймаутов: Сокращение времени ожидания неактивных сессий позволит быстрее освобождать лицензии, которые «зависли» после некорректного завершения работы программы.

Решение 3: Разделение пользователей по группам

Если в вашей организации два ключа (например, на 20 и 50 пользователей), мы рекомендуем физически распределить нагрузку. Для одной группы пользователей в файле nnhasp.ini укажите в качестве приоритетного NH_SERVER_ADDR адрес первого сервера, а для другой — второго.

Пример для группы А: NH_SERVER_ADDR = 192.168.1.10

Пример для группы Б: NH_SERVER_ADDR = 192.168.1.11

Это гарантирует, что пользователи будут в первую очередь занимать лицензии на «своем» ключе, и только при его заполнении (если указан второй адрес через запятую) пойдут на другой.

Дополнительные рекомендации для платформы 8.2 и 8.3

Выясним еще несколько важных нюансов, которые могут влиять на результат:

Отключение лишних протоколов: В файле nnhasp.ini обязательно установите NH_IPX = Disabled и NH_NETBIOS = Disabled. Эти протоколы давно устарели и часто становятся причиной задержек и конфликтов при поиске ключа.
Кэш лицензий: Иногда платформа сохраняет данные о последнем успешном подключении в локальном кэше пользователя (папка AppData\Local\1C). Если настройки изменены, а проблема сохраняется, попробуйте очистить временные файлы 1С.
Серверная выдача лицензий: Если вы используете клиент-серверный вариант работы, проверьте параметр «Разрешить выдачу лицензий сервером 1С:Предприятия» в свойствах информационной базы. Если этот флаг включен, лицензии выдает процесс rphost, и логика работы с аппаратными ключами может отличаться от локального запуска. В случае проблем с дублями иногда помогает перевод всех клиентов на получение лицензий строго через сервер 1С, либо наоборот — полное отключение этой функции и использование только nnhasp.ini на клиентах.

Важный момент: Если вы столкнулись с тем, что на одном сервере установлено два ключа одной серии (например, два сетевых ORGL8), помните, что менеджер лицензий HASP License Manager увидит только один из них. Для использования обоих ключей их необходимо разнести на разные физические или виртуальные серверы.