← На главную

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

Анализ кода и внутренних механизмов 1С

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

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

Не забудем проверить состояние блокировок. Для этого проанализируем содержимое специализированных регистров. Выполним запрос к базе данных или воспользуемся консолью запросов:

ВЫБРАТЬ * ИЗ РегистрСведений.БлокировкиСеансовОбластейДанных

Если в этом регистре присутствуют записи с установленным временем начала, совпадающим с моментом вылета пользователей, значит, срабатывает механизм блокировки регламентных заданий или областей данных.

Проверка планов обслуживания SQL Server

Одной из наиболее частых причин принудительного разрыва соединений являются регламентные операции на уровне СУБД. Если вы используете Microsoft SQL Server, нам необходимо проверить Maintenance Plans (Планы обслуживания). Рассмотрим по шагам, как это сделать:

1. Запустим Microsoft SQL Server Management Studio (SSMS).
2. Перейдем в раздел Management (Управление) и выберем Maintenance Plans (Планы обслуживания).
3. Изучим расписание каждой задачи. Особое внимание уделим задачам «Reorganize Index», «Rebuild Index» или «Full Backup».

Часто в скриптах обслуживания прописывается предварительное переведение базы в Single User Mode или выполнение команд, сбрасывающих активные транзакции, что неминуемо ведет к обрыву сеансов 1С. Даже если бэкап настроен на другое время, длительные операции (например, проверка целостности базы) могут начинаться именно в 22:00.

Настройки кластера 1С и рабочих процессов

Выясним, не связано ли отключение с жизненным циклом рабочих процессов rphost. В консоли администрирования кластера 1С проверим параметры рабочего сервера:

• Интервал перезапуска: Если процессы настроены на перезапуск каждые 86400 секунд (24 часа), и сервер был запущен когда-то в 22:00, то каждые сутки в это время будет происходить ротация процессов.
• Выключенные процессы: Проанализируем параметр «Выключать через». Если процесс помечен как неисправный, сервер 1С дает ему время на завершение текущих вызовов, после чего принудительно «убивает» оставшиеся сеансы.

Диагностика со стороны операционной системы и Active Directory

Проанализируем настройки учетных записей пользователей в домене. Если сервер находится под управлением Active Directory, заглянем в свойства учетной записи пользователя на вкладку Account. Нажмем кнопку Logon Hours (Часы входа). Если там установлен запрет на работу после 22:00, Windows начнет принудительно разрывать сетевые сессии, что приведет к закрытию 1С.

Рассмотрим также Планировщик задач Windows (Task Scheduler). Нам нужно найти задания, запускающиеся в 21:55–22:05. Это могут быть:

• Скрипты (батники) для очистки временных папок Temp. Если скрипт удаляет файлы, занятые сеансом 1С, приложение аварийно завершается.
• Системы стороннего резервного копирования (Veeam, Acronis), которые используют технологию VSS (Shadow Copy). В момент создания теневой копии происходит кратковременная заморозка операций записи, что может быть критично для толстого клиента. Чтобы исключить подобные сбои, для обслуживания инфраструктуры настраивают автоматическое архивирование и тестирование баз 1С по расписанию в тихом фоновом режиме.
• Антивирусное сканирование по расписанию, вызывающее пиковую нагрузку на дисковую подсистему.

Сетевые параметры и терминальный доступ (RDP)

Если пользователи работают через удаленный рабочий стол, проверим настройки Групповых политик (GPO). Перейдем по пути: Конфигурация компьютера -> Административные шаблоны -> Компоненты Windows -> Службы удаленных рабочих столов -> Узел сеансов удаленных рабочих столов -> Ограничения сеансов по времени.

Убедимся, что не установлены жесткие лимиты на длительность активной или бездействующей сессии. Также стоит проверить параметры Keep Alive в реестре Windows, чтобы исключить обрыв соединений из-за простоя сетевого оборудования (роутеров или файрволов), которые могут сбрасывать сессии по таймауту.

Рекомендация по финальной диагностике

Для того чтобы точно определить виновника, выполним следующий алгоритм действий:

1. В 21:59 откроем Event Viewer (Просмотр событий) на сервере 1С и сервере СУБД.
2. Отфильтруем журналы System и Application.
3. Сравним время появления записей в журналах Windows с временем «Завершения сеанса» в журнале регистрации 1С.
4. Если мы увидим события от службы TerminalServices-LocalSessionManager или ошибки DistributedCOM, значит, корень проблемы лежит в настройках операционной системы, а не в коде 1С.

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