Почему пользователь на терминальном сервере теряет доступ к аппаратному ключу 1С?

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

Диагностика проблемы: с чего начать?

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

1. Анализ сообщения об ошибке: Если в окне ошибки вы видите сообщение Net Status=0, System Error=0, Warning=15, это означает, что файл nethasp.ini был прочитан корректно, но менеджер лицензий не смог выдать ключ.
2. Проверка приоритетов поиска: Платформа 1С использует файл конфигурации nethasp.ini для определения порядка обращения к ключам. Если этот файл содержит неверные параметры, поиск аппаратного ключа может быть принудительно отключен.
3. Проверка целостности настроек: Зачастую после обновления платформы настройки в каталогах C:/Program Files (x86)/1cv8/conf/ могут измениться или быть перезаписаны конфигурационными файлами по умолчанию.

Шаг 1: Проверка файла nethasp.ini

Самая распространенная причина «пропадания» ключа заключается в параметре UseHwLicenses. Если в конфигурационном файле установлено значение UseHwLicenses=0, платформа 1С полностью игнорирует аппаратные ключи HASP и пытается найти только программные лицензии. Если ваш сервер использует именно аппаратную защиту, это приведет к ошибке доступа.

Разберем, как правильно настроить файл nethasp.ini. Откройте его в текстовом редакторе (например, Блокнот) и проверьте следующие параметры:

[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 
NH_USE_BROADCAST = Enabled
[NH_NETHASP]
UseHwLicenses = 1

Убедитесь, что UseHwLicenses стоит в значении 1. После внесения изменений перезапустите сеанс 1С. Это действие часто решает проблему без необходимости удаления профиля пользователя.

Шаг 2: Влияние обновлений платформы на профили пользователей

Почему пересоздание профиля помогает временно? При обновлении платформы в локальном профиле пользователя (в папке AppData/Roaming/1C/1cv8 или AppData/Local/1C/1cv8) могут оставаться файлы кэша конфигурации и старые настройки nethasp.ini, которые «конфликтуют» с новой версией платформы. Мы рекомендуем:

• Очистить кэш 1С в профиле пользователя.
• Проверить ветку реестра HKEY_CURRENT_USER\Software\1C на наличие устаревших записей, если проблема повторяется у конкретного пользователя системно.
• Убедиться, что права доступа к папке conf, где лежит nethasp.ini, позволяют пользователю считывать этот файл.

Шаг 3: Сетевые таймауты и работа менеджера лицензий

Если параметры файла настроены верно, но ошибка сохраняется, проанализируем сетевую доступность HASP License Manager. Работа по протоколу UDP на порту 475 может быть ограничена антивирусным ПО или межсетевым экраном (Firewall) на терминальном сервере.

Посмотрим, как минимизировать сетевые задержки:

1. Укажите прямой IP-адрес сервера лицензий в параметре NH_SERVER_ADDR. Использование широковещательного запроса (Broadcast) не всегда надежно в сложных сетевых топологиях.
2. Проверьте, не «съедают» ли все лицензии другие пользователи или запущенные регламентные задания.
3. Если используется HASP LM, убедитесь, что служба запущена и не находится в состоянии критической нагрузки.

Шаг 4: Использование технологического журнала для глубокой отладки

Если описанные выше методы не помогли, настроим технологический журнал 1С. Это позволит увидеть на уровне платформенных вызовов, почему 1С не видит ключ. В файле logcfg.xml зададим фильтр:

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

Подводя итог, можно сказать, что решение подобных задач требует методичного подхода: от проверки простейших конфигурационных файлов до анализа сетевых протоколов. В 90% случаев проблема скрывается в некорректно заданных приоритетах поиска лицензий внутри nethasp.ini.