← На главную

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

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

Штатные возможности платформы и механизм внешнего управления сеансами (КОРП)

В стандартной поставке уровня ПРОФ встроенного механизма расстановки весов или приоритетов при выдаче лицензий сервером не предусмотрено. Сервер 1С выдает лицензии по принципу первой поступившей заявки. Однако для лицензий уровня КОРП существует специализированный инструмент — Сервис внешнего управления сеансами.

Проанализируем принцип его работы:

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

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

Разделение аппаратных ключей HASP и настройка параметров менеджера лицензий

Если на предприятии используются аппаратные USB-ключи защиты HASP, задачу можно решить на уровне сетевой топологии менеджеров лицензий:

1. Разделим общий пул на два физических ключа (например, ключ на 30 лицензий и ключ на 20 лицензий), установленных на разные хосты в сети.
2. На рабочих станциях приоритетного отдела настроим файл конфигурации nethasp.ini, явно указав IP-адрес сервера с ключом на 30 мест в секции NH_SERVER_ADDR.
3. Для неприоритетного отдела в nethasp.ini пропишем IP-адрес сервера с меньшим ключом.

Дополнительно на самом сервере лицензирования в файле nhsrv.ini менеджера лицензий можно задействовать параметр NHS_IP_LIMIT. Он позволяет жестко ограничить диапазоны IP-адресов, с которых разрешено запрашивать лицензии с конкретного ключа.

Обратим внимание на особенность расхода сетевых лицензий:

1. Если в свойствах информационной базы параметр Разрешить выдачу лицензий сервером 1С:Предприятия установлен в значение Нет, лицензии запрашиваются клиентом напрямую через HASP License Manager по схеме один компьютер — одна лицензия независимо от числа запущенных баз.
2. Если выдача лицензий возложена на сервер 1С, учет ведется по схеме один сеанс — одна лицензия.

Стратегия раздельной активации программных лицензий

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

1. Активируем однопользовательские лицензии локально на рабочих станциях сотрудников приоритетного отдела. В этом случае рабочее место гарантированно получает свою постоянную лицензию, привязанную к оборудованию ПК.
2. Оставшуюся часть пин-кодов активируем как многопользовательскую лицензию на сервере 1С или сервере терминалов для остальных пользователей.

Автоматизированное освобождение лицензий через регламентные задания или RAS/RAC

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

Разберем два варианта реализации такого контроля:

Вариант 1. Внутри базы с помощью регламентного задания. Фоновый процесс периодически анализирует общее количество активных сеансов через функцию ПолучитьСеансыИнформационнойБазы(). Если свободный остаток лицензий становится меньше заданного резерва (например, занято 49 из 50 мест), сеанс неприоритетного пользователя принудительно завершается методом Удалить(), освобождая место для сотрудника приоритетного отдела.

Вариант 2. Внешний скрипт администрирования через утилиту RAC. С помощью службы ras и консольной утилиты rac создается скрипт (на PowerShell или Python), который запускается по расписанию и контролирует весь кластер серверов. При приближении к лимиту скрипт находит сеансы пользователей неприоритетной группы и отключает их, не требуя внесения изменений в конфигурацию баз данных.

Ограничение на уровне терминального сервера (RDS)

Если работа пользователей организована через Remote Desktop Services (RDP), разграничение доступа проще всего выполнить средствами операционной системы. Для этого создаются раздельные группы пользователей или коллекции сеансов, где для неприоритетного отдела устанавливается жесткий лимит на количество одновременно открытых терминальных сессий. Это гарантирует постоянное наличие свободных ресурсов и лицензий для ключевых сотрудников.