Почему новая платформа 1С не видит сетевой HASP-ключ и как это исправить?

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

Анализ причин: почему новая версия ведет себя иначе?

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

1. Обновленные механизмы самозащиты: Новые версии платформы умеют определять наличие остатков эмуляторов («ломалок») в системе и блокировать работу с настоящим аппаратным ключом при их обнаружении.
2. Разрядность платформы: Если вы перешли с 32-битной (x86) на 64-битную (x64) платформу, требования к поиску ключа и конфигурации сетевых интерфейсов могут измениться.
3. Версия драйвера HASP: Старые драйверы, работавшие с версией 8.3.10, могут быть несовместимы с логикой работы новых версий платформы или новыми обновлениями ОС Windows.

Шаг 1: Проверка работы менеджера лицензий HASP LM

Выясним, запущен ли на сервере, где физически установлен ключ, менеджер лицензий (HASP License Manager). Без этой службы сетевые клиенты не смогут получить лицензию.

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

1. Откроем диспетчер задач и перейдем на вкладку «Службы».
2. Найдем службу с именем hasplms (Sentinel LDK License Manager).
3. Убедимся, что её статус — «Выполняется».

Если в списке программ нет явных упоминаний HASP LM, но в процессах висит hasplms.exe, значит, менеджер установлен как системная служба. Это правильный режим работы.

Шаг 2: Настройка файла nethasp.ini на клиентских местах

Часто автоматический поиск ключа в локальной сети (через широковещательные запросы) работает нестабильно. Разберем, как принудительно указать программе адрес сервера с ключом. Для этого используется файл nethasp.ini.

Проанализируем структуру файла и внесем необходимые правки. Обычно файл находится по пути C:\Program Files\1cv8\conf\ или в папке bin конкретной версии платформы. Нам необходимо отредактировать секцию [NH_TCPIP]:

[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100  ;; Укажите здесь IP-адрес вашего сервера с ключом
NH_USE_BROADCAST = Disabled      ;; Отключаем широковещательный опрос
NH_TCPIP_METHOD = UDP            ;; Указываем протокол работы

Важно: Убедитесь, что галочка «Использовать аппаратный ключ защиты» в настройках запуска базы установлена. Если вы используете 64-битную платформу, проверьте, что файл nethasp.ini находится в правильном каталоге Program Files, а не Program Files (x86).

Шаг 3: Диагностика влияния «эмуляторов» и старых патчей

Рассмотрим ситуацию, описанную в сообщениях форума: старая платформа работает, а новая — нет. Часто это является признаком того, что ранее в системе применялись обходы защиты (патчи). Новая платформа 1С видит изменения в библиотеках (например, в backbas.dll) и отказывается работать.

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

1. Удалим все старые версии платформы через «Панель управления».
2. Проверим систему на наличие файлов-эмуляторов, таких как VUSBBus или MultiKey в диспетчере устройств.
3. Попробуем вынуть ключ из сервера. Если старая версия платформы продолжает запускаться без физического ключа, значит, в системе определенно стоит эмулятор.

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

Шаг 4: Настройка сетевого экрана (Брандмауэра)

Выясним причину возможной блокировки трафика. Для работы сетевого ключа используется UDP-порт 475. При установке новой платформы правила безопасности могут измениться.

Посмотрим, как открыть порт:

1. Перейдем в настройки Брандмауэра Windows на сервере.
2. Создадим правило для входящих подключений для порта UDP 475.
3. Аналогичное правило рекомендуется создать для исходящих подключений на клиентских машинах.

Шаг 5: Проверка маркировки ключа

Не забудем проверить и сам аппаратный ключ. На корпусе ключа должна быть маркировка. Рассмотрим основные типы:

• ORGL8: Клиентский ключ (на 1, 5, 10, 20, 50, 100 пользователей).
• ENSR8: Серверный 32-разрядный ключ.
• EN8SA: Серверный 64-разрядный ключ.

Если у вас 64-битный сервер 1С, ему обязательно нужен либо программный ключ, либо аппаратный ключ соответствующей серии (например, EN8SA). Помните, что 64-битный сервер не видит клиентские ключи, если они воткнуты в него же, — он требует их получения через менеджер лицензий HASP LM по сети, даже если всё находится на одной физической машине.

Резюме решения

Если после обновления платформы 1С не видит ключ, первым делом проверьте, не использовались ли ранее «ломаные» версии. Как показывает практика, именно это становится основной причиной проблем в 90% случаев. После полной очистки системы от эмуляторов, установки свежего драйвера Sentinel LDK и настройки nethasp.ini с прямым указанием IP-адреса, работа сетевого ключа, как правило, восстанавливается.