Как ограничить количество сеансов пользователя в 1С

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

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

Важно понимать разницу между сеансом и соединением: один пользователь может держать несколько сеансов (например, тонкий клиент, веб-клиент и фоновое задание), и каждый из них отображается в консоли отдельно. Именно поэтому «глазами» за дублями следить сложно — нужен либо регламент, либо автоматика.

Как 1С учитывает сеансы и почему их становится слишком много

Сеанс создаётся при каждом подключении к информационной базе: запуск толстого или тонкого клиента, веб-клиента, COM-соединения, веб-сервиса, фонового задания. Один и тот же пользователь легко накапливает 3–5 сеансов, даже не замечая этого. Например, при аварийном закрытии клиента сеанс на сервере может остаться «висеть» до тайм-аута, а пользователь тем временем запускает новый.

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

Контроль сеансов через консоль кластера серверов 1С

В клиент-серверном варианте основной инструмент администратора — консоль управления кластером. Откройте оснастку «Администрирование серверов 1С Предприятия», раскройте нужный кластер, затем ветку информационной базы и пункт «Сеансы». Здесь видны все активные подключения: пользователь, приложение, время начала, длительность простоя, объём памяти.

Чтобы завершить лишний сеанс вручную, выделите его в списке и выберите «Удалить» в контекстном меню. Пользователь получит сообщение о разрыве соединения. Перед массовым удалением убедитесь, что не трогаете сеансы фоновых заданий и служебных подключений — их завершение может прервать обмены данными.

Для регулярного контроля полезно отсортировать список по колонке «Пользователь» и посмотреть, у кого сеансов больше одного. Если дубли появляются систематически у конкретных сотрудников, причина обычно в привычке закрывать клиент «крестиком» при обрыве связи либо в нестабильной сети — тогда ручной чистки недостаточно, нужна автоматика.

1. 1
   Откройте консоль «Администрирование серверов 1С Предприятия»
2. 2
   Перейдите: кластер → информационная база → «Сеансы»
3. 3
   Отсортируйте список по пользователю и найдите дубли
4. 4
   Проверьте колонку «Приложение» — не трогайте фоновые задания и служебные сеансы
5. 5
   Выделите лишний сеанс и удалите его через контекстное меню
6. 6
   Повторно откройте список и убедитесь, что остался один рабочий сеанс

Программное ограничение числа сеансов при входе

Наиболее надёжный способ ограничить пользователя одним-двумя сеансами — проверка при старте системы. В модуле сеанса или в обработчике ПриНачалеРаботыСистемы общего модуля можно получить список активных сеансов через ПолучитьСеансыИнформационнойБазы(), подсчитать сеансы текущего пользователя и при превышении лимита выдать предупреждение и завершить работу.

Пример логики: если у пользователя уже есть активный сеанс с тем же именем и он не входит в список исключений (администраторы, служебные учётные записи для обменов), новый сеанс завершается принудительно с поясняющим сообщением. Список исключений удобно хранить в константе или регистре сведений, чтобы не править код при каждом изменении.

Процедура ПриНачалеРаботыСистемы()
	ТекущийПользователь = ИмяПользователя();
	Сеансы = ПолучитьСеансыИнформационнойБазы();
	Счетчик = 0;
	Для Каждого Сеанс Из Сеансы Цикл
		Если Сеанс.ИмяПользователя = ТекущийПользователь Тогда
			Счетчик = Счетчик + 1;
		КонецЕсли;
	КонецЦикла;
	Если Счетчик > 1 Тогда
		Предупреждение("Превышен лимит одновременных сеансов");
		ЗавершитьРаботуСистемы(Ложь);
	КонецЕсли;
КонецПроцедуры

У этого подхода есть ограничения. В файловой базе ПолучитьСеансыИнформационнойБазы() возвращает только текущий сеанс, поэтому метод работает полноценно только в клиент-серверном режиме. Кроме того, код выполняется уже после создания сеанса, то есть кратковременно лишний сеанс всё же существует — для лицензионного учёта это обычно некритично, но для монопольных операций недостаточно.

Блокировка сеансов и установка монопольного режима

Отдельная задача — временно запретить новые подключения, например на время обновления конфигурации. В клиент-серверном варианте это делается в консоли кластера: свойства информационной базы → параметр «Блокировка начала сеансов включена». Можно задать сообщение для пользователей, время начала и окончания блокировки, а также код разрешения — строку, с которой отдельные пользователи (администраторы) смогут войти через параметр запуска /UC.

В файловом варианте аналог — установка монопольного режима через конфигуратор или функциональность типовых конфигураций («Администрирование → Обслуживание → Блокировка работы пользователей» в конфигурациях на БСП). Типовой механизм БСП также позволяет завершить активные сеансы по расписанию: пользователи получают предупреждение, а через заданный интервал их работа завершается.

Код разрешения блокировки храните отдельно от общего доступа: любой, кто знает его, обойдёт ограничение. После завершения работ не забывайте снимать блокировку — забытая блокировка с пустым периодом окончания станет причиной массовых обращений «не заходит в 1С».

Автоматическое завершение простаивающих сеансов

«Зависшие» сеансы — главный источник превышения лимитов. Бороться с ними можно двумя способами. Первый — настройки кластера: в свойствах рабочего процесса и информационной базы есть параметры, влияющие на время жизни соединений, а на уровне СУБД можно ограничить время простаивающих подключений. Второй — регламентное задание, которое периодически получает список сеансов и завершает те, у которых простой превышает порог, например 8–12 часов (за исключением фоновых заданий и служебных подключений).

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

Частые ошибки при ограничении сеансов

Самая распространённая ошибка — завершение всех сеансов подряд при чистке, включая фоновые задания и сеансы обменов. В результате прерывается синхронизация с другими базами, не выполняются регламентные операции, а причина сбоя ищется долго. Всегда фильтруйте список по типу приложения перед удалением.

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

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

Проверка результата и мониторинг

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

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

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