Как сделать, чтобы сервер 1С перестал раздавать клиентские лицензии

· 9 мин

Содержание

Запретить выдачу лицензий сервером 1С можно для каждой информационной базы отдельно: в консоли администрирования серверов откройте свойства базы и снимите флажок «Разрешить выдачу лицензий сервером 1С:Предприятия». Из командной строки то же самое делает rac infobase update с параметром --license-distribution=deny. После этого клиенты этой базы берут лицензию сами — с локального ключа, локальной программной лицензии или сетевого ключа HASP.

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

Как сервер 1С раздаёт клиентские лицензии

В клиент-серверном варианте лицензию для сеанса может получить не только клиентский компьютер, но и сам кластер. Тогда пользователь занимает место из пула клиентских лицензий, установленных на сервере, а на его машине ключ не нужен.

Цепочка подключения такая:

  • 🔌 клиент обращается к агенту сервера (порт 1540);
  • 🧭 агент передаёт его менеджеру кластера (1541);
  • ⚙️ сеанс обслуживает рабочий процесс из диапазона портов, заданного в свойствах рабочего сервера (по умолчанию 1560-1591);
  • 🔑 если для базы разрешена выдача лицензий, кластер ищет свободную клиентскую лицензию на своих рабочих серверах.

Если лицензию выдал сервер, в консоли администрирования в списке сеансов будет видно, на каком сервере она получена. В rac это показывает rac session list --licenses.

Когда выдачу лицензий запрещают

  • 🧪 тестовые и учебные копии баз не должны расходовать серверный пул;
  • 💻 у части пользователей свои локальные или сетевые ключи, и их нужно заставить работать именно с ними;
  • 📊 вы проверяете, сколько реально нужно лицензий, и хотите видеть, кто работает на каком ключе;
  • 🏢 в кластере несколько рабочих серверов, а лицензии стоят только на одном.

Запрет действует только на клиентские лицензии. Серверная лицензия (на сам кластер) от этого флажка не зависит.

Шаг 1. Запрет выдачи лицензий в свойствах базы через консоль администрирования

Это основной и самый безопасный способ. Он затрагивает одну базу и не обрывает сеансы, которые уже получили лицензию.

  1. Запустите оснастку «Администрирование серверов 1С Предприятия» на сервере или на компьютере администратора.
  2. Раскройте дерево: Central 1C:Enterprise 8.3 servers → <имя сервера> → Кластеры → <кластер> → Информационные базы.
  3. Щёлкните правой кнопкой по нужной базе и выберите Свойства.
  4. Введите имя и пароль администратора информационной базы, если консоль их запросит.
  5. Снимите флажок «Разрешить выдачу лицензий сервером 1С:Предприятия».
  6. Нажмите OK.

Новые сеансы этой базы больше не получат лицензию с сервера. Уже открытые сеансы продолжат работать до выхода пользователя.

Как проверить, что запрет сработал

Сразу после смены флажка ничего видимого не происходит, поэтому проверку лучше сделать руками:

  1. Попросите одного пользователя закрыть программу и войти заново.
  2. В консоли откройте Информационные базы → <база> → Сеансы и найдите его новый сеанс.
  3. Посмотрите колонку с информацией о лицензии: у нового сеанса не должно быть лицензии, выданной сервером.
  4. Сравните со старыми сеансами, открытыми до изменения: у них серверная лицензия останется.

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

Что чаще всего путают

  • 🔁 Флажок в свойствах базы и флажок «Использовать аппаратную лицензию (ключ защиты)» в окне добавления базы в список на клиенте. Второй относится к поиску ключа на стороне пользователя и сервер не настраивает.
  • 🗂 Запрет для одной базы и для кластера. Флажок снимается у каждой базы отдельно; новая база, созданная позже, получит значение по умолчанию.
  • 🧾 Клиентские и серверные лицензии. Запрет не освобождает серверную лицензию и не позволяет запустить кластер без неё.

Если консоль не открывается

Оснастка регистрируется библиотекой radmin.dll из каталога bin установленной платформы. После обновления платформы консоль нередко перестаёт запускаться или видит не ту версию. Перерегистрируйте библиотеку нужной версии от имени администратора:

regsvr32 "C:\Program Files\1cv8\8.3.24.1548\bin\radmin.dll"

Номер версии в пути подставьте свой: он должен совпадать с версией платформы сервера.

Если в кластере заданы администраторы, консоль попросит их пароль при подключении к кластеру. Это отдельная учётная запись, не пользователь базы.

Шаг 2. Тот же запрет командой rac

Утилита rac удобна, когда баз много или нет графической консоли. Ей нужен запущенный сервер администрирования ras (по умолчанию порт 1545).

Сначала получите идентификаторы кластера и базы:

rac cluster list
rac infobase summary list --cluster=<uuid_кластера>

Затем запретите выдачу лицензий для базы:

rac infobase update --cluster=<uuid_кластера> --infobase=<uuid_базы> ^
  --infobase-user="Администратор" --infobase-pwd="пароль" ^
  --license-distribution=deny

Чтобы вернуть как было, выполните ту же команду с --license-distribution=allow. Проверить текущее значение можно через rac infobase info с теми же идентификаторами: в выводе есть строка license-distribution.

Если у кластера есть администратор, добавьте --cluster-user и --cluster-pwd. Полный список параметров для вашей версии платформы покажет rac help infobase.

СпособКогда удобенОграничения
Консоль администрированияодна-две базы, разовая настройканужен Windows и зарегистрированный radmin.dll
rac infobase updateмного баз, скрипты, Linuxнужен запущенный ras
Требования назначения функциональностикластер из нескольких серверовдействует на все базы кластера

Шаг 3. Какой рабочий сервер может выдавать лицензии

В кластере из двух-трёх рабочих серверов лицензии часто установлены только на одном. Чтобы остальные не пытались их выдавать, используют требования назначения функциональности.

  1. В консоли откройте Кластеры → <кластер> → Рабочие серверы → <сервер> → Требования назначения функциональности.
  2. Создайте новое требование.
  3. В поле типа объекта выберите «Клиентская лицензия».
  4. Тип требования — «Не назначать».
  5. Сохраните и повторите для каждого сервера, который не должен выдавать лицензии.
  6. На сервере с лицензиями создайте требование «Клиентская лицензия» с типом «Назначать».
  7. Примените требования командой контекстного меню кластера (в зависимости от версии платформы это «Применить требования» — частичное или полное).

Разница с флажком в свойствах базы простая. Флажок решает, выдаёт ли кластер лицензии для конкретной базы. Требования решают, какой сервер кластера этим занимается.

Если поставить «Не назначать» на всех рабочих серверах, кластер фактически перестанет выдавать клиентские лицензии всем базам сразу. Так делают редко: проще и прозрачнее снимать флажок у баз.

Шаг 4. Заблокировать новые сеансы и завершить текущие

Запрет выдачи лицензий не мешает пользователю войти, если у него есть свой ключ. Когда задача — вообще не пускать людей в базу (обновление, закрытие периода , перенос), нужна блокировка сеансов.

Блокировка в свойствах базы

В тех же свойствах информационной базы в консоли:

  1. Включите флажок «Блокировка начала сеансов включена».
  2. Задайте время начала и окончания блокировки.
  3. Напишите сообщение, которое увидят пользователи, например База закрыта на обновление до 20:00.
  4. Укажите код разрешения. Администратор сможет войти, добавив в строку запуска параметр /UC<код>.
  5. При необходимости включите «Блокировка регламентных заданий включена».

Аналог командой rac:

rac infobase update --cluster=<uuid_кластера> --infobase=<uuid_базы> ^
  --infobase-user="Администратор" --infobase-pwd="пароль" ^
  --sessions-deny=on --denied-message="База закрыта на обновление" ^
  --permission-code=12345 --scheduled-jobs-deny=on

Снять блокировку — та же команда с --sessions-deny=off и --scheduled-jobs-deny=off.

Блокировка из самой программы

В типовых конфигурациях на БСП (Бухгалтерия 3.0, ЗУП 3.1, УТ 11) есть обработка Администрирование → Обслуживание → Блокировка работы пользователей. Она ставит ту же блокировку и умеет завершать сеансы. В файловой базе блокировка оформляется служебным файлом 1Cv8.cdn в каталоге базы.

Удалять 1Cv8.cdn вручную, пока в базе кто-то работает или идёт обновление, не стоит. Снимайте блокировку той же обработкой или в Конфигураторе.

Принудительное завершение сеансов

Сеансы, которые уже получили лицензию с сервера, флажок не отключит. Их завершают вручную:

  1. В консоли откройте Информационные базы → <база> → Сеансы.
  2. Отсортируйте по колонке с лицензией или пользователю.
  3. Выделите сеансы, правой кнопкой — Удалить.

То же в командной строке:

rac session list --cluster=<uuid_кластера> --infobase=<uuid_базы>
rac session terminate --cluster=<uuid_кластера> --session=<uuid_сеанса>

Завершённый сеанс теряет незаписанные данные: открытый документ, недопроведённую обработку. Предупредите людей заранее и делайте это вне рабочего пика.

Завершать рабочий процесс rphost или перезапускать службу агента ради одной базы не нужно. Это оборвёт сеансы во всех базах, которые обслуживает процесс.

Шаг 5. Закрыть доступ к кластеру на сетевом экране

Сетевой экран не умеет различать «получить лицензию » и «просто подключиться». Он закрывает доступ к серверу целиком. Поэтому это инструмент для другой задачи: не пустить определённые компьютеры или подсети в кластер вообще.

Что закрывать в брандмауэре Windows или в правилах сетевого оборудования:

  • 🚪 входящий TCP 1540 — агент сервера;
  • 🚪 входящий TCP 1541 — менеджер кластера;
  • 🚪 диапазон рабочих процессов, по умолчанию 1560-1591;
  • 🚪 1545, если не нужен удалённый доступ к ras и rac.

Пример правила для Windows, которое разрешает доступ только подсети бухгалтерии:

netsh advfirewall firewall add rule name="1C cluster buh" dir=in action=allow ^
  protocol=TCP localport=1540-1541,1560-1591 remoteip=192.168.10.0/24

Для остальных адресов при этом не должно быть разрешающих правил на эти порты.

Если сервер СУБД стоит на другой машине, правила для него настраиваются отдельно. Закрытие портов 1С на сервере приложений не трогает порты PostgreSQL или MS SQL.

Сетевой ключ HASP

Если пользователи после запрета берут лицензию с сетевого ключа HASP, ограничение по адресам удобнее задать в файле nethasp.ini на клиентах (параметр NH_SERVER_ADDR с адресом сервера ключей). Тогда клиент не ищет ключ широковещательным запросом по всей сети.

Шаг 6. Включать и снимать запрет по расписанию

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

Пример bat-файла deny_license.bat:

@echo off
set RAC="C:\Program Files\1cv8\8.3.24.1548\bin\rac.exe"
set CL=<uuid_кластера>
set IB=<uuid_базы>
%RAC% infobase update --cluster=%CL% --infobase=%IB% ^
  --infobase-user="Администратор" --infobase-pwd="пароль" ^
  --license-distribution=deny >> C:\scripts\1c_license.log 2>&1

Второй файл allow_license.bat такой же, но с --license-distribution=allow.

Как поставить в расписание:

  1. Откройте «Планировщик заданий» Windows и создайте простую задачу.
  2. Триггер — ежедневно, например в 20:00 для запрета и в 07:00 для разрешения.
  3. Действие — запуск программы, укажите путь к bat-файлу.
  4. В свойствах задачи отметьте «Выполнять для всех пользователей» и укажите учётную запись с правами на запуск rac.
  5. Запустите задачу вручную и проверьте лог и вывод rac infobase info.

Пароль администратора базы в bat-файле лежит открытым текстом. Создайте для этих задач отдельного пользователя базы с административными правами и ограничьте доступ к каталогу со скриптами правами NTFS.

На Linux то же самое делается через cron, путь к rac обычно /opt/1cv8/x86_64/<версия>/rac.

Перед запретом выдачи лицензий
Выполнено: 0 / 5

Частые вопросы

Что увидит пользователь, если выдача запрещена, а своего ключа у него нет?
Платформа сообщит, что не обнаружила лицензию, и сеанс не начнётся. Работать без лицензии нельзя: исключение только учебная версия.
Отберёт ли запрет лицензии у тех, кто уже работает?
Нет. Флажок действует на новые сеансы. Уже открытые сеансы держат свою лицензию, пока пользователь не выйдет или администратор не завершит сеанс.
Нужно ли перезапускать службу сервера после изменения флажка?
Нет. Настройка применяется без перезапуска агента и рабочих процессов.
Можно ли запретить выдачу лицензий только части пользователей одной базы?
Флажком — нет, он действует на всю базу. Разделить пользователей можно через разные базы, сетевой экран или настройку ключей на их компьютерах.
Как проверить, откуда пользователь взял лицензию?
Откройте список сеансов базы в консоли администрирования или выполните rac session list --licenses. В выводе видно, выдана лицензия сервером или получена на клиенте.