Почему 1С перестает видеть КОРП-лицензии при наличии локальной лицензии и как это исправить?

Системный администратор 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← На главную

В процессе эксплуатации систем на базе 1С:Предприятие 8.3 системные администраторы часто сталкиваются с ситуацией, когда на одном рабочем месте необходимо совмещать работу в тяжелых конфигурациях (например, 1С:ERP или 1С:УХ), требующих КОРП-лицензий, и в локальных файловых базах (например, ФастФуд или Бухгалтерия), использующих базовые или ПРОФ-лицензии. Рассмотрим подробно, почему привычная схема работы может внезапно дать сбой и как восстановить работоспособность систем.

Разберем причину конфликта лицензий

Основная проблема заключается в алгоритме поиска лицензий платформой 1С:Предприятие. Проанализируем ситуацию: когда пользователь запускает локальную информационную базу, платформа находит файл программной лицензии (.lic) в стандартном каталоге C:\ProgramData\1C\licenses. Этот сеанс помечается как использующий лицензию уровня ПРОФ. Если после этого (или одновременно) пользователь пытается подключиться к базе на сервере КОРП, возникает конфликт.

Дело в том, что сервер 1С уровня КОРП часто использует функции, недоступные для ПРОФ-лицензий, такие как:

  1. Режим распределения нагрузки: настройка "Приоритет по производительности".
  2. Безопасный расход памяти: ограничение объема памяти на один вызов.
  3. Количество ИБ на процесс: управление количеством баз в одном рабочем процессе.

Если в настройках кластера включена хотя бы одна из этих функций (даже если значения стоят "по умолчанию", но платформа считает их активными), сервер требует от каждого подключающегося клиента лицензию уровня КОРП. Когда платформа уже "захватила" локальную ПРОФ-лицензию, она пытается предъявить её серверу, на что получает отказ с ошибкой: "Операция не может быть выполнена с текущим составом лицензий".

Выясним приоритет выбора лицензий платформой

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

  1. Локальная программная лицензия (файлы *.lic в профиле пользователя или в общих папках).
  2. Локальный аппаратный ключ защиты (USB-ключ, вставленный непосредственно в компьютер).
  3. Сетевой аппаратный ключ защиты (через HASP License Manager).
  4. Многопользовательская лицензия, выдаваемая сервером 1С:Предприятия.

Как мы видим, локальная программная лицензия имеет наивысший приоритет. Если платформа её нашла, она не будет запрашивать лицензию у сервера, что и приводит к ошибке при работе с КОРП-функциями.

Решение №1: Использование разных версий платформы и разнесение лицензий по папкам

Это самый эффективный способ разделить "сферы влияния" лицензий. Рассмотрим его по шагам:

1. Установим на компьютер пользователя две разные версии платформы. Например, версию 8.3.24.XXXX для локальных баз и 8.3.25.YYYY для работы с КОРП-сервером.

2. Переместим файл программной лицензии (.lic) из общей папки C:\ProgramData\1C\licenses в папку conf конкретной версии платформы, предназначенной для локальной работы. Путь будет выглядеть примерно так: C:\Program Files\1cv8\8.3.24.XXXX\bin\conf\.

3. В настройках запуска базы (в списке баз 1С) для локальной базы жестко пропишем использование версии 8.3.24.XXXX. Для серверной базы укажем версию 8.3.25.YYYY.

Теперь проанализируем результат: при запуске локальной базы платформа 8.3.24 найдет лицензию в своем каталоге bin\conf и успешно запустится. При запуске серверной базы платформа 8.3.25 не увидит лицензию в своем каталоге bin\conf (так как её там нет) и не найдет её в общей папке ProgramData. В результате она обратится к серверу , который выдаст ей необходимую КОРП-лицензию из общего пула.

Решение №2: Отключение КОРП-функций в кластере

Если специфика работы позволяет, мы можем привести настройки кластера к уровню ПРОФ. Рассмотрим, что нужно изменить в консоли администрирования серверов 1С:

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

Решение №3: Работа с файлом nethasp.ini и параметрами запуска

Если в вашей сети присутствуют "фантомные" или старые аппаратные ключи HASP (как было выявлено в процессе обсуждения темы), они могут вносить путаницу. Рассмотрим, как ограничить поиск ключей.

Для отключения поиска аппаратных ключей при запуске конкретной базы можно использовать параметр /UseHwLicenses-. Однако помните, что он влияет только на USB-ключи и не отключает поиск программных файлов .lic.

Для более тонкой настройки поиска сетевых USB-ключей отредактируем файл nethasp.ini. Разберем основные параметры:


[NH_COMMON]
NH_TCPIP = ENABLE

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; Указываем адрес конкретного менеджера лицензий
NH_USE_BROADCAST = DISABLE ; Отключаем широковещательный поиск

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

Проанализируем "Правило 10%"

Существует распространенное мнение о "правиле 10%", согласно которому в КОРП-кластере можно использовать до 10% ПРОФ-лицензий. Посмотрим на реальные условия его срабатывания: это правило работает только в режиме обратной совместимости, когда в кластере отключены все специфические КОРП-функции. Как только вы активируете хотя бы одну КОРП-настройку, проверка становится строгой, и 10%-й порог перестает действовать.

В завершение отметим, что внезапное проявление проблемы (как в случае с датой 23.07.2024) часто связано с автоматическим обновлением механизмов защиты через интернет-поддержку или проверку лицензионной чистоты, которая внедрена в современные релизы платформы 8.3.24/25. Рекомендуется заранее планировать распределение лицензий и избегать хранения файлов .lic в общих папках на машинах "смешанного" типа использования.

← На главную