Пользователи 1С: как считаются лицензии и подключения

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

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

Различие между списком пользователей и лицензиями

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

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

Существует важный нюанс для файловых баз: там ограничение часто задается на уровне количества одновременных подключений, прописанных в файле конфигурации или настройках хоста. В клиент-серверном варианте контроль жестче и осуществляется службой лицензирования hasp или программными ключами защиты. Поэтому наличие лишней записи в списке пользователей безопасно, а вот попытка 11-го человека зайти при наличии 10 лицензий приведет к ошибке доступа.

⚠️ Внимание: Фоновые задания и регламентные операции также могут потреблять клиентские лицензии, если они запускаются под конкретным пользователем в интерактивном режиме. Всегда проверяйте список активных сеансов перед диагностикой нехватки мест.

Механика работы клиентских лицензий

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

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

Для оптимизации распределения ресурсов администраторы часто используют механизм приоритетов. Критически важным сотрудникам (например, операционистам в банке или кассирам) можно выдать локальные ключи, чтобы они работали гарантированно. Остальной персонал будет использовать общий пул сетевых лицензий. Такой подход позволяет гибко управлять бюджетом и избегать покупки избыточного количества прав доступа.

• 🔑 Локальные лицензии привязываются к ID оборудования и не зависят от нагрузки на сервер.
• 🌐 Сетевые лицензии распределяются динамически между всеми подключенными узлами сети.
• ⏳ Лицензия может удерживаться «мертвым» сеансом до 30-60 минут при нестабильном соединении.

Серверные лицензии и их влияние на подключения

Помимо клиентских прав, в архитектуре клиент-сервер существуют серверные лицензии. Они определяют, сколько одновременных подключений может обработать сам сервер 1С:Предприятия. Если у вас есть 100 клиентских лицензий, но серверная лицензия рассчитана только на 50 подключений, то работать одновременно смогут не более 50 человек. Серверная лицензия является «потолком» пропускной способности системы.

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

В современных версиях платформы 1С:Предприятие 8.3 реализована гибкая модель лицензирования, где серверные лицензии могут масштабироваться. Однако, физическое ограничение все равно существует. При планировании инфраструктуры всегда закладывайте запас в 10-15% от расчетного количества пользователей для обеспечения стабильности в пиковые часы отчетности.

Что происходит при превышении лимита серверной лицензии?

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

Анализ активных сеансов и диагностика

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

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

Также стоит обращать внимание на тип клиента. Веб-клиент и мобильное приложение могут иметь свои особенности учета сессий. Например, при работе через веб-сервер сессия может оставаться активной дольше из-за особенностей протокола HTTP и настроек таймаутов веб-сервера (IIS или Apache). Проверка настроек пула приложений может помочь в освобождении зависших ресурсов.

Тип сеанса	Источник подключения	Особенности учета
Толстый клиент	Локальное приложение Windows	Удерживает лицензию до явного выхода или обрыва связи
Тонкий клиент	Локальное приложение или терминал	Стандартный механизм захвата лицензии
Веб-клиент	Браузер через веб-сервер	Зависит от таймаутов сессии веб-сервера
Внешнее соединение	COM/V8Connection	Требует отдельной лицензии на подключение

⚠️ Внимание: Принудительное завершение сеанса пользователя, который в данный момент проводит сложную обработку данных (например, закрытие месяца), может привести к повреждению данных или необходимости перепроведения документов.

Настройка ограничений и квот

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

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

Также существует возможность ограничения ресурсов на уровне процессов rphost. Хотя это не влияет напрямую на количество пользователей, это позволяет предотвратить ситуацию, когда один «тяжелый» пользователь монополизирует всю оперативную память сервера, замедляя работу остальных. Грамотная настройка квот памяти и времени процессора обеспечивает стабильность всей системы в целом.

Автоматизация контроля и скрипты

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

Пример простой логики для автоматизации: скрипт подключается к кластеру, получает список сеансов, фильтрует их по времени последней активности (например, старше 60 минут) и завершает те, что принадлежат пользователям из списка «разрешенных на авто-завершение». Это позволяет поддерживать пул лицензий в чистоте без постоянного вмешательства человека.

Для реализации таких задач часто используется внешний инструмент rac (Remote Admin Console). Это консольная утилита, позволяющая управлять кластером серверов 1С из скриптов (bat, sh, python). Она дает полный доступ к информации о сеансах, процессах и лицензиях, что делает её незаменимым инструментом для DevOps-инженеров, обслуживающих 1С.

rac session list --cluster=192.168.1.10 --cluster-port=1545

Использование таких команд в планировщике задач (Cron или Task Scheduler) позволяет реализовать политику «самоочищения» системы. Однако, важно добавить исключение для пользователей с привилегированными правами или тех, кто работает в режиме отладки, чтобы не прерывать их работу случайно.

Частые ошибки при подсчете пользователей

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

Часто администраторы забывают про лицензирование внешних подключений. Если к вашей базе 1С подключается сторонний сайт, мобильное приложение или система CRM через ODBC или COM-соединение, каждое такое подключение также требует клиентской лицензии. В высоконагруженных системах с множеством интеграций это может стать сюрпризом и причиной нехватки мест.

Также стоит учитывать особенности работы в терминальном режиме (RDP). Если 10 человек работают на одном сервере через RDP, каждый из них открывает свой процесс 1С и потребляет свою лицензию. Лицензия на терминальный сервер (Microsoft CAL) и лицензия 1С — это разные вещи, и одна не заменяет другую. Ошибочное мнение, что «сервер один, значит лицензия одна», приводит к нарушениям лицензионного соглашения.

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

Влияние обновлений на лицензии

При обновлении платформы до новой мажорной версии (например, с 8.3.20 на 8.3.25) старые ключи защиты могут потребовать перепрошивки или замены на программные пин-коды нового образца.

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

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

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

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

Сколько пользователей может работать одновременно в файловой базе?

В файловой версии 1С количество одновременных подключений ограничено настройками конкретной базы и версией платформы. Обычно это ограничение задается в файле 1SCV8.DAT или через параметры запуска. Стандартная конфигурация часто поддерживает до 5-20 подключений, но для стабильной работы более 5 пользователей настоятельно рекомендуется переход на клиент-серверный вариант.

Что делать, если закончились лицензии в самый неподходящий момент?

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

Влияет ли переход на новую версию 1С на количество лицензий?

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

Как проверить, сколько лицензий занято прямо сейчас?

Самый быстрый способ — использовать консоль управления кластером серверов 1С. В дереве объектов раскройте узел «Сеансы». Там будет отображен полный список активных подключений. Также можно воспользоваться утилитой командной строки rac с командой session list, что удобно для скриптов мониторинга.