Многие администраторы 1С сталкиваются с ситуацией, когда при наличии физического USB-ключа защиты (например, на 20 пользователей) программа внезапно начинает сообщать об ошибке: Не обнаружено свободной лицензии! При этом в логах сервера мы видим долгий поиск лицензий по локальной сети и множество ошибок соединения с менеджером лицензий. Давайте подробно разберем, проанализируем ситуацию и выясним причину такого поведения платформы.
В первую очередь рассмотрим, за что отвечают различные цвета аппаратных ключей защиты. В нашей ситуации фигурируют красный и зеленый ключи, установленные в один сервер.
Таким образом, если сервер перестал пускать пользователей, надеяться на то, что «зеленый ключ раздаст лицензии», ошибочно.
Рассмотрим подробнее один из главных вопросов: как 70 человек могли успешно работать, если установлен только один красный ключ на 20 лицензий? Секрет кроется в механике выдачи лицензий.
Если клиентский компьютер получает лицензию по сети от менеджера лицензий HASP LM, то лицензия выдается на физический ПК (или терминальную сессию). В этом случае один сотрудник может запустить на своем компьютере хоть пять разных информационных баз — это израсходует всего одну лицензию из ключа.
Если же лицензию раздает сам сервер 1С:Предприятия (что обязательно происходит при использовании современных программных пин-кодов), то лицензии выдаются на каждый сеанс. Запустил сотрудник три базы — сервер забрал три лицензии. Это часто приводит к резкой нехватке свободных подключений после обновления оборудования или перехода на программные лицензии.
Проанализируем историю поиска ключей в логе 1С. Если мы видим строки вида:
Информационная база:
Локальный HASP4 ORGL8 10
Сетевой HASP4 ORGL8 20
Сетевой HASP4 ORGL8 50
Это говорит о том, что платформа «помнит» ключи на 10, 20 и 50 мест. Если физически в наличии только один ключ на 20 мест, а ранее в базе работало 70 человек, мы имеем дело с классическим симптомом работы эмулятора аппаратных ключей (например, vusbbus или MultiKey).
Эмуляторы создают в системе виртуальные USB-устройства, которые менеджер лицензий воспринимает как настоящие. Даже после переустановки сервера следы эмулятора могут остаться в реестре Windows, вызывая конфликты с легальными ключами. Для решения этой проблемы необходимо вручную удалить скрытые устройства в Диспетчере задач и вычистить ветки реестра, связанные с виртуальными HASP-устройствами.
Если вы решили докупить аппаратные ключи, важно помнить критическое ограничение: в один физический или виртуальный компьютер нельзя устанавливать два сетевых ключа одной серии (например, два красных ключа ORGL8). Служба HASP LM захватит только один из них, а второй будет игнорироваться. Для использования нескольких одинаковых сетевых ключей их нужно физически разнести по разным компьютерам локальной сети и на каждом поднять свой экземпляр менеджера лицензий.
В логах часто можно встретить ошибки сети (Net Status=0, System Error=0, Warning=129). По умолчанию 1С ищет лицензии с помощью широковещательных запросов (Broadcast) по всей сети, перебирая все возможные серии ключей. Это сильно замедляет запуск программы.
Разберем по шагам, как оптимизировать этот процесс с помощью файла nethasp.ini на рабочих местах пользователей:
nethasp.ini (обычно лежит в папке conf установленной платформы).NH_USE_BROADCAST и установите его значение в Disabled.NH_SERVER_ADDR. Например: NH_SERVER_ADDR = 192.168.1.100.По умолчанию 1С ищет лицензии по цепочке: локальный ключ -> локальная программная -> сеть (HASP LM) -> сервер 1С. Чтобы сэкономить лицензии и заставить пользователей получать их строго на ПК через HASP LM, мы можем запретить серверу раздавать клиентские лицензии.
Для этого откройте консоль администрирования кластера серверов 1С, перейдите в свойства информационной базы и установите параметр Разрешить выдачу лицензий сервером 1С:Предприятия в значение Нет. После этого сервер перестанет тратить лицензии на каждый сеанс, и клиенты будут напрямую связываться с менеджером аппаратных ключей.