Часто системные администраторы и специалисты 1С сталкиваются с парадоксальной ситуацией: программный комплекс успешно запускается, пользователи работают, но при попытке найти файлы лицензий (с расширением .lic) или получить информацию через утилиту ring, система выдает пустоту. Особенно это сбивает с толку, когда в справке "О программе" значится "Локальный HASP4", хотя физические USB-ключи в сервер не вставлены.
В данной статье мы подробно разберем, почему так происходит, как 1С на самом деле определяет способ защиты и где искать "невидимые" лицензии. Проанализируем ситуацию по шагам, чтобы вы могли точно определить: используется ли у вас официальная защита, аппаратный ключ или скрытый эмулятор.
Первым делом нам необходимо выяснить, какой именно тип лицензии видит платформа. Для этого откроем окно "О программе" и внимательно изучим раздел "Лицензия: Текущая".
Вариант А: Программная лицензия. Если в справке указано "Программная лицензия" и далее следует регистрационный номер (например, 810... или 801...), название организации и адрес — значит, 1С использует файлы .lic. В этом случае утилита ring должна их видеть (если они активированы в соответствующем реестре).
Вариант Б: Аппаратный ключ (HASP). Если вы видите надписи типа Локальный HASP4 ORGL8 5 или Сетевой HASP4 ORGL8 100, это означает, что платформа не ищет программные файлы. Она обнаружила ответ от аппаратного драйвера защиты или устройства. Если физического ключа (флешки-ключа) в сервере нет, значит, в системе работает эмулятор.
Рассмотрим подробнее, почему утилита ring license list может ничего не выдавать. Она предназначена исключительно для управления лицензиями нового образца. Если лицензия старая или аппаратная, ring будет бесполезна.
Если справка настойчиво пишет "HASP", а ключа в разъеме нет, давайте проанализируем систему на наличие эмуляторов. Они могут быть очень глубоко интегрированы и не отображаться в списке обычных служб Windows.
Выясним причину через Диспетчер устройств:
Virtual USB MultiKey, Virtual Bus Enumerator или Sentinel HASP Key.Также стоит проверить системный реестр. Проанализируем следующие ветки:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\haspflt
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emulator
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Emu
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\USB\VID_0529&PID_0001
Наличие этих веток при отсутствии ключа прямо указывает на использование неофициальных методов обхода защиты.
Бывают случаи, когда эмулятора как отдельного устройства нет, но 1С всё равно "видит" лицензию. Это может означать, что сама платформа была модифицирована (пропатчена). Разберем, как это проверить.
Наиболее часто модификациям подвергается файл backbas.dll, который находится в папке bin установленной платформы. Рассмотрим алгоритм проверки:
C:\Program Files\1cv8\8.3.13.1644\bin\.backbas.dll.Именно поэтому при обновлении платформы 1С часто "теряет" лицензию: вы устанавливаете чистый backbas.dll, который не содержит механизмов обхода, и система начинает требовать легальный ключ.
Если вы уверены, что лицензии программные (официальные), но поиск *.lic по дискам не дает результата, давайте проверим скрытые и системные пути. Платформа 1С ищет файлы лицензий в строго определенном порядке.
Проанализируем основные места хранения:
C:\ProgramData\1C\licenses. Это самое распространенное место.C:\Program Files\1cv8\conf.1C:Enterprise Server Administration запущена от имени конкретного пользователя (например, USR1CV8), лицензия может лежать в его профиле: C:\Users\USR1CV8\AppData\Local\1C\1cv8\conf.Обратите внимание, что файлы могут иметь скрытый атрибут или права доступа могут быть ограничены так, что обычный поиск их "не зацепляет". Попробуйте зайти в эти папки вручную под правами администратора.
В случае с ERP и клиент-серверной базой, механизм выдачи лицензий может быть еще сложнее. Выясним, кто именно раздает лицензии — сервер или клиент.
Если в консоли администрирования серверов 1С у сеанса в колонке "Лицензия" указано "Сервер", значит, лицензию выдал менеджер кластера (процесс rmngr). Сервер 1С может использовать:
HASP License Manager.Посмотрим на файл nnhasp.ini. Он может находиться в папке bin\conf. Если в нем жестко прописан параметр NH_SERVER_ADDR = 127.0.0.1, платформа будет искать ключ только на локальной машине, игнорируя сеть. Если там прописаны другие IP-адреса, возможно, 1С "подхватывает" лицензию с другого сервера в вашей сети.
Интересный симптом был упомянут в обсуждении: база запускается в консольной сессии сервера, но не находит лицензию в терминальной. Это классическое поведение для локальных аппаратных ключей серии HASP4. По правилам лицензирования, локальный ключ (однопользовательский) "не виден" в RDP-сессии. Для терминала нужен либо сетевой аппаратный ключ, либо программная лицензия.
Если у вас именно так и происходит — это лишнее подтверждение того, что система пытается использовать аппаратную защиту (или её имитацию), а не программный файл .lic.
Подведем итог нашему анализу. Чтобы найти "исчезнувшую" лицензию, выполните следующие действия:
.lic искать бесполезно, ищите эмулятор или физический ключ.C:\ProgramData\1C\licenses. В 90% случаев официальные лицензии находятся там.Помните, что использование патченных библиотек (backbas.dll) рано или поздно приведет к ошибке "Обнаружено нарушение целостности системы", так как современные версии платформы 8.3 имеют встроенные механизмы проверки оригинальности кода.