Что делать, если сетевой ключ 1С (красный) работает как локальный?

Системный администратор IT и автоматизация бизнеса
← На главную

Рассмотрим распространенную, но нетривиальную ситуацию: у вас есть красный многопользовательский аппаратный ключ защиты HASP для 1С v8, который должен обеспечивать работу нескольких пользователей, но по факту определяется системой как локальный и предоставляет лицензию только на одну машину. Часто такая проблема встречается у ключей со старой версией микропрошивки, например, 2.17. В окне "О программе" 1С такой ключ может отображаться как локальный hasp4 orgl8, несмотря на то, что он сетевой.

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

Шаг 1. Вопрос о прошивке: стоит ли обновлять?

Первая мысль, которая может возникнуть, — обновить "кривую" микропрошивку ключа. Делать это самостоятельно категорически не рекомендуется.

Прошивка 2.17 действительно считается устаревшей и может вызывать проблемы, особенно при работе в среде Linux. Однако попытка обновить ее вручную с помощью неофициальных утилит с вероятностью 99% приведет к необратимому выходу ключа из строя. Вы просто получите "кирпич".

Вывод: идею самостоятельной перепрошивки следует отбросить сразу. Единственный легальный и безопасный способ — официальная замена ключа через партнера "1С".

Шаг 2. Правильная диагностика: используйте верные инструменты

Это самый важный этап, на котором совершается большинство ошибок. Современные системные администраторы привыкли использовать для диагностики ключей утилиту Sentinel Admin Control Center, которая доступна в браузере по адресу http://localhost:1947. Однако эта утилита предназначена для более новых ключей Sentinel LDK.

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

Для диагностики старых ключей необходимо использовать "родную" утилиту — Aladdin HASP Monitor (также известна как AKS Monitor).

  1. Найдите, скачайте и запустите утилиту Aladdin Monitor на любом компьютере в той же сети, что и сервер с ключом.
  2. Утилита просканирует сеть и покажет все доступные HASP-ключи.
  3. В результатах вы должны увидеть свой ключ, его серию (например, ORGL8), общее количество лицензий и число занятых лицензий.

Если в Aladdin Monitor вы видите, что ключ корректно раздает лицензии, значит, аппаратно он исправен, и проблема кроется в настройках сервера или клиентских машин.

Шаг 3. Проверка настроек на стороне сервера

Если Aladdin Monitor ключ не видит или видит, но лицензии не раздаются, проверим сервер, в который физически установлен ключ.

1. Драйверы ключа защиты.

Конфликт версий драйверов — частая причина проблем. Рекомендуется выполнить полную очистку и переустановку:

  1. Скачайте последнюю версию командной утилиты для установки драйверов Sentinel HASP/LDK с официального сайта Thales (ранее Gemalto/Aladdin).
  2. Полностью удалите все установленные драйверы с помощью команды в командной строке, запущенной от имени администратора: haspdinst.exe -purge
  3. Перезагрузите компьютер.
  4. Установите драйверы заново с помощью команды: haspdinst.exe -i

2. Служба менеджера лицензий.

Убедитесь, что служба HASP License Manager (в старых версиях может называться Hasp Loader) запущена и работает в режиме автозапуска. Проверить это можно в стандартной оснастке "Службы" (services.msc).

3. Сетевые настройки и брандмауэр.

Менеджер лицензий HASP по умолчанию использует для обмена данными UDP-порт 475. Убедитесь, что этот порт не заблокирован брандмауэром Windows или любым другим антивирусным ПО как на сервере, так и на клиенте. Также проверьте, что сетевое оборудование (маршрутизаторы, коммутаторы) не блокирует UDP-трафик по этому порту.

4. Конфликт ключей.

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

Шаг 4. Настройка клиентских рабочих мест

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

  1. Найдите файл nethasp.ini в папке conf каталога установки платформы 1С на клиентском компьютере (например, C:\Program Files\1cv8\conf\).
  2. Откройте его в текстовом редакторе.
  3. Найдите секцию [NH_TCPIP].
  4. Убедитесь, что протокол TCP/IP включен для поиска ключа.
  5. Самое главное — явно укажите IP-адрес сервера, на котором установлен ключ. Это избавит систему от необходимости искать ключ широковещательными запросами, что часто не работает в сложных сетях.

Пример содержимого файла nethasp.ini:


[NH_COMMON]
NH_TCPIP = Enabled      ; Включаем использование протокола TCP/IP

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

После внесения изменений сохраните файл и попробуйте запустить 1С снова.

Шаг 5. Если ничего не помогает: аппаратная неисправность

Существует редкая, но возможная аппаратная неисправность, при которой USB-ключ "деградирует". Внутренняя логика, отвечающая за сетевую часть, выходит из строя, но базовая часть, позволяющая ему работать как локальный ключ, остается исправной. Это как раз и приводит к описанному в начале симптому.

Признаки аппаратной неисправности:

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

← На главную