Ситуация, когда внешние соединения через V83.COMConnector внезапно перестают работать с ошибкой «Не найдена лицензия. Не обнаружен ключ защиты программы или полученная программная лицензия», является классической проблемой для распределенных кластеров 1С:Предприятие 8.3. Особенно часто это проявляется в конфигурациях, где менеджер лицензий вынесен на отдельный сервер или используется дополнительный менеджер кластера. В этой статье мы подробно разберем, почему возникает эта «плавающая» ошибка и как её устранить несколькими способами.
Прежде всего, проанализируем механизм поиска лицензии 64-разрядным COM-соединением. В отличие от обычного клиентского сеанса, V83.COMConnector, запускаемый на стороне сервера, имеет специфический порядок поиска:
Проблема заключается в том, что в версиях платформы 8.3.20, 8.3.21 и 8.3.22 был зафиксирован баг (например, ошибка 60004007), из-за которого COM-соединение «забывало» обратиться к пункту №4, если локальные ключи не найдены. Оно ограничивалось поиском локальных ресурсов и, не обнаружив их, выдавало исключительную ситуацию. Именно поэтому перезапуск службы 1С временно решает проблему: кэш лицензирования очищается, и соединение на какое-то время «вспоминает» правильный путь к серверу лицензий.
Рассмотрим метод, который позволяет обойти баг платформы путем выноса COM-соединения в отдельное адресное пространство операционной системы. Это заставляет 1С запрашивать лицензию не как «внутренний серверный процесс», а как полноценное клиентское приложение.
Разберем по шагам настройку COM+ на сервере приложений:
Console Root -> Component Services -> Computers -> My Computer -> COM+ Applications.1C_COM_Connector, и установим тип «Server application».USR1CV8). Это критически важно для доступа к программным лицензиям в папке ProgramData.Components и нажмем New -> Component.comcntrl.dll (обычно это C:\Program Files\1cv8\8.3.XX.XXXX\bin\comcntrl.dll).После этой настройки V83.COMConnector начнет потреблять обычную клиентскую лицензию. Проверить это можно в консоли администрирования 1С в списке сеансов: в колонке «Лицензия» вместо «Сервер» появится «Клиент».
Проанализируем топологию вашего кластера. Если основной сервер приложений (Server1) постоянно обращается к дополнительному менеджеру (Server2) только за лицензией, это создает лишнюю точку отказа. Рассмотрим вариант переноса файла серверной лицензии (.lic) непосредственно на Server1.
Выясним преимущества этого подхода:
Важно: При переносе лицензии убедитесь, что у пользователя USR1CV8 на Server1 есть полные права на папку C:\ProgramData\1C\1cv8\ и файл 1cv8conn.pfl. Если этот файл заблокирован или недоступен для записи, механизм лицензирования может давать сбои.
Иногда задержка при поиске лицензии вызвана тем, что COM-коннектор долго пытается опросить несуществующие менеджеры лицензий HASP по всей сети. Чтобы ускорить этот процесс и исключить ошибки таймаута, рекомендуется явно настроить файл nethasp.ini на сервере приложений.
Отредактируем файл (путь: C:\Program Files\1cv8\conf\nethasp.ini):
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 127.0.0.1 ; если ключей HASP нет вообще
NH_USE_V6 = Disabled
NH_TCPIP_METHOD = TCP
NH_SESSION_HOOK = Enabled
Это заставит систему быстрее проходить этапы поиска сетевых ключей и переходить к запросу программных лицензий у кластера.
Если проблема сохраняется, настроим сбор технологического журнала для анализа процесса лицензирования. Это поможет увидеть, на каком именно этапе прерывается поиск. Создадим файл logcfg.xml в папке conf:
<config xmlns="http://v8.1c.ru/7.4/config">
<log location="C:\LOGS\LICENSE" history="24">
<event>
<eq property="name" value="HASP"/>
</event>
<event>
<eq property="name" value="LEVENT"/>
</event>
</log>
</config>
Обратим внимание на события LEVENT — в них фиксируются все попытки обращения к программным лицензиям и причины отказов. Если в логах фигурирует запуск процесса dllhost.exe, значит, ваша настройка через COM+ работает корректно.
Подводя итоги, отметим, что наиболее эффективным и проверенным решением для обхода багов лицензирования COM в версиях до 8.3.23 является использование COM+. Это архитектурно изолирует процесс и стабилизирует получение лицензий. Однако в долгосрочной перспективе рекомендуется обновить платформу до актуальных релизов (начиная с 8.3.23.1912 и 8.3.24.1342), где механизмы взаимодействия менеджеров кластера были существенно переработаны для устранения подобных ошибок.