Как настроить приоритет использования локальных лицензий 1С и избежать дефицита серверных ключей

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

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

Почему локальные пользователи забирают серверные лицензии

Проанализируем стандартный алгоритм поиска программной лицензии клиентским приложением (тонким или толстым клиентом). Платформа 1С выполняет поиск строго в следующем порядке:

  1. Локальный аппаратный ключ (USB), если в настройках запуска разрешен поиск HASP.
  2. Локальная программная лицензия — файл .lic, установленный на компьютере пользователя (в профиле пользователя или в общих папках ProgramData).
  3. Сетевой аппаратный ключ (HASP) через менеджер лицензий.
  4. Многопользовательская программная лицензия, установленная на компьютере сервера приложений (доступна через файл лицензии).
  5. Лицензия, выданная сервером 1С:Предприятия из своего пула (опция «Разрешить выдачу лицензий сервером»).

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

Риски при создании «дублей» баз в консоли сервера

Часто у администраторов возникает идея создать в консоли сервера 1С две разные информационные базы, которые физически указывают на одну и ту же базу SQL (например, UT_Web с разрешенной выдачей лицензий и UT_Office с запрещенной). Это крайне опасный путь.

Разберем, почему нельзя подключать два инстанса базы к одной SQL-БД:

  1. Конфликты блокировок: Менеджер блокировок каждого сервера (или инстанса базы) работает в оперативной памяти процесса rmngr. Если две независимые службы 1С работают с одними и теми же таблицами SQL, они не знают о блокировках друг друга. Это неизбежно приведет к нарушению согласованности данных при одновременной записи.
  2. Дублирование номеров: Механизмы автонумерации документов кэшируются на стороне сервера 1С. Два разных сервера выдадут одинаковые номера двум разным документам, что приведет к ошибкам при записи в SQL.
  3. Повреждение индексов: Полнотекстовый поиск и другие сервисные механизмы будут конфликтовать, пытаясь обновлять одни и те же служебные таблицы.

Рассмотрим безопасные и правильные способы решения проблемы.

Шаг 1. Очистка кэша и сеансовых данных

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

  1. Необходимо полностью очистить локальный кэш пользователя на рабочей станции (папки %AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8).
  2. Крайне важно очистить сеансовые данные на стороне сервера. Для этого можно использовать рекомендации по удалению временных файлов в каталоге snccntx (хранилище контекста сеансов).

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

Шаг 2. Настройка параметров запуска клиента

Чтобы принудительно заставить Тонкий клиент искать локальную лицензию, мы можем использовать параметры запуска. В списке баз выберем нужную базу, нажмем «Изменить» и на последней закладке в поле «Дополнительные параметры запуска» пропишем настройки использования аппаратных ключей, если они есть:

/UseHwLicenses+

Или, наоборот, если мы хотим жестко ограничить поиск, убедимся, что файл 1cescmn.cfg в папке установки платформы содержит корректные настройки DistributeLicenses.

Шаг 3. Использование разных типов клиентов

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

Разберем стратегию разделения:

Шаг 4. Особенности работы в терминальном режиме (RDP)

Проанализируем ситуацию, если пользователи работают на терминальном сервере. В этом случае локальные программные лицензии должны быть установлены в режиме «На этот компьютер», чтобы они были доступны всем пользователям сервера. Если лицензия установлена «На пользователя», другие сессии её не увидят и пойдут за лицензией на сервер 1С.

Итоговые рекомендации по настройке

Рассмотрим пошаговый план действий для стабилизации работы системы:

  1. Проверка установки: Убедитесь, что локальные лицензии на рабочих местах активированы корректно и платформа их видит (в окне «О программе» должно быть указано «Локальный программный ключ»).
  2. Консоль сервера: В консоли администрирования кластера для базы УТ оставьте включенной выдачу лицензий сервером (это нужно для веб-клиента).
  3. Оптимизация клиентских мест: На компьютерах локальных пользователей проверьте наличие файлов .lic в папке C:\ProgramData\1C\Licenses. Это обеспечит доступность лицензии для любого пользователя данного ПК.
  4. Мониторинг: Используйте консоль сервера (раздел «Сеансы»), чтобы отслеживать, кто именно забирает лицензии. В колонке «Лицензия» будет указано, выдана она сервером или получена клиентом самостоятельно.

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

← На главную