Что делать, если отвалился сетевой ключ HASP и 1С не видит лицензии

← На главную

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

Шаг 1. Первичная проверка физического подключения и служб

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

Переподключение: Извлечем ключ из USB-порта, подождем 5–10 секунд и вставим его обратно. Желательно использовать порты, расположенные непосредственно на материнской плате сервера, избегая передних панелей и USB-хабов.
Проверка службы: На сервере, где установлен ключ, должна быть запущена служба HASP Loader (или Sentinel LDK License Manager в новых версиях). Проверим ее состояние через консоль services.msc. Если служба запущена, попробуем ее перезапустить.
Анализ виртуализации: Если сервер является виртуальной машиной (ESXi, Hyper-V), проанализируем настройки проброса USB-устройств. Нередко после обновления гипервизора или миграции машины связь с USB-портом хоста разрывается.

Шаг 2. Локальная видимость ключа в диспетчере устройств

Выясним, видит ли операционная система само устройство. Откроем Диспетчер устройств и проанализируем раздел «Контроллеры USB» (или «USB-контроллеры»). Рассмотрим, какие записи должны там присутствовать при исправном ключе и корректных драйверах:

SafeNet Inc. HASP Key
SafeNet Inc. USB Key
SafeNet Inc. Sentinel Key

Если в диспетчере отображается «Неизвестное устройство» или устройство с восклицательным знаком, значит, проблема в драйверах. Проанализируем ситуацию: возможно, на сервере Windows Server 2008 R2 отсутствуют обновления для поддержки подписи драйверов SHA-2, что блокирует работу новых версий драйверов Sentinel.

Шаг 3. Проверка сетевой доступности (Порт 475)

Сетевой ключ HASP общается с клиентскими местами по порту 475. Выясним, открыт ли этот порт и отвечает ли менеджер лицензий. Для проверки TCP-составляющей используем telnet. В командной строке на клиентском ПК выполним:

telnet IP_СЕРВЕРА 475

Если после нажатия Enter открылось пустое черное окно — порт открыт. Если появилось сообщение об ошибке подключения — порт заблокирован брандмауэром сервера или антивирусом. Важный нюанс: HASP активно использует протокол UDP для широковещательных запросов. Проанализируем настройки сетевого экрана: правила должны разрешать трафик по порту 475 для обоих протоколов (TCP и UDP).

Шаг 4. Использование Sentinel Admin Control Center (ACC)

В современных драйверах (Sentinel Runtime) доступен мощный инструмент диагностики через веб-интерфейс. Попробуем зайти на страницу управления ключами на самом сервере, открыв в браузере адрес http://localhost:1947.

Разберем основные разделы ACC:

Sentinel Keys: Здесь отображаются все ключи, которые видит менеджер лицензий. Если список пуст, но ключ горит и виден в диспетчере устройств — это верный признак внутренней неисправности контроллера ключа.
Diagnostics: В этом разделе можно посмотреть лог ошибок и версию прошивки (Firmware). Рассмотрим версию прошивки: если она ниже 3.21, ключ может работать нестабильно с новыми версиями 1С.

Шаг 5. Конфигурация клиентского доступа через nethasp.ini

Если в сети несколько ключей (как в нашем примере — на 50 и 100 пользователей), 1С может «запутаться» при автоматическом поиске. Проанализируем файл nethasp.ini, который обычно находится в папке bin/conf установленной платформы. Чтобы заставить 1С искать конкретный ключ, отредактируем секцию [NH_TCPIP]:


[NH_COMMON]
NH_TCPIP = ENABLED

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.10  ; Укажите IP-адрес сервера с ключом на 50 пользователей
NH_TCPIP_METHOD = TCP
NH_USE_BROADCAST = DISABLED

Такая настройка исключает широковещательный опрос сети и направляет запрос напрямую на нужный сервер. Это позволяет выяснить, виновата ли сеть или сам ключ.

Шаг 6. Конфликт имен в nhsrv.ini

Рассмотрим ситуацию, когда два менеджера лицензий работают в одной сети. В файле настроек сервера nhsrv.ini (находится в папке с установленным HASP LM) есть параметр NHS_SERVERNAMES. Если оба сервера имеют одинаковое имя по умолчанию, 1С может видеть только один из них. Попробуем задать уникальные имена:


[NHS_SERVER]
NHS_SERVERNAMES = Server50UserKey

Шаг 7. Тестирование на изолированной машине (Окончательный вердикт)

Если все предыдущие шаги не дали результата, проведем решающий эксперимент. Выясним, жив ли «пациент», исключив влияние серверной ОС и сетевой инфраструктуры. Алгоритм тестирования:

Возьмем обычный рабочий компьютер, который гарантированно не находится в сети с другими ключами.
Установим на него платформу 1С с обязательной пометкой «Установить драйвер защиты».
Вставим исследуемый ключ. Убедимся, что драйверы установились успешно и устройство готово к работе.
Попробуем запустить локальную базу данных (не сетевую!).

Важный момент: Если 1С выдает «Лицензия не найдена», при этом драйверы стоят корректно, а ключ светится — значит, микросхема памяти или контроллер внутри USB-флешки вышли из строя. Тот факт, что светодиод горит, свидетельствует лишь о наличии питания (5V), но не о работоспособности логики устройства. В этом случае ключ подлежит замене через обслуживающего партнера 1С.

Шаг 8. Полная очистка системы (Утилита Purge)

Иногда драйверы «криво» встают после обновлений Windows. Попробуем выполнить полную очистку. Для этого скачаем официальную утилиту haspdinst.exe и запустим ее из командной строки с ключом очистки:

haspdinst.exe -purge

После завершения процесса перезагрузим сервер и установим последнюю версию драйвера Sentinel LDK Runtime. Рассмотрим этот метод как «последнюю надежду» перед признанием ключа неисправным.

Резюме: Мы проанализировали путь диагностики от физического контакта до низкоуровневой проверки. Чаще всего причина кроется либо в блокировке порта 475, либо в «уставшем» железе самого HASP-ключа, которое требует физической замены.