В процессе эксплуатации клиент-серверных версий 1С:Предприятия часто возникает ситуация, когда пользователи, имеющие собственные локальные лицензии (программные или USB), начинают «захватывать» многопользовательские лицензии с сервера. Это приводит к тому, что внешние пользователи, работающие через веб-клиент, не могут зайти в систему из-за нехватки свободных лицензий в серверном пуле. Разберем подробно, почему так происходит, какие методы решения существуют и какие ошибки категорически нельзя совершать при настройке кластера.
Проанализируем стандартный алгоритм поиска программной лицензии клиентским приложением (тонким или толстым клиентом). Платформа 1С выполняет поиск строго в следующем порядке:
.lic, установленный на компьютере пользователя (в профиле пользователя или в общих папках ProgramData).Проблема возникает в тот момент, когда по каким-то причинам платформа «пропускает» первые два пункта и сразу переходит к получению лицензии от сервера. Рассмотрим основные причины такого поведения:
%ProgramData%\1C\1CEStart.Часто у администраторов возникает идея создать в консоли сервера 1С две разные информационные базы, которые физически указывают на одну и ту же базу SQL (например, UT_Web с разрешенной выдачей лицензий и UT_Office с запрещенной). Это крайне опасный путь.
Разберем, почему нельзя подключать два инстанса базы к одной SQL-БД:
rmngr. Если две независимые службы 1С работают с одними и теми же таблицами SQL, они не знают о блокировках друг друга. Это неизбежно приведет к нарушению согласованности данных при одновременной записи.Рассмотрим безопасные и правильные способы решения проблемы.
Выясним причину, по которой клиент игнорирует локальный ключ. Часто это связано с устаревшими данными в сеансе. Проанализируем алгоритм очистки:
%AppData%\1C\1cv8 и %LocalAppData%\1C\1cv8).snccntx (хранилище контекста сеансов).После очистки платформа будет вынуждена заново пройти весь цикл поиска лицензии, начиная с локальных ключей.
Чтобы принудительно заставить Тонкий клиент искать локальную лицензию, мы можем использовать параметры запуска. В списке баз выберем нужную базу, нажмем «Изменить» и на последней закладке в поле «Дополнительные параметры запуска» пропишем настройки использования аппаратных ключей, если они есть:
/UseHwLicenses+
Или, наоборот, если мы хотим жестко ограничить поиск, убедимся, что файл 1cescmn.cfg в папке установки платформы содержит корректные настройки DistributeLicenses.
Посмотрим на ситуацию со стороны веб-клиента. Веб-клиент по своей природе не умеет работать с локальными программными лицензиями напрямую (через браузер), поэтому для него выдача лицензий сервером 1С обязательна.
Разберем стратегию разделения:
Тонкий клиент и активируем на их ПК однопользовательские программные лицензии. При открытии базы клиент сам найдет лицензию локально и не будет обращаться к серверу.Разрешить выдачу лицензий сервером 1С:Предприятия в значении «Да».Проанализируем ситуацию, если пользователи работают на терминальном сервере. В этом случае локальные программные лицензии должны быть установлены в режиме «На этот компьютер», чтобы они были доступны всем пользователям сервера. Если лицензия установлена «На пользователя», другие сессии её не увидят и пойдут за лицензией на сервер 1С.
Рассмотрим пошаговый план действий для стабилизации работы системы:
.lic в папке C:\ProgramData\1C\Licenses. Это обеспечит доступность лицензии для любого пользователя данного ПК.Важный момент: Если вы используете многопользовательскую программную лицензию на сервере, помните, что при выдаче лицензии сервером, она тратится на каждый сеанс (каждое окно 1С). Если же лицензию берет клиент, он тратит одну лицензию на один запуск ОС, независимо от количества открытых баз (в рамках одной версии платформы). Именно поэтому возвращение офисных сотрудников на локальные лицензии существенно экономит общий пул ключей.