В практике администрирования систем на базе 1С:Предприятие часто встречается ситуация, когда внешнее соединение между двумя информационными базами обрывается с ошибкой «не обнаружило свободной лицензии / ключ защиты». Эта проблема особенно коварна в распределенных инфраструктурах, где задействовано несколько физических или виртуальных серверов. Давайте подробно разберем, как работает механизм лицензирования COM-соединений, и проанализируем пошаговый алгоритм поиска неисправности.
Прежде всего, нам необходимо усвоить фундаментальное правило: каждое COM-соединение потребляет одну полноценную лицензию 1С. Рассмотрим ситуацию, описанную в исходной проблеме: есть сервер А и сервер Б. Когда база, находящаяся на сервере Б, инициирует подключение к базе на сервере А, лицензия должна быть выделена именно на стороне сервера А.
Рассмотрим пример кода, который инициирует такое подключение:
ПараметрыСоединения = "Srvr=""ServerA"";Ref=""A_UP"";Usr=""Admin"";Pwd=""123"";";
V82Connector = Новый COMОбъект("V82.COMConnector");
Попытка
Соединение = V82Connector.Connect(ПараметрыСоединения);
Сообщить("Соединение успешно установлено");
Исключение
Сообщить("Ошибка подключения: " + ОписаниеОшибки());
КонецПопытки;
Проанализируем этот процесс: в момент вызова метода Connect система начинает поиск лицензии. Если подключение идет к серверной базе, поиск лицензии происходит в следующей последовательности: сначала на сервере приложений, затем (при определенных настройках) на клиентской стороне. Если на целевом сервере (в нашем случае сервер А) свободные лицензии отсутствуют или сервер не может их выдать, мы получим ошибку лицензирования.
Выясним причину, по которой сервер может «отказаться» выдавать лицензию COM-соединению. Одной из самых частых причин является выключенный флаг в настройках информационной базы. Разберем, как это проверить:
A_UP).Важный момент: если этот флаг установлен в значение «Нет», то сервер не будет использовать свои программные лицензии для обеспечения работы COM-сеанса. В этом случае система попытается найти лицензию на стороне «клиента», но так как клиентом в данном случае выступает другой сервер (Сервер Б), он может не иметь доступа к лицензиям сервера А. Всегда устанавливайте этот флаг в значение «Да» для баз, к которым планируются внешние подключения.
Часто проблема кроется не в самих лицензиях, а в технической невозможности инициализировать объект V82.COMConnector или V83.COMConnector. Это происходит из-за несовпадения разрядности службы сервера 1С и зарегистрированной в Windows библиотеки comcntr.dll.
Проанализируем ситуацию: если сервер 1С работает как 64-битное приложение, ему требуется 64-битная версия COM-соединителя. Если при этом в системе зарегистрирована только 32-битная версия (например, от тонкого клиента), возникнет ошибка. Проверим регистрацию компоненты через командную строку от имени администратора:
regsvr32 "C:\Program Files\1cv8\8.x.x.x\bin\comcntr.dll"
Рекомендуется выполнять регистрацию именно из того каталога конкретной версии платформы, которая используется как основная на сервере. Также убедимся, что в коде используется корректный идентификатор объекта: для платформы 8.2 это V82.COMConnector, для 8.3 — V83.COMConnector.
Рассмотрим подробнее, как программные лицензии (файлы .lic) считываются системой. Служба сервера 1С работает под определенной учетной записью (часто это USR1CV8). При COM-соединении процесс rphost должен иметь возможность прочитать файлы лицензий из папки C:\ProgramData\1C\licenses.
Проверим следующие настройки прав:
1C:Enterprise 8.3 Server Agent на сервере А, должен иметь права «Чтение» и «Просмотр содержимого папки» на каталог с лицензиями.Если в вашей инфраструктуре используются аппаратные USB-ключи HASP, то COM-соединение может не видеть их из-за ограничений сетевого поиска. По умолчанию менеджер лицензий ищется широковещательным запросом (broadcast), который часто блокируется маршрутизаторами между разными подсетями.
Разберем, как принудительно указать серверу, где искать ключ. Для этого отредактируем файл nethasp.ini, который обычно находится в папке conf установленной платформы. Нам необходимо раскомментировать и заполнить секцию [NH_TCPIP]:
[NH_COMMON]
NH_TCPIP = Enabled
[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; IP-адрес сервера, где установлен ключ
NH_TCPIP_METHOD = TCP
NH_USE_UDP = Disabled
Указав конкретный IP-адрес сервера А в настройках сервера Б, мы исключаем вероятность того, что COM-объект «потеряется» в сети при поиске ключа защиты.
Проанализируем ситуацию с точки зрения количественных лимитов. Даже если у вас есть 100 лицензий, они могут быть исчерпаны. Особенность COM-соединений заключается в том, что при некорректном завершении кода (например, аварийное завершение процедуры без вызова Соединение = Неопределено;) сеанс может «зависнуть» на сервере в статусе «Спящий».
Посмотрим, как это выявить:
Если мы видим множество старых сеансов от одного и того же пользователя, это явный признак утечки лицензий. В таком случае необходимо доработать код инициализации соединения, обязательно используя конструкцию Попытка...Исключение...КонецПопытки и явно обнуляя объект соединения в конце работы. Также проверьте настройки рабочего сервера: параметр «Максимальный объем памяти рабочих процессов» и «Количество сеансов на один процесс». При достижении этих лимитов сервер может выдавать ошибку лицензирования как наиболее общую, хотя проблема в нехватке ресурсов процесса rphost.
Подводя итог, если вы столкнулись с ошибкой «не обнаружило свободной лицензии» при межсерверном подключении, действуйте по следующему алгоритму:
ProgramData\1C\licenses.nethasp.ini.comcntr.dll нужной разрядности.Эти шаги позволяют решить проблему в 95% случаев, обеспечивая стабильную работу интеграционных механизмов вашей системы.