Несколько серверов лицензирования 1С: как закрепить нужную лицензию за конкретным сервером

16 мая 2026 · infolimp.ru

Автор: 1С Инсайдер · роль: практик 1С · проверка: типовые конфигурации и рабочие сценарии · 0 комментариев

В компании выросло хозяйство: один сервер 1С под продакшен, второй под тестовую среду, третий под обмен с маркетплейсами. Лицензии тоже выросли — КОРП на одном сервере, ПРОФ на остальных. И вдруг тестовый сервер раз в неделю «выхватывает» дорогую КОРП-лицензию, потому что она ближе по сетевому списку. ITSecurity ругается, бухгалтерия лезет уточнять, кто перекидывает лицензии. Знакомо? Разбираем, как объяснить кластеру лицензирования, какой именно сервер 1С имеет право на какую лицензию — и почему «оставить как настроилось по умолчанию» — это бомба замедленного действия.

Как rphost выбирает лицензию

Сервер 1С (рабочий процесс `rphost`) при необходимости лицензии идёт по своему списку серверов лицензирования, спрашивает: «есть свободная?». Первый ответивший «да» — выдаёт. Логика «по умолчанию» работает с одной ключевой особенностью: никто не следит, какая именно лицензия должна попасть на какой сервер 1С. Доступная — значит выдаётся. Раздаются обычно по порядку из списка серверов лицензирования.

Пока лицензии однотипные — это не проблема. Как только появляются разные типы (КОРП, ПРОФ, базовая) или разные ключи с разным числом подключений — порядок становится важен. Кто первым в списке — тот первым и получает.

Что обычно идёт не так

Сценарий	Симптом	Что чинить
Тестовый сервер берёт КОРП-лицензию	Дорогая лицензия занята тестовой средой, продакшен жалуется на нехватку	Явно указать тестовому серверу другой сервер лицензирования
Удалённый филиал лезет к лицензии центрального офиса	Лицензии «гуляют» между офисами, сетевая задержка съедает скорость	Назначить филиалу локальный сервер лицензирования
После обновления платформы сервер перестал видеть лицензии	Все сеансы получают сообщение о нехватке лицензий	Перепроверить пути конфигурации сервера лицензирования, кэш и порты
Бухгалтерская база делит лицензии с маркетплейсной	В пик отправки заказов на Ozon бухгалтерия не может войти в УТ	Разделить кластеры или явно зафиксировать лицензии

Как направить конкретный сервер 1С на нужную лицензию

Через конфигурационный файл клиента лицензирования

Каждый сервер 1С имеет файл настроек, в котором указано, к каким серверам лицензирования он обращается и в каком порядке. Этот файл — точка контроля: явно перечислите адреса серверов лицензирования, которым этот конкретный сервер имеет право подключаться, и порядок приоритета. Если в списке только один адрес — туда и пойдёт; если несколько — пойдёт по порядку до первого ответа.

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

Через центральный сервер лицензирования

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

// Диагностический фрагмент: показать в журнале регистрации,
// какой сервер 1С куда сейчас обращается за лицензией
// Запускать на проблемном rphost при подозрении на «уход» лицензии
ЗаписьЖурналаРегистрации(
    "Лицензирование.Диагностика",
    УровеньЖурналаРегистрации.Информация,
    ,
    ,
    "Имя сервера: " + ИмяКомпьютера()
        + "; пользователь: " + ИмяПользователя()
        + "; рабочий каталог: " + КаталогВременныхФайлов());

Сам факт лицензии этот код не покажет — лицензирование живёт в системных слоях платформы. Но три параметра контекста (имя машины, пользователь сеанса, рабочий каталог) помогают понять, на какой именно rphost пришёл пользователь, чьи сеансы вдруг получают «не свою» лицензию.

Через ролевое разграничение в кластере

Если у вас один сервер лицензирования и нужно ограничить доступ к лицензии только определённым кластерам — это делается в самой консоли администрирования сервера 1С. Каждому кластеру указываются разрешённые лицензии, и тестовый кластер не сможет «дотянуться» до продакшен-лицензии, даже если технически сервер лицензирования доступен.

Главное правило при разделении лицензий — все правила фиксируйте письменно и кладите рядом со схемой инфраструктуры. Через год при увольнении сетевого администратора никто не вспомнит, почему тестовый сервер ходит за лицензией в Москву через Уфу, и кто-то «упростит». Лицензии начнут гулять, расследование займёт неделю.

Чек-лист аудита лицензирования

Составить список всех серверов 1С в компании: продакшен, тест, обмены, филиалы.
Составить список всех серверов лицензирования и какие лицензии на них зарегистрированы.
Для каждого сервера 1С — определить, какие именно лицензии ему разрешено брать. Не «какие может», а «какие должен по политике компании».
Для каждого сервера 1С — открыть конфигурационный файл клиента лицензирования. Сверить, что список серверов лицензирования соответствует политике из пункта 3.
На центральном сервере лицензирования — проверить ролевые ограничения по кластерам.
Включить аудит выдачи лицензий: журнал регистрации события «сеанс не получил лицензию» и регулярный отчёт «сеансов с типом лицензии X в час по серверам».
Зафиксировать схему в документации: какой сервер 1С → какой сервер лицензирования → какая лицензия. Положить рядом с другими схемами инфраструктуры.

Типичные ошибки

«Один сервер лицензирования на всё». Кажется проще, по факту — точка отказа: сервер ушёл в ребут, вся компания не может войти. Минимум — пара серверов лицензирования с резервированием.
«Поставил, забыл, через год не помню». Через двенадцать месяцев настройка кажется правильной — пока однажды лицензия не «уплывает», и никто в команде не помнит, почему была такая конфигурация. Документация в виде схемы рядом с реальной инфраструктурой — обязательна, а не «когда-нибудь сделаем».
«Тестовый сервер настроили как продакшен». При создании тестовой среды скопировали конфигурацию с продакшена — и тестовый сервер ходит к продакшен-лицензии. До первого пика, когда продакшен в течение дня недополучает лицензии. Каждый новый сервер 1С — отдельный пересмотр прав на лицензию.
Без аудита. Лицензии гуляют между серверами, но это никто не видит, потому что в журнале регистрации событий лицензирования не настроено. Появляется проблема — расследовать нечего. Аудит включается заранее, не «после первого инцидента».
«Поправил конфиг — забыл перезапустить». Конфигурационный файл клиента лицензирования читается при старте процесса. Меняете значения — обязательно перезапускаете соответствующие службы; иначе изменения не вступают в силу, и появляется иллюзия, что «всё настроено правильно, но не работает».

Профессиональные решения для 1С и marketplace-интеграций — каталог отчётов и инструментов на витрине НОПи.

Перейти в каталог решений →