Что делать, если сетевой ключ HASP ORGL8 перестал раздавать лицензии по сети, но работает локально?

В практике администрирования инфраструктуры 1С системные администраторы иногда сталкиваются с крайне загадочным поведением аппаратных ключей защиты. Представьте ситуацию: сетевой красный многопользовательский USB-ключ (например, на 5 или 10 пользователей серии HASP HL Net) внезапно перестает раздавать лицензии компьютерам в локальной сети. При этом на сервере, куда физически подключен этот ключ, платформа 1С запускается без каких-либо нареканий, а светодиод на самом устройстве горит ровным красным цветом. Однако ни одна рабочая станция в сети лицензию получить не может, а утилита мониторинга Aladdin Monitor отображает пустое окно, будто менеджера лицензий вовсе не существует.

В этой статье мы подробно проанализируем причины возникновения этой аппаратной «аномалии», разберем эффективные методы пошаговой диагностики и выясним, как правильно решить проблему с минимальными простоями для бизнеса.

Выясняем причины неисправности: почему сетевой ключ «превращается» в локальный?

Для понимания природы этой неисправности обратимся к внутреннему устройству ключей Sentinel HASP. В сетевых моделях информация о сетевом статусе устройства, лимитах подключений и уникальных идентификаторах хранится в специальной защищенной области энергонезависимой памяти — EEPROM. За сетевые функции отвечает так называемый сетевой флаг (Network Bit).

Специалисты выделяют три ключевые технические причины, по которым сетевой ключ может «деградировать» до локального:

1. Повреждение ячеек памяти EEPROM. Это наиболее частая причина сбоя. В результате скачков напряжения в USB-порту материнской платы, накопления статического электричества или естественного старения полупроводников сектор памяти, отвечающий за сетевые свойства ключа, повреждается. При запуске службы HASP License Manager драйвер не может считать сетевую сигнатуру и начинает определять ключ как локальный (серии HASP HL Pro). При этом базовая сигнатура защиты остается доступной, поэтому локально на сервере 1С продолжает успешно запускаться.
2. Сбой микрокода контроллера (Firmware). Каждый USB-ключ оснащен встроенным микропроцессором. У старых моделей ключей (выпущенных в середине 2000-х годов) версия прошивки может быть ниже 3.21. При их эксплуатации в современных операционных системах с новейшими драйверами Sentinel LDK микрокод может войти в ступор, заблокировав сетевой стек ключа.
3. Конфликт сетевых протоколов и драйверов. Современная служба Sentinel Runtime использует для управления веб-интерфейс Admin Control Center (ACC), работающий по порту 1947 (TCP/UDP). Старая утилита Aladdin Monitor работает исключительно со старой службой HASP Loader через порт 475 (UDP). Если на сервере произошел сбой маршрутизации или службы лицензирования перехватили управление портами друг у друга, ключ может оказаться заблокирован для сетевого вещания.

Пошаговый алгоритм диагностики ключа

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

Шаг 1. Проверка через веб-интерфейс Sentinel Admin Control Center

Современные версии драйверов Sentinel предоставляют мощный инструмент диагностики через браузер. Перейдем по адресу:

http://localhost:1947

После открытия страницы выполним следующие действия:

1. В левом боковом меню выберем раздел Sentinel Keys.
2. Найдем в таблице наш проблемный ключ (серии ORGL8).
3. Внимательно изучим колонку Key Type. Если вместо ожидаемого значения HASP HL Net там написано просто HASP HL Pro или HASP HL, это аппаратный приговор. Ключ окончательно потерял свои сетевые свойства на физическом уровне.

Шаг 2. Использование утилиты Aladdin Diagnostics

Для более глубокого анализа воспользуемся специализированной сервисной утилитой hspdiet.exe (Aladdin Diagnostics). Запустим утилиту и проанализируем параметр Access Mode. Если для подключенного сетевого ключа утилита возвращает статус Local, это подтверждает повреждение внутренней логики микроконтроллера.

Шаг 3. Анализ логов менеджера лицензий

Если на сервере установлена служба HASP License Manager, обратимся к файлу ее логов. Обычно он называется nhsrv.log и располагается в каталоге установки службы. Откроем его текстовым редактором и найдем записи об инициализации ключей:

Server IP protocol: active. No HASP keys found.
Error 129: HASP key not found or network features disabled.

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

Шаг 4. Проверка правила "один ключ одной серии"

Необходимо учитывать важную особенность защиты 1С: на одном компьютере (физическом сервере или виртуальной машине) может одновременно полноценно работать только один сетевой ключ одной серии (в нашем случае — серии ORGL8). Если на сервере установлены два ключа (например, на 5 и на 10 лицензий), служба лицензирования инициализирует только один из них (обычно тот, который определился первым), а второй будет полностью проигнорирован.

Для чистоты эксперимента выполним следующие действия:

1. Полностью остановим службу HASP License Manager через консоль services.msc.
2. Извлечем из USB-портов абсолютно все аппаратные ключи защиты.
3. Перезагрузим сервер для очистки кэша драйверов.
4. Вставим только один тестируемый ключ на 5 лицензий в заведомо исправный порт USB (желательно USB 2.0 непосредственно на задней панели материнской платы, минуя разветвители и хабы).
5. Запустим службу HASP License Manager и проверим статус раздачи лицензий.

Для тонкой настройки вещания лицензий по сети мы можем явно указать параметры в конфигурационном файле менеджера лицензий nhsrv.ini, который располагается в каталоге со службой. Отредактируем параметры, чтобы принудительно активировать нужные протоколы:

[NHS_SERVER]
NHS_USER_IP = 192.168.1.0/24 ; Ограничиваем вещание нашей подсетью
NHS_USE_UDP = Enabled         ; Включаем протокол UDP
NHS_USE_TCP = Enabled         ; Включаем протокол TCP

После сохранения изменений обязательно перезапустим службу менеджера лицензий.

Что делать, если ключ неисправен? Процедура замены

Если проведенная диагностика подтвердила худшие опасения и ключ действительно перестал распознаваться как сетевой на аппаратном уровне, восстановить его работоспособность программными средствами невозможно. Требуется физическая замена устройства.

Рассмотрим детальный регламент замены неисправного оборудования через партнеров фирмы 1С (Франчайзи):

1. Оценка физического состояния. Внимательно осмотрите пластиковый корпус USB-ключа и металлический коннектор. Фирма 1С производит замену неисправных ключей бесплатно, если на них нет следов механических повреждений (трещин, следов оплавления, согнутых контактов, вскрытия корпуса). Если же ключ имеет явные повреждения, замена будет произведена с оплатой стоимости нового электронного носителя (пошлины).
2. Подготовка пакета документов. Свяжитесь с вашим обслуживающим партнером 1С. Вам потребуется предоставить:
   • Регистрационную карточку программного продукта 1С, к которому привязан ключ;
   • Заявление на замену аппаратного ключа с описанием выявленной неисправности (укажите, что ключ определяется как локальный);
   • Сам неисправный физический ключ.
3. Временное решение на период замены. Экспертиза и доставка нового ключа могут занять от нескольких дней до двух недель. Чтобы ваше предприятие не простаивало, попросите у франчайзи временные программные лицензии (пин-коды) или подменный аппаратный ключ из их собственного резервного фонда. 1С охотно идет навстречу пользователям в таких ситуациях.

Таким образом, мы детально разобрали редкую, но крайне неприятную аномалию сетевых ключей HASP. Своевременное использование современных инструментов диагностики, таких как веб-панель Sentinel ACC, позволяет администратору быстро локализовать неисправность, отбросить ложные предположения о сетевых сбоях и оперативно запустить процедуру замены оборудования.