Как решить проблему нехватки лицензий 1С на терминальном сервере при наличии аппаратных ключей HASP?

← На главную

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

1. Анализ журнала поиска лицензий и настроек nethasp.ini

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

Например, в нашем случае, журнал поиска лицензий с клиента (как в сообщении 15) указывает на следующее:


Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия!
по причине:
Поиск лицензии на клиенте:
  Файл программной лицензии не найден
  nethasp.ini: C:/Program Files (x86)/1cv8/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORGL8 Сетевой, не установлен
  Файл программной лицензии не найден
  локальный ключ недоступен: Status=-10, ORGL8 Локальный, не установлен
  локальный ключ недоступен: Status=-10, ORG8A Локальный, не установлен
  локальный ключ недоступен: Status=-10, ORG8B Локальный, не установлен
  nethasp.ini: C:/Program Files (x86)/1cv8/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8A Сетевой, не установлен
  nethasp.ini: C:/Program Files (x86)/1cv8/conf/nethasp.ini, прочитан успешно, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=129, ORG8B Сетевой, не установлен
Поиск лицензии на сервере:
  Файл программной лицензии не найден
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORGL8 Сетевой, не установлен
  Файл программной лицензии не найден
  локальный ключ недоступен: Status=-100, ORGL8 Локальный, не установлен
  локальный ключ недоступен: Status=-100, ORG8A Локальный, не установлен
  локальный ключ недоступен: Status=-100, ORG8B Локальный, не установлен
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORG8A Сетевой, не установлен
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORG8B Сетевой, не установлен
Поиск лицензии в сервисе лицензирования:
  Файл программной лицензии не найден
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORGL8 Сетевой, не установлен
  Файл программной лицензии не найден
  локальный ключ недоступен: Status=-100, ORGL8 Локальный, не установлен
  локальный ключ недоступен: Status=-100, ORG8A Локальный, не установлен
  локальный ключ недоступен: Status=-100, ORG8B Локальный, не установлен
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORG8A Сетевой, не установлен
  nethasp.ini: отсутствует, использованы настройки по умолчанию, ошибка соединения с менеджером лицензий: Net Status=0, System Error=0, Warning=159, ORG8B Сетевой, не установлен

Этот журнал показывает, что клиент успешно читает nethasp.ini, но возникают ошибки соединения с менеджером лицензий (Net Status=0, System Error=0, Warning=159 и 129) для сетевых ключей ORGL8, ORG8A, ORG8B. Также видно, что локальные ключи недоступны. Это указывает на проблемы либо с сетевой доступностью менеджеров лицензий, либо с их настройками, либо с порядком поиска.

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

Протоколы связи: Для взаимодействия с HASP License Manager используем только протокол IPv4. Обращение всегда происходит по UDP, а параметр NH_TCPIP_METHOD со значением TCP программами 1С игнорируется. Нам необходимо явно отключить устаревшие протоколы и включить TCP/IP.
```
[NH_COMMON]
NH_IPX = Disabled
NH_NETBIOS = Disabled
NH_TCPIP = Enabled
```
Широковещательный поиск: Рекомендуется отключать широковещательный поиск (Broadcast) для повышения стабильности и производительности. Вместо этого мы будем явно указывать IP-адреса серверов с ключами. NH_USE_BROADCAST = Disabled
Явное указание IP-адресов серверов с ключами: Мы должны указать IP-адреса машин, где установлен HASP License Manager и куда воткнуты аппаратные ключи. Это делается с помощью параметра NH_SERVER_ADDR. NH_SERVER_ADDR = 192.168.1.10, 192.168.1.11
Здесь 192.168.1.10 и 192.168.1.11 - это IP-адреса виртуальных машин, куда проброшены наши ключи на 5 и 10 пользователей соответственно (согласно сообщению 5).

Проблема с суммированием лицензий от разных ключей

Мы выясним, что аппаратные лицензии HASP, воткнутые в разные машины (даже если это разные ВМ), не "суммируются" автоматически в единый пул. Более того, существует известная проблема: клиент 1С сначала ищет лицензию на первом указанном в NH_SERVER_ADDR сервере. Если этот сервер доступен, но лицензии на нем закончились, клиент не будет переходить ко второму серверу в списке. Он просто выдаст ошибку о нехватке лицензий, даже если на втором сервере есть свободные лицензии (сообщение 16).

Решение: Распределение настроек nethasp.ini для разных групп пользователей

Для того чтобы эффективно использовать оба ключа (на 5 и 10 пользователей) в нашей ситуации, когда они воткнуты в разные виртуальные машины, нам необходимо "разделить" клиентские потоки. Это можно сделать, создав разные файлы nethasp.ini для разных групп пользователей:

Для первой группы пользователей (например, 5-ти человек):
Нам необходимо создать или отредактировать файл nethasp.ini так, чтобы первым в списке был сервер с ключом на 5 лицензий, а вторым — с ключом на 10. [NH_COMMON] NH_IPX = Disabled NH_NETBIOS = Disabled NH_TCPIP = Enabled NH_USE_BROADCAST = Disabled NH_SERVER_ADDR = 192.168.1.10, 192.168.1.11 ; IP-адрес ВМ с 5-ю лицензиями, затем IP-адрес ВМ с 10-ю лицензиями
Для второй группы пользователей (остальные 10 человек):
Для этих пользователей nethasp.ini должен быть настроен так, чтобы первым в списке был сервер с ключом на 10 лицензий, а вторым — с ключом на 5. [NH_COMMON] NH_IPX = Disabled NH_NETBIOS = Disabled NH_TCPIP = Enabled NH_USE_BROADCAST = Disabled NH_SERVER_ADDR = 192.168.1.11, 192.168.1.10 ; IP-адрес ВМ с 10-ю лицензиями, затем IP-адрес ВМ с 5-ю лицензиями

Поскольку мы работаем на терминальном сервере, где файл nethasp.ini находится в папке с платформой 1С (например, C:/Program Files (x86)/1cv8/conf/nethasp.ini), и является общим для всех пользователей, нам необходимо продумать механизм его динамического применения. Возможны следующие подходы:

Различные установки платформы: Установить две разные версии (или просто две папки) платформы 1С на терминальном сервере, каждая со своим настроенным nethasp.ini. И затем создавать ярлыки для пользователей, указывающие на разные пути к платформе.
Использование скриптов: При входе пользователя в терминальную сессию или при запуске 1С, запускать небольшой скрипт (например, на PowerShell или VBScript), который будет копировать нужный nethasp.ini в папку conf платформы в зависимости от принадлежности пользователя к группе или его имени.

Также важно проверить файл nhsrv.ini на машинах, где установлен HASP License Manager и ключи. Убедитесь, что параметр NHS_USERLIST (максимальное количество клиентов, которым менеджер может выдать лицензии) достаточен. По умолчанию он может быть равен 250. При необходимости его следует увеличить. Также можно использовать параметр NHS_IP_LIMIT для ограничения списка IP-адресов, с которых разрешено подключаться к менеджеру лицензий, что повышает безопасность.

2. Устранение зависших лицензий

Одной из наиболее частых причин кажущейся нехватки лицензий является их "зависание" после некорректного завершения работы клиентского приложения. Это может происходить по нескольким причинам:

Аварийное завершение работы: При обрыве связи, принудительном завершении процесса или закрытии окна браузера (если используется веб-клиент) лицензии могут не освобождаться сразу.
Двойное потребление лицензий: Если клиент аварийно завершил работу, а затем подключился к другому менеджеру лицензий, он может занять вторую лицензию, при этом первая останется "висеть" (сообщение 20).
Таймаут HASP License Manager: Зависшие лицензии освобождаются самим менеджером лицензий только по истечении длительного таймаута, который по умолчанию составляет 36 часов с момента последнего обращения. До этого момента лицензию можно освободить только путем перезапуска HASP License Manager.

Разберем методы борьбы с зависанием лицензий.

1. Регламентный перезапуск HASP License Manager

Поскольку "зависшие" лицензии не освобождаются мгновенно, а ручной перезапуск службы при каждом инциденте неудобен, мы рекомендуем настроить регламентный перезапуск службы HASP License Manager (называемой также "hasp loader" или "Aladdin HASP License Manager").

Создание пакетного файла (батника): Нам необходимо создать простой .bat файл, который будет перезапускать службу.
```
net stop "HASP License Manager"
timeout /t 5 /nobreak
net start "HASP License Manager"
```
Мы используем команду timeout для небольшой задержки между остановкой и запуском службы, чтобы дать ей время корректно завершить работу.
Настройка планировщика заданий Windows:
Мы открываем "Планировщик заданий" (Task Scheduler) на каждой виртуальной машине, где установлен HASP License Manager. Затем создаем новое задание:
- Триггер (Trigger): Настраиваем его на ежедневный запуск, например, каждые 1-2 часа или раз в сутки в нерабочее время (например, в 3:00 утра). В сообщении 29 предлагается запускать его хоть раз в час.
- Действие (Action): Указываем путь к нашему .bat файлу.
- Общие (General): Устанавливаем флажок "Выполнить с наивысшими правами" (Run with highest privileges) и выбираем пользователя с правами администратора для выполнения задания.
Если ключи установлены на разных виртуальных машинах, мы рекомендуем сдвинуть время запуска батника на этих ВМ, например, на полчаса. Это поможет избежать одновременного короткого отсутствия всех лицензий и уменьшит вероятность конфликтов.

2. Настройка таймаутов спящих сеансов 1С

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

Для файловых баз, где нет сервера 1С:Предприятия, этот механизм менее актуален, так как лицензия удерживается непосредственно клиентом и менеджером HASP. Однако, в клиент-серверном режиме мы можем повлиять на поведение сервера 1С:

Открываем базу в режиме "Конфигуратор".
Переходим в меню "Администрирование" -> "Настройка информационной базы".
Находим параметры, связанные со спящими сеансами и отключением пользователей. Нам необходимо уменьшить время таймаута для неактивных сеансов, чтобы они быстрее закрывались и освобождали лицензии (сообщение 6). Конкретные параметры могут зависеть от версии платформы и типа базы.
Для кластера серверов 1С:Предприятия, мы можем настроить параметры рабочих процессов. Уменьшаем время удержания клиентских лицензий неактивными сеансами.

3. Проблема с процессом SplWOW64.exe

Еще одной неочевидной, но распространенной причиной зависания лицензий на Windows x64 терминальных серверах является процесс SplWOW64.exe (сообщение 23). Этот процесс запускается при печати из 32-разрядных приложений (таких как 1С:Предприятие) для взаимодействия с 64-разрядными компонентами Windows. По умолчанию, SplWOW64.exe может оставаться активным некоторое время после завершения печати для повышения производительности при повторных операциях.

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

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

Уменьшение таймаута завершения SplWOW64.exe:
Мы можем изменить значение таймаута через реестр Windows. Открываем "Редактор реестра" (regedit) и переходим по пути: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print

Создаем (если его нет) или изменяем параметр DWORD (32-бит) с именем SplWOW64TimeOut и устанавливаем его значение в 1 (или 0 для немедленного завершения). Это заставит процесс SplWOW64.exe завершаться быстрее после печати.
Добавление SplWOW64.exe в список процессов, завершаемых при завершении терминальной сессии:
Для того чтобы система принудительно завершала SplWOW64.exe при закрытии терминальной сессии, мы можем добавить его в специальный список реестра. Переходим по пути: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TerminalServer\SysProcs

Создаем (если его нет) или изменяем параметр DWORD (32-бит) с именем SPLWOW64.EXE и устанавливаем его значение в 0. Это укажет системе, что данный процесс должен быть завершен при завершении пользовательской сессии.

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

3. Особенности работы в виртуальной среде и альтернативы

Работа с аппаратными ключами HASP в виртуальной среде (например, Hyper-V) имеет свои нюансы, которые могут приводить к проблемам с доступностью лицензий. Мы рассмотрим эти особенности и возможные альтернативы.

1. Проброс USB-ключей в виртуальные машины

В нашем случае (сообщение 5) ключи проброшены в виртуальные машины. Это часто является источником дополнительной нестабильности. В некоторых гипервизорах (например, Hyper-V) отсутствует прямая поддержка USB-устройств. Приходится использовать сторонние утилиты (USB over Network, VirtualHere и т.д.) для проброса USB-портов с физического хоста в виртуальную машину.

Такой "проброс" добавляет дополнительные точки отказа: сетевое соединение между хостом и ВМ, стабильность работы самой утилиты проброса USB, драйверы USB в ВМ. Любой сбой в этом пути может привести к потере ключа, недоступности лицензий и зависанию сессий.

Мы выясним, что предложение вынести сервер лицензий HASP с виртуальной машины на обычную (сообщение 10) основано именно на этих соображениях стабильности.

2. Неразличимость ключей одной серии

Мы должны понимать, что не имеет смысла присоединять несколько аппаратных ключей HASP одной серии (например, несколько ORGL8) к USB-портам одного компьютера или пробрасывать в одну ВМ. Они будут неразличимы системой, и фактически будет задействован только один из них, а остальные просто не будут видны. Однако, если ключи разных серий (например, ORGL8 и ORG8A), они могут работать совместно и использоваться одним менеджером лицензий.

3. Альтернатива: Программные лицензии

Мы рассмотрим альтернативный вариант, который упоминается в обсуждении (сообщение 8) – обмен аппаратных ключей на программные лицензии. Программные лицензии являются более современным решением и решают проблему проброса USB-ключей в виртуальных машинах, поскольку они не требуют физического USB-ключа.

Преимущества программных лицензий:

Не требуется проброс USB-портов.
Меньше точек отказа, связанных с физическим оборудованием и драйверами.
Удобство развертывания в облачных и виртуальных средах.

Недостатки программных лицензий:

Программные лицензии жестко привязываются к параметрам компьютера (ОС, железо, сетевые карты, UUID виртуальной машины и т.д.), на котором они были активированы.
Изменение этих параметров (например, переустановка ОС, смена виртуального оборудования, клонирование ВМ) может привести к "слету" лицензии, требуя повторной активации или обращения в техподдержку 1С.
Количество резервных активаций ограничено.

Несмотря на то, что автор в сообщении 9 указывает, что "вариант обмена не рассматривается", мы считаем важным упомянуть это как возможное стратегическое решение проблемы в долгосрочной перспективе, особенно для виртуализированных инфраструктур.

4. Дополнительные проверки и рекомендации

Для обеспечения стабильной работы лицензий 1С мы также рассмотрим несколько дополнительных, но не менее важных моментов.

1. Выдача лицензий сервером 1С:Предприятия

Для клиент-серверных баз мы должны убедиться, что параметр "Разрешить выдачу лицензий сервером 1С:Предприятия" установлен в значение "Нет" (сообщение 25, сообщение 26). Если этот параметр установлен в "Да", то сервер 1С может сам выдавать лицензии, что может конфликтовать с HASP License Manager и приводить к некорректному распределению или зависанию. Для комфортной настройки параметров кластера и контроля сеансов можно применить альтернативную консоль администрирования кластера серверов 1С.

Для проверки и настройки этого параметра:

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

2. COM-соединения

Мы должны учитывать, что COM-соединения также потребляют лицензии 1С (сообщение 27). Если в нашей инфраструктуре используются сторонние приложения или сервисы, которые подключаются к 1С через COM-соединения, каждое такое соединение будет занимать одну клиентскую лицензию. Это может быть неочевидным источником потребления лицензий, особенно если таких соединений много или они не освобождаются корректно.

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

3. Диагностика и мониторинг

Для постоянного контроля и оперативной диагностики мы рекомендуем использовать специализированные инструменты:

Aladdin Monitor (HASP License Manager Monitor): Эта утилита позволяет увидеть, доступен ли HASP License Manager на определенном IP-адресе и какие ключи он "видит". Однако, мы должны помнить, что Aladdin Monitor увидит сам ключ только после того, как защищенное приложение откроет хотя бы одну сессию с ключом. Он работает по UDP на порту 475. Отсутствие данных о ключе в мониторе не всегда означает его недоступность.
Aladdin DiagnostiX: Этот инструмент предназначен для более глубокой диагностики работоспособности локальных и сетевых ключей HASP, позволяет настраивать их конфигурацию и генерировать отчеты, которые могут быть полезны для техподдержки.
1С:Предприятие – менеджер лицензий: Начиная с платформы 8.5.2, 1С постепенно отходит от HASP License Manager в пользу собственного менеджера лицензий. Этот новый менеджер поддерживает мониторинг лицензий с помощью стандартной обработки "Управление лицензиями", которая позволяет в режиме реального времени видеть, какие приложения и кто занимает лицензии. Мы должны рассмотреть возможность перехода на этот инструмент в будущем.

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

Мы должны удостовериться, что сетевые настройки наших серверов корректны:

Статический IP: На сервере (или виртуальной машине), где установлен HASP License Manager и ключ, должен быть настроен статический IP-адрес. Это обеспечит стабильность его обнаружения клиентами.
Брандмауэр (Firewall): Убеждаемся, что брандмауэр как на серверах с HASP License Manager, так и на клиентских машинах (терминальном сервере) разрешает прохождение UDP- и TCP-пакетов по порту 475 в обе стороны. Брандмауэр может блокировать обмен данными с менеджером лицензий, что приводит к ошибкам соединения.

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