Как настроить работу 1С с несколькими ключами защиты HASP и правильно сконфигурировать nethasp.ini?

← На главную

При масштабировании бизнеса системные администраторы часто сталкиваются с ситуацией, когда на предприятии скапливается несколько физических USB-ключей защиты HASP (например, два ключа по 50 лицензий и один на 100 лицензий). Естественное желание любого администратора — объединить их ресурсы в общий пул, чтобы пользователи могли беспрепятственно получать свободные лицензии с любого доступного сервера. Однако при стандартной настройке система часто выдает ошибку: «Не найден ключ защиты программы».

В этой статье мы подробно разберем по шагам, почему возникает эта проблема, как правильно настроить конфигурационные файлы nethasp.ini и nhsrv.ini, проанализируем критические ограничения самой платформы «1С:Предприятие» и рассмотрим три рабочих сценария для обхода этих ограничений.

Критическое ограничение платформы «1С:Предприятие» (By Design)

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

Платформа 1С не умеет суммировать (пулить) лицензии с нескольких сетевых аппаратных ключей одной серии на одном или разных серверах.

Все многопользовательские ключи HASP (номиналом 5, 10, 20, 50, 100 и 300 рабочих мест) относятся к одной и той же серии — ORGL8. Когда клиентское приложение запускается, оно выполняет поиск доступных менеджеров лицензий (HASP LM) в локальной сети. Если в сети развернуто три сервера с ключами серии ORGL8, платформа выберет только один менеджер лицензий (обычно первый ответивший по сети) и привяжется к нему.

Если на выбранном сервере закончатся свободные лицензии, платформа «1С:Предприятие» не будет опрашивать оставшиеся серверы. Пользователь сразу же получит сообщение об ошибке, даже если на соседнем сервере лицензий свободны все 100 рабочих мест. Исключение составляют ключи разных серий: например, один ключ серии ORGL8 (до 100 пользователей), один ключ серии ORG8A (на 300 пользователей) и один серии ORG8B (на 500 пользователей). Такие ключи опрашиваются последовательно, но в нашем случае все три ключа имеют одинаковую серию ORGL8.

Выяснив первопричину проблемы, рассмотрим, как минимизировать конфликты сетевых запросов и заставить клиентские компьютеры корректно видеть серверы лицензирования.

Решение проблемы: правильная настройка конфигурационных файлов

Когда мы прописываем несколько серверов лицензий в файле конфигурации, стандартный механизм широковещательного поиска (Broadcast) начинает мешать стабильной работе. Он отправляет пакеты по всей сети, вызывая хаотичный выбор менеджера лицензий. Для исправления этой ситуации нам потребуется жестко перевести систему на адресную работу по протоколу TCP/IP.

Разберем по шагам процесс настройки конфигурационных файлов на стороне клиента и сервера.

Шаг 1. Настройка nethasp.ini на рабочем месте пользователя

Файл nethasp.ini обычно располагается по пути C:\Program Files\1cv8\conf\ или в папке конкретной версии платформы (например, C:\Program Files\1cv8\8.3.XX.XXXX\bin\conf\). Нам необходимо отредактировать секцию [NH_TCPIP].

Откроем файл любым текстовым редактором от имени Администратора и приведем его к следующему виду:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 15.95.0.238, 15.95.0.239, 15.95.0.240
NH_USE_BROADCAST = Disabled
NH_TCPIP_METHOD = UDP

Проанализируем ключевые параметры, которые мы настроили:

NH_TCPIP = Enabled — принудительно разрешает использование протокола TCP/IP для поиска ключей защиты.
NH_USE_BROADCAST = Disabled — важнейший параметр. Мы полностью отключаем широковещательный поиск (Broadcast) в локальной сети. Это убирает хаос при поиске менеджеров лицензий и ускоряет запуск 1С.
NH_SERVER_ADDR = 15.95.0.238, 15.95.0.239, 15.95.0.240 — здесь мы перечисляем конкретные статические IP-адреса всех трех серверов, на которых физически установлены USB-ключи и запущены службы HASP License Manager.
NH_TCPIP_METHOD = UDP — платформа 1С всегда обменивается данными с менеджером лицензий по протоколу UDP через порт 475. Убедитесь, что данный порт открыт в брандмауэрах на серверах и клиентах.

Шаг 2. Настройка nhsrv.ini на стороне серверов лицензирования

На каждом из трех серверов, где установлены физические USB-ключи, работает служба HASP License Manager. Ее настройки хранятся в файле nhsrv.ini (обычно находится в папке установки менеджера лицензий, например, C:\Program Files (x86)\Aladdin\HASP LM\).

Чтобы серверы не конфликтовали и корректно идентифицировали себя в сети, нам нужно присвоить каждому менеджеру лицензий уникальное имя. Разберем пример настройки для сервера с IP-адресом 15.95.0.238:


[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM03

Для второго сервера (например, 15.95.0.239) пропишите:


[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM01

Для третьего сервера (например, 15.95.0.240):


[NHS_SERVER]
NHS_USERLIST = 250
NHS_SERVERNAMES = LM02

Важное примечание: Имена серверов в параметре NHS_SERVERNAMES не должны совпадать с именами компьютеров в сети Windows. Это внутренние имена менеджеров лицензий (HASP LM), длина которых не должна превышать 7 символов (использовать можно только латиницу и цифры).

После изменения файлов nhsrv.ini обязательно перезапустите службу HASP License Manager (HLServer) на каждом сервере через оснастку services.msc.

Архитектурные варианты решения задачи «перелива» лицензий

Поскольку прямое суммирование однотипных ключей невозможно из-за ограничений самой платформы 1С, рассмотрим три гарантированных архитектурных подхода, которые позволяют эффективно распределить нагрузку.

Вариант А. Административное деление пользователей на группы через GPO

Это самый популярный практический метод, не требующий дополнительных финансовых затрат. Разберем схему его реализации:

Всех пользователей организации делят на три условные группы пропорционально номиналу ключей. Например: 50 бухгалтеров, 50 менеджеров по продажам и 100 сотрудников склада.
В Active Directory создаются три групповые политики (GPO).
Для каждой группы на компьютеры копируется свой индивидуальный файл nethasp.ini:
- У группы бухгалтеров в файле прописан только: NH_SERVER_ADDR = 15.95.0.238 (сервер с ключом на 50 лицензий).
- У группы продаж прописан только: NH_SERVER_ADDR = 15.95.0.239 (второй сервер на 50 лицензий).
- У сотрудников склада прописан: NH_SERVER_ADDR = 15.95.0.240 (сервер на 100 лицензий).

При таком подходе пользователи жестко закрепляются за конкретными серверами, лицензии не расходуются хаотично, а проблема переполнения пулов сводится к минимуму.

Вариант Б. Переход на программные лицензии 1С

Если администрирование аппаратных USB-ключей становится слишком трудоемким, рассмотрим переход на программную защиту:

Вы можете официально обменять имеющиеся физические USB-ключи у любого партнера фирмы «1С» на программные лицензии (пин-коды) по процедуре апгрейда.
Программные лицензии, в отличие от HASP, великолепно суммируются.
Вы можете активировать на одном сервере 1С комплекты лицензий номиналом 50, 50 и 100 рабочих мест. Сервер 1С объединит их в единый пул на 200 лицензий и будет централизованно раздавать их пользователям без конфликтов и сетевых сбоев.

Вариант В. Апгрейд ключей защиты на один ключ большего номинала

Еще один надежный способ избавиться от необходимости администрирования нескольких HASP LM — это физическая замена трех ключей (50 + 50 + 100) на один сетевой ключ большего номинала:

Через процедуру апгрейда в фирме «1С» сдаются три старых ключа серии ORGL8.
Взамен приобретается один сетевой ключ серии ORG8A на 300 пользователей.
В результате в сети разворачивается всего один менеджер лицензий (HASP LM), исчезает необходимость сложной настройки файлов nethasp.ini на рабочих станциях, а все 200 (или 300) лицензий становятся доступны в общем пуле для каждого сотрудника.

Таким образом, правильная настройка параметров NH_USE_BROADCAST = Disabled и NH_SERVER_ADDR решает проблему видимости ключей, а грамотное распределение пользователей или своевременный апгрейд защиты полностью закрывают вопрос нехватки лицензий на предприятии.