Как ограничить количество клиентских лицензий 1С на одном компьютере

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

В крупных организациях часто возникает ситуация, когда пул программных лицензий 1С стремительно истощается из-за того, что пользователи открывают одновременно по 5–10 различных информационных баз. При стандартной настройке сервера 1С:Предприятие каждая открытая база (каждый сеанс) поглощает отдельную лицензию. В результате 20–30 активных сотрудников могут полностью занять пул из 100 и более лицензий, блокируя работу остальным.

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

Почему сервер 1С тратит так много лицензий?

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

  1. Выдача лицензий сервером 1С: Сервер сам управляет пулом программных лицензий. В этом режиме на каждый запущенный экземпляр программы (каждое окно) тратится одна лицензия. Это удобно для работы через веб-клиент или при подключении по низкоскоростным каналам связи, но крайне невыгодно при работе в локальной сети.
  2. Получение лицензии клиентом самостоятельно: Клиентское приложение само ищет лицензию (на локальном ПК или в сети через HASP License Manager). В этом случае одна лицензия обычно выдается на одно рабочее место (один IP-адрес), независимо от количества открытых баз.

Рассмотрим подробнее способы ограничения и оптимизации этого процесса.

Решение 1: Программное ограничение через интерфейс RAS/RAC

Если бюджет ограничен и покупка дополнительных лицензий или КОРП-пакета не планируется, мы можем реализовать собственный механизм контроля. Для этого воспользуемся сервером администрирования 1С (RAS) и его консольной утилитой RAC.

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

Проанализируем пример логики, которую можно внедрить в модуль управляемого приложения (процедура ПриНачалеРаботыСистемы):


Процедура ПриНачалеРаботыСистемы()
    #Если Клиент Тогда
        ЛимитСессий = 3; // Устанавливаем желаемое ограничение
        ИмяКомпьютераКлиента = ИмяКомпьютера();
        
        // Вызываем серверную функцию для проверки через внешнюю компоненту или RAC
        КоличествоСеансов = ПроверитьКоличествоСеансовЧерезRAS(ИмяКомпьютераКлиента);
        
        Если КоличествоСеансов > ЛимитСессий Тогда
            Предупреждение("Вы открыли более " + ЛимитСессий + " баз. Пожалуйста, закройте неиспользуемые окна.");
            ЗавершитьРаботуСистемы(Ложь);
        КонецЕсли;
    #КонецЕсли
КонецПроцедуры

Для реализации функции ПроверитьКоличествоСеансовЧерезRAS системному администратору потребуется настроить службу ras.exe на сервере 1С. Скрипт на стороне сервера может выглядеть примерно так (пример для командной строки):

rac session --cluster=ID-КЛАСТЕРА list --infobase=ID-БАЗЫ | findstr /C:"host"

Важный момент: этот способ требует определенных навыков программирования и настройки прав доступа для выполнения внешних команд сервером.

Решение 2: Переход на аппаратные ключи и HASP License Manager

Многие специалисты считают этот метод наиболее оптимальным для локальных сетей. Аппаратные USB-ключи защиты позволяют использовать HASP License Manager (HLM).

Разберем, как это работает:


[NH_COMMON]
NH_TCPIP = ENABLED

[NH_TCPIP]
NH_SERVER_ADDR = 192.168.1.100 ; IP сервера с ключом
NH_TCPIP_METHOD = UDP

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

Решение 3: Использование функционала версии КОРП

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

Посмотрим на возможности КОРП:

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

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

Решение 4: Терминальный сервер (RDP)

Еще один архитектурный вариант — использование терминального сервера. Здесь есть важная техническая тонкость: если программные лицензии 1С активированы непосредственно на терминальном сервере как многопользовательские, то платформа считает лицензии "на терминальную сессию".

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

Однако будьте внимательны: этот метод требует наличия лицензий на сам терминальный сервер (RDS CAL), что может быть сопоставимо по стоимости с покупкой новых лицензий 1С.

Резюме и рекомендации

Мы проанализировали ситуацию и выяснили, что стандартная раздача программных лицензий сервером 1С — самый расточительный вариант. Чтобы ограничить выдачу лицензий, выберите подходящий путь:

Выбор конкретного метода зависит от текущей конфигурации вашей сети, бюджета и количества свободных ресурсов системного администратора.

← На главную