Почему сервер 1С:Предприятие 8.3.11 продолжает раздавать лицензии после удаления файла nethasp.ini?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

При работе с многопользовательскими аппаратными ключами защиты HASP системные администраторы часто сталкиваются с неочевидным поведением платформы «1С:Предприятие». Особенно ярко это проявляется при обновлении платформы (например, на ветку 8.3.11) и переносе баз данных между тестовыми и боевыми окружениями. Классический сценарий: на одном сервере удаление конфигурационного файла nethasp.ini мгновенно приводит к потере лицензий, а на другом — сервер продолжает бесперебойно работать и раздавать лицензии клиентам через веб-сервер. В этой статье мы подробно разберем, как именно функционирует механизм поиска HASP-ключей в современных версиях 1С, и выясним истинные причины такого поведения.

Как платформа 1С ищет лицензии по умолчанию

Для начала проанализируем базовый алгоритм работы HASP-драйвера и сервера 1С. Когда файл nethasp.ini отсутствует в каталогах системы или в нем не заданы жесткие настройки, платформа не прекращает поиск лицензий. Вместо этого она переходит на настройки по умолчанию. Режим по умолчанию предполагает автоматический поиск менеджеров лицензий (HASP License Manager) в локальной сети.

Этот поиск осуществляется следующим образом:

  1. Выполняется широковещательный опрос (UDP Broadcast) по всей локальной сети через порт 475.
  2. Если в вашей локальной сети (в том же сетевом сегменте) запущен хотя бы один менеджер лицензий hasplm (служба nhsewice.exe) с активным сетевым ключом, он ответит на этот запрос.
  3. Сервер 1С успешно получит лицензию и передаст ее клиенту.

Таким образом, если боевой сервер находится в одном физическом или виртуальном сегменте сети (VLAN) с сервером лицензирования, удаление файла nethasp.ini никак не повлияет на работоспособность системы — поиск по умолчанию (Broadcast) успешно отработает за доли секунды.

Почему на тестовом сервере лицензии сразу «отвалились»?

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

Фактор кэширования настроек процессами сервера 1С

Еще один важнейший нюанс, который часто вводит администраторов в заблуждение, — это кэширование конфигурационных файлов рабочими процессами сервера 1С (rphost и rmngr). Проанализируем, как они работают с файлом настроек:

Файл nethasp.ini считывается процессами сервера 1С только один раз — в момент их инициализации (запуска). Если боевой сервер работает под постоянной высокой нагрузкой, его рабочие процессы могут не перезапускаться сутками. Когда вы удаляете файл nethasp.ini на «живом» сервере, процессы rphost продолжают использовать старые настройки, которые уже сохранены в их оперативной памяти. Изменения вступят в силу только после перезапуска службы ragent (Агент сервера 1С:Предприятия) или после планового перезапуска рабочих процессов по таймауту.

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

Множественные пути поиска конфигурационных файлов

Вы уверены, что удалили абсолютно все файлы nethasp.ini? Платформа «1С:Предприятие» имеет строго определенный приоритет каталогов для поиска файлов конфигурации HASP. Давайте разберем по шагам, где именно сервер 1С может находить дублирующие файлы настроек:

  1. Каталог конкретной версии платформы: C:\Program Files\1cv8\8.3.11.XXXX\bin\conf\nethasp.ini (или аналогичный путь для x86-версии в Program Files (x86)).
  2. Профиль пользователя операционной системы, под которым запущена служба Агента сервера 1С (по умолчанию это системная учетная запись USR1CV8): %USERPROFILE%\AppData\Local\1C\1cv8\conf\nethasp.ini.
  3. Общий каталог конфигурации платформы 1С: C:\Program Files\1cv8\conf\nethasp.ini.
  4. Каталоги, явно переопределенные в файле conf.cfg.

Если вы удалили файл из папки конкретного релиза, но забыли про общий каталог ...\1cv8\conf\ или профиль пользователя службы, 64-разрядный боевой сервер продолжит считывать настройки из этих резервных мест.

Локальное чтение ключей напрямую через драйвер

Не стоит забывать и о физическом расположении ключей защиты. Если многопользовательский клиентский ключ (красного цвета) или серверный ключ защиты подключен непосредственно к боевому серверу (физически в USB-порт или проброшен в виртуальную машину через USB-over-IP технологии), то сервер 1С может забирать лицензии напрямую через драйвер HASP Device Driver.

При таком сценарии служба HASP License Manager вообще не участвует в процессе, а файл nethasp.ini полностью игнорируется, так как он предназначен исключительно для управления сетевым поиском через протоколы TCP/IP или IPX.

Как правильно настроить nethasp.ini для стабильной работы

Чтобы избежать хаотичного поиска ключей в сети и сделать поведение серверов предсказуемым, мы рекомендуем жестко прописывать параметры подключения. Рассмотрим правильную структуру файла nethasp.ini, при которой широковещательный поиск отключается, а опрос идет строго по целевому IP-адресу:


[NH_COMMON]
NH_TCPIP = Enabled

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Укажите здесь IP-адрес вашего HASP License Manager
NH_PORT_NUMBER = 475
NH_TCPIP_METHOD = UDP
NH_USE_BROADCAST = Disabled

Параметр NH_USE_BROADCAST = Disabled критически важен. Он запрещает забивать локальную сеть лишними UDP-пакетами и гарантирует, что если указанный сервер лицензий (в нашем примере 192.168.1.100) недоступен, 1С не начнет хаотично забирать случайные лицензии из других ключей в сети.

Резюме и чеклист для диагностики

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

  1. Проверьте галочку «Разрешить выдачу лицензий сервером 1С:Предприятия» в свойствах информационной базы в консоли администрирования кластера. Если она выключена, сервер вообще не будет заниматься раздачей клиентских лицензий, и все настройки nethasp.ini на стороне сервера станут неактуальными.
  2. Выполните поиск всех файлов с именем nethasp.ini на всем системном диске сервера, обращая особое внимание на папки профиля пользователя USR1CV8.
  3. Убедитесь, что после любых манипуляций с конфигурационными файлами вы производите полный перезапуск службы Агента сервера 1С (ragent), чтобы очистить кэш рабочих процессов.
  4. Для детального мониторинга используйте утилиту Aladdin Monitor. Она позволит наглядно увидеть, какой именно менеджер лицензий в сети отдает свободные слоты вашему серверу приложений.
← На главную